When your AI tool loses the model underneath it

On 28 August 2026, OpenAI notified SpaceX that it intended to wind down the contract supplying OpenAI models to Cursor, with a proposed shutoff date of 12 November, 76 days later, following SpaceX’s acquisition of the company [1]. The stated reason had nothing to do with Cursor’s product or its customers. OpenAI said it “cannot be confident that SpaceX will use our technology within our terms of service, based on our experience with Elon Musk’s companies violating contracts” [1]. Nothing was switched off that day. What changed was that a date now existed, and everyone who had tuned their work to a specific OpenAI model inside Cursor had 76 days to do something about it.

That is the loud version of something that happens quietly every month. Models get retired on published schedules. Contracts lapse. Products get folded into other products. Almost every AI tool you pay for is a good interface wrapped around intelligence it rents from a company you have no agreement with, and the rental can end for reasons that have nothing to do with you. This guide is about finding those dependencies before they find you, working out what each one would actually cost to replace, and doing the modest amount of work now that turns a forced migration into a week of re-testing. It is not for enterprise buyers with a vendor-risk function and a procurement lawyer, who already run this exercise on a spreadsheet. It is for a solo operator or a small team whose month gets wrecked when a tool quietly stops behaving.

Every AI tool is at least two companies

The logo on the product is rarely the company that can switch you off. Cursor supports models from Anthropic, Google, OpenAI and SpaceX AI alongside its own Composer, and its router picks between them on Teams and Enterprise plans [6]. Notion AI runs on models “hosted by Notion as well as by organizations such as Anthropic and OpenAI” [7]. In both cases you bought one product and inherited two or three supplier relationships you cannot see, cannot read, and were never party to.

So the first piece of work is a list, and it takes about 20 minutes. Write down every AI tool you pay for. Next to each one, write the model provider or providers it actually calls. Most vendors publish this, either in their model documentation like Cursor [6] or in their security and subprocessor pages like Notion [7]. If a vendor will not tell you which models it uses, write “unknown” and treat that as a finding rather than a gap, because it means you cannot predict what a change upstream will do to your output.

The point of the list is not paranoia. It is that two tools that look independent are often the same bet. If your writing assistant, your coding tool and your notes app all route to the same provider, you do not have three suppliers. You have one supplier and three invoices, and a single change at that provider moves all three at once.

Model retirement is scheduled, published, and far more likely than a corporate feud

The dramatic case is the rare one. The ordinary case is a date in a table that you never read.

OpenAI commits to minimum notice before retiring a model: at least 6 months for generally available models, at least 3 months for specialised variants such as chat and Codex variants, and as little as 2 weeks for preview models, with the caveat that safety or compliance concerns can shorten that to “as much notice as reasonably possible” [2]. Anthropic commits to at least 60 days’ notice for publicly released models, notifies affected customers by email and in the docs, and publishes a tentative retirement date against every active model, so you can look up today that claude-haiku-4-5-20251001 is scheduled to retire not sooner than 15 October 2026 [3]. Google promises advance notice but publishes no guaranteed minimum, and is explicit that the dates in its own table “indicate the earliest possible dates on which a model might be retired” [4].

Those three policies are meaningfully different, and the difference should change what you build on top of each. They are also honoured to the letter rather than generously. claude-opus-4-1-20250805 was deprecated on 5 June 2026 and retired on 5 August 2026, 61 days apart against a 60-day promise [3]. OpenAI announced the deprecation of gpt-5-chat-latest and gpt-5.1-codex on 22 April 2026 and shut them down on 23 July 2026, 92 days against a 3-month promise, on a day that took more than a dozen models offline at once [2].

The part people miss is that it is not only models. OpenAI’s deprecation table also lists the Evals dashboard and API, Agent Builder and the reusable prompts API for shutdown on 30 November 2026 [2]. If you built your quality checks inside a vendor’s evaluation product, the thing you were going to use to test your migration can be deprecated on the same page as the model you were migrating from.

The unscheduled version has no notice period you can rely on

Deprecation schedules are a promise about models. They are not a promise about your access to them, and those are separate things.

Read what the commercial terms actually say. OpenAI’s Services Agreement lets either party terminate for material breach after a 30-day cure period, and does not offer termination for convenience. It permits suspension where required by law, where the customer violates the agreement or OpenAI’s policies, or where suspension is necessary to prevent or terminate a “Security Emergency”, using “reasonable efforts to notify” beforehand but allowing action without notice where reasonably necessary. If an update “materially reduces the Services functionality”, customers get 5 business days to elect termination on 30 days’ written notice, and that right does not apply to features provided on a beta or evaluation basis [5]. Those are the terms available to a customer with an order form. Most small teams are not that customer.

