The model you depend on is rented

Most conversations about model choice are about capability and price. There is a quieter question underneath them, and it is the one that is hard to answer in a hurry: what happens to your operation on the morning the model is not there. Not because a data centre caught fire, but because the terms under which you were permitted to use it changed.

Eighteen days, by order

On 12 June 2026 the US Department of Commerce applied export controls to two of Anthropic's models, requiring that access be withheld from foreign nationals inside and outside the United States. The order took effect immediately, and with no reliable way to verify nationality in real time, Anthropic suspended both models for everyone. Commerce lifted the controls on 30 June, and access was restored globally the following day, roughly eighteen days after it stopped.

Restoration arrived with its own conditions. The model was included in paid plans for up to half of weekly usage limits only until 7 July, after which it moved to usage credits, and the more capable sibling came back for a set of US organisations rather than everyone. A new classifier blocks the flagged technique in over 99% of cases; triggered requests are notified and routed to an older model instead. The trigger for all of it was a safety report, and the remedy was a filter. But for anyone whose work depended on the model, the mechanism was beside the point. The capability was available on one day and gone the next, and the decision that removed it was taken in a room where they had no standing.

Retirement is scheduled, and it is the normal case

The dramatic version of this makes the news. The routine version sits on a documentation page. Anthropic publishes a model lifecycle in which a retired model is no longer available and requests to it fail, with at least sixty days' notice before retirement for publicly released models. The record bears it out: Opus 4.1 was deprecated on 5 June 2026 and retired on 5 August; Sonnet 4 and Opus 4 were deprecated in April and retired in June. The stated reason is capacity for new releases, which is an honest answer and not a reassuring one.

Anthropic is the example here because it documents the lifecycle openly and has committed to preserving old model weights. The transparency is what makes it quotable, and quoting the vendor that publishes its schedule is not the same as singling it out. The same page notes something easy to miss: partner platforms set their own retirement schedules, so the same model can have a different lifespan depending on which cloud you reach it through. Run one workload across two platforms and you are running two clocks.

The same risk, running the other way

The June order restricted who could reach a model after it was already public: a government on the buyer's side of the transaction, acting on a model built somewhere else. The same kind of decision can be made from the other side of it. Reuters reported in July 2026 that China’s Ministry of Commerce had held exploratory discussions with Alibaba, ByteDance and Z.AI about restricting overseas access to advanced Chinese AI models, including a proposed tiered regime that would put basic open tools under a simple filing, more advanced technology under security review, and frontier models under domestic-only use. The reporting is consistent that nothing has been decided, that the scope remains under discussion, and that the options sketched apply chiefly to future releases rather than withdrawing models already distributed. A separate public legal dialogue inside China has been debating adjacent questions, including whether open source is straightforwardly pro-competitive, and some commentators argue that dialogue should not be read as a preview of settled policy. We take no position on whether such restrictions should happen, or on how either debate should resolve. What the reporting establishes, at minimum, is that the assumption many organisations have been building on, that a frontier open-weight lineage will simply keep releasing its next generation on the same open terms as the last one, is not a technical fact. It is a policy choice, made in a jurisdiction where the organisation relying on it has no standing, exactly like the one that grounded a rented model for eighteen days in June.

One distinction matters here and is easy to lose in the headline. Weights you have already downloaded and deployed inside your own boundary keep working regardless of a later export decision; nothing reported would reach back and switch off a model you already run. What a restriction of this kind would remove is the next generation, not the last one. That makes it a renewal risk rather than an availability risk, a slower and quieter version of the same dependency, and no less worth writing down for arriving gradually instead of on one Thursday in June.

A fallback nobody has run is not a fallback

Swapping a model sounds like editing a string in a configuration file, and occasionally that is all it is. More often the system has quietly grown around the model it was built on. Prompts are tuned to its habits. Output parsing assumes its formatting. The evaluation suite was calibrated against its behaviour, so it measures agreement as much as correctness. Latency budgets were set by its speed, and the routing thresholds were chosen when it was the only candidate. A replacement that wins on every public benchmark can still be worse on your workflow, and nobody finds out which until it runs on real cases.

That is the true cost of the dependency, and it is payable either in advance or in an emergency. Paying in advance means keeping a second model exercised often enough on your own work that its results are known rather than assumed. It is not free, and it is a great deal cheaper than discovering the answer during the fortnight you do not have the first one.

The column missing from the register

A live register with a named owner against every AI system is the minimum for governing an estate, and where one exists the dependency column is usually the part left out. For each workflow that matters, it should record which model the workflow calls and through which platform, what degrades if that model is unavailable on Monday, what the declared alternative is, when the alternative was last evaluated against the same ground truth as the incumbent, and whose decision, commercial or governmental, ultimately controls whether the model keeps arriving on the terms the workflow was built around. We set out how we grade that whole picture, sole-sourced through to diversified, in grading model dependency risk.

None of this is an argument for building everything yourself or for staying away from frontier models, and it is equally not an argument against self-hosting an open-weight model to escape exactly this kind of dependency. Where the capability gap is real, renting it is usually the right call, and the choice between private and frontier deployment should still be made from the task rather than from anxiety. It is an argument for knowing precisely what you have rented, and what you are quietly depending on continuing to be given, even where nobody sends you an invoice for it. That is a modest amount of writing, and it turns a category of surprise into a category of decision: not which vendor or which government deserves your trust, but which parts of your operation could survive losing one supply, and what you are willing to spend so that the rest can.