A Preview video model in production: pin a Sume id or use sume/auto?
Vidu calls Q4 a Preview. On Sume, pin a model id for a repeatable look, or use sume/auto, which hides the family and defaults to 720p and 8 seconds.
The short answer
If a clip must look the same next month, pin a model id. If you only need a good clip and do not mind which family makes it, use sume/auto. Vidu names its new model Q4 Preview, and its release makes no commitment about how the preview will change, so any pipeline built on a preview model should expect change. Sume does not list Vidu. Its docs say sume/auto never discloses which family served a request, and tell you not to infer the family from the output.
Pinned against auto
The two modes trade control for convenience. The numbers below come from the Sume docs and catalog.
| Property | Pinned id such as wan-3.0 | sume/auto |
|---|---|---|
| Which model runs | The one you named | Sume selects; never disclosed |
Poll response model | The id you sent | sume/auto |
| Default settings | Per model | 720p, 8 seconds |
| Clip length | Per model, such as 2-30 s for Wan 3.0 | 3-10 s, 16:9 or 9:16 |
| Idempotent replay | Same job | Same price and same route |
| 8 s at 720p, Wan 3.0 | 8 x $0.125 = $1.00 | Depends on the route chosen |
When pinning is the right call
Pin when a brand look has been approved, when a client compares revisions side by side, or when your cost model depends on one rate. A pinned id also protects a quote: 8 seconds of Wan 3.0 at 720p is always priced from the same catalog row until the catalog changes.
Use auto for exploration, internal drafts and scripts where the output goes through a human check. The docs say resolution is a function of the normalised request and the catalog version, so a replay with the same key gets the same price and route, but a new request may route differently after the catalog changes.
A preview rule of thumb
Treat a preview model as a supplier you have not yet signed. Keep the prompt, the references and the settings for every approved clip in your own storage, so you can re-create the look on another row if the first one changes. On Sume, GET /v1/videos/models lists the live rows, and the video generation docs explain the sume/auto addition. Check that list before each release, in the same way as the catalog check.
A request that pins
Pinning is one field. Send "model": "wan-3.0" in place of "model": "sume/auto" on POST /v1/videos and you get that row, its limits and its price. Auto changes nothing else in the request, so you can switch between the two by editing one string. A common pattern is to explore on auto, record the poll response, then pin the row you liked. Since auto reports only sume/auto as the model, keep your own note of the prompt and settings, not a model name.
Sources
Related posts
More in Developers
- Check probe.has_audio before paying $0.20 for Short captions
A silent clip makes speech-based captions fail with caption_no_speech. A probe-only Video inspect with frames false shows has_audio first. Captions are $0.20.
- Promise.allSettled for many Sume job statuses: isolate one failure
Check many Sume job statuses at once with Promise.allSettled so one 429 or network error is reported on its own row and does not hide the other results.
- Prompting Omni Flash with sound: write the audio as its own line
Gemini Omni Flash 1.1 always generates audio. A prompt layout that separates picture from sound, three example prompts, and the request on Sume.
- Python 3.15 rc3 in CI: test your Sume job poll logic before Oct 9
Python 3.15.0rc3 is out and the final is planned for Oct 9. Add a CI job that runs a stdlib unittest on your Sume status-poll decision function.
Written by Sume