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.

1. Estimate — the platform computes an upper-bound cost from the input (token count, model rate, expected output ratio).
2. Reserve — credits equal to the estimate are placed on hold against the operator's balance. The agent cannot spend them on anything else.
3. Execute — the work runs. Token usage is recorded per request, per model, per lane.
4. Settle — the actual cost is computed from real usage. The hold is converted into a charge for that amount.
5. 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.

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 $10, $25, $100, with custom amounts between $5 and $500. The descriptor lists settlement currency, sub-cent precision, the credit lifecycle, and the endpoints for top-up and balance.
• **/.well-known/acp** describes the agent-onboarding surface. It lists the auth mechanisms the platform supports (OAuth, OIDC, API key), the agent-registration endpoint, the payment discovery endpoint, and the relationship between an agent identity and a billable account.

Having these as well-known paths matters because the agent doesn't read documentation. It does an HTTP GET. The descriptor tells the agent everything it needs to know to register, top up, reserve, execute, and settle — without a human writing integration code in the middle.

{
  "ucp_version": "0.1",
  "billing_model": "prepaid_credits",
  "currency": "USD",
  "min_unit": "0.0001",
  "credit_packs": [
    { "amount": 10, "label": "Starter" },
    { "amount": 25, "label": "Standard" },
    { "amount": 100, "label": "Pro" },
    { "amount_min": 5, "amount_max": 500, "label": "Custom" }
  ],
  "lifecycle": ["estimate", "reserve", "execute", "settle", "release"],
  "endpoints": {
    "balance": "/v1/credits/balance",
    "topup": "/v1/credits/topup",
    "receipts": "/v1/receipts"
  }
}

A receipt, line by line

Here's a concrete example. The agent submitted a 12,000-row classification batch — mixed Anthropic Claude and OpenAI GPT-4o mini — through a single Batchrouter batch_id. The router split it into two model-specific internal lanes. Both lanes settled inside the 24-hour SLA.

Every line is auditable. The provider subtotal comes from token counts and published rates. The batch discount is a fixed percentage on the public batch lane. The native lane discount is Batchrouter's posted 10% on top of the provider rate. The control-plane fee is a flat $0.02 per internal lane, charged once per lane regardless of size. The service fee is the platform's margin. The actual usage charge is the sum. The reservation is what was held; the difference goes back.

Expressed as JSON, the receipt is small and stable enough for an agent to reason about:

{
  "receipt_id": "rcpt_01HZQ3J7K4...",
  "batch_id": "batch_01HZQ3...",
  "estimate": "5.2000",
  "actual": "4.7100",
  "currency": "USD",
  "lines": [
    { "kind": "provider_subtotal", "amount": "10.0400" },
    { "kind": "batch_discount", "amount": "-5.0200" },
    { "kind": "native_lane_discount", "amount": "-0.5000" },
    { "kind": "control_plane_fee", "amount": "0.0400" },
    { "kind": "service_fee", "amount": "0.1500" }
  ],
  "settled_at": "2026-05-29T18:21:44Z",
  "released": "0.4900"
}

What this enables

Three things become possible once usage-based receipts exist as a first-class primitive.

• Agents that pay per actual cost. The agent commits to a ceiling, but the operator is only charged for what was used. No padding, no rounding-up tax, no "close enough" billing.
• Operators that audit per receipt. Every batch produces one receipt with every line itemized. Disputes resolve by reading the lines, not by reconstructing an invoice.
• Accounting that closes cleanly. The credit ledger is monotone — every reservation either becomes a charge or is released. There is never an in-flight charge that the books can't explain.

None of this is exotic. It's the same primitive Visa added in the 1970s when it separated authorization from capture. The version we're shipping for agents is just that primitive, applied per-token, with sub-cent precision and a public descriptor for discovery.

If you want to look at the live descriptors, they're at [/.well-known/ucp](/.well-known/ucp) and [/.well-known/acp](/.well-known/acp). The credit packs and prepaid model are documented on [/pricing](/pricing). Per-batch receipts ship alongside the artifacts — see the Batches API reference.