Your AI Has an Off-Switch. You Don't Hold It.

A model you reach through an API is not an asset. It's a dependency, and the off-switch sits outside your building. Most teams never think about this until the switch gets thrown. This month it got thrown, in public, on one of the most capable models in the world — and the lesson is the kind you don't want to learn during an outage.

On June 12 the US Commerce Department ordered Anthropic to disable Fable 5 and Mythos 5 for foreign nationals worldwide, citing a jailbreak technique. The model didn't crash. It didn't get deprecated on a roadmap. A regulator made a phone call and the most capable closed model on the leaderboard went dark for a large slice of the planet. As of last weekend it was still dark, with no restoration date. Anthropic disputed the finding and started negotiating. Doesn't matter for our purposes who's right. What matters is the mechanism.

If your production system was calling that model on June 11, here's what your team controlled on June 12: nothing. Not the timing, not the appeal, not the fallback. You found out when your traffic started erroring.

Three ways the lights go out

Strip this to fundamentals. When you build on a model you access but don't possess, the switch can get flipped three ways, and none of them route through you.

The vendor deprecates it. This is the routine one, and the one people underprice. A model you tuned your prompts and evals against gets a sunset date, and now you're re-validating an entire system against a replacement that behaves differently in ways you'll discover the hard way.

The vendor reprices it. Your unit economics are a guest in someone else's pricing meeting. Inference cost has been falling roughly 10x a year, which sounds like it only cuts your way — until the model you actually depend on gets moved to a premium tier while the cheap one gets capabilities you can't use.

And then the one nobody modeled: a government reaches in and pulls it. That wasn't on most risk registers in May. It's on them now.

Three different mechanisms. One shared property — the decision happens in a room you're not in, on a timeline you don't set.

The part that's actually interesting

Here's where it gets good. The same week the closed model went dark, Z.ai dropped GLM-5.2 — benchmarks on the 17th, the weights on Hugging Face under an MIT license, trained end to end on Huawei Ascend silicon with no NVIDIA hardware anywhere in the stack. Competitive with Western frontier models on coding and agentic work. And this is the line worth sitting with, straight from how people described it: once downloaded, no external party can revoke or monitor them.

Read that as an architectural property, not a political one. "Impossible to revoke" is a real, durable feature of a system, the same way "no single point of failure" is. The weights are on your disk. There is no API to throttle, no account to suspend, no directive that reaches your hardware. The off-switch moved inside your building. Nobody can phone your data center.

The performance gap that used to justify eating the dependency risk has mostly closed — Stanford's index put the best US-versus-China model spread at under three points. So the trade you're actually making is no longer "world-class capability with a leash" versus "a weaker model you own." It's much closer to even. And when the capabilities are close, control stops being a tax and starts being the differentiator.

Don't oversimplify it

Open weights are not a free lunch, and I'm not selling you a religion. The hosted API version of that same Chinese model carries its own data-exposure questions. Running weights yourself means you own the inference bill, the GPUs, the ops, the security patching — all the unglamorous work the API was renting you. The off-switch being in your hand also means the maintenance is in your hand.

So the answer isn't "open good, closed bad." The answer is: know where your off-switch lives, and price it into the architecture before you wire anything load-bearing to a single vendor's single model.

Concretely. Put an abstraction between your system and any specific model, so swapping one out is a config change and not a rewrite. Keep a real fallback path that you've actually tested, not a line in a doc. For anything genuinely critical, ask the uncomfortable question out loud: if this exact model vanished tomorrow morning, what's our Tuesday look like? If the honest answer is "we're down until the vendor comes back," you don't have a system. You have a hostage situation you volunteered for.

The model is a component. Components fail, get deprecated, get repriced, and — we now know — get pulled by people who've never seen your codebase. Build like the off-switch is in someone else's hand, because until you do the work to move it, it is.

Rent the capability if you must. Just don't be surprised whose name is on the breaker.

— Dustin