Sora 2 vs Veo 3 for Video Ads: One Leaves the API on Sept 24

When a head-to-head has a deadline on one side

As of September 19, 2026, only one side of this comparison has a future you can schedule around: OpenAI's deprecations page lists the Videos API and every Sora 2 model identifier for removal from the API on September 24, 2026, and the column where a recommended replacement would go is blank. Google's side is not called Veo 3 any more, it is Veo 3.1, documented and priced in the Gemini API at 720p, 1080p and 4k with natively generated audio.

That makes this a strange comparison to write and a simple one to act on. You searched a quality question. For the next five days the honest answer is a calendar question, and after that, for anyone calling the public API, it stops being a question at all.

So here is the head-to-head you typed, dated to the day. Then the part that still matters in October: what Veo 3.1 is, what it costs by the second, and the two clocks inside it that catch ad teams out.

The quick answer, dated September 19, 2026

Both halves of this answer come from the vendors' own pages, fetched on the day this post published. Neither is a forecast.

What OpenAI's page says about Sora 2

The deprecations page carries a section headed with the date of the notice, and one sentence does the work: "On March 24th, 2026, we notified developers using the Videos API and Sora 2 video generation model aliases and snapshots of their deprecation and removal from the API on September 24, 2026."

Under it sits a table with six rows, every one dated 2026-09-24: the Videos API itself, sora-2, sora-2-pro, sora-2-2025-10-06, sora-2-2025-12-08 and sora-2-pro-2025-10-06. On September 19, 2026 that section still sits above the page's past-deprecations heading, in the upcoming list, and OpenAI's Help Center, in a capture dated September 14, 2026, still writes it in the future tense: "The Sora API will be discontinued on September 24, 2026."

What Google documents on its side

Google's Gemini API page for the model is equally plain: "Veo 3.1 is a model for generating 8-second videos (720p, 1080p, or 4k) with natively generated audio." The duration parameter takes 4, 6 or 8 seconds, and the docs add that it "Must be 8 when using extension, reference images or with 1080p and 4k resolutions." Three identifiers carry it: veo-3.1-generate-preview, veo-3.1-fast-generate-preview and veo-3.1-lite-generate-preview.

Dimension	Sora 2 (OpenAI)	Veo 3.1 (Google)
API surface	Videos API	Gemini API
Model identifiers	sora-2, sora-2-pro, three snapshots	three -preview identifiers
The date on the record	Removed from the API Sept 24, 2026	Rate card updated Sept 16, 2026
Recommended replacement	Column blank	n/a
Consumer app	Discontinued April 26, 2026	n/a

What changes on the 24th, and what does not

What the page says goes on that date:

• The Videos API stops being a listed endpoint.
• sora-2 and sora-2-pro stop resolving as public model identifiers.
• The three dated snapshots go with them, including the default one.
• Anything of yours pointing at those strings loses its target.

What is not in that row, and gets misreported anyway:

• The app and web experiences. Those ended earlier, on April 26, 2026.
• A successor. The replacement column is blank, so nothing is inherited automatically.
• Every other video model in your stack. This is one supplier's calendar, not the category's.

The five-day clock, in OpenAI's own words

A deprecation notice reads like paperwork and lands like a production incident, so it is worth reading precisely rather than quickly. Three details change what you should do.

Two dates, and they are not one event

The consumer product and the developer surface went on different days under different notices. OpenAI's Help Center states both in the same article: "The Sora web and app experiences were discontinued on April 26, 2026" and "The Sora API will be discontinued on September 24, 2026."

Collapsing those into a single shutdown is the most common error in coverage of this, and it produces bad advice in both directions. If you assumed the whole thing ended in April, you may have skipped an export you still had time to run. If you assumed the consumer app was fine because the API rows are only dated September 24, 2026, that has not been the case since April 26, 2026.

The blank column is the story

Plenty of deprecation rows name a successor. These do not. The Recommended replacement column beside all six Sora rows is blank, while other tables on the same page point developers at named replacement models.

Resist the urge to fill that column in your head. No OpenAI surface we could reach names a successor video model, so the accurate sentence is the narrow one: a removal date was published, a replacement was not. If you have already accepted the move and want a switching list rather than a comparison, our four-model switch plan for the Sora shutdown is where that work lives.

What "removed from the API" does not mean

It does not mean the weights evaporate at midnight for every customer on earth. The same deprecations page notes that "In some cases, developers may be able to provision dedicated capacity for continued access after a model's shutdown date."

So the bounded, defensible claim is this: the public API listing ends on September 24, 2026, and the consumer app and web experiences ended on April 26, 2026. Anything broader than that is a guess dressed as news, and it is the kind of guess that gets repeated until somebody plans a quarter around it.

Get your Sora work out before the 24th

This is the part that has an actual deadline attached, and it is the beat most comparison posts skip because it is unglamorous.

The export surface

OpenAI's Help Center names the place: "You can export content you created in Sora by going to sora.chatgpt.com/sunset" and clicking Export, after which you get an email when the archive is ready. That is a first-party instruction, not a workaround someone found on a forum.

What the deletion notice says

The same article is direct about what follows: "After Sora is discontinued, and after the period of time of any final export window passes (if we are able to offer one), we will permanently delete any data associated with your use of Sora."

Read the parenthesis. A final export window is described as something OpenAI may be able to offer, not something promised, which is exactly the shape of sentence you should treat as a deadline rather than a cushion.

A migration checklist for an ad account

Half an hour of this now is cheaper than a campaign that fails to launch on a Tuesday.

• Export from the sunset page and store the archive somewhere your team will still find it next quarter.
• Grep your repo, your prompt library and your automation tools for sora-2 and sora-2-pro. An identifier that stops resolving fails as a 404 in a log, not as a helpful message in a dashboard.
• List the ads that are still spending and note which ones were rendered on Sora. Those are the only ones worth re-rendering first.
• Re-render your two or three best performers on a currently documented model, then compare hook retention on the new cuts before you swap them in.
• Write the model name into your creative log next to each asset. The next time a vendor retires something, that log is what turns a hunt into a filter.

The wider lesson is unsentimental: a model identifier is a dependency, and dependencies get versions, deprecation notices and end dates. Treating creative tooling like infrastructure is not overkill, it is the reason a shutdown becomes an afternoon of work instead of a bad week. For the longer view of how these models get chosen and replaced, our Seedance 2.0 versus Sora 2 retrospective is a dated record of what that decision looked like earlier this year.

Your keyword says Veo 3. Google's docs say Veo 3.1

This is not pedantry. It is the difference between a comparison that survives a reader clicking through and one that does not.

The three identifiers you would actually pin

In the Gemini API, the current model ships as veo-3.1-generate-preview, with veo-3.1-fast-generate-preview and veo-3.1-lite-generate-preview beside it on the rate card. All three still carry the -preview suffix as of September 19, 2026, which is worth knowing if your integration pins model strings rather than resolving an alias.

What the current model generates

The documented shape, straight from Google's page:

• Length: 4, 6 or 8 seconds, with 8 required for 1080p, 4k, reference images and extension.
• Resolution: 720p, 1080p or 4k.
• Audio: generated natively with the video rather than added in a second pass.
• Tiers: Standard, Fast and Lite, each with its own per-second price.

For most vertical ad work that is a single hook or a single beat, which is why the interesting question is rarely one clip. It is how many you can afford to try, and that is a pricing question rather than a modelling one.

Why the version gap matters here

If you benchmarked Veo 3 in the spring and filed a verdict, that verdict is attached to a version number Google's current docs do not use. Re-run it, or at least date it. And if what you actually want is the shot-craft adjudication rather than the availability one, our Seedance 2.5 versus Veo 3.1 comparison runs it properly on realism, motion, audio, length and cost per clip, which is deliberately not what this page is for. A broader field sits in our Veo alternatives roundup.

What re-rendering on Veo 3.1 actually costs

A migration is not a pricing page, it is a re-render bill, and those two numbers are not the same thing.

The rate card is per second, not per clip

Google's Gemini API pricing page, last updated 2026-09-16 UTC, prices Veo 3.1 by the second of output: Standard video with audio at $0.40 for 720p and 1080p and $0.60 for 4k, Fast at $0.10 for 720p, and Lite at $0.05 for 720p.

Per-second pricing quietly rewards discipline. A four-second hook is literally half the cost of an eight-second one, and the tier you pick moves the bill by 8x before anyone argues about creative.

The arithmetic for one eight-second ad

