Per-customer spend caps on Sume: what Sume caps, what you log

Sume cannot know who your end customers are: a key resolves a workspace and an owner, and nothing in the request carries your tenant. A per-customer budget therefore has two layers, a per-run cap that Sume enforces and a per-customer total that your code enforces from your own records.

The layer Sume enforces

On Format runs, generation_spend_cap_usd bounds what one run may spend; the docs treat a missing cap as a client bug, and a value of 0 or over 500 is rejected with 400 invalid_request. Balance is a second gate: when it cannot cover the estimate, a submit fails 402 insufficient_credits before provider work starts.

The layer you own

Record, per customer, the job or run id, the idempotency key and the cap you granted before you submit. Refuse the submit when granted caps would pass the customer's allowance. Where an endpoint takes caller metadata (Video 1.0 documents it as stored on the job and not sent to the provider), tag the job with your customer id to join later.

Reconcile from the ledger

GET /v1/usage lists ledger entries such as reservations, captures, refunds and top-ups. Compare those against your per-customer totals on a schedule; the difference is either a cap you granted but did not spend or a job you failed to record.