Retry cost of a mixed project: what a failed shot, 402 and replay bill

Six failure cases for an image, voice, music, video and render project, with the cost of the retry for each and the one mistake that pays for everything twice.

5 min readSume
All posts

Retrying a failed step in a mixed project costs the price of that step only when the failure was refunded or never started. A 402, a queue_full, and a replay with the same Idempotency-Key cost nothing. A failed 5-second wan-3.0 shot at 720p is refunded and costs $0.6250 to redo. The expensive mistake is resubmitting the whole project without the saved job ids: that bills every step again.

What the docs say gets refunded

Sume reserves the estimate at submit, captures it on success, and releases or refunds the reservation when a job fails, when queue admission fails, or when you cancel before work starts. The ledger shows these as reserved, captured and refunded rows. A cancel only works before generation starts.

A step that finished stays paid. If a later step fails, there is no refund for the earlier generation. The cost of a failure is therefore the cost of the failed step, and you keep everything before it.

Six cases for one project

The project is the 30-second explainer from the cost sheet: three 2K stills, 450 characters of voice, a music bed, six 5-second wan-3.0 shots at 720p and a one-minute render. Rates are from the Sume catalog (read 2026-10-08).

Cost of each retry case, Sume list prices as of 2026-10-08
CaseWhat happens to the moneyExtra cost on retryRight move
402 insufficient_credits at submitNothing ran$0.00Add funds, then submit the same request
429 queue_full at submitFailed admission releases the hold$0.00Wait for a job to finish, retry with the same key
Replay with the same Idempotency-KeyReturns the original job$0.00Safe after a timeout
Shot job fails at the providerHold refunded$0.00Resubmit that shot only ($0.6250)
Render fails after 6 shots completedShots stay captured$0.00 for shots, render is newRetry the render ($0.1000)
Retry the whole project by mistakeEvery finished step bills again$4.4464Avoid: keep job ids per step

Keep one job id per step

The last row is $4.4464, the whole project again. It happens when the script keeps no state and the retry starts from step one. Store the job id and the idempotency key for each step as you submit it, and on a re-run skip steps that already completed.

The Idempotency-Key rule is narrow: reuse a key only for an exact retry of the same request. The same key with a different payload gives 409 idempotency_conflict. And do not retry an unsafe submit at all without a key, because the first attempt may have been accepted before the timeout.

Retry rules by error code

Match the retry to the code. For 429 rate_limited, wait for retry-after and send the same request with the same key. For queue_full, wait until a job reaches a terminal state or cancel queued jobs you no longer need. For provider_capacity_exceeded, retry later with the same key. For 402, retrying does nothing until the balance changes.

A job error with category quota means add funds or reduce the request cost. Categories like generation_unavailable and queue are retry-later. generation_rejected and validation mean the input must change first, and a retry of the same input will fail the same way.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume