Most businesses have learned to expect that the AI model they use will be replaced by a better one. Three days ago a different thing happened: a capability was withdrawn, on schedule, with nothing offered in its place.
01 — What happened
On 24 September 2026, OpenAI removed the Videos API and the entire Sora 2 model family from its API — sora-2, sora-2-pro and their dated snapshots. Developers were notified six months in advance, on 24 March 2026. On OpenAI’s own deprecations page, the recommended-replacement column for every one of those entries is empty.
That is the part worth noticing. A version being retired in favour of a newer one is routine maintenance. A product line closing is not.
The consumer side went first. OpenAI announced the closure of the Sora app on 25 March 2026, following sustained criticism over non-consensual deepfakes and low-quality output, and the app shut the following month. The three-year licensing agreement Disney signed in December 2025, covering more than 200 of its characters, ended with it. Disney’s statement said it “respects OpenAI’s decision to exit the video generation business.”
Sora is the visible case, not an isolated one. OpenAI’s deprecations page carries nine dated announcements between 24 March and 11 September 2026, and several of them retire products rather than models:
- Agent Builder, the visual tool for assembling agents, shuts down on 30 November 2026.
- The Evals platform and its graders go read-only on 31 October 2026 and shut down on 30 November. The published migration path points at Promptfoo — a third-party tool.
- The
v1/promptsAPI and reusable prompt objects shut down on 30 November 2026; the guidance is to move prompt content back into your own code. - Self-serve fine-tuning is being restricted in phases through 6 January 2027.
- The Assistants API was removed on 26 August 2026, twelve months after notice.
Notice periods vary enormously. Sora got six months. The Assistants API got twelve. gpt-5.4-cyber, announced on 11 September 2026 and scheduled for removal on 1 October, gets twenty days.
Other vendors publish their own terms. Anthropic gives “at least 60 days’ notice before model retirement for publicly released models”, publishes a table of “not sooner than” dates currently running about a year ahead, names a recommended replacement, and committed in November 2025 to preserving the weights of retired models. DeepSeek’s April 2026 changelog gave three months on its legacy model names, discontinued on 24 July 2026 as scheduled.
02 — Why it matters
We have written before about AI prices moving in both directions. A price rise is uncomfortable but absorbable: you pay more, or you route the work elsewhere, and the feature keeps working either way.
Withdrawal is a different category of event. There is no version of “absorb it.” If the capability your product depends on stops existing, you either find another supplier, build it yourself, or tell your customers the feature is gone — all on a date someone else chose.
This is not the familiar lock-in argument about switching costs and contract terms. It is narrower: some of what you buy from an AI vendor is a commodity with several suppliers, and some of it is a line of business the vendor is still deciding whether to be in. They look identical in the documentation and carry completely different risk.
The pattern in that list is clear enough. What survived is the core interface — the API you send a request to. What is being withdrawn is the scaffolding on top of it: the agent builder, the evals platform, the hosted prompt store, self-serve fine-tuning, the video model. Those are the convenient parts, and the parts where you have no second supplier, because they exist only inside one vendor’s platform.
03 — The economics
The cost of a forced migration is almost entirely determined by a decision you made before the notice arrived: how many places in your system know which supplier you are using.
Take an illustrative case. A business has a web application that generates short video clips for customers, and the vendor call sits in one module behind an internal function the rest of the application uses. A shutdown notice means evaluating alternatives, rewriting one integration and re-testing output quality. Call it days of work.
Now the same feature where the vendor’s SDK is called directly from the request handler, the background worker, the admin tool and two scheduled jobs, with the response format assumed in each. Same notice, same replacement supplier, but now it is a project. The work is not proportional to the change in capability. It is proportional to how deeply the supplier is embedded.
The second cost is scheduling. Twenty days’ notice lands on whatever you were doing that month; six months does not. Neither is optional, but one displaces planned work and the other can be planned around. The notice period is a commercial term, like uptime — and unlike uptime, hardly anyone checks it before committing.
The third cost is the promise you made to customers. Disney’s deal is the instructive version at scale: a three-year agreement announced in December 2025 was finished within months, because the platform it depended on closed. A business that markets a feature it cannot supply without one vendor has adopted that vendor’s product strategy as its own roadmap risk — and customers do not accept “our supplier withdrew it” as an explanation.
04 — What businesses should do
If your AI arrives inside software you already pay for — summaries in your CRM, draft replies in your helpdesk, transcription in your meeting tool — this is your vendor’s problem, not yours. They absorb the migration. Do nothing, and be glad you are on that side of it.
If your own systems call an AI API directly, spend an hour this week on three things.
First, write down every external AI capability your systems call, and next to each one, where it is called from. Not the architecture diagram — the actual count of files. This is the number that determines what a shutdown notice costs you, and most teams have never counted it.
Second, for each supplier, find the deprecation page and read the notice commitment — the figures above differ by more than an order of magnitude. Then check whether anyone is subscribed to those notices, or whether you are relying on an email reaching whoever created the API key.
Third, sort each capability into commodity or speciality. If three credible vendors sell something close enough that you could switch, treat it as a utility and do not over-engineer. If only one vendor has it, that is where an abstraction layer earns its cost — and where you should be conservative about promising the feature to customers.
If you make one or two AI calls a month, stop here. Building a vendor-abstraction layer around a single call is the more expensive mistake. Keep the call in one file and move on.
05 — Where technology fits
For most businesses, honestly: nothing needs building because of this. If you consume AI through software someone else maintains, read this, note it, and get back to work.
Where it does matter, the thing worth building is small and unglamorous: one place in your own codebase that owns each external AI capability, so the rest of the system asks for “a video clip” or “a summary” rather than naming a supplier. That is not an AI project. It is ordinary integration discipline — a boundary in the right place, drawn once — and the same discipline that decides what disconnected systems actually cost you.
Two things we would not recommend. Do not build a multi-vendor routing framework because a supplier might one day leave; the maintenance is real and the benefit theoretical until the second supplier is working. And do not adopt a platform’s convenience tooling — the visual builder, the hosted prompt store, the managed evals — for anything you would struggle to replace. Those have the shortest observed lifespan and no alternative supplier. Convenient for a prototype. A liability in something you sell.
What is worth doing is asking the question at design time rather than at notice time — really a question about how you scope and build rather than a question about AI. A system you control can change suppliers. A system assembled inside someone else’s product cannot.
06 — RevenueStack’s take
Our view: the significant thing about Sora is not the video. It is that a major vendor demonstrated it will exit a capability entirely, on a published date, with the replacement column left blank — and that this is now visible as a pattern rather than a one-off.
The industry has spent two years telling businesses to build on AI platforms as though they were infrastructure. Infrastructure behaves differently: electricity suppliers do not stop selling electricity because the margins disappointed. What is on offer is a fast-moving product portfolio, and portfolios get pruned. That is not a scandal — it is what a competitive market looks like — but it should change what you build on top of, and how much of it you sell as a promise.
So the practical discipline is not vendor loyalty or vendor paranoia. It is knowing, for every external capability in your system, whether it has a substitute. Where it does, use the best one available and enjoy the price war. Where it does not, keep the dependency shallow and the commitment modest.
The vendors will keep shipping and keep pruning. The businesses that ride that out are the ones for whom a deprecation notice is a diary entry, not an emergency.
Sources
- Deprecations — OpenAI, 2026-09-11
- OpenAI to abruptly close Sora video app following backlash over deepfakes and AI slop — Euronews, 2026-03-25
- Model deprecations — Anthropic, 2026-09-22
- Commitments on model deprecation and preservation — Anthropic, 2025-11-04
- DeepSeek API — News and updates — DeepSeek, 2026-04-24
- Sora (text-to-video model) — Wikipedia, 2026-09-25
