Plan for losing your model vendor

You picked a model, wired it into the thing that makes you money, and stopped thinking about it. That was the right call, right up until access changed for a reason that had nothing to do with you. Anthropic retired claude-opus-4 and claude-sonnet-4 on June 15, 2026, and claude-opus-4-1 on August 5, 2026 [2]. OpenAI announced on June 11, 2026 that older GPT-5 and o3 model snapshots, including gpt-5-2025-08-07 and o3-2025-04-16, shut down on December 11, 2026 [8]. Nobody did anything wrong in any of those cases. The exact endpoint you built against simply stops answering on a date somebody else picked.

The louder version of the same risk is political rather than technical. Anthropic does not list China, Hong Kong, Macau or Russia among the countries where its API and Claude.ai are available, and it reserves the right “to not provide its products or services to entities whose majority direct or indirect ownership is attributable to nations other than those listed in our Supported Regions Policy” [3]. OpenAI warns that “accessing or offering access to our services outside of the countries and territories listed below may result in your account being blocked or suspended” [7]. On November 13, 2025 Anthropic published its assessment of a threat actor “whom we assess with high confidence was a Chinese state-sponsored group” that had manipulated its Claude Code tool “into attempting infiltration into roughly thirty global targets”, with the attackers able “to use AI to perform 80-90% of the campaign” and human intervention required only sporadically, at “perhaps 4-6 critical decision points per hacking campaign” [5]. You had no seat at any of those tables and you still carry the consequences. This guide is about making the consequences survivable. It is not for teams self-hosting open-weight models, whose problems are different, and it is not an argument for leaving any particular vendor.

Access goes away in three ways, and only one of them is dramatic

The first way is scheduled. Models get deprecated, then retired, on published dates. Anthropic commits to “at least 60 days’ notice before model retirement for publicly released models” [2]. OpenAI commits to at least 6 months for generally available models, at least 3 months for specialized variants such as chat and Codex snapshots, and as little as 2 weeks for preview models [8]. Those are the numbers that decide whether a retirement is an afternoon of work or a bad quarter. If you are building on a preview model, you have agreed to 2 weeks of warning, whether or not you noticed.

Deprecation and retirement are also two separate dates, and the gap between them is not fixed. Anthropic deprecated claude-3-7-sonnet on October 28, 2025 and retired it on February 19, 2026, close to four months later. It deprecated claude-opus-4-1 on June 5, 2026 and retired it on August 5, 2026, two months later [2]. Both of those satisfy the same 60-day commitment. Plan against the commitment rather than against the most generous gap you happen to remember, and treat the deprecation notice, not the retirement date, as the day the clock starts.

The second way is jurisdictional. Both vendors publish a list of countries they serve and reserve the right to act on it [3][7]. Anthropic’s clause reaches past where you sit to who owns you: majority direct or indirect ownership attributable to an unlisted nation is grounds for refusal [3]. If you are a solo operator with one passport and one bank account, that is unlikely to touch you. If you took investment from a fund with opaque limited partners, or you have a co-founder who relocated, or your largest client resells your product into a market you never checked, it is worth ten minutes of your attention rather than none.

The third way is commercial, and it is the one that actually happens to small operators. Prices move, sometimes down. Claude Sonnet 5 sits at $2 per million input tokens and $10 per million output tokens, and a previously scheduled increase to $3 and $15 on September 1, 2026 did not take effect [1]. That is pleasant this year and tells you nothing about next year. The lesson is not that models are getting cheaper. It is that the number in your spreadsheet is a number somebody else edits.

Your lock-in is not the API call

The API call is the cheapest thing to move and the thing people worry about most. Anthropic publishes an OpenAI SDK compatibility layer: point an OpenAI client at https://api.anthropic.com/v1/, swap the key, and set the model to something like claude-opus-5 [6]. Three lines. If your mental model of switching vendors is “rewrite the integration”, the integration is not your problem.

What is expensive is everything wrapped around the call. Prompts tuned by hand against one model’s habits. Tool and function definitions shaped to one provider’s schema. A retry-and-fallback path that assumes a particular error taxonomy. Cached context you pay for once and reuse. Most of all, the absence of any way to tell whether a replacement model is doing the job as well, which means a switch turns into weeks of squinting at outputs and hoping.

There is also a quieter cost hiding in the tokenizer. Anthropic notes that Claude 4.7 and later models use a newer tokenizer that “produces approximately 30% more tokens for the same text”, and that Claude Sonnet 4.6 and earlier use the previous one [1]. Two models with identical published prices are not the same price for your workload. Any comparison you run on list prices alone will be wrong by an amount you cannot predict from the pricing page.

Price the switch while nothing is broken

Do the arithmetic once, in calm conditions, and write it down. You need three figures: what you spend now, what the nearest alternative would cost at the same volume, and what a smaller model from the same vendor would cost if the answer to a crisis is “downgrade rather than migrate”.

That third option is underrated. Within Anthropic’s own lineup the spread is wide: Claude Fable 5.1 at $10 and $50 per million input and output tokens, Claude Opus 5 at $5 and $25, Claude Sonnet 5 at $2 and $10, and Claude Haiku 4.5 at $1 and $5 [1]. Dropping one tier is a configuration change. Changing vendor is a project. If a price rise or a rate limit is the thing that hits you, the cheap move is usually vertical, not lateral.

Run it for your current model, then for the replacement, then for the tier below. If the three numbers are close, you have less exposure than you feared. If the replacement is triple, you have found a real dependency and you should know that now rather than on the morning it matters.

Four contract facts decide how bad a switch is

Most operators have never read the terms they clicked through, which is understandable and also the reason a routine vendor change turns into a scramble. Four things are worth knowing by heart.

Who owns the output. Anthropic’s commercial terms say the customer “retains all rights to its Inputs” and “owns its Outputs” [4]. That is the clause that lets you take a corpus of generated material with you.

Whether your work trains the model. The same commercial terms state that “Anthropic may not train models on Customer Content from Services” [4]. Check which agreement the account you actually use sits under, because that commitment is a term of the commercial contract rather than a property of the chat window you happen to be typing into.

How much notice you get. 60 days from Anthropic for publicly released models [2]; 6 months, 3 months or 2 weeks from OpenAI depending on the model’s status [8]. Write the shortest of these on the same page as your architecture notes.

Where you are allowed to operate. The published country lists, and the ownership-attribution language attached to them [3][7]. This is the clause nobody reads and the only one that can end access without a countdown.

Alongside those four, write one plain paragraph describing what leaves your machine. Not a policy document, just a description accurate enough that you could answer a client asking which of their material reaches a model, how long it sits there, and under which plan. If you cannot write that paragraph today without going to look, that is the finding. The clause that says you own your outputs [4] only helps if you can say what the inputs were.

Keep a second option warm rather than documented

A fallback plan in a document is not a fallback. The test is whether you could route production traffic to a different model this week and know within a day whether the output got worse.

That capability costs less than it sounds. Keep a second vendor account funded with a small balance so the billing and identity checks are already done. Keep 20 to 40 real inputs from your actual work, with the outputs you consider correct, in a plain file. Once a month, run them through the alternative model and read the results yourself. You are not building a benchmark. You are building the ability to answer one question quickly: would this be fine.

The file matters more than the process, so be specific about what goes in it. Use inputs that already broke something once, the long ones, the badly formatted ones, the client who writes in fragments. Include at least a few cases where the correct answer is a refusal or a request for missing information, because that is where models differ most and where a quiet regression does the most damage. Keep the known-good output next to each input, in your own words, so that a year from now you are comparing against a standard rather than against your memory of one. Twenty inputs assembled from real work beat two hundred synthetic ones, and the whole thing fits in a single text file you can read in ten minutes.

Then write down where the model is called. For most small operations the answer is scattered: a script on a server, a step inside Zapier or n8n, a summarising field in Notion, a coding assistant nobody has audited. The list is usually shorter than people expect and nobody has ever made it. Making it is an hour, and it converts a vague anxiety into a finite checklist.

Be honest about which parts you would actually move. Some work is worth pinning to one vendor and accepting the risk. Long-context reasoning where the quality gap is visible to your clients is a reasonable place to be exposed on purpose. Batch summarising and classification is not. Sort your calls into those two piles and stop worrying about the second pile.

What still goes wrong

The compatibility layer is not a migration strategy. Anthropic says plainly that it “is primarily intended to test and compare model capabilities, and is not considered a long-term or production-ready solution for most use cases”, and points you at the native API for the full feature set, naming PDF processing, citations, thinking and prompt caching [6]. It is excellent for running your evaluation file against a second model on a Tuesday. It is not the thing you want carrying production traffic for a year.

Redundancy has a real cost and it is mostly attention. Two vendors means two sets of docs, two billing surfaces, two changelogs, two ways to be surprised. For a one-person business that is a meaningful tax, and there are cases where the right answer is to accept single-vendor exposure deliberately and spend the saved hours on the product. The failure is not choosing one vendor. The failure is choosing one by accident and finding out on the day it stops working.

The political risk is also genuinely unpredictable, and pretending otherwise would be its own kind of dishonesty. The espionage disclosure of November 2025 [5] and the ownership-attribution language now sitting in supported-region policies [3] are the visible edge of something no small operator can forecast. What you can do is keep the switching cost low enough that the forecast stops mattering. That is the whole of the defence, and it is enough.