Why AI Companies Keep Cutting Off Rivals

When one AI company stops serving another, the reporting reaches for the rivalry: who insulted whom, which launch was imminent. The contracts are duller and more useful. Almost every cutoff runs through one of three clauses, and you can read your own vendor's terms this afternoon to find out which ones you are exposed to.

Two recent cases make the mechanics visible.

Two cutoffs, and what triggered each

The 2025 case was reported by TechCrunch at the time; Anthropic's commercial terms bar using the service to build a competing product or to reverse engineer it, and OpenAI's response was that benchmarking rival systems is industry standard. The 2026 case is documented in OpenAI's own note on the decision and covered in our report on the cutoff.

Clause one: competing use

Nearly every model provider's terms restrict using the service to build, train or evaluate a competing product. The wording is broad on purpose. Read literally, running a rival model against yours in an evaluation harness can fall inside it, which is exactly the reading Anthropic applied in 2025.

If you are a small team, this clause rarely bites. It starts to matter the moment your product could plausibly be described as competing with something the vendor sells, which is a wider category each year as providers ship their own agents, editors and app builders.

Clause two: ownership change

This one has nothing to do with your behaviour. It lets the vendor terminate if you are acquired, and it is what OpenAI used in August 2026. Nobody had to be in breach. The counterparty simply became a company OpenAI did not want to supply.

For a solo builder the direct risk is low, because nobody is acquiring you. The indirect risk is not: the tools you depend on can be acquired, and their model supply can be pulled as a result. That is a second-order dependency most people never map.

Clause three: acceptable use and unilateral amendment

Acceptable-use policies sit outside the main contract and can usually be amended without your agreement. A change there can make a workload non-compliant overnight without anyone renegotiating anything. This is the quiet one, and it is why an AI vendor changing its terms of service deserves an actual alert rather than an unread email.

What a cutoff looks like from inside a product

From the user's side these events are undramatic, which is part of why they catch people out. The sequence is consistent: an announcement with a date some weeks out, a period where nothing changes, then a quiet removal of an option from a dropdown.

There is rarely an error message. The tool falls back to whatever else it has, output quality shifts slightly, and the person using it notices a week later that results feel different without being able to say why. That is the actual cost: not an outage, a silent change in behaviour under a workflow you had tuned.

Which is why the useful preparation is knowing which model each workflow runs on. If you cannot name it, you cannot notice when it changes, and you will attribute the difference to the tool or to yourself.

How to check your own exposure

1. Search your provider's terms for the words acquisition, change of control, and assign. If a change-of-control clause exists, note who it protects. Usually not you.

2. Search for compete and competing. Decide honestly whether a hostile reading of your product lands inside that definition.

3. Find out whether the acceptable-use policy is incorporated by reference and amendable at the vendor's discretion. It almost always is.

4. Write down which single model each of your workflows actually depends on. Most people cannot answer this from memory, which is the real problem.

Vetting an AI vendor properly covers the rest of the checklist, and the structural version of this risk is vendor lock-in in AI app builders.

What this means in practice

Not much, if you keep one habit: know your fallback before you need it. A workflow that runs acceptably on two different providers is immune to all three clauses. A workflow tuned to the quirks of exactly one model is exposed to all three at once, and the notice period is whatever the contract says it is.

That is the whole lesson. Portability is not an architecture project. It is knowing which model you are on and having run your real tasks through one alternative recently enough to trust the result. Planning for a model going away walks through the migration itself.

Frequently asked questions

Can a model provider cut me off with no notice?

Contracts usually specify a notice period, and providers generally use it. OpenAI gave Cursor roughly eleven weeks. Suspension for an acceptable-use breach is a different matter and can be immediate, which is why the acceptable-use policy is worth reading even though it is the least interesting document in the stack.

Does using open-weight models remove this risk?

It removes the termination risk, because nobody can revoke weights you already hold. It does not remove the hosting risk if you run those weights through a provider, and it introduces the cost of maintaining your own inference. It is a real answer, not a free one.

Is benchmarking a rival model against my own a terms violation?

It depends on the provider and on how you access the model. The 2025 dispute turned on API access being used for evaluation rather than ordinary product use. If you plan to publish comparisons, read the competing-use clause of every provider involved first.

How often should I test a fallback model?

Once a quarter is enough for most people, plus any time you hear that a supplier relationship has changed. The point is not to stay current with every release, it is to know that a switch would take an hour rather than a fortnight.