Billable vs debited on a Sume run: why the wallet moved more

On a Sume run receipt, billable_amount_usd_micros covers generation only and excludes the language model turn, while debited_usd_micros is what actually left the wallet, including the language model row. If your wallet moved more than the video cost, that gap is the first place to look.

Both numbers sit in the usage block of the receipt, and GET /v1/usage with a run_id filter returns the same rows, so you can reconcile without guessing.

People often compare the wallet to the media price on a pricing page and conclude they were overcharged. In most cases the difference is the language model turn that planned the run, which is a real cost that sits outside the generation line.

The fields

Amounts are in micros of a US dollar, so 1,000,000 equals $1.00. The usage block also reports whether the amount was held, refunded, or final, and shows the effective cap in generation_spend_cap_usd_micros. The Format runs page describes the block.

A worked example: a generation line of 600,000 micros is $0.60. If the language model turn adds 30,000 micros, billable stays at 600,000 and debited reads 630,000, or $0.63. The numbers here are illustrations to show the arithmetic, not prices.

Another useful habit is to show both numbers in your internal dashboard with the labels generation and total. Support staff then stop asking which one is right, because both are, for different questions.

Which number to use for what

Use billable_amount_usd_micros when you compare the cost of two recipes, because it isolates generation. Use debited_usd_micros for wallet reconciliation and for customer invoices that must match what you paid. Use the cap in usage when you check whether a failed run hit its limit.

On a canceled run you pay for generation completed before the cancel, so billable and debited can both be non-zero on a run that produced nothing you can use.

Reconciling a day

Pull your run index for the day, then query usage for each run id, or page the usage endpoint and group by run. Sum debited per Format, not billable, and compare the total to the wallet's movement. A small remaining difference usually means runs still held or not yet final, so reconcile only terminal runs.

mcp_unavailable failures are not charged, and a run that failed with provider_credits_exhausted tells you the problem is on the funding side. Both are worth tagging in your report so finance can tell a charge from a non-charge.

Budget alerts

Build an alert from debited, not from your estimate. If one Format's average debited per completed run climbs by a fifth in a week, something changed in the recipe, the inputs, or the models behind it. Check format.version on the receipts first.

Keep one number out of the alert: the held amount. Holds move while a run is active and are expected to settle, so alert on final and refunded amounts, not on holds.