sume/auto on a retried submit: same job, model still sume/auto

When you submit model: "sume/auto" twice with the same Idempotency-Key, Sume returns the original job both times. The docs say resolution is a pure function of the normalized request and the catalog version, so an idempotent replay gets the same price and the same route. The poll response reports "model": "sume/auto", and Sume does not disclose which family served the request.

What the docs state

The video docs list sume/auto as an addition that only Sume has. OpenRouter has no generate-time auto routing. The table collects the claims.

Check it

The script sends the same request twice under one key and compares the ids. Expect True sume/auto sume/auto. Run it with a key set, and note that the first call is a paid submit while the second should not bill again.

import asyncio
import json
import os
import urllib.request

def submit(key: str) -> dict:
    body = {"model": "sume/auto", "prompt": "Vertical product clip on a desk",
            "aspect_ratio": "9:16", "duration": 5}
    req = urllib.request.Request(
        "https://api.sume.com/v1/videos",
        data=json.dumps(body).encode(),
        headers={"Authorization": f"Bearer {os.environ.get('SUME_API_KEY', '')}",
                 "Content-Type": "application/json", "Idempotency-Key": key},
    )
    with urllib.request.urlopen(req, timeout=30) as resp:
        return json.load(resp)

async def main() -> None:
    first = await asyncio.to_thread(submit, "auto-demo-001")
    again = await asyncio.to_thread(submit, "auto-demo-001")
    print(first["id"] == again["id"], first["model"], again["model"])

asyncio.run(main())

When to pin instead

Use sume/auto when you do not care which family renders the clip. Pin an id when you A/B test models, when you need a duration outside the intersection of what the families accept, or when you want a fixed per-second price in your estimate. With sume/auto, the catalog version is part of the route, so the same request submitted under a new key after a catalog change is not guaranteed to resolve the same way.

A changed payload under the same key is a conflict: 409 idempotency_conflict. Use a key again only for an exact retry.

Operational notes

Because the catalog version is part of resolution, log it alongside your request when you can, so a change in routing is traceable. If a result looks different from yesterday's, check whether the catalog changed before blaming the request.

The price is the same on replay, but a new key is a new job and a new charge. Generate keys per logical request and persist them before the first send.