When a model can be switched off by Friday
4 min read
In June, two frontier models were pulled off the market by the US government inside a single month. The lesson is not political. It’s architectural.
What happened
On June 12, Anthropic disabled its two most capable models — Fable 5 and Mythos 5 — for every customer. It did so because the US government issued an export-control directive barring access by any foreign national, inside or outside the country. Because no provider can verify a user’s citizenship at the API layer, a restriction on some users functioned as a switch for all of them. Anthropic complied within hours and disputed the order. No end date was given. Every other Anthropic model kept working.
Roughly two weeks later, the pattern repeated in a softer form: OpenAI’s next flagship release reached the market as a government-shaped limited preview — access granted institution by institution — rather than as a general launch.
We are not going to tell you what either government action was for. The motive is contested, and a great deal of what is circulating about it is speculation dressed as reporting. What is verified is narrow and sufficient: a frontier model was launched, and within days it was rendered legally unusable for everyone, with no notice and no stated duration.
Verified vs. speculation
It is worth being precise, because the noise around this story is louder than the facts.
Verified: the suspension happened; it came as a government export-control directive; it took effect almost immediately; it was scoped to the top two models and left the rest of the lineup available.
Speculation: that the affected lab engineered the outcome to entrench itself; that the cited security concern was a pretext; that this is the opening move of a permanent licensing regime. These may turn out to be true. None of them is established. We mention them only to say: build your plans on the verified part.
The verified part is enough.
What it means for you
For most teams, the exposure is not that a model got worse. It’s that a capability your product depends on can become unavailable on someone else’s schedule — a vendor’s pricing decision, a regional outage, or now a government directive delivered on a Friday afternoon.
If your application calls one specific model by name, and that call sits on a path your users depend on, you have a single point of failure you did not choose and cannot control. The teams that felt nothing in June had one thing in common: the specific model was never load-bearing. They ran on the general, widely-available tier and treated the frontier SKU as an upgrade, not a foundation. The teams that scrambled had wired a named, bleeding-edge model directly into a critical path.
This is the same lesson the end of the AI subsidy era has been teaching from the cost side. Through the first half of this year, the economics of running agents at scale stopped being subsidized; the cheap, unlimited-feeling plans started metering the workloads that actually matter. The teams insulated from that shock were, again, the ones who had kept the model behind a boundary they controlled — so swapping to a cheaper option was a configuration change, not a rewrite. Availability risk and cost risk turn out to have the same mitigation.
What to do
Three moves, in order of urgency:
Put every model behind a boundary. Your application should ask for a capability — “summarize this,” “find the vulnerability,” “draft this component” — not for a model by name. When the call goes through a thin, vendor-neutral layer, switching providers is a config change. When it’s hardcoded, switching is a project. This is not exotic; it is the same discipline that made database abstraction normal twenty years ago, applied to a dependency that is now changing weekly.
Keep a default that you know will be there. Pick a conservative, broadly-available tier as your floor and prove your product works on it. Treat the frontier model as the version that makes things better, never the version without which things break. In June, the conservative default is the thing that kept working.
Make the system auditable. When a vendor can silently change a model’s behavior — or be ordered to pull it — the question “what did the model actually do for us last Tuesday?” should have an answer that doesn’t depend on the vendor’s word. An audit trail at the boundary is how you reason about a system whose upstream you no longer fully control.
None of this requires predicting where the policy lands. It requires assuming, correctly, that the thing you depend on can move.
Where we fit
This is the work we do. We build the boundary, choose the default, and stand up the audit trail — vendor-neutral, with no kickback from any model provider, so the recommendation is the recommendation. If June made you realize a named model is sitting on one of your critical paths, that is a half-day conversation worth having before it becomes an outage.
The models will keep changing on a schedule you don’t set. Your architecture doesn’t have to.