The model you build on is rented. Price the risk.
Author
Oleksandr Kotliarov
Date
July 15, 2026
Reading Time
7 min
On 12 June 2026, at 5:21pm Eastern, Anthropic’s two newest models stopped answering. Not degraded — gone, worldwide, on a US Commerce Department export-control order. Access returned on 1 July, the day after the order was lifted. Nineteen days.
The detail that should bother you is not the outage. It is that Anthropic didn’t choose the timing either. There was no SLA to invoke, no escalation path, no account manager who could fix it. A frontier lab with the most publicised safety commitments in the industry could not keep its own product switched on.
If your product had those models in its hot path, you had no move. You waited.
Most teams price this risk at zero
Ask an engineering leader what happens if their model provider changes the terms, and you will usually get some version of “we’d switch.” Ask how long switching takes and the answer gets vague, because nobody has measured it.
That vagueness is the risk. Model access is a dependency you do not control, and it moves on someone else’s schedule. It belongs on the same page as your payment provider and your cloud region — a thing that can be taken away, with a documented cost of losing it.
It usually isn’t taken away, though. Usually it just gets more expensive.
The trigger is the invoice, not the model
The failure mode people imagine is the model getting worse. The failure mode that actually shows up is the bill moving while the model stays exactly the same.
Cursor is the cleanest example. On 16 June 2025, Anysphere switched its Pro plan from a request cap to metered billing at API rates. Same models. Same output. Same product. Bills climbed overnight, and the company apologised on 4 July — “We recognize that we didn’t handle this pricing rollout well and we’re sorry” — and refunded the eighteen days in between.
The apology was sincere. The billing change stayed.
GitHub did the same thing a year later, at larger scale: usage-based billing announced on 27 April 2026, effective 1 June. About five weeks’ notice for a change that turned a listed subscription price into an “included credit value” rather than a ceiling, and removed the old fall-back-to-a-cheaper-model behaviour.
Neither of these was a model deprecation. Neither was a provider behaving badly. Both were unilateral changes to the economics of a dependency that teams had already built into their core loop — and in both cases the teams’ only move was to pay.
A note on the number people like to quote here: individual users reported bills going from $29 to $750, or $50 to $3,000. Those are user reports relayed secondhand, not published data, and I would not build an argument on them. The billing-mechanism change is documented. That is enough.
What “too deep” actually looks like
“Don’t over-index on one provider” is advice nobody argues with and nobody acts on, because it doesn’t say what to look at. Here is what to look at.
The model is in the hot path. A request from your user cannot be served without a call to that specific model. Not “we use AI for a feature” — the product’s core loop routes through it.
Your prompts are tuned to one model’s quirks. You have discovered, over months, that this model needs the instruction repeated at the end, or that it handles the JSON schema better if you put the examples first. That accumulated tuning is real work, and it is not portable. It is a switching cost you have been quietly paying down in the wrong direction.
You have no eval that can qualify a replacement. This is the one that decides everything. If you cannot answer “is this other model good enough for our task?” with a test rather than a vibe, then switching is not a decision you can make in a week. It is a research project.
You do not know your fallback. Ask the question cold: if this model went away this afternoon, which one would you move to? A team with a real answer names a model. A team without one names a strategy.

Any one of these is survivable. All four together and you are not a customer, you are a hostage — and the provider does not even have to be hostile for that to hurt you.
What actually protects you
Not “resilience.” Two concrete pieces of engineering, and one number to size them against.
A provider-agnostic seam. Model access sits behind an interface your application talks to, and swapping the provider behind it is a config change, not a rewrite. This is unglamorous, and it is the whole game. Sara Landi Tortoli of Polyweb puts the boundary well: “Your tools, memory, data layer, permissions, prompts, routing, and evaluations should sit outside the model and be designed independently from it.”
The seam costs you something. Provider-specific features — a particular cache mechanism, a structured-output mode, a tool-calling dialect — are exactly what you give up by refusing to depend on them. That is a real trade, and for some teams the speed those features buy is worth the exposure. Make it deliberately. The teams that got hurt in June had not made a trade; they had made an assumption.
An eval suite that can qualify a replacement in days. Not a benchmark. A set of cases from your actual product, with a pass bar you agreed on in advance, that you can point at a new model and get an answer from by Friday. Without this, the seam is decorative — you can swap the provider, but you cannot tell whether the swap made your product worse.
Now the number.
Anthropic’s contractual floor for retiring a model you already ship is 60 days’ notice, and their recent practice sits right at that floor. That is the routine case, the polite case, the case where everyone behaves well. Claude Opus 4 was retired about thirteen months after launch. Flagship models get roughly a year, not a decade.
And the export-control case gave zero.
So the test for any countermeasure is simple: can you execute it inside your provider’s own notice window? Sixty days if things go normally. Zero if they don’t. A plan that takes a quarter is not a countermeasure. It is a postmortem you have already scheduled.

What to do this week
Open your config and find the model name. If it appears in more than one place, or if it appears inside a prompt string, you have found your seam and it isn’t one.
Then write down the fallback. An actual model, from an actual second provider, with an actual account that has actual credentials in your secret store. Not a plan to open an account — an account.
Then run your evals against it. If you don’t have evals, that is the week’s work, and it is worth more than the seam: the seam without the eval lets you switch blind, and the eval without the seam at least tells you what you would be switching to.
You will not do any of this after the pricing email arrives. You will be too busy re-forecasting your margins.
References
- AI models can disappear overnight — is your engineering team built to survive it? — LeadDev. The framing piece, and the source for the practitioner quotes.
- Anthropic disabled Fable 5 and Mythos 5 after a US export-control order — Time, 13 June 2026. The 19-day shutdown, and the timeline.
- Model deprecations — Anthropic. The 60-day contractual notice floor, and the retirement dates behind the ~13-month flagship lifespan.
- Cursor apologizes for unclear pricing changes — TechCrunch, 7 July 2025. The metered-billing switch and Michael Truell’s apology.
- GitHub Copilot is moving to usage-based billing — GitHub, 27 April 2026. Five weeks’ notice; subscription price becomes “included credit value.”
WEEKLY NOTE
One note per week.
One short note from current work plus 2–3 outside links worth your time.
No spam. Unsubscribe anytime.
Oleksandr Kotliarov
Founder · Engineering Lead · Kraków, Poland
I build engineering teams that ship — from MVP to Series A delivery.