Usage-based receipts: the missing billing primitive for agentic commerce

Agents are starting to buy things directly. Not the toy version — booking a flight from a chat window — but the operational version: a long-running agent that dispatches an embedding job, a transcription job, or a 40,000-row classification batch, and pays for it out of a budget the operator handed it that morning. The billing primitives we have today don't fit this. Charge-on-checkout assumes the buyer knows the price at the moment of purchase. Monthly invoices assume the buyer trusts the seller to be reasonable across thousands of small charges. Agentic commerce breaks both assumptions at once: the agent doesn't know the cost up front because token usage depends on the model's actual output, and the operator doesn't trust an open-ended charge because the agent is, by definition, acting without supervision. What's missing is a primitive that lets the agent commit to a bounded spend, do the work, and settle for the actual amount — with both numbers preserved in a receipt the operator can audit later. That primitive is the usage-based receipt. What "usage-based receipt" actually means A usage-based receipt is a charge that resolves after the work is done, against a reservation made before it started. The lifecycle has five steps, and each one corresponds to a discrete event the operator can inspect. Estimate — the platform computes an upper-bound cost from the input (token count, model rate, expected output ratio). Reserve — credits equal to the estimate are placed on hold against the operator's balance. The agent cannot spend them on anything else. Execute — the work runs. Token usage is recorded per request, per model, per lane. Settle — the actual cost is computed from real usage. The hold is converted into a charge for that amount. Release — any unused portion of the reservation is returned to the operator's spendable balance. Sub-cent precision matters here. A 40,000-row batch at $0.00018 per row resolves to $7.20, not $7. Rounding a settlement up to the nearest cent on every batch is a 6-figure tax on a high-volume operator over a year. The receipt has to record the exact charge in the smallest unit the underlying provider bills in, and the credit ledger has to subtract that exact amount. The reservation is the trust boundary. Without it, the agent could initiate work it can't pay for, and the platform absorbs the loss. With it, the platform never executes a job it isn't already prepaid for — and the operator never pays more than the upper bound they pre-approved. Why estimates aren't enough Historically, estimates have been informational. Cloud consoles show you a projected monthly cost based on instance counts; SaaS tools show you an upgrade preview. Nobody enforces them. If actual usage drifts above the estimate, the invoice just goes up. In agentic commerce, estimates need to be load-bearing. The agent has to be able to say: "I'm authorized to spend up to $12.40 on this batch." If the platform agrees, it has to honor that ceiling — by reserving the credit, by refusing to start work without the reservation, and by failing the job rather than overrunning the cap. That is what makes the receipt trustworthy: the operator knows the actual charge will fall between zero and the reserved amount, with no surprises. A token-usage-based receipt closes the loop the way no fixed-price tier can. The operator funds a prepaid balance. The agent commits to bounded reservations. The platform executes and settles. Every charge maps to a discrete unit of work, and the difference between estimate and actual is part of the public record — not a back-office reconciliation. UCP and ACP, briefly Two early standards are starting to formalize this pattern: the Universal Commerce Protocol (UCP 0.1) and the Agentic Commerce Protocol (ACP 1.0). Both are discovery-first: they publish well-known endpoints that an agent can fetch to learn how to transact. /.well-known/ucp describes the billing model. For Batchrouter, that's prepaid_credits — packs of…