Sume job usage_summary: reserved, captured, refunded, final
Read usage_summary on a Sume job: status reserved, captured or refunded, amounts in micros, the final flag, and why dollars are micros divided by 1,000,000.

usage_summary on a Sume job shows what the job cost the workspace: a status of reserved, captured, or refunded, amounts in USD micros and cents, and a final flag that turns true once the reservation has been captured or released. Dollars are micros divided by 1,000,000; the cents fields are rounded up for balance compatibility and are not dollars.
Field names and descriptions come from the PublicDeveloperApiJobUsageSummary schema in the API reference; the reserve and capture lifecycle comes from Generation admission. Both read 2026-10-02.
What does usage_summary contain?
It is on GET /v1/jobs/{id} as data.job.usage_summary, and is null until a usage ledger row exists. The schema says provider costs, ledger metadata, and idempotency keys are omitted.
| Field | Meaning |
|---|---|
status | reserved, captured, or refunded |
currency | USD |
reserved_amount_usd_micros / _cents | Amount held at submit |
captured_amount_usd_micros / _cents | Amount captured on completion |
refunded_amount_usd_micros / _cents | Amount refunded |
released_amount_usd_micros / _cents | Amount no longer held after refund or release |
final | True once captured or released |
updated_at | Last change |
How does a job move through reserved, captured, and refunded?
Per the admission page, Sume reserves the estimated amount when the request is accepted. Successful completion captures the reserved usage. Failed jobs and failed queue admission release or refund the reservation where applicable. So a queued or processing job reads reserved with final false, a completed job reads captured, and a job whose hold was released or refunded is expected to read refunded. Confirm that on one of your own failed jobs before you build reporting on it.
The schema adds one caveat on released_amount_usd_micros: spendable balance restoration can differ when the original credit lot expires before release.
How do I turn micros into dollars?
The schema is blunt about this for the submit response's usage estimate: the canonical dollar value is billable_amount_usd, which is always micros divided by 1,000,000, and dividing micros by 10,000 gives cents, which overstates spend 100 times if you call it dollars. Its own example: 133,061 micros is $0.133061, not $13.31. For a finished job, do the same division on the captured field:
curl -s https://api.sume.com/v1/jobs/job_123 \
-H "Authorization: Bearer $SUME_API_KEY" \
| jq '.data.job.usage_summary | {status, final, captured_usd: (.captured_amount_usd_micros / 1000000)}'What should a billing script check?
Four checks keep a spend report honest.
- Wait for
finalto be true before treating a number as settled. - Quote dollars from micros, never from cents.
- Read the status, not just the amount: a
refundedjob has a reservation that was released. - Do not resubmit a paid job to "fix" a slow one; the reservation is already held. Cancel only while
cancelableis true.
Sources
Related posts
More in Developers
- Sume job webhook_delivery: attempts, exhausted, redeliveries
Read the webhook_delivery object on a Sume job: status, attempts of 10, last_status_code, manual_redeliveries, and what to do when delivery is exhausted.
- Submit a Sume video job with curl, save it with sume jobs download
The CLI has no video generate command, but jobs watch and jobs download work on jobs created through the API. A shell script that submits, waits and saves.
- List Sume jobs: next_cursor, starting_after, and idempotency_key
Page through GET /v1/jobs with limit, next_cursor and starting_after, then recover a lost wave by joining your own key to each job's idempotency_key.
- Sume SumeMediaFile duration_ms: the 10 percent check and null
In a Sume structured output, a duration_ms must agree with the artifact's recorded length within 10 percent, or the projection fails. A null means not measured.
Written by Sume