Format run failed with unattended_blocked: why it never half-finishes
Over the API, a Sume Format run is told approvals are granted. If it still cannot finish it fails with unattended_blocked, never a half-done completed.

A Format built for chat can stop and ask a person, for example to approve stills before the video is made. Over the API there is no person, so Sume tells the run those approvals are already granted and to carry on within its spend cap. If it genuinely cannot continue, the run comes back failed with error.code: unattended_blocked, never as a half-finished completed.
What the failure looks like
The docs show a failed receipt with output: null and output_error and error both carrying unattended_blocked, with a message written to be shown, such as no avatar matching the brief so no video was made.
| Item | Value |
|---|---|
error.code | unattended_blocked |
| Cause | A gate the run could not pass without a person: no avatar matched, or an input it would have asked about in chat |
| Fix | Fix the input or the brief; retry with a new Idempotency-Key |
A completed run | Always did real work and fills artifacts[] |
| Also check | output_error on a completed run when your output_schema was not met |
Reading results safely
Branch in this order: status, then error, then output_error, and only then output. primary_output_url is null on a failure, so testing if (run.primary_output_url) is a safe way to ask whether the deliverable exists. A completed run can carry output_error when the projection did not match your schema, so a green status alone is not enough.
Because the retry needs a new Idempotency-Key, derive it from your own record plus a version you bump on purpose, as the docs advise, not from the time of the call.
- Put missing facts in
inputup front, so the run has nothing to ask about. - Give clear, complete briefs; a vague brief is what a chat Format would have asked about.
- Use the spend cap as the guard on unattended work.
Prevention in the request
Most blocks come from a brief that is missing something. Put every fact the run could need into input, name the exact asset, voice or product, and avoid phrases that invite a question, like asking it to pick the best option when you have a preference. Test a new Format with one run on a low cap before you wire up a batch, and read the failure message, since it is written to be shown.
Limits
Telling the run approvals are granted means it can spend up to its cap without a human looking at the stills, so set generation_spend_cap_usd on purpose. The docs do not guarantee that a failed run spent nothing; compare usage.billable_amount_usd_micros with the cap on the receipt.
Related posts
More in Formats
- Format run webhook payload is null: receipt over 1 MiB
A Sume format.run.terminal webhook carries payload null when the receipt is over 1 MiB. Read error.result_url, fetch the receipt, and guard your handler.
- Gemini batch structured output per request vs Sume per-item schema
Gemini batch requests can each carry a JSON schema. A Sume bulk item is a full run body, so each item can bind its own output_schema; read output on each child.
- gpt-5.6-sol retired: it now runs on gpt-6-sol in Formats
A Format run that still sends model gpt-5.6-sol is not rejected: Sume runs it on gpt-6-sol. The receipt proof, the default, and how to update payloads.
- List all Sume Format runs: no cross-Format endpoint, page per Format
GET /v1/format-runs does not exist. List runs per Format with limit and next_cursor, or keep your own index of the run ids you stored at create.
Written by Sume