Why your Sume balance drops at submit: hold, capture and refund

Sume reserves the estimated price when it accepts a job, captures it on success and releases it on failure. How holds show up in the usage ledger.

3 min readSume
All posts

If your available balance dips the moment you submit a video job, that is a hold, not a charge. Sume's generation-admission docs describe the sequence: at submit time it reserves the estimated amount, a successful completion captures it, and a failed job or failed queue admission releases or refunds the reservation where applicable.

The three states

The usage API shows each ledger row with a status of reserved, captured or refunded. A reserved row is a hold that has not turned into spend yet. The scope summary separates the pieces: debited_usd_micros is what the wallet actually lost, held_usd_micros is the sum of open holds, and refunded_usd_micros is what was given back. The summary also carries a final flag that turns true once no hold is open, which is the moment the spend stops moving.

Ledger row states from the Developer API usage types, read 2026-10-04
StatusMeaningCounts as spend
reservedHold placed at submitNo
capturedJob finished, amount takenYes
refundedHold released or returnedNo

What size is the hold

For video the docs say Sume reserves the provider list price times 1.25 at submit, and usage.cost on the poll response is the billable amount. Money is tracked in USD micros, so a hold can be a fractional cent figure such as 625,000 micros for a 5-second Wan 720p clip, or $0.625.

What this means for budgeting

  • Concurrent jobs each hold their own estimate, so a big batch ties up a lot of balance at once even though the final spend is lower if some jobs fail.
  • The balance endpoint reports spendable USD only. Amounts that are reserved or captured are excluded from the expiry summary.
  • To see what a job really cost, read its row or the job-scoped usage summary after it settles, not the balance mid-run.

A worked example

You submit a 10-second Seedance 2.5 clip at 720p. The estimate is $5.778, so $5.778 is reserved at submit and your available balance drops by that amount. If the job completes, the row becomes captured and $5.778 is spend. If the job fails, the row is released or refunded and the balance comes back. In between, the usage summary for that job shows the amount under held_usd_micros and final is false.

If you are reconciling against an invoice, use debited_usd_micros. The docs call it the source-of-truth figure, and the summary rounds to cents only once.

The dashboard's billing page shows the same balance and the usage ledger. Public API reads are GET /v1/balance and GET /v1/usage; both are scoped to the workspace of the key.

Sources

Related posts

More in Pricing

All Pricing posts

Written by Sume