A US government directive recently forced Anthropic to suspend access to Fable 5 and Mythos 5 for users in several foreign jurisdictions. Whatever you think of the policy rationale, the operational fact is striking: a frontier model that thousands of businesses had baked into production became unavailable to a class of users overnight, by order of a government that is not their own.
This is not a story about export controls being good or bad. It is a story about what procurement teams have been implicitly assuming when they sign up for frontier model access, and how those assumptions need to change.
The assumption we have all been making
When a team picks a model provider, the risk register usually contains things like: price increases, rate limit changes, model deprecation, accuracy regressions, data handling terms, uptime SLAs. These are vendor risks. They are negotiable, monitorable, and broadly familiar from the SaaS era.
What the Fable 5 and Mythos 5 suspension makes explicit is a category that has been sitting quietly underneath all of that: the assumption that the relationship between you and your model provider is a commercial one, governed primarily by contract.
It is not. It is a commercial relationship that sits inside a regulatory perimeter set by the provider's home government, and that perimeter can move without your provider's consent and without warning. Anthropic did not choose to suspend foreign access. They were directed to. The same applies to OpenAI, Google, and any other US-headquartered lab. It applies in reverse to providers headquartered in other jurisdictions with their own export regimes.
This is not new in principle — cloud customers have lived with sanctions exposure for years — but the dependency profile is different. Most SaaS substitutions are inconvenient. Substituting a frontier model that your product was tuned against, prompted against, evaluated against, and shipped against is something else entirely.
What actually breaks when access is cut
To think about this concretely, it helps to enumerate what a typical AI-native product is coupled to when it says "we use Mythos 5":
- Prompts tuned to that model's idiosyncrasies, including system prompts, few-shot examples, and chain-of-thought scaffolding.
- Evaluation suites whose pass thresholds were calibrated against that model's specific behaviour.
- Tool-use schemas that assume a particular function-calling format and a particular tolerance for ambiguity.
- Latency and cost models that underwrite the product's unit economics.
- Safety behaviours — refusals, jailbreak resistance, hallucination profile — that QA has signed off on.
- Fine-tunes or distillations built on top of base model access.
None of these port cleanly. Swapping Mythos 5 for a competitor of nominally equivalent capability is not a config change. In our experience it is typically two to six weeks of focused work for a serious production system, and that is when the substitute is genuinely close in capability. When it is not, you are looking at a product regression.
This is the real exposure. Not "our model went away" but "our model went away and the replacement takes a month to integrate and is measurably worse at the three things our customers most value."
What a sensible procurement position looks like
We do not think the answer is to avoid frontier models or to insist on running everything on open weights. That trades one set of risks for another, usually a worse one. The answer is to be deliberate about three things.
First, model portability as an engineering discipline, not an aspiration. This means writing prompts and tool schemas against an abstraction, maintaining a parallel evaluation harness that runs nightly against at least one alternative provider, and knowing — with numbers — what the regression looks like on each substitute. If you cannot answer "what happens to our quality if we switch to provider B tomorrow" with a chart, you do not have portability. You have a hope.
Second, jurisdictional diversity at the provider layer. For systems where continued operation matters, the alternative provider should not share a home jurisdiction with the primary. A US-headquartered primary with a US-headquartered fallback gives you redundancy against vendor failure but zero protection against a directive that targets both. This is the bit most procurement teams have not yet internalised. Resilience against export controls requires a provider whose government is not the one issuing the controls.
Third, an explicit position on which capabilities you are willing to degrade. Not every feature deserves the same protection. A coding assistant where the top model is meaningfully better than the alternatives may simply be accepted as US-frontier-dependent, with a documented degradation plan: if access is cut, the feature falls back to a weaker model and customers are told. A core workflow that the business depends on should not have that profile. Forcing this conversation produces a tiered architecture rather than a uniform one, and tiered architectures are what actually survive disruption.
The contractual layer is largely theatre
Procurement teams will be tempted to push this into contract clauses — uptime commitments, notice periods, geographic guarantees. We would not put much weight on this. No commercial contract overrides a government directive. The provider cannot promise you something they are not permitted to deliver. The most a contract can usefully do is clarify notification timelines, define what happens to data and fine-tuned artifacts on suspension, and establish credits. Useful, but not protection.
Protection lives in the architecture, not the paperwork.
What this means for AI-native builders
There is a broader implication worth naming. The era in which a startup could build its entire product on a single frontier model and treat that choice as a pure technical decision is closing. The choice now carries a geopolitical posture. Building exclusively on US-frontier models implicitly aligns your product's availability with US foreign policy. Building exclusively on Chinese open weights does the equivalent in the other direction. Neither is wrong, but both should be conscious.
For teams shipping into multiple jurisdictions — which is most of the interesting ones — the practical answer is a portfolio. A primary provider for capability, a secondary provider in a different jurisdiction for resilience, and an open-weights fallback running on infrastructure you control for the cases where the first two are unavailable or unsuitable. The cost of maintaining this is real. The cost of not maintaining it is now visible.
Our view
The Fable 5 and Mythos 5 suspension is not a one-off. It is a preview of how frontier AI will be governed: as strategic technology, subject to the same export logic that has applied to advanced semiconductors and cryptographic systems for decades. Anyone whose product roadmap assumes uninterrupted access to a specific frontier model, in a specific jurisdiction, on terms set by commercial considerations alone, is running an unhedged position.
The good news is that the engineering work required to hedge it is not exotic. Abstractions over model providers, parallel evaluation harnesses, tiered capability planning, and a deliberate choice of jurisdictionally diverse providers — these are tractable problems. The teams that treat them as procurement-led engineering work, starting now, will be the ones whose products keep running the next time a directive lands.