Reserve, capture, refund: a 20-clip batch with 3 failures, 2 cancels

Across 20 ten-second Wan 3.0 clips at 720p ($1.25 each), Sume holds $25.00 at submit. If 3 jobs fail and 2 are canceled while still queued, the 15 that completed capture $18.75 and the other $6.25 is released. The balance is touched at three moments: submit, completion, and failure or cancel.

That timeline comes from the cancellation-and-billing section of Generation admission: paid generation reserves the estimate when accepted, a success captures it, and failed jobs and cancellations before capture release or refund it.

The balance step by step

Cancel only works early

Cancellation succeeds only before generation starts. After that, POST /v1/jobs/{id}/cancel returns 409 job_generation_already_started with details.cancelable: false, and the job runs to a normal end. A cancel on an already canceled job is idempotent.

What to record

• The job id for every accepted submit, so a crash does not orphan a hold.
• The terminal sume_status per job, which is what turns a hold into a charge or a refund.
• The request_id of any failed submit, for support.

Reading the ledger

Use GET /v1/balance and GET /v1/usage to check the numbers rather than trusting the arithmetic above. The balance shows what is spendable, and the usage ledger shows the entries behind it, so you can match every captured amount to a job id. If a held amount seems to linger, the usual cause is a job that is still queued or processing, not a leak.

• A job in processing keeps its hold until it reaches a terminal state.
• A failed job releases its hold; the job error tells you the category and the next action.
• A rejected admission, such as queue_full, releases or refunds the reservation for that attempt.

Keep the arithmetic as a test in your own code: for any batch, held plus captured plus released should equal what you reserved at submit. When it does not, look for jobs whose terminal status you never read.