Do the multiplication once and keep it somewhere visible:

• Standard, 720p or 1080p: 8s x $0.40 = $3.20
• Fast, 720p: 8s x $0.10 = $0.80
• Lite, 720p: 8s x $0.05 = $0.40

Why per-second pricing changes the brief

When a model bills by the second, length stops being a stylistic choice and becomes a line item. A six-second hook and an eight-second hook are not the same purchase, and on a twenty-variation test the difference is a real number rather than a rounding error.

This is worth pushing back into the script stage. Most UGC hooks earn their attention in the first two seconds and spend the rest paying it off, so writing to six seconds instead of eight is usually a tightening exercise rather than a sacrifice. Pick the tier the same way: a Lite render is fine for a concept you are still arguing about internally, and a Standard render is for the cut you are about to put money behind. Deciding that before you brief is cheaper than deciding it after you have rendered eighty clips at the top tier.

A worked example: twelve hooks, rebuilt

Say a skincare brand had twelve hook variations rendered on Sora and wants them back before the end of the month. Twelve eight-second clips on Fast at 720p is 12 x $0.80 = $9.60 of model spend. The same twelve on Standard is 12 x $3.20 = $38.40.

Neither number is the real cost. The real cost is the second pass, because the first pass of any migration produces two or three clips where the pacing drifted or the read landed flat, and you re-render those. Budget a 30% overshoot and the migration stays boring. Budget exactly twelve renders and you will be arguing about ten dollars at eleven at night. If you would rather not meter any of this by hand, you can run the same model inside Novoads at a flat credit price per video.

Veo's other clock: two days on the server

Every team that has migrated onto Veo has discovered this rule the same way, which is by losing a render.

What the documentation says

Google is explicit: "Generated videos are stored on the server for 2 days, after which they are removed." And, in the same breath: "To save a local copy, you must download your video within 2 days of generation."

Why an ad team gets caught by it

Ad production is not a weekday-shaped activity. A batch runs on a Friday evening, the person who triggered it is on a plane Saturday, and by Monday afternoon the files are gone from the server even though the job succeeded and was billed. Nothing failed, which is precisely why nobody noticed.

The second trap is subtler. When a video is referenced for extension, its two-day storage timer resets, so a stitched sequence and a one-shot clip can have genuinely different expiry times inside the same project. That is not a bug to work around, it is a rule to encode.

What to do instead

• Download inside the render job itself, not as a manual step afterwards.
• Write every finished asset to your own storage with the model name and the date in the filename.
• Treat the vendor's server as a delivery queue, never as an archive.

Two days is a generous window for a script and a short window for a human process. The fix is to remove the human from that particular loop, which is a good rule for render times generally.

How Novoads solves the stranded model identifier problem

Novoads runs Google Veo 3.1 behind the same login as the rest of its video models, so when a vendor retires an identifier, repointing it is our migration rather than yours. Uploading a product photo or writing a script and picking an AI actor gets you an ad-ready vertical video, and the model behind it is a dropdown rather than a dependency in your codebase.

Veo 3.1 costs a flat 72 credits per video in Novoads, alongside cheaper Seedance and Kling options for the volume end of a test plan, and the credit ledger is the same whichever one you pick. Novoads starts at $15/month (Starter, 200 credits per month), all plans are published on /pricing, and the assets land in your library rather than on a vendor's two-day timer. If you are curious how the credit math works across models, we broke it down in our guide to AI video credits.

That is the whole pitch. It is not that any single model is untouchable. It is that the number of vendors whose roadmap can freeze your ad calendar should be smaller than one.

Availability belongs on the comparison sheet

Every model comparison you have read this year scored realism, motion, audio and price. Almost none of them scored whether the model will still answer a request next quarter, and that turned out to be the row that decided this particular head-to-head.

So add it. The next time you compare two generators, write down four things before you score a single frame:

• The version the vendor's own documentation names today, not the one you remember.
• The date its pricing page says it was last updated.
• How long the vendor keeps your output before deleting it.
• Whether any vendor surface carries an end date for the model or its endpoint.

Those four facts take ten minutes to collect and they age better than any quality verdict, because a model you cannot call has no quality at all.

If you want the creative side of the decision rather than the calendar side, our guide to making AI video look real is the better next click. Then come back and fill in the availability row yourself.