Scheduled run receipt shows less than the wallet debit: which number

A run receipt's usage.billable_amount_usd_micros is the generation spend attributed to that run, and it leaves out the Agent's own LLM turn. The number to quote as what the run cost is summary.debited_usd_micros from GET /v1/usage?run_id=..., which counts every captured ledger row the run caused, agent turns included.

Both numbers are correct; they answer different questions. The receipt figure is what the run's spend cap is enforced against. The ledger figure is what left the wallet. This post reads both from the Sume docs pages on runs and usage, read on 2026-10-03, and shows which one to use for a budget, an invoice and a cap.

Two numbers, two jobs

The Scheduled runs page says billable_amount_usd_micros counts both reserved and captured generation amounts and climbs while the run is in flight. It excludes the Agent's own LLM turn, which bills the separate Agent wallet, so the page states it is not the run's total cost. It also says the figure is a receipt, not an invoice.

The Usage page describes the other side. Adding thread_id, run_id or job_id to GET /v1/usage returns a summary folded over every ledger row the scope caused. Its debited_usd_micros is what the wallet deducted, captured rows of every operation type, and the page calls it the figure to quote.

The read that settles it

Take the run id from the receipt (arun_...) and ask the ledger. The limit parameter only caps how many rows are listed; the summary is folded over every row regardless.

Do not add the rows yourself. The usage page warns that a refunded row keeps its hold amount in billable_amount_usd_micros, so a hand sum counts money that went back to the wallet.

curl -sS "https://api.sume.com/v1/usage?run_id=$RUN_ID&limit=50" \
  -H "Authorization: Bearer $SUME_API_KEY"

What to do with the gap

If the ledger figure is higher than the receipt figure, the difference is the Agent's own turns and any other row types in the scope; the by_operation_type breakdown in the summary shows which. That gap is normal and does not mean the cap failed. The cap is enforced on generation rows only, so a $1.00 schedule cap can coexist with a debit above $1.00 once the LLM turn is counted.

If the receipt figure is zero while the run is in flight, do not read that as free. usage can also be null when spend could not be read at all, which the runs page distinguishes from a real 0. For finance, wait until summary.final is true, then store debited_usd_micros next to the run id.

• Budgeting a schedule: size the cap from the receipt's generation figure, then add the Agent turn on top.
• Client invoicing: use debited_usd_micros once final is true.
• Alerting: compare cap in the summary, which shows the cap, what counts against it and what is left, instead of computing it yourself.