Which Sume video model is fastest? The catalog's latency labels
Each Sume video model card carries a typical-latency label. Which rows are fast, medium or medium-slow, and what you pay for the faster ones.
Sume does not publish a measured seconds-per-clip figure for video models, and this post does not invent one. What the repo does carry is a typical-latency label on each Video Router model card: fast, medium, or medium-slow. Those labels are the honest basis for choosing a model when the wait matters, for example when a user is watching a spinner.
The labels below come from the model cards in the Sume API source (read 2026-10-07). Prices are the billed rates at 720p, 9:16, list x 1.25.
The labels, sorted
| Model id | Typical latency | Max clip | 5 s price | Why you would pick it |
|---|---|---|---|---|
| seedance-2-mini | fast | 15 s | $0.95 | Cheapest Seedance 2.0 row |
| seedance-2-fast | fast | 15 s | $1.52 | Lower latency than seedance-2 |
| seedance-2 | medium | 15 s | $1.89 | Quality over Mini at the same limits |
| seedance-2.5 | medium | 30 s | $2.89 | Longest Seedance clip, 1080p, many references |
| wan-3.0 | medium | 30 s | $0.63 | 2 s floor, 30 s ceiling |
| gemini-omni-flash-1.1 | medium | 10 s | $0.63 | Edit mode and 4K |
| minimax-h3 | medium | 15 s | $0.38 (768p) | Character consistency from references |
| grok-imagine-video-1.5 | medium | 15 s | $0.07 | Image-to-video only |
| kling-3 | medium-slow | 15 s | $0.70 silent / $1.05 audio | Cinematic motion, 1080p without references |
| minimax-h3-max | medium-slow | 15 s | $0.50 (768p) | Faster than a full-size MiniMax tier at native 768p |
How to use the labels
Only two rows are labelled fast, and both are Seedance 2.0 variants. If you need a quick result, send the same prompt to seedance-2-mini first. At 5 seconds it costs $0.95 per clip, and you can promote the best prompt to seedance-2.5 later.
The two medium-slow rows, Kling 3 and MiniMax H3 Max, are the ones to keep out of a synchronous request path. Use callback_url or poll GET /v1/videos/{id}; the docs suggest a 30-second poll interval. Long waits are normal for these rows, and a job that stays in pending is not a failure.
A measured number beats a label
Time ten of your own prompts on the two models you are deciding between, and log the gap between POST /v1/videos and status: completed. Queue depth and resolution both move the result, so a label ranks models and does not predict a number. Treat any wait-time figure from a vendor page or blog, including this one, as a hint that must be confirmed with your own prompts.
Sources
Related posts
More in Developers
- Sume webhooks: 10 attempts 30 seconds apart for a video receiver
A Sume job webhook is tried up to 10 times, 30 seconds apart by default, with a 10 s timeout each. What that means for a video receiver, plus a Python verifier.
- Sume webhook.test has no job_id: keep it out of your job table
The dashboard's Send test posts a signed webhook.test with no job_id. Route on event first, dedupe on job_id second, and no phantom job row appears.
- Can a Sume webhook arrive twice? Build an idempotent receiver
Sume retries failed webhook deliveries up to 10 times and Redeliver replays a real event, so one terminal event can reach you twice. Dedupe on job_id or run_id.
- Sweep Format runs for failed webhook deliveries, then redeliver
Sweep in Python: read each run's webhook_delivery, redeliver only failed or exhausted ones, and leave the rest alone. Uses formats:read, formats:write.
Written by Sume