Format run `model` picks the orchestrator, not the video model
A new image or video model launches and you set model on a Sume Format run. That field picks the orchestrating LLM only; media models come from Format tools.

On a Sume Format run, the model field chooses the language model that orchestrates the run. It does not choose the image, video or audio model that renders the pixels. Those come from the Format's tools. So when a new generation model is announced, adding its name to model does nothing useful: the call docs say an id outside the Agents catalog is 400 invalid_request. To change which media model a Format uses, change the Format, or call a generation endpoint where the model is a field.
Two different meanings of model
The word is overloaded, and launch weeks make it worse. On POST /v1/formats/{handle}/{slug}/runs, model is optional and means the orchestrator. Omit it for the gpt-6-sol default. A request for the retired gpt-5.6-sol runs on gpt-6-sol, and the receipt echoes the id that actually ran, so you can see what was used.
On the generation surfaces, model means the media model. POST /v1/videos takes a catalog id such as seedance-2 or the sume/auto routing pseudo-model, and the catalog lists what each supports. The two catalogs are different, so the same string is valid in one place and a 400 in the other.
| Where you send it | What model means | Valid values |
|---|---|---|
| POST /v1/formats/{handle}/{slug}/runs | Orchestrating LLM | Agents catalog id; omit for gpt-6-sol |
| POST /v1/videos | Video model | Video catalog id or sume/auto |
| Format tools | Image, video and audio models | Chosen by the Format, not the request |
A guard against the mix-up
The helper below builds a Format run body and refuses a media model id in the orchestrator slot, so the mistake shows up in a unit test instead of as a production 400. The set of media ids is yours to maintain from the catalog; the ones shown are examples from the Video Router. It runs on any Python 3.
MEDIA_MODEL_IDS = {"seedance-2", "seedance-2.5", "kling-3", "minimax-h3-max", "h3-max-recast"}
def build_body(instruction, input_obj, orchestrator=None):
body = {"instruction": instruction, "input": input_obj}
if orchestrator:
if orchestrator in MEDIA_MODEL_IDS:
raise ValueError(f"{orchestrator} is a media model; `model` picks the orchestrating LLM")
body["model"] = orchestrator # omit to get the documented default
return body
print(build_body("15 s teaser", {"sku": "A1"}))
try:
build_body("15 s teaser", {"sku": "A1"}, orchestrator="seedance-2")
except ValueError as e:
print("refused:", e)How to actually adopt a new media model
If a launch matters to you, there are two honest paths. For a generation endpoint, read the catalog, check that the new id is listed, and change the model you pass; if it is not listed yet, Sume has not shipped it and you should not assume it has. For a Format, the media model is a property of the Format's own tools and instructions, so the change belongs in the Format, tested with a few runs before you rely on it.
Either way, check the receipt. It echoes the orchestrator id, and its artifacts show what was produced, so you can compare before and after on a handful of identical inputs. Keep the old Format version available for a rollback.
Pin or omit
Omit model unless you have a reason. The documented default moves with Sume's catalog, and retired ids are mapped for you, which is less work than pinning. Pin only when you need reproducibility across weeks, and record the id from the receipt rather than your request so your logs show what ran.
What to log
Log three things per run: the model you sent, the id the receipt echoes, and the Format version you called. When output quality shifts after a launch, those three tell you whether the orchestrator changed, the Format changed, or neither did and the cause is elsewhere. Keep the media model ids you care about in the Format's own documentation, so the person who edits the Format knows which tools it relies on. A retired orchestrator id is mapped to its replacement by Sume, which is convenient but means your request and the receipt can legitimately disagree.
If you manage several Formats for several teams, add a short line to each Format's description saying which orchestrator it was tested with and which media tools it relies on. People who later pin or omit model will then be choosing from facts rather than guesses, and a launch announcement becomes a checklist item for the Format's owner instead of a rumor in a chat channel.
Sources
Related posts
More in Formats
- Format run spend cap: above the Format cap is honored, null is $500
generation_spend_cap_usd on a Sume Format run may exceed the Format's cap and is not clamped; null runs at the $500 maximum; 0 or over 500 is a 400.
- Format run spend: wait for usage.final before you quote a cost
On a Sume Format receipt, debited is the cost, held and refunded are not spend, and final turns true only once no hold is open.
- Watch a Format run's spend against its cap while it runs
A Format run's receipt reports usage.cap with limit, counted and remaining while it is in flight. Read it to see how close a video run is to failing on its cap.
- Format run webhook retries: dedupe on request_id, order by created_at
Sume Format run webhook retries repeat request_id, which equals run_id. Dedupe on it and order deliveries by created_at, which changes per built body.
Written by Sume