Does a replayed sume/auto video submit get the same model and price?

Yes. The Sume video docs state that Auto 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. A retry with the same Idempotency-Key and the same body returns the original job, and it does not pick a second model or reserve a second amount. The poll response reports model: "sume/auto", and Sume does not disclose which family served the request.

What is and is not stable

Two things hold the answer together: the key and the body. Change either and you are asking a different question. A different body can resolve to a different family. A different key creates a new job, even with an identical body, and that job is billed separately.

Do not infer the family

The docs ask you not to use observable traits of the output to work out which family ran. Treat Auto as a price-and-route decision made once at submit. If you need a known price, or a model that supports a longer clip, pin a catalog id from GET /v1/videos/models instead of Auto. Auto is limited to 3 to 10 seconds, while pinned models such as seedance-2.5 accept 4 to 30 seconds.

Checking it yourself

The script submits twice with one key and compares the job ids. If the two ids match, the second call was a replay. It uses a short clip to keep the cost small, and only one job is created when replay works.

import asyncio, os
import httpx

async def main():
    key = os.environ.get("SUME_API_KEY", "")
    if not key:
        raise SystemExit("set SUME_API_KEY")
    headers = {"Authorization": f"Bearer {key}",
               "Idempotency-Key": "auto-replay-check-001"}
    body = {"model": "sume/auto", "duration": 3, "aspect_ratio": "9:16",
            "prompt": "A vertical clip of a coffee cup on a desk"}
    async with httpx.AsyncClient(timeout=60) as c:
        ids = []
        for _ in range(2):
            r = await c.post("https://api.sume.com/v1/videos",
                             json=body, headers=headers)
            r.raise_for_status()
            ids.append(r.json()["id"])
    print(ids, "replay" if ids[0] == ids[1] else "two jobs")

asyncio.run(main())

What to store

Keep the job id, the key, and the body hash together. If your worker restarts, resubmit with the stored key and you get the original job back instead of a second one.

Why this matters for budgeting

Auto removes the model decision, which makes the price feel unknown. The replay rule fills part of that gap. The reservation is made once, at submit, from the resolved route, and a replay does not create a second reservation. So a retry loop around an Auto submit cannot multiply your spend, as long as the key is stable.

What the docs do not give you is a price before submit. If you need a fixed number, pin a catalog model. The video docs say a successful completion captures the reserved amount and usage.cost is the billable amount, so you can read the cost of each completed Auto job and build your own average from it.

The first mistake is a retry wrapper that generates a new key on each attempt. The second is putting the attempt number into the key. The third is treating a different duration or aspect_ratio as the same request, which changes the body and, with the same key, returns 409 idempotency_conflict. Keep the key, the body and the intent together as one unit and the replay behaves.