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.

5 min readSume
All posts

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.

usage_summary fields, from the Sume OpenAPI PublicDeveloperApiJobUsageSummary schema, read 2026-10-02.
FieldMeaning
statusreserved, captured, or refunded
currencyUSD
reserved_amount_usd_micros / _centsAmount held at submit
captured_amount_usd_micros / _centsAmount captured on completion
refunded_amount_usd_micros / _centsAmount refunded
released_amount_usd_micros / _centsAmount no longer held after refund or release
finalTrue once captured or released
updated_atLast 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 final to be true before treating a number as settled.
  • Quote dollars from micros, never from cents.
  • Read the status, not just the amount: a refunded job 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 cancelable is true.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume