OpenAI switched off the Sora API with no replacement: what a deprecation policy actually promises

On 24 September 2026 OpenAI removed the Videos API and every Sora 2 model from its developer platform. The list on its deprecations page is sora-2, sora-2-pro and the dated snapshots sora-2-2025-10-06, sora-2-2025-12-08 and sora-2-pro-2025-10-06, all with the same shutdown date. In the column headed "Recommended replacement", every row reads ---.

This was the second half of a shutdown announced six months earlier. On 24 March OpenAI posted on X that it was "saying goodbye to Sora" and that it would "share more soon, including timelines for the app and API and details on preserving your work." The same day it notified API developers of the removal date. The Sora app and web experience closed on 26 April, and the API followed in September.

Nothing about this was a surprise, and nothing about it broke a promise. That is exactly why it is worth reading carefully.

Six months, to the day#

OpenAI's deprecations page opens with its policy, and the wording is precise:

"Unless safety or compliance concerns require a faster timeline, we provide the following minimum notice periods before model retirement: Generally available models: At least 6 months. Specialized variants of generally available models: At least 3 months."

24 March to 24 September is six months. The notice period for Sora was the published minimum, and the page's own entry records that developers were told on the first day of it. The policy also commits that "impacted customers will always be notified by email and in our documentation along with blog posts for larger changes."

So the process worked as designed. Anyone who read their email in March had half a year. I want to be fair about that, because the easy version of this story is that a vendor pulled the rug, and that is not what happened.

What happened is more useful to understand. The policy did everything it says it does, and a developer who built a product on the Videos API still ended up with a capability that no longer exists and no pointer to where it went.

The column that was empty#

Look at the other entries on the same page and the pattern is obvious.

When OpenAI deprecated whisper-1 and three gpt-4o transcription models on 26 August 2026, with removal on 26 February 2027, the replacement column reads gpt-live-transcribe or gpt-transcribe. When it deprecated older GPT Image models on 2 June 2026, with removal on 1 December 2026, the replacement for gpt-image-1-mini reads gpt-image-2.5-sunburst or gpt-image-2.5-flare.

Those are migrations. The work is real but bounded: change the model name, rerun your evaluations, adjust whatever behaved differently, ship.

An empty replacement column is a different kind of event. There is no model to evaluate. The question stops being "how do we move to the new version" and becomes "does this feature still exist, and if so, whose infrastructure does it run on now". That is not an engineering ticket. It is a product decision, and the deadline for it was set by someone else.

The Decoder's reporting on the shutdown frames it as OpenAI redirecting compute toward "coding tools and enterprise customers", with Sora continuing as a research effort on world models. Whatever the reason, the effect on an API customer is the same. A capability you were paying for was retired as a business decision, and the business decision did not include a successor.

What a deprecation policy actually promises#

Read the policy text again and notice what it covers. It promises notice. It does not promise a successor, capability parity, similar pricing or a migration path. Those are what most people assume when they hear "deprecation", because most deprecations come with them, but they are not in the contract.

The policy also has exceptions written into it. The minimum periods apply "unless safety or compliance concerns require a faster timeline", and "preview models may be retired with much shorter notice, such as 2 weeks." The same page shows how short that can be in practice: gpt-5.4-cyber was deprecated on 11 September 2026 with removal on 1 October 2026, and its replacement is an instruction rather than a model name: "Migrate to the most capable cyber model available to you before the shutdown date." The page does not say which of the policy's exceptions applied.

None of this is unusual for a model provider, and I do not think it is unreasonable. A lab retiring expensive capabilities that do not earn their keep is behaving like a business. The mistake is on the building side, when a product is designed as though a notice period were a continuity guarantee.

Where the coupling actually lives#

When a model disappears, the API call is the smallest part of what you have to change. The coupling is usually spread across places nobody thinks of as "the integration".

The request shape is the obvious one. Less obvious is everything downstream that was tuned to one model's output: the durations, formats and quality your UI expects, the moderation behaviour your support team has learned to explain, the cost per generation baked into your pricing page, and the prompts your customers wrote and saved in your product. A replacement model from another provider can be better on every benchmark and still break most of those.

I made a version of this argument about enterprise integrations in general: the documentation describes the happy path, and the real cost shows up in reconciliation and late failures. Model APIs are the same. The part you depend on is wider than the part you call.

What I would put in place before the next one#

This is the list I would want in any product that calls a model it does not own.

1. An inventory with lifecycle status. Every model and endpoint in production, the provider's current status for it, and the date that status was last checked. It is a spreadsheet, not a platform, and it is the thing that turns an email in March into a plan rather than a surprise in September.
2. An interface you own, shaped around the capability. Your code should call "generate a video from this brief" or "transcribe this call", not a vendor's SDK directly. That boundary is where a second provider plugs in, and where you normalise the output differences described above.
3. A second provider you have actually tested. Tested means your own evaluation set runs against it on a schedule and you know how its output differs. A name in an architecture document is not a fallback. For text workloads, an open-weight model you can run yourself is the one fallback no vendor can retire, which is part of why I keep coming back to hybrid local and cloud designs.
4. A written answer for "what if this capability disappears". Swap provider, degrade gracefully, or remove the feature. Decide while nothing is on fire, and write down who makes the call.
5. Notice terms in the contract, where you have leverage. If a capability is core to what you sell, the standard policy is a floor. Enterprise agreements are the place to ask for more, and the time to ask is before you depend on it.

None of that is expensive when it is designed in. All of it is expensive when it is retrofitted in the last month of a notice period.

The protocol gave twelve months. The model gave six#

There is a useful contrast from earlier this year. When the Model Context Protocol shipped its stateless specification in July, it adopted a twelve-month deprecation policy. A shared protocol has every reason to be generous: breaking it breaks an ecosystem, and nobody owns the ecosystem.

A model is a product, and the provider owns it outright. Six months is a reasonable floor for a product, and the Sora shutdown shows that the floor can also be the ceiling. If your architecture treats a hosted model with the same confidence as a protocol, it has the wrong mental model of which one can be switched off.

What I would watch next#

Three things.

First, whether video generation comes back to OpenAI's API in some other form, given The Decoder's report that Sora continues as a research effort. If it does, it will arrive as a new product with new terms, not as a restoration of the old one.

Second, whether other providers start treating the replacement column as a commitment rather than a courtesy. An empty column is honest. It would be more useful if providers said in advance which capabilities they would support with a successor and which they would not.

Third, and closest to home: how many products quietly lost a feature on 24 September without announcing it. The teams that had an interface of their own and a tested second provider will have swapped and moved on. The teams that did not will be making the product decision now, six months late.