Sent sume/video-1.0, the poll says sume/auto: the alias is rewritten

If you send model: "sume/video-1.0" to POST /v1/videos and the poll shows "model": "sume/auto", nothing is wrong. Video 1.0 is documented as a compatibility alias for the same Auto pipe, and the response reports sume/auto. Sume does not disclose which video family actually served the request.

The aliases

Auto routing is a Sume addition that the OpenRouter video API does not have. The id sume/auto is the recommended spelling for new code. The contract also accepts auto-, auto and sume/video-1.0 for the same pipe, and the last one is rewritten to sume/auto on the way in. The Video Router docs say Sume will retire Video 1.0 soon, so migrate when you next touch the code.

What to change in your code

A check such as assert poll["model"] == requested_model fails for every alias. Compare against a normalized value instead, and store both the model you asked for and the model the poll returned. The first is your intent and the second is the id that Sume reports; for Auto they differ by design.

Do not try to infer the underlying family from the output or from timing. The docs say not to, and the pinned models exist for the case where the family matters. Pin a model such as wan-3.0 or gemini-omni-flash-1.1 and the poll echoes that id.

AUTO_ALIASES = {"sume/auto", "sume/video-1.0", "auto", "auto-"}

def expected_echo(requested: str) -> str:
    return "sume/auto" if requested in AUTO_ALIASES else requested

def check_poll(requested: str, poll: dict) -> None:
    got = poll.get("model")
    if got != expected_echo(requested):
        raise ValueError(f"asked {requested!r}, poll says {got!r}")

Where the echo shows up

The echoed id appears on the 202 submit response as well as on every poll, so the first response you receive already says sume/auto. It is also the value to use in your own metrics: group Auto jobs under one label, and pinned jobs under their model ids. A dashboard that splits Auto jobs by guessed family would invent a number that Sume does not publish.

If a customer asks which model made a clip, the honest answer for an Auto job is that Sume chose it and does not say which. If they need to know, pin the model on the next request and the echo will name it.

Replays and price

Resolution for Auto is a pure function of the normalized request and the catalog version, so an idempotent replay gets the same price and the same route. That is why you can retry a submit with the same Idempotency-Key without worrying that Auto picks a different model the second time.

The Auto create controls default to 720p and 8 seconds, with 3 to 10 second clips at 16:9 or 9:16. A request outside those limits is a 400 unsupported_capability; see the 21:9 case and the full field-by-field migration.

• Log the requested id and the echoed id separately.
• Pin a model if a customer contract names one.
• Do not parse sume/auto as a provider/model pair.