sume/auto, auto and auto-: three spellings, and two ids it never picks

Video Router accepts auto-, sume/auto and auto as the same Auto pipe. Genjutsu and H3 Max Recast stay explicit picks. Defaults, limits and what to pin instead.

5 min readSume
All posts

The model field on the Video Router accepts three Auto spellings, auto-, sume/auto and auto, and all three let Sume pick the family. Auto never selects higgsfield-genjutsu or h3-max-recast: the router code removes both from its automatic model ids, so a person swap or motion transfer needs the id named in the request.

New code should send sume/auto through POST /v1/videos, which is what the Video generation docs recommend. The other spellings exist because the OpenAPI enum for Video Router lists them, and Video 1.0 is retiring and remains a compatibility alias for the same Auto pipe.

Defaults and limits on Auto

The Video Router docs state Auto create controls default to 720p and 8 seconds, with 3 to 10 second clips at 16:9 or 9:16. That is narrower than the catalog: seedance-2.5 takes 4 to 30 seconds and wan-3.0 takes 2 to 30, so a 20-second brief belongs on a pinned id.

The prompt is optional on Auto, and a task field carries an optional creative brief on auto-; the API reference says task is ignored on named catalog models. Auto also rejects bitrate_mode with a parameter error, as the code shows.

Auto versus pinned ids (read 2026-10-03)
NeedUseWhy
Let Sume choose, 3 to 10 s, 16:9 or 9:16sume/autoDefault 720p and 8 s
Clip longer than 10 sseedance-2.5 or wan-3.04 to 30 s and 2 to 30 s
Swap people in a videoh3-max-recastExplicit pick, 1 to 4 photos
Transfer motion onto reference imageshiggsfield-genjutsuExplicit pick, 1 to 8 images

What the response tells you

Responses echo sume/auto as the model, and the family that ran is never disclosed. Errors follow the same rule: validation code reports the name you sent, so a request that trips the resolved family's envelope still says sume/auto in the message. The docs tell you not to infer the family from any trait of the output.

Auto has no price of its own. The Video generation docs say Sume reserves the workspace balance at provider list × 1.25 for every model, so the usual multiplier applies whichever family serves the request.

Where the Seedance 2.5 and Wan 3.0 news fits

Vendor launches such as Seedance 2.5 and Wan 3.0 raise the same question every time: will Auto start using it? The docs give no promise either way, and they tell you not to infer the family from the output. If a launch matters to your product, call its id directly. seedance-2.5 and wan-3.0 are both in the catalog today, so you can pin them without waiting for Auto to do it.

A practical split: use Auto for exploratory work and early drafts, where saving a decision is worth more than knowing the family, then pin the family you liked for the production batch. Because Auto's routing is deterministic for an identical request and catalog version, you can also re-run an Auto brief later and expect the same routing, though not a guaranteed identical video.

Pin when the choice is part of the job

Pin an id whenever the model is part of the deliverable. A customer-facing person swap needs h3-max-recast, whose input is one source video plus one to four photos, and it will never come out of Auto. A reproducible A/B between Seedance 2.5 and Wan 3.0 needs both ids named, since Auto hides which one ran.

Auto suits the opposite case: a vertical product clip with no strong model preference.

``json { "model": "sume/auto", "prompt": "A vertical UGC-style product clip on a desk, natural light", "aspect_ratio": "9:16", "duration": 5 } ``

That is the example the Video generation docs give. Sending duration: 12 on the same model fails, since Auto stops at 10 seconds.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume