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
- OpenAI response_format json_schema to a Sume output_schema
Moving a json_schema from OpenAI structured outputs to a Sume Format run: the field name, what transfers, no JSON mode, and why output comes once, post-run.
- Sume agent_reported_failure: the three reasons and what to do
agent_reported_failure on a Sume run means the run's own receipt said it did not deliver. Its details.reason tells you which of three cases it was.
- Sume primary_output_missing: schema satisfied, run still failed
A Sume run can match your output_schema and still end failed with primary_output_missing. It means the key named in primary_output_key had no value.
- Sume output_extraction_failed: the run stays completed, reread it
output_extraction_failed with reason harvest_unavailable is transient. The Sume run stays completed and fills in on your next read; retry only if it persists.
Written by Sume