OpenAI gave six months' notice on Sora: dates and a checklist

OpenAI's deprecations page says it notified developers on March 24, 2026 that the Videos API and the Sora 2 model aliases and snapshots would be removed on September 24, 2026, and it lists no recommended replacement for any of them. That is a six-month window, and it has now closed.

If you integrated Sora, the useful lesson is about the shape of the notice: a date, a list of exact ids, and an empty replacement column. Whoever owns your video pipeline has to choose the replacement themselves.

The six items on the removal list

These are the entries on OpenAI's page. Every one has the same shutdown date and the same blank replacement.

What a six-month notice buys you

Six months is long enough to run a proper replacement test, if you start in the first month rather than the last. A repeatable test is cheap on a per-second catalog. Sume's video generation docs show how to list every model with GET /v1/videos/models, and each row reports its supported resolutions, durations, aspect ratios and whether it produces audio. Sume bills the provider list price times 1.25 per output second, so a ten-prompt trial on one 5-second row is a number you can compute before you submit.

• Week 1: grep for model ids and for the endpoint path, and write down every duration and size you send.
• Week 2: map each call to a candidate whose row accepts that duration; reject candidates that clamp.
• Week 3: run the same ten prompts on two candidates and compare by eye.
• Week 4: ship behind a flag and keep the old path until the date.

Make the next retirement boring

Keep the model id in one config value, log it with every job, and keep a short list of fallback ids that you have already tested. Sume also offers model: "sume/auto", where Sume selects the family; the docs say the response reports sume/auto and that Sume does not disclose which family ran, so use a pinned id when you must know exactly what produced a clip.

Why the empty replacement column matters

Deprecation tables from some vendors name a successor, which makes a migration a find-and-replace plus a regression test. This one does not, which turns the migration into a product decision. A Sora call carried assumptions: a clip length, a frame size, a price, a tone of motion. Each of those has to be matched against a new model's documented envelope, not guessed.

The cheapest way to do that is to write the assumptions down as a spec and score candidates against it. A spec has five lines at most: length in seconds, aspect ratio, resolution, whether sound is needed, and whether references or edits are used. Everything else is taste, which a ten-prompt side-by-side will settle.

A one-page spec template

Fill this in once per use case, not once per call site. Most teams find that two or three specs cover every Sora call they had.

• Length: the shortest and longest clip you send, in whole seconds.
• Frame: aspect ratio and the smallest acceptable resolution.
• Sound: required, optional, or not wanted.
• Inputs: text only, a first frame, references, or an existing clip to edit.
• Budget: the most you can pay for one finished clip.