AI video models compared: Veo 3.1, Kling, Wan and Sora's exit

Five days before this article was written, OpenAI shut down its Videos API. The deprecations page lists the Videos API, sora-2 and sora-2-pro — every variant — as announced on 24 March 2026 and shut down on 24 September 2026, with no replacement named¹. The Sora 2 model page now says the model and API were discontinued on that date².

That is the most useful fact in any video model comparison this year. Video models are young, their APIs change shape often, and a model you build a product around can leave with six months' notice. So this comparison sticks to what vendors document, gives you a way to choose for your own prompts, and treats "how hard is it to move" as a first-class criterion.

What to compare, and what not to

Leaderboards for video are subjective, change monthly and rarely match a specific product's prompts. The facts that decide whether a model can serve a workload at all are more stable and are published by each vendor:

• Clip length per generation, and whether clips can be extended.
• Resolution and aspect ratio, and the combinations that are allowed together.
• Audio: generated natively, supplied by you, or absent.
• Job semantics: how you submit, poll or receive a callback, and the status values.
• Output retention: how long the finished file stays downloadable at the provider.
• List rate per second of output, and what moves it.

Everything below comes from the vendor's own page, opened on 29 September 2026. Where a page did not state something, the table says so rather than guessing.

The documented facts, side by side

Google Veo 3.1. The Gemini API offers three preview models: veo-3.1-generate-preview, veo-3.1-fast-generate-preview and veo-3.1-lite-generate-preview. Clips are 4, 6 or 8 seconds; 1080p, 4K, reference images and extension all require 8 seconds. Veo 3.1 and Fast render 720p, 1080p and 4K; Lite stops at 1080p. All three generate audio natively, aspect ratios are 16:9 and 9:16, and generated videos are kept on Google's servers for two days. Google documents request latency from 11 seconds to 6 minutes at peak, and every video carries a SynthID watermark³.

Kling VIDEO 3.0 series. Kling's own guide says the 3.0 series generates from 3 to 15 seconds, with native audio covering dialogue, ambience, effects and lip movement, native 4K output, and multi-shot generation that sets framing and camera movement per shot within one request⁴.

Alibaba Wan 2.7. The text-to-video reference lists wan2.7-t2v (with a dated snapshot), 2 to 15 second clips defaulting to 5, 720P or 1080P, and five aspect ratios. Without an audio_url the model adds background music or effects; with one, it uses your WAV or MP3. The task id and the video URL are both valid for 24 hours only⁵.

MiniMax H3. MiniMax's current video guide lists MiniMax H3 (768P or 2K, 4–15 seconds) and H3 Max (480P or 768P, 5–15 seconds), with text-to-video, first- and last-frame image-to-video, and generation from reference images, video or audio⁶.

xAI Grok Imagine video 1.5. grok-imagine-video-1.5 generates up to 15 seconds; you start a request, poll /v1/videos/{request_id}, and stop at done, failed or expired⁷. xAI's model page lists it at $0.080 per second⁸.

ByteDance Seedance 2.5. BytePlus ModelArk documents Dreamina Seedance 2.5 behind a task API with create, retrieve, list and cancel-or-delete operations⁹. The model's own tutorial did not load for this article, so its clip limits are not listed here.

List rates per second

Video is billed per second of output, and resolution usually moves the rate. The chart shows only rows in INFRO's model catalog whose vendor rate carries a checked source.

Google lists Veo 3.1 at $0.40 a second at 720p and 1080p and $0.60 at 4K; Veo 3.1 Fast at $0.10, $0.12 and $0.30; Veo 3.1 Lite at $0.05 and $0.08¹⁰. Runway lists Gen-4.5 at $0.12 a second and Gen-4 Turbo at $0.05¹¹. For Sora 2 the model page still shows $0.10 a second at 720p², but that rate no longer buys anything.

Two practical notes. Per-second rates multiply by the seconds actually rendered, so a model whose minimum clip is longer than you need charges for footage you discard. And a rate on a vendor page is what an account without a negotiated agreement pays; if you have a contract, your own rate is the one that matters.

Asynchronous jobs are the real integration work

Every video API above is asynchronous. The shape is the same — submit, receive an id, poll or receive a callback, download — but the details differ in ways that break naive code:

• Status vocabulary. OpenAI's retired API used queued, in_progress, completed and failed¹². Wan uses PENDING, RUNNING, SUCCEEDED, FAILED, and UNKNOWN after expiry⁵. xAI uses done, failed and expired⁷. A client written for one maps poorly onto another.
• Retention. Google keeps Veo output for two days³; Wan's URL lasts 24 hours⁵; OpenAI's download URLs lasted at most one hour¹². Treat every provider URL as a handoff and copy the file to your own storage.
• Latency. Google's documented range runs from seconds to minutes³, and OpenAI noted that a single render could take several minutes, longer for higher resolutions and durations¹². Nothing in a video path belongs inside a user-facing HTTP request.
• Content rules. OpenAI's guide listed rejections for real people, copyrighted characters and music, and input images with human faces¹²; Google restricts person generation settings in some regions³. Test your actual prompt categories, including refusals.

How to choose for your workload

1. Filter on hard constraints. Required clip length, resolution, aspect ratio, audio, and regions you may process in. This usually removes half the list.
2. Write a fixed prompt set from real product requests: 20 to 50 prompts, including the ones that must be refused.
3. Render each prompt on the remaining two or three models with the same duration and resolution, and have the people who own the output rate them blind.
4. Compute cost per accepted clip: list or negotiated rate × seconds × renders per accepted result.
5. Record the job behaviour you observed: time to completion, failure rate, and how failures were reported.
6. Keep a second model qualified. A shutdown with no named replacement is exactly the case where an already-tested alternative is worth having.

Running video jobs through INFRO

INFRO documents one asynchronous job API for video: POST /v1/videos returns 202 with a job in queued, and the job moves through running to succeeded, failed or canceled. The submit is checked against your budgets using the requested duration; INFRO then submits the render to the first of your connections that accepts it, trying the next target on your route if a submit fails, and checks the provider for status about 15 seconds after submitting and then every one to five minutes. Once a provider has accepted a render it is never moved, and a render unfinished after 60 status checks fails with 408 request_timeout. See video generation and async jobs.

Three details matter in production. Send an Idempotency-Key on the submit: a retry with the same key returns the original 202 instead of starting, and paying for, a second render. Prefer webhooks over polling — deliveries to endpoints configured in the console are signed with an HMAC you verify, retried on a widening schedule for about 16 hours, and may arrive more than once, so deduplicate on the event id. And copy the output: output.url expires 24 hours after completion, when INFRO deletes its copy.

A succeeded job carries usage.seconds and usage.cost, an estimate of what your provider will bill, with price_source naming the rate used; cost is null for an unpriced model, and INFRO records no cost for failed or canceled jobs. INFRO charges nothing per second; its subscription is separate from what your provider bills.

Keeping the model name in a route rather than in code is the lesson from Sora 2 either way: when a vendor retires a model, you change the route's targets, not every service that renders video.