sume/auto video returns 400 unsupported_capability: 2 s, 11 s, 480p

A request with model: "sume/auto" that asks for something Auto cannot serve fails closed with 400 unsupported_capability and is never submitted to a provider. Sume's video generation docs say Auto validates the request against Gemini Omni Flash 1.1: durations of 3 to 10 seconds (default 8), resolutions of 360p, 720p, 1080p and 4K (default 720p), 16:9 or 9:16, and native audio that is always on. Anything outside that envelope is refused rather than quietly routed to a different family.

The usual surprise is that other rows in the catalog accept values Auto does not. Seedance 2.5 takes 4 to 30 seconds, Wan 3.0 goes down to 2, and the MiniMax rows run at 480p or 768p.

Which Auto requests fail, and what fixes each?

These four are the cases the decision table in Sume's docs names. No balance is held for them, because they fail before submission.

Why does the error not say which model refused it?

Sume does not disclose which family Auto resolves to. The error names sume/auto, and details.model stays opaque, so the message cannot be used to learn the routing. Read the error message for the value that was refused, and GET /v1/videos/models for the values Sume advertises.

Do not build on observable traits of the output to infer the served family either; the docs tell you not to.

Should I pin a model or change the request?

If the value is incidental, change it: send 8 seconds at 720p and move on. If the value is the point, such as a 2-second sting or a 480p draft, pin a catalog id instead. wan-3.0 accepts 2 to 30 seconds, minimax-h3 and minimax-h3-max run at 480p, and seedance-2.5 reaches 30 seconds. Pinning costs you the default, but the request then validates against that row's own limits.

Because the request never reaches a provider, fixing the body and resubmitting is safe; reusing an Idempotency-Key with a different body is a 409, so send a fresh key.