Reserved, captured, refunded: the ledger for a 6 s Omni 720p job

A 6-second gemini-omni-flash-1.1 job at 720p is a $0.75 line on your Sume balance (6 x $0.125). It appears first as a reserved amount when Sume accepts the job. If the job completes, Sume captures the reserved amount. If the job fails, or is canceled before generation starts, Sume releases the reservation and the row shows as refunded.

The estimate and the final charge are the same number for a fixed per-second model like this one. The reserved, captured and refunded states still matter because they decide what your balance looks like while the job runs.

The three states

The usage ledger lists three statuses for generation work. Each is a row you can match to a job id.

Reading one job

Pass job_id to the usage endpoint and the response adds a summary that folds every ledger row the job caused. The documented fields to quote are debited_usd_micros (what the wallet deducted), held_usd_micros (holds still open), refunded_usd_micros (holds given back) and final (true when no hold is open).

For this example, micros are millionths of a dollar, so $0.75 is 750,000. While the job runs you would expect held_usd_micros of 750000 and final: false. After success, debited_usd_micros of 750000 and held_usd_micros of 0. After a failure, debited_usd_micros of 0 and refunded_usd_micros of 750000. Those three readings follow from the field definitions; the exact JSON for your workspace comes from the live API.

The docs also say not to sum the rows yourself. Use the summary, because a refunded row keeps its hold amount in its own billable field and would double count if added up.

When estimate and final differ

Fixed per-second video models do not drift. Variable work does: Modal-backed jobs such as frame extraction reserve a compute ceiling and capture what ran, never more than the hold, and speech transcription settles to zero on a silent track. Reading debited_usd_micros after final is true is the only figure that is a cost.

A related trap is the run receipt on Formats. Its billable_amount_usd_micros counts reserved plus captured generation and excludes the agent's own LLM turn, so it is a cap meter and not the total cost. The wallet fields in usage are the cost.

Cancel and refund timing

Cancellation succeeds only before generation work starts. A job already processing is not refundable by canceling it. If you submitted a batch and want to stop spending, cancel the queued jobs; the processing ones will capture. That is also why queue depth, not only balance, decides how much of a mistaken batch you can still avoid paying for.

A checklist for reconciling a month

To reconcile a month of generation, group usage by operation type and compare three totals: captured rows, refunded rows and open holds. Captured plus open holds is what the cap meter counts. Captured alone is what you have been billed. Refunded rows are not spend, even though they carry the hold amount in their own field. If a job id appears with a reserved row and no later captured or refunded row, check its status: it is either still queued or processing, and final for its scope will be false.