Now notice where you sit in that structure. In the Cursor case, the agreement being wound down was between OpenAI and Cursor. The developers affected had no clause to invoke, no cure period, and no standing. As of today, Cursor’s documentation still lists OpenAI’s GPT-5.6 Luna, Sol and Terra among the models you can select [6], while the proposed cutoff is 68 days away [1]. The product page and the contract are telling you two different things, and only one of them is binding.

Sort your work by what a swap would cost, not by how much you use it

Volume is the wrong sorting key. Plenty of people run hundreds of chat messages a month through a tool and would lose nothing at all if the model changed underneath them, because every one of those messages was disposable. Sort by replacement cost instead, into three tiers.

Tier one is disposable. You asked a question, you read the answer, you moved on. A model swap costs you nothing here, and no preparation is warranted. Most of what most people do with an assistant lives here, which is why the panic about model changes is usually overblown.

Tier two is reusable. Prompts you paste every week, standing instructions, templates, a rules file your coding tool reads on every request. A swap costs you a few hours of tightening, because instructions written for one model often lean on habits another model does not share. This tier is worth preparing, and preparing it is cheap.

Tier three is load-bearing. Anything with a schedule, a fine-tune, a measured quality bar, an integration that other people depend on, or an output that goes to a customer without you reading it first. A swap here costs real days, and it is the only tier where the answer might be to avoid a dependency rather than manage it. Count how many tier-three items you have. For most small teams the honest answer is two or three, and knowing which two or three is most of the value of this whole exercise.

Keep everything you wrote on your side of the line

The parts of your setup that are genuinely yours are text. Prompts, instructions, examples, the notes about what the model gets wrong, the list of test cases. If that text lives in a vendor’s settings panel, it leaves when the vendor does. If it lives in a file you keep, it survives every one of the failures described above.

For coding work there is now a standard shape for this. AGENTS.md is an open format for the instructions a coding agent needs, used by over 60,000 open-source projects and listed as supported by more than 20 tools including Cursor, OpenAI’s Codex and Google’s Gemini CLI, and it is stewarded by the Agentic AI Foundation under the Linux Foundation rather than by any one vendor [8]. The practical consequence is that the project context you write once is read by whichever tool you happen to be using, so switching tools stops being a rewrite.

The same principle applies outside code without a formal standard. Keep your standing instructions in a document you own and paste them, rather than configuring them into three different products. Export your data once during the trial, from a menu, without asking support, so you know the export exists and you know what it contains. Own the credentials for anything the tool connects to, so that removing it does not also break your calendar or your inbox. None of this is interesting work and all of it is done once.

A swap you have already run is not a migration

The difference between a bad week and a bad quarter is whether you have ever tried the alternative on your actual work.

Build a small test set. Ten to 20 real tasks you have already done, each paired with an output you were happy with. Not benchmark questions, and not the demo the vendor suggests. Your actual Friday summary, your actual support reply, your actual refactor. Keep it in a file next to your prompts.

Then run it against a second model once a quarter. The purpose is not a score. The purpose is a list of what got worse, because that list is the real migration plan, and producing it while nothing is on fire takes an afternoon instead of a fortnight. Anthropic’s own guidance follows the same order: audit your usage from the Console usage page, export a CSV broken down by API key and model, and test your applications with the newer models well before the retirement date rather than after it [3].

If the second model does the work acceptably, you have converted a dependency into a preference, and you can stop worrying about who acquires whom. If it clearly does not, you have found a genuine tier-three dependency, and you now know its cost in advance rather than under a deadline you did not set.

What still goes wrong

The deprecation dates in this guide are a snapshot verified on the date in the header, and they move. Anthropic’s published retirement dates are explicitly tentative [3], Google’s are explicitly the earliest possible rather than the actual [4], and OpenAI’s notice commitment carries an exception for safety or compliance that can shorten it [2]. Check the vendor’s own page before you plan around any date, including the ones cited here.

Portability also has a real ceiling. Prompts and instructions move well. Fine-tuned models, vendor-specific tool integrations, retrieval indexes and anything built on a product rather than a model do not, and no amount of discipline makes them move. If your work genuinely needs one provider’s specific behaviour, the honest answer is not to pretend it is portable. It is to accept the dependency deliberately, keep the migration cost written down, and stop describing the choice as a preference.

The last failure is the one this guide can most easily cause. Building for portability has a price, and it is paid in capability you decline to use. A workflow that works acceptably on any of four models is usually worse than one tuned hard to the best model for that job. Reversibility is the right bias when you are spending your own money and a bad month is expensive, and it is the wrong bias when you are deliberately going deep on one platform because depth is the whole point. Decide which of those you are doing before you start optimising, because the caution that saves a small business from a forced migration will also stop it from ever getting particularly good at anything.