sume/auto 400 unsupported_capability: 11 s, 2 s, 480p and silent audio
sume/auto fails closed on 2 s, 11 s, 480p, 768p and generate_audio false. The request is rejected before any provider call. Here is what to send instead.

sume/auto returns a 400 unsupported_capability for a duration of 2 or 11 seconds, a resolution of 480p or 768p, and generate_audio: false. The request is rejected with no provider submission. Sume does not quietly reroute it to another model. The limit is the Gemini Omni Flash 1.1 envelope, which is the model sume/auto validates against for text, frame and reference inputs.
What auto accepts and refuses
Per the Videos doc:
| Field | Accepted | Fails with 400 |
|---|---|---|
| duration | 3-10 s, default 8 s | 2 s, 11 s |
| resolution | 360p, 720p, 1080p, 4K (default 720p) | 480p, 768p |
| aspect_ratio | 16:9, 9:16 | Anything else, for example 1:1 or 21:9 |
| generate_audio | Omit, or true | false |
Why a platform spec makes this matter
A spec such as TikTok's up-to-10-minutes or YouTube's up-to-3-minutes is far above what one auto clip can be. If you ask auto for 15 seconds because the ad should be 15 seconds, you hit the 400. The error is fail-closed on purpose, since the caller cannot see which model is behind sume/auto. The message and details.model name sume/auto, and supported lists the values the API accepts, so read that list instead of guessing.
Three ways to fix it
- Cut the length to 10 seconds or less and join clips in Timeline.
- Pin a model that lists the length, for example
seedance-2.5at 4 to 30 seconds. - Leave
generate_audioout of the request. If you need a silent clip, pick a model whose catalog entry has a toggle, or mute it after generation.
Reading the error
The 400 body names sume/auto rather than the model that would have served the request. That is deliberate: the caller never sees the family behind auto, so the error cannot reveal it. What you get is a list called supported with the accepted values. Parse that list and show it to whoever wrote the request, rather than retrying with a guess.
A retry loop is the wrong response. The request is wrong, not the server, so sending it again will fail the same way. Treat unsupported_capability as a validation error in your own code, log the field that was out of range, and stop.
Because auto and pinned models have different envelopes, keep them as separate code paths if you can. One path sends sume/auto with 3 to 10 seconds and 16:9 or 9:16. The other sends a named model and reads that model's lists from the catalog. Mixing them in one function is how a 15-second request ends up in the wrong place.
The tradeoff
Auto is the lowest-effort route and its envelope is narrow. Pinned models give you longer clips, but you take on reading each model's own limits. Fetch GET /v1/videos/models and check supported_durations before you submit. The 3 to 10 second limit post covers the join pattern.
Sources
Related posts
More in Developers
- AI video client timeout: the Sume job still runs and still bills
A timeout on your HTTP client does not cancel a Sume job. Save the job id, poll the polling_url, and cancel only before generation starts. Python example.
- Sume mode webhook without a webhook_url: no delivery is armed
On a Sume Format run, communication.mode is descriptive; only a webhook_url arms delivery. Send the URL, then keep status_url as your backup.
- Sume idempotency: JSON key order is ignored, array order is not
Resending a Sume job with the same fields in a different JSON key order still returns the original job. Changing an array's order or a value gives a 409.
- How long does a Sume Idempotency-Key last? The docs don't say
The Sume docs describe Idempotency-Key replay and the 409 conflict but give no lifetime. What is documented, what is not, and a safe way to design around it.
Written by Sume