Build like your model can be switched off on Friday.

A frontier model that was generally available on Thursday was undeployable on Friday. Not deprecated, not throttled. Switched off by government order, for everyone, with no notice.

I want to use that to make a larger point, because the revocation is not really the story. The story is what it exposed.

We are all renting our intelligence

We do not own these models, and we cannot.

The frontier models decisively outclass anything open source you could run on your own hardware. People argue the other side of this, and on narrow, specific tasks they have a point, some open models are genuinely competitive there. But on broad general capability the gap is real and it has not closed. When the work is open-ended and hard, the frontier is where you go.

And you cannot bring the frontier in-house. These models are large enough that the compute and inference cost of running them is beyond even the largest companies, never mind everyone else. Self-hosting a model of this class is not a budget line, it is a non-starter.

So we all reach these models the same way. From a third party, over an API. That is not a poor decision someone made and could unwind. It is the structural reality of the technology. You cannot engineer the dependency away. You can only decide how exposed it leaves you.

The dependency just bit

On the Friday evening of 12 June the US government issued an export control directive ordering Anthropic to suspend Fable 5 and Mythos 5 for any foreign national worldwide. There is no clean way to enforce “no foreign nationals” on a model served to hundreds of millions of people, so Anthropic complied the only way it could. It disabled both models for everyone.

Eight days earlier I had published a post built on Fable 5, describing how a single open-ended prompt had cleared two long standing problems. A model we were actively using was gone between a Thursday and a Friday.

This is the dependency from the section above, made concrete. Not a tail risk on a slide. A thing that happened, on someone else’s timetable, with no warning and no migration window. If a database engine or a cloud platform had been pulled out from under us like that, it would have been weeks of painful work. The interesting question is why it was not.

So be defensive, in three different ways

Since the dependency cannot be removed, the only rational response is to be defensive in how you build. Assume any given model can be taken away at any moment, and arrange things so that when one is, your work survives it.

What that looks like depends on who you are. I want to walk three kinds of user, because the principle underneath all three is the same. Keep the valuable thing, your knowledge, your architecture, your verification, separate from the model. Then the model stays a component you can swap, and never becomes a foundation you cannot.

The individual, keep your knowledge not your tool’s memory

Start with the person who lives inside Claude, ChatGPT or Gemini all day.

Every one of those tools is quietly accumulating context about you. Your style, your projects, your history, the way you like things done. It files all of it inside its own construct, the memory feature, the custom GPT, the Gem, the Project. That accumulated context is the valuable thing, and it is also the lock-in. When the model goes away, or you want to move, or it gets switched off on a Friday, the knowledge is trapped behind it.

The defensive move is to keep your knowledge in a portable substrate you own, not in any one tool’s memory.

Andrej Karpathy described a clean version of this earlier in the year, the LLM Wiki. The idea is his, not mine, and it is worth reading in full, but the shape is simple. Three layers, all plain markdown in a git repository. A collection of raw sources you curate and never edit. A wiki of interlinked pages that an LLM writes and maintains for you, summaries, entity pages, an evolving synthesis. And a schema file that tells the model how to keep the whole thing tidy. The model does the bookkeeping. You own the artefact. Any model can read it, because it is just markdown in a folder.

That is the entire trick. Your knowledge sits in files you control, and the model is pointed at them. Swap the model and the knowledge does not move.

We run the enterprise version of exactly this principle. Our agentic-rag platform maintains a living knowledge base for clients, an LLM keeps it current with feedback loops, contradiction detection and semantic patching, the same job Karpathy hands to the model over a personal wiki. The scale is different, the principle is identical. The knowledge is the asset. The model is a reader you can replace.

The team building agents, make the model a setting

The second kind of user builds agents for customers. This is where we can speak from direct experience.

We run two production agent systems for a coffee manufacturer, a green coffee buying expert and a financial expert. Both pull operational data from the business application, web data, and our own knowledge base of documents and interviews. Both let the end user choose which model to use, live, in the conversation interface, not just in some backend config file. We had added Fable support quickly after launch, because it was there and it was capable.

When the ban hit, we caught it on the Saturday morning. Over the weekend we removed Fable from the selection list. No production incident, no stuck users. We dropped the option and the systems carried on with the models that remained. The customer never knew.

The swap cost us almost nothing, and that is the part worth dwelling on. Most of the frameworks we build with let you change the model in a single line of configuration. There is some plumbing where providers differ, prompt caching interfaces in particular have to be reinstated per model, but it is minimal. Treating the model as a configuration variable costs almost nothing if you do it from the start. If you are not already doing this, that is a bug in your architecture, not a feature request.

I want to be honest about the one limit. The conversation context is managed by us and is stateful on our side, so a user can switch models between turns but cannot resume a single in-flight task on a different model. In practice nobody was mid-task, because we caught it before Monday. The prescription that falls out of that is simple. Do not make a single model choice load-bearing for a long-running task.

And here is the thing we did not plan. Model selection was never a resilience feature for us. It was a cost feature. Not every conversation needs the most powerful model, a simple lookup can run on a cheap one. We expose a token usage screen in almost everything we build, and most of it is bring-your-own-keys, so the cost lands directly with the customer. The primary lever we hand them is which model they use. We optimised for the customer not paying for capability they did not need, and that same lever is what absorbed a government order. Efficiency turned out to be resilience. They were the same architecture all along.

The developer, put your verification in gates not weights

The third kind of user is the developer, and this one hits everyone who writes code with these models, not just the ones running them in production.

Fable was genuinely better for agentic development. In the week we had it, the uplift in our own coding velocity was real, and losing it was painful. I am not going to pretend otherwise. But we did not get stuck, because the pipeline is the constant and the model is the variable.

Automated tests run before code is checked in. Broad security checks run as code reaches main. Automated code reviews run on every pull request. Structural artefacts are embedded in the code so a model can understand it quickly, the progressive constraint we apply to our own source. Our own automated penetration test runs after release. None of that verification lives in the model.

When Fable went dark we dropped back to Opus for the development work, and every gate kept running unchanged. We lost speed. We did not lose safety or quality, because neither ever lived in the model. The pipeline holds the line regardless of which model writes the code.

The honest caveat is that one gate is currently Claude Code Security, which is tied to Anthropic. The principle is provider-agnostic. The implementation is not fully there yet. Making that gate swappable is the obvious next step, and naming it is stronger than claiming an independence we do not yet have. This is the same methodology I described in security by obscurity is dead, and that gap is the part I am least comfortable with.

What this risk actually is

It would be easy to file the Fable revocation under freak event and move on. That would be a mistake.

The US government did not rule the model unsafe and pull it. It told Anthropic the model could not be supplied to foreign nationals. Anthropic said it could not enforce that selectively. So it disabled the model for everyone, as the only compliant path. That is an operational feasibility problem created by export control, not a safety failure and not really an Anthropic failure either.

And it has a sting in the tail for us specifically. The directive bars supply to foreign nationals worldwide. We are a UK company. If the order stands as written and Anthropic finds a way to enforce it selectively, the model comes back for US users and stays dark for us. The revocation we absorbed cleanly could become permanent for everyone outside the US.

The surrounding fight is loud and contested, and I am not going to adjudicate it. The government’s stated reason is a jailbreak that bypasses the safeguard separating Fable from the unrestricted capabilities of the Mythos model beneath it, and Commerce Secretary Howard Lutnick cited fears the models could be used by military intelligence in China, Russia or other countries of concern. Anthropic characterised the same jailbreak as a small number of previously known, minor vulnerabilities, relatively simple, and findable on other public models including OpenAI’s GPT-5.5, and warned that recalling a model on this basis would essentially halt all new model deployments across the industry. There is a separate, sharper claim from the administration’s side that Anthropic was warned and refused to fix the flaw, which Anthropic disputes. The company has sued to reverse the order, more than eighty security leaders including Alex Stamos have signed an open letter backing it, and at the time of writing Anthropic says it expects access back within days.

From the practitioner’s seat it does not matter whose fault it was. The model was available, then it was not, and your system either survived that or it did not.

What does matter is the structural fact underneath the noise. This is the first use of the Export Control Reform Act against a model. Export control is now an established lever over frontier models, and the China-access concern that drove it is not going away. This was not even the first rupture between this administration and Anthropic. A low-probability, zero-notice, total-loss event is exactly the kind you architect against. It is not the kind you ignore because it is rare.

Build like it can be switched off on Friday

The model will likely come back, though perhaps not for us. Anthropic expects restoration within days, and it is probably right about US access. But the directive bars foreign nationals worldwide, so reinstatement for American users could leave a UK company like ours exactly where the revocation left us. Either way, it does not return the lost time to the teams who had no fallback, and it does not unmake the precedent. The next directive has a template now.

This is the same thread I pulled on when SpaceX bought Cursor, that your tooling is a supplier and you should build to leave. That was commercial risk, a vendor changing the deal, and you could at least switch vendors. This is harder, because there is no stable vendor to switch to. Geopolitics does not have a competitor you can hedge into. The only hedge is architectural.

So before you ship anything on a model, ask one question. What survives if that exact model is switched off on Friday. If the answer is nothing, you have not built a product. You have rented one.

The fix is not a second model qualified and ready at extra cost. It is discipline you would want anyway. Keep your knowledge in a file you own. Make the model a setting. Put your verification in gates, not in weights.

We did not see this coming. We did not need to, because the architecture that made us efficient and correct also made us hard to switch off. Same capability for everyone. Different surrounding architecture. That is the whole difference.