Sume Auto video: an idempotent replay prices and routes the same

When you send model: "sume/auto" to POST /v1/videos, the family that runs is chosen by Sume and never disclosed. The docs add one guarantee that matters for retries: resolution is a pure function of the normalized request and the catalog version, so an idempotent replay prices and routes identically. In practice, if your client retries a submit with the same Idempotency-Key, you get the original job back and you do not get a second, differently priced one.

This note explains what the guarantee covers, what it does not, and how to design retries around it.

What the guarantee says

Two inputs decide the outcome: the request after Sume normalizes it, and the catalog version at the time. Same inputs give the same answer. The docs call a replay with an idempotency key a retry that returns the original job, so for the same key the question of which family would run never arises a second time.

The poll response reports "model": "sume/auto". Sume does not disclose which family served the request, and the docs say you should not build on any observable trait of the output to infer it. That is the other half of the contract: stable resolution, opaque result.

What Auto controls look like

Auto create controls default to 720p and 8 seconds, with 3 to 10 second clips at 16:9 or 9:16, according to the Video Router page. If you need a square clip, a 21:9 clip or more than 10 seconds, pin a catalog model and read its row from GET /v1/videos/models.

Billing is the usual one: the workspace balance is reserved on submit at provider list times 1.25, and usage.cost on the poll is the Sume billable amount.

Retry design

The key is what makes a client crash safe. A worker that dies after submit and restarts can submit again with the stored key and get the original job.

• Generate one Idempotency-Key per intended clip, store it with the job record, and reuse it for every retry of that clip.
• Use a new key when you change the prompt, duration, ratio or any other field, because a changed payload under the same key is a conflict.
• Do not compare two Auto outputs to learn which family ran; the docs tell you not to rely on that.
• If you need a specific look, pin a model instead of sending Auto.

When to pin instead of using Auto

Auto is a convenience for requests that fit its controls. If you need a particular duration beyond 10 seconds, a square or ultra-wide frame, a reference video or a specific look, name a model. A pinned id is also the only way to compare two models on the same prompt, since Auto never tells you which family ran.

A pinned model has a row on the models list, so you can check durations, ratios and references up front. Auto has no row to validate against, which is the trade for not choosing.

Limits

The docs do not say how often the catalog version changes, so the guarantee is about replays of one request, not about two requests made weeks apart. A job you submit again next month with a new key is a new request and is resolved against whatever the catalog is then.