The four ways your AI vendor changes the deal

You have a prompt that took a month to get right. It sits inside a weekly report, or a support macro, or step three of a Zapier run that fires whether or not you are awake. It works. And none of it is yours. The model name in that call is a lease, the usage policy is a document the vendor edits on its own schedule, and the price is whatever it is this quarter. That is not sinister and it is not new. It is what buying software from a fast-moving vendor has always been. What is new is that the leased part is not a feature you can route around. It is the part that does the work.

So the useful question is not whether your vendor will change the deal. It will, in four ways: it will retire the model you use, it will rewrite the policy that says what you may use it for, it will get into fights you are not a party to, and it will go down. This guide is about measuring how exposed you are to each and cutting that exposure down to something you can absorb in an afternoon. It is written for a one-person business or a team under about twenty, paying monthly with its own money. If you have a procurement function, a vendor risk questionnaire and counsel on retainer, you already run a heavier version of this and should keep running it.

The thing you depend on is a model version, not a brand

Your dependency is not on “Claude” or “ChatGPT”. It is on a specific string. Model ids get retired on published schedules, and the schedules are short by the standards of most business software. Anthropic marked claude-opus-4-1-20250805 deprecated on 5 June 2026 and retired it on 5 August 2026; claude-sonnet-4-20250514 was deprecated on 14 April 2026 and retired on 15 June 2026 [1]. OpenAI announced on 11 June 2026 that gpt-5-2025-08-07 and o3-2025-04-16 shut down on 11 December 2026 [2]. If a prompt of yours names one of those, it stopped working or it has a date on it.

Parameters expire too, which is the part that catches people who assume only model names move. Anthropic has deprecated temperature, top_p and top_k for Claude Opus 4.7 and later; setting them to non-default values returns a 400 error, and the recommended approach is to omit them and steer behaviour through the prompt instead [1]. Code that ran unchanged for two years now fails on an argument nobody thought of as a feature.

There is a commitment worth reading precisely, because it is easy to misread as insurance. In November 2025 Anthropic committed to preserving the weights of all publicly released models, and models deployed for significant internal use, for “at minimum, the lifetime of Anthropic as a company” [3]. That is a commitment about an archive, not about an endpoint you can call. Preserved and available are different words. Nothing in it means the model you tuned against will still answer your requests next year.

If you work in the chat app rather than the API, you have less control here, not more. You do not choose the model behind the box, you do not pin a version, and the behaviour you tuned your prompts around can shift without a line item anywhere.

Notice periods are the real contract, and they are not equal

Every vendor says it will give you notice. The word means very different amounts of time.

Anthropic commits to at least 60 days’ advance notice before retiring a publicly released model, sent by email to customers with active deployments [1]. OpenAI commits to at least 6 months for generally available models, at least 3 months for specialised variants such as chat, codex and deep research, and as little as 2 weeks for preview models, while noting that safety or compliance concerns may warrant faster timelines than any of those minimums [2].

Read that as a planning input rather than a scorecard. Sixty days is a weekend of work if you already have a way to test a replacement, and a lost quarter if you do not. Six months is comfortable unless you are on a preview model, in which case you have two weeks and a production dependency. The rule that falls out of it is dull and worth following: do not build anything that has to run next year on a preview or experimental id, and pin exact dated ids everywhere else so you can answer the question “what am I actually running” without guessing. Anthropic’s Console publishes a usage page that exports a CSV of usage by API key and model, which is the fastest honest answer to that question [1].

The usage policy is the clause most likely to move under you

Both major usage policies carry effective dates, which is the point: they are living documents, revised on the vendor’s timetable, and your workflows have to sit inside whatever the current version says. Anthropic’s Usage Policy is effective 15 September 2025 [4]. OpenAI’s usage policies are dated 29 October 2025 [5].

The contents matter to ordinary small businesses more than most people expect, because the prohibitions are written around capabilities, not around industries. Anthropic’s policy prohibits using Claude to target or track a person’s physical location without consent, facial recognition applications, predictive policing, and biometric categorisation systems that infer protected characteristics [4]. OpenAI’s prohibits weapons development, procurement or use including CBRNE, forbids building facial recognition databases without data subject consent and real-time remote biometric identification in public spaces, and prohibits the automation of high-stakes decisions in sensitive areas without human review, naming law enforcement, employment, housing, credit, insurance, legal and medical among them [5]. If you do tenant screening, hiring screens, insurance work, debt collection, physical security or anything that resolves to identifying a person, those lines are load-bearing for you and you should read them yourself rather than take a summary.

Enforcement is blunt. OpenAI states that breaking or circumventing its rules and safeguards “may mean you lose access to our systems or experience other penalties”, with an appeals process available [5]. Loss of access is not a refund event. It is a Tuesday on which your product does not work and your customers find out before you do.

One more thing to notice, because it explains a lot of confusing vendor behaviour: the policy you read is not necessarily the policy everyone operates under. Anthropic’s policy says it may enter into contracts with certain governmental customers where tailored restrictions apply, if safeguards adequately address the harms the policy is written to prevent [4]. Different customers get different rules, and you are not in the room where that is negotiated.

Political risk lands on your invoice

The extreme case is instructive precisely because you will never be a party to it. On 28 August 2026, US District Judge Rita Lin ruled that the Defense Department’s designation of Anthropic as a national security supply-chain risk was unlawful retaliation under the First Amendment, denied the company due process under the Fifth, and was arbitrary and capricious under the Administrative Procedure Act [8]. The designation had directed federal agencies to stop working with the company, and it followed Anthropic’s refusal to remove guardrails that would have permitted autonomous weapons and mass surveillance uses [8]. Judge Lin wrote that “the empty invocation of national security is not a blank check to punish and retaliate against government critics” [8].

Strip out the constitutional law and what is left is a plain operating fact. A vendor you depend on can be cut off from an entire class of customer by someone with no relationship to you, for reasons that have nothing to do with your account. If your work reaches those customers through that vendor, your work gets cut off with it. Vendor risk is not only “will this company still exist”. It is also “will this company still be permitted to serve the people I serve”.

The lesson that survives the news cycle is about timing, not about who won. The outcome went the vendor’s way, and it took a lawsuit and months to get there. A favourable ruling is a fine thing to have and it is not a continuity plan, because nothing about winning eventually restores your access while the fight is running. Meanwhile, the reason the fight existed at all is that the vendor held a line written into its own usage policy. The commitments that make a vendor a careful custodian of your data are the same commitments that put it in conflict with its largest customers. You do not get to pick one.

Portability is real at the API and imaginary everywhere else

The comfort most people reach for is the OpenAI-compatible endpoint. It is genuine: point the OpenAI SDK at https://api.anthropic.com/v1/, swap the key, use a Claude model name, and the request goes through [6].

Then read what the vendor says about its own compatibility layer. Anthropic’s documentation states 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” [6]. The specifics are worse than the summary. Prompt caching is not supported. The strict parameter for function calling is not supported, so JSON schema compliance is not guaranteed. Audio input is stripped from requests. All system and developer messages are concatenated into a single initial message. And a long list of parameters is silently ignored, including response_format, seed, logprobs, presence_penalty, frequency_penalty and logit_bias [6].

Silently is the word to sit with. Nothing errors. Your code runs, your bill arrives, and the quality of what comes back is quietly different from what you tested. So the request layer is portable and the thing you actually built is not: prompts tuned to one model’s habits, tool definitions, output shapes your code parses, and above all the judgment about whether a replacement is good enough.

That last item is the one worth buying, and it does not cost money. Collect 20 real inputs from your actual work, with the outputs you would have shipped, in a plain file. That file is the only benchmark that matters, because the only question at migration time is whether the new model does your job, not whether it scores well on someone else’s. With it, a forced migration is an afternoon of comparison. Without it, it is weeks of vibes and a nagging suspicion that things got worse.

Two hours a quarter is the whole programme

None of this needs a policy document. It needs a recurring calendar entry and about two hours.

Open the deprecation page for each vendor you pay and write down the next retirement date that touches an id you use [1][2]. Check the effective date on each usage policy, and if it moved, read only the sections that touch your work [4][5]. Then look at published reliability instead of trusting your memory of it. OpenAI publishes aggregate uptime figures, showing 99.94% for APIs and 99.64% for ChatGPT across June to September 2026, and notes that availability is reported at an aggregate level and that individual availability may differ by subscription tier and model [7]. A shortfall of 0.36% is roughly 2.6 hours in a 30-day month. Decide now whether that is compatible with what you promised a client, rather than during the outage.

The other half is rehearsal. Keep a funded key at a second vendor and run your 20-case file through it once a quarter, not to switch but to know the answer before you need it. Export what you would lose, meaning prompts, saved projects and any knowledge base you have loaded, and time how long the export takes, because that duration is your real migration cost and it is usually longer than the number in the calculator. Then write half a page that says what breaks if this vendor is unavailable for a week, what you fall back to, and who you tell. Half a page written calmly is worth more than any amount of clarity you will have on the day.

What still goes wrong

The fallback is worse. That is the honest finding almost everyone reaches on their first real test, and it does not get better by being annoyed about it. A second vendor you have not tuned for produces output that is close and off, in ways that show up in tone, formatting and the specific edge cases you spent months teaching the first one about. Plan for a degraded mode rather than a substitute, and decide in advance which of your outputs can survive being 10% worse for two weeks and which cannot.

The quarterly pass catches scheduled changes only. It will not catch an account suspension you did not see coming, a policy applied more strictly than it reads, or a dispute between your vendor and an entity vastly larger than you. Notice periods are floors and not quality guarantees either: a retired model can be replaced by a successor that is better on published evaluations and worse at your particular task, and no vendor owes you the old behaviour. OpenAI’s own policy reserves room for faster timelines than its stated minimums where safety or compliance concerns apply [2]. Every commitment in this guide has a clause like that somewhere behind it.

And the uncomfortable part: the concentration you are worried about is the reason these tools are as cheap and as good as they are. A stack spread thin across four vendors to reduce dependency is a stack you understand worse and pay more for. The point of the exercise is not independence, which you are not going to get at this size. It is knowing your exposure well enough that when the deal changes you spend an afternoon on it instead of a quarter.