Format run create: 202 fresh, 200 replay, 409 conflict in Python
A Format create returns 202 for a fresh run and 200 with idempotency_hit true for a replay. 409 means conflict or in-flight. A Python classifier.

How should your code read the response to a Format run create? 202 means Sume started a fresh run; 200 with idempotency_hit true means the same key and body already created one and you get its original receipt; 409 means the key was used with a different body, or another request with that key is in flight. Branch on status first, then code.
This is the retry story for an overnight series job. Network errors will happen across 40 episode submits, and the Idempotency-Key is what lets you resend safely.
The table
The scope of a key is one Format: the same key on two Formats starts two runs.
| Case | Result | Action |
|---|---|---|
| New key | 202, fresh receipt | Store data.id |
| Same key, same body | 200, idempotency_hit true | Use the original receipt |
| Same key, different body | 409 idempotency_conflict | Fix the key or the body |
| Same key, concurrent | 409 idempotency_key_in_use (retryable) | Wait about 1 s, resend |
| Create failed (402, 503) | Key released | Fix cause, reuse the key |
Classifier
The function below returns the next step as a string and works on the documented envelope, where errors live under error.code.
def classify(status: int, body: dict) -> str:
if status == 202:
return "started"
if status == 200 and (body.get("idempotency_hit") or body.get("data", {}).get("idempotency_hit")):
return "replay"
code = body.get("error", {}).get("code", "")
if status == 409 and code == "idempotency_key_in_use":
return "retry_in_1s"
if status == 409 and code == "idempotency_conflict":
return "change_key_or_body"
return "inspect"
print(classify(202, {}))
print(classify(200, {"idempotency_hit": True}))
print(classify(409, {"error": {"code": "idempotency_key_in_use"}}))Choosing keys
Derive the key from the item: episode id plus a revision number you change when you want a new run. A time-based key defeats the mechanism. Edits to the instruction or the attachment list count as a different body, so a tweak with the old key is a 409, not a silent re-run.
Retries in practice
The idempotency key is what makes a retry safe. After a timeout, send the same key and the same body: you get 200 with idempotency_hit true and the original run, not a second charge. If you change the body but reuse the key, you get 409. Treat 409 as a bug in key reuse, not as a reason to retry blindly.
- Store the run id the first time you see it.
- Make keys deterministic per episode, such as the season and episode number.
- A 409 with key_in_use means the first request is still running; wait and ask again.
Wiring it into a worker
Call the classifier right after the HTTP response and branch on the result: new runs go to your tracking table, replays update nothing, and conflicts raise an alert. Keep the function pure so it is easy to unit test. A few fixture responses, one for each status code, are enough to cover it.
Sources
Related posts
More in Formats
- Format run limits: 64 input keys, 2 MiB, 8,000-character instruction
Put episode data in input (64 top-level keys, 2 MiB) and the task in instruction (8,000 characters). The body cap is 4 MiB; unknown top-level fields return 400.
- Format run receipt: $14.96 billed against a $120 cap, field by field
The documented Format run receipt shows billable_amount_usd_micros 14,959,638 and a cap of 120,000,000. How to read micros, and what unused cap means.
- Format showcase field: judge a Format by a real output first
GET /v1/formats returns showcase, a verified sample output. Use it with description and io to pick a Sume Format before you spend credits on a run.
- Format spend caps: the $400 default, $500 maximum, and your own
A Sume Format run can never spend past its cap. How the cap is chosen, what happens when a run hits it, and how to size generation_spend_cap_usd per run.
Written by Sume