H3 Max Recast job failed: what Sume refunds and what to retry

When an H3 Max Recast job fails on Sume, its hold is released: per the admission docs, failed jobs and failed queue admission release or refund the reservation where applicable. What to do next depends on the error category on the job. Fix validation and generation_rejected problems in your input, retry queue errors with the same Idempotency-Key and generation_unavailable later, and never resubmit a job that is still processing.

Where do I read why it failed?

Three reads, all authenticated with the key that created the job. GET /v1/jobs/{id}/status shows the status and the public error metadata: category, stage, whether it is retryable, retry-after seconds, a public reason and a next action. GET /v1/jobs/{id}/events shows the event history, which Sume's docs name as the place to look for generation_rejected and internal errors. GET /v1/jobs/{id}/result answers 409 until the job is completed, so an empty result is not a failure.

curl https://api.sume.com/v1/jobs/job_123/status \
  -H "Authorization: Bearer $SUME_API_KEY"

curl https://api.sume.com/v1/jobs/job_123/events \
  -H "Authorization: Bearer $SUME_API_KEY"

Which failures should I fix, and which should I retry?

The categories below are from Sume's error docs, read 2026-10-03, with Recast examples that are our reading of them:

• Most shape errors are caught before the job exists: Sume rejects bad Recast bodies at submit with an error response, so they never become a job and never bill. See the rejected-field list.
• If the failure points at the clip, check shot lengths first. fal's schema forbids a single shot over 15 seconds.

How do I tell a failure from a slow job?

queued is a normal state. Sume accepts a valid paid job as queued while the workspace's concurrency is full and starts it when there is room, so a job that waits is not stuck. processing means it is running or being finalized. Only failed and canceled are terminal failures, and completed is the terminal success.

Poll with backoff and stop on a terminal status. Read the video only when the job is completed, because the result endpoint answers with a conflict before then. If a job seems to sit for a long time, read /status once more and look at next_poll_after_seconds rather than opening a second job.

When must I not resubmit?

Do not resubmit because your own process timed out, your connection dropped, or your wait expired. Sume's docs say not to resubmit the original paid request in those cases: the first job is still running, and still billing. A sync or subscribe submit that returns before the job finishes is a normal 2xx with the current state, not a failure; keep polling the status URL and honour next_poll_after_seconds.

Cancelling is a separate path. POST /v1/jobs/{id}/cancel works only before generation starts. Once it has started it returns 409 job_generation_already_started, and the job completes or fails normally, so a clip you have changed your mind about can still bill if it ran.

How do I retry safely?

A retry of the same intent reuses the same Idempotency-Key; Sume's docs say to retry queue and capacity errors that way once capacity opens, using retry-after when it is present. A retry that changes the input, such as a trimmed clip or a different photo, is a new intent and gets a new key, because it is a different job with a different price. Keep the key, the job id and the request id from the error body together; Sume asks for the request id when you report an issue, and asks you not to include keys or signed URLs.

The price of a retry that runs to the end is a full clip: $0.375 a second at 768p, so $3.75 for 10 seconds. Fix a rejected input on a 5 second slice first. It is the cheapest way to learn whether the fix worked, at $1.88 on Sume.