When a government can switch off your AI model

On 12 June the US government handed Anthropic an export control directive. Within hours, Anthropic had disabled two of its models, Fable 5 and Mythos 5, for every customer it has. Not throttled or rate-limited. Switched off.

The directive itself was narrower than the result. It suspended access for any foreign national, inside or outside the United States, including Anthropic’s own overseas staff. To actually comply, Anthropic pulled both models for everyone, because it could not cleanly separate the foreign nationals from everyone else fast enough. If you are reading this from Toowoomba, you are one of those foreign nationals. So is every other Australian business that had built something on those two models. You broke no rule, missed no payment, did nothing at all, and your AI stopped working overnight.

Anthropic disagrees with the decision. Its statement says the government is worried about a jailbreak that involves asking the model to read code and point out flaws, which most capable models can do and which defenders use every day. The company is working to restore access, and it may well be sorted by the time you read this. That is not really the point.

The point is that it happened at all, and how little say anyone running those models had in it.

A dependency you cannot see until it bites

We have written before about vendor lock-in, usually about a SaaS tool that owns your data or an API gated behind a higher plan. This is the same problem in a much bigger coat. When your product calls a frontier model over an API, you are not only depending on a vendor’s pricing and uptime. You are depending on the political relationship between that vendor and its government, and you have no seat at that table.

This is not the first warning either. Back in February the US federal government told its own agencies to stop using Anthropic, and OpenAI picked up the Pentagon work soon after. Put the two events side by side and the lesson is hard to miss. Frontier AI is now close enough to national security that access can move for reasons that have nothing to do with you, your contract, or what you built.

What open models change

An open-weight model, the kind you can download and run yourself, does not have this failure mode. The weights already sit on your disk or in your own cloud account. No directive reaches in and deletes a file you already hold. The model you tested on Monday is the same model on Friday, because nobody outside your business can touch it.

That is the real argument for open source in AI, and it has little to do with ideology or saving money. It comes down to who holds the off switch. With a hosted frontier model, that is someone else, and right now you are watching how fast they can use it. With weights on your own hardware, it is you.

Open models are not a free lunch, and it would be dishonest to sell them as one. The best open-weight models still trail the best frontier models on the hardest tasks, and that gap is real if your product genuinely needs the top of the range. Running them yourself means you own the hosting, the inference bill, the security patching and the updates. Some licences that wear the word open come with field-of-use restrictions buried in the fine print, so it pays to read them rather than trust the label. For plenty of jobs a hosted frontier model is still the right tool, and we reach for one often.

So this is not a pitch to rip out every API and self-host the lot. It is a pitch to know which parts of your business could survive the morning Anthropic’s customers just had, and which could not.

How to hold your own off switch

Start by working out which parts of your product actually need a frontier model. Most features people wave the word AI at, like classification, extraction, tidying text or simple drafting, run perfectly well on a mid-tier or open-weight model. Save the expensive frontier calls for the genuinely hard work that needs them and you have already shrunk your exposure.

Put your own layer between your product and whichever model you call, so swapping one for another is a config change instead of a rewrite. This is the same integration discipline that stops any vendor owning your logic, pointed at models. If your code talks to the model through an interface you control, you can repoint it at a different provider, or at something you host, without unpicking the rest of the app.

Wire up a fallback and actually run traffic through it. A second provider you have never sent a real request to is a hope, not a backup. The teams that handled this outage best were the ones who could flip to another model and keep serving, a little slower or a little rougher, while everyone else refreshed a status page.

For anything you genuinely cannot afford to lose, prefer a model you can host. That is the whole case for private and on-prem AI: not only data staying in the country, but the model staying somewhere a third party cannot pull it. If a feature carries your revenue or your customers, an open-weight model you run is a steadier foundation than a frontier API you rent.

Keep the portable things portable too. Your prompts, your evaluation sets, the data you retrieved or fine-tuned against, the logs you debug with. Hold them somewhere you own, so moving between models is an afternoon and not a project.

The honest position

Frontier models from Anthropic and OpenAI are remarkable, and we build with them. For a lot of work they are the sharpest tool on the bench and the right choice. Using them is not the mistake. The mistake is building something your business leans on and quietly assuming the model behind it will always be there, on the same terms, because it always has been.

This suspension is a cheap lesson if you take it now and an expensive one if you wait for it to be your model next time. Spend an afternoon on the plain question: what breaks if your main model disappears tomorrow, and how fast could you be running on something else?

If you want help mapping that, the AI readiness assessment is a sensible start, or tell us what your product relies on and we will work through where the single points of failure actually are.