In short: OpenAI has not published a reason for shutting down the Sora API, only a removal date of September 24, 2026 and no named replacement, which tells you more about planning your own dependencies than any of the reporting does.
If you built anything on OpenAI’s video generation endpoints, your deadline is now a specific date: September 24, 2026. After it, the Videos API and every sora-2 model are gone.
The obvious question is why, and it is worth reading the actual notice, because it is short and something is missing from it. OpenAI gives a date and five model names. It gives no reason. It names no replacement.
So every explanation you have read for why the Sora API is being shut down came from journalists rather than from OpenAI. That is not a pedantic distinction. It changes which parts you should plan around and which parts you should treat as informed guesswork.
Why is the Sora API being shut down?
OpenAI has not said. Its deprecation notice, dated March 24, 2026, states only that developers using the Videos API and the Sora 2 model aliases and snapshots were notified of removal on September 24, 2026. Press reporting attributes the decision to the consumer Sora app costing around one million dollars a day in compute while its usage collapsed, and to that compute being redirected to other products.
1. What OpenAI actually said
The whole official record is one entry on the OpenAI API deprecations page: on March 24, 2026, developers using the Videos API and the Sora 2 aliases and snapshots were notified of their removal from the API on September 24, 2026.
Five names are listed: sora-2, sora-2-pro, sora-2-2025-10-06, sora-2-2025-12-08 and sora-2-pro-2025-10-06. Those are the strings to search your codebase for today. The consumer side went first, with the app and sora.com discontinued on April 26, 2026.
Now the detail that carries the most information, and it is an absence. The deprecation entry names no replacement. When a model is retired it is normally pointed at a successor, because the vendor wants you to stay. Nothing is offered here. That is the difference between an upgrade and an exit, and it is the clearest signal in the whole notice.
What actually breaks, and when
On September 24, 2026 the models and the Videos API are removed from the API. Anything in your product that generates video through them stops producing video on that date, in production, whether or not anyone on your team is tracking the deprecation list. OpenAI has not published what a request will return afterward, so do not design a fallback around a specific error code you saw quoted on a blog.
2. What the reporting says, and how much weight to give it
The widely repeated figures come from a Wall Street Journal investigation, relayed by other outlets. TechCrunch reported on March 29, 2026 that Sora cost roughly one million dollars a day to run, that users peaked near one million and then fell below 500,000, and that Sam Altman’s decision was about freeing compute to compete elsewhere. Other coverage of the same reporting reached the same numbers.
Separately, OpenAI’s chief financial officer said publicly that the company is turning down opportunities because it does not have enough compute, which is the same story from the inside without Sora being named as the trade. And the timing is brutal in one specific way: Disney had committed a reported one billion dollars in December 2025 for a three-year license putting its characters on Sora 2, and that arrangement ended with the product.
Treat all of it as credible and second hand. One figure in particular gets mangled: the 2.1 million dollars you will see quoted as Sora’s total revenue is in-app purchases from the consumer app, not the product’s revenue and certainly not API revenue. Nothing published tells you how much developer usage existed.
3. Your integration was collateral damage
Here is the part worth sitting with. Nothing in any account suggests the API failed. What failed was a consumer social app for making short videos, and what followed was a compute allocation decision inside a company that has said it does not have enough compute to go around.
If you shipped a feature on this API, you did nothing wrong and there was no engineering decision available to you that would have prevented this. Your dependency was ended by the economics of an unrelated product. Usage did not protect you, correctness did not protect you, and paying did not protect you.
A capability can be withdrawn while working perfectly, for reasons that have nothing to do with you.
That is a different risk from the ones teams normally plan for, and it is the one that most often turns a working prototype into an emergency. It is the same category of surprise we wrote about in what actually breaks between prototype and production.
4. What to do if you have Sora in production
Five steps, in this order, and the order matters because step one usually changes how big people think this job is.
Search for the five model strings and count the call sites. Then decide, per feature, whether you are replacing the capability or removing the feature and telling users. Both are legitimate; quietly shipping worse video is not.
When you shortlist a replacement, choose on the job rather than the leaderboard: latency you can live with, licensing and content terms your business can actually accept, and output your customers will tolerate. Google, Runway, Luma and several strong models from Chinese labs all have real developer offerings, and the right one depends on what you are generating and where it will be published.
“Swapping a video model is a small job”
Behind one interface, it is. It is a config change and a round of output testing. At forty call sites written directly against a vendor SDK, spread across three services and a scheduled job nobody remembers owning, it is a quarter. The size of this migration is not set by the vendor. It was set by how your code was organized long before the notice arrived.
5. The lesson that outlives this deadline
The instinctive reaction is to distrust OpenAI. That is the wrong conclusion. Every serious lab retires models on a schedule, and a vendor that publishes deprecation dates and gives six months of notice is behaving better than one that does not.
The right conclusion is about concentration. Futurum’s 1H 2026 research, from a survey of 838 organizations, found 61 percent naming OpenAI as their primary generative AI platform. Concentration is efficient right up to the moment it is a single point of failure, and this shutdown is a small, survivable rehearsal for a larger one.
So ask two questions of every AI dependency you have. If this capability disappeared in six months, how many files would we edit? And if it disappeared next week, what would our users see? A team that can answer both is not exposed to this class of event. A team that cannot has a project waiting for them, scheduled by someone else. Getting the plumbing right is the same argument behind standardizing how your systems talk to models.
- Every call site using a sora-2 model is found and counted
- Each affected feature has a decision: replace the capability, or remove it and tell users
- The replacement was chosen on latency, licensing and output quality, not on a leaderboard
- One module owns video generation, so the vendor name appears in exactly one place
- The new vendor was tested on your real inputs, not on demo prompts
- Someone owns the inbox that deprecation notices arrive in
Myth vs Facts
Myth: “OpenAI explained why it is shutting the Sora API down.”
Fact: It did not. The notice is a date and five model names. Every reason in circulation is journalism, mostly one Wall Street Journal investigation about the consumer app. Credible, but not a company statement, and not about the API.
Myth: “There will be a drop-in replacement from OpenAI.”
Fact: The deprecation entry names none. Model retirements normally point at a successor because the vendor wants to keep you. The absence of one here is the difference between an upgrade path and an exit.
Myth: “Sora made almost no money, so nobody was using the API.”
Fact: The 2.1 million dollar figure people quote is in-app purchases from the consumer app, second hand, and says nothing about developer usage. No published number tells you how many production systems are affected. Yours counts regardless of how many others there are.
Myth: “This is an OpenAI problem, so use a different lab.”
Fact: Every lab deprecates models, and OpenAI at least published a date six months out. Switching vendors without changing your architecture just re-buys the same risk under a new name. The fix is structural, not a change of logo.
The Sora API shutdown, assumption by assumption
| What you might assume | What the record shows | What to do about it |
|---|---|---|
| Something better is replacing it | The notice names no replacement | Shortlist third-party vendors yourself |
| It failed as a developer product | The consumer app failed and compute moved | Do not assume your usage protects you |
| Six months is plenty of notice | It is, if someone owns the inbox it arrived in | Give deprecation notices an owner |
| Swapping video models is small | Small behind one interface, a quarter at forty call sites | Wrap the vendor before you need to |
| The revenue figure proves nobody cared | It is in-app purchases, and second hand | Do not plan around a miscited number |
| Big vendors do not remove capabilities | This one went months after a reported billion dollar license | Treat every model as replaceable |
What this means if you’re running AI in your business
Most companies are not affected by this particular shutdown. Almost all of them are exposed to the pattern, because the normal way to add an AI feature is to call a vendor from wherever the feature happens to live, and that decision is invisible until a deprecation notice makes it expensive.
We build agentic systems that depend on frontier models, so this is a live design constraint rather than a philosophical one. The models sit behind interfaces we control, the choice of provider is configuration, and swapping one is a test run rather than a rewrite. That is also why we push clients toward owning the workflow and treating the model as a component, which is the heart of the build versus buy decision: you can rent capability safely, as long as you own the shape of the thing that uses it.
How exposed are you to the next deprecation?
Tick each that applies to you.
- You could not say today how many places call a model provider directly
- No one person receives and reads vendor deprecation emails
- A model name is hard-coded in more than one service
- You have no tested fallback if one provider is unavailable for a day
- An AI feature would silently degrade rather than fail visibly
If This Were Your System, Here’s Our First Move
We would spend the first day counting, not choosing. Every place your code names a model provider, every feature that depends on one, and what a user would see if each stopped answering. That inventory is usually the moment the real scope becomes clear, and it is frequently larger than expected.
Then we would put each vendor capability behind one interface you own, move the provider choice into configuration, and test the replacement on your actual inputs rather than a demo prompt. For a team with a September deadline, that is the difference between a scramble now and a config change the next time this happens, because there will be a next time.
If you have Sora or any single provider wired through your product and you are not sure how deep it goes, send us what you are running and we will map the exposure before anything needs rewriting.
