Cost transparency: what to show before an agent spends
Two kinds of spend, tracked two different ways
When people worry about an agent "spending money," they usually mean one of two different things. The first is compute: tokens burned running the agent itself, billed by the API provider. The second is money changing hands in the world — the agent buying a plane ticket, paying a vendor, topping up a service. Both deserve a number shown to the human before the fact, not just a total after it. Right now almost nothing shows both, because the two live in separate systems built by separate teams.
What compute-spend transparency looks like today
Claude Code is a reasonable proxy for where this has landed. Its /usage command prints a running total for the current session — dollar cost, duration, a per-model breakdown — computed locally from token counts at standard list-rate pricing. Anthropic's own docs note that figure can diverge from the real bill for anyone on a negotiated rate; it's an estimate, not an invoice (Manage costs effectively).
The harder cap lives at the organization level. On the Claude Console, admins can set a workspace spend limit that turns a soft warning into a hard stop: exceed it and the API key returns an error instead of running (same doc). Claude Enterprise goes a step further with a dedicated Spend Limits API. Spend limits resolve through a hierarchy — a per-user override, then seat tier, then group, then organization default — and a member who hits their ceiling can request more from inside the product, with the admin seeing the requester's live spend against their current limit before deciding (Spend Limits API). That's a genuinely well-built loop: cap by default, request-and-approve to raise it, no spreadsheet reconciliation after the fact.
None of it tells you the cost of the next action before you take it, though. Every mechanism here is a running total or a ceiling, never a quote. An agent about to burn 200k tokens on a large refactor gives no warning beyond "your usage looks unusually high," and that only shows up after the tokens are gone.
What money-spend transparency looks like today
The payments protocols took the opposite approach: cap first, act second, and make the cap part of the transaction rather than a dashboard setting somebody has to remember to check.
Google's AP2 structures this as a signed Intent Mandate the human issues before the agent goes shopping. It carries a max_amount, a stated purpose, an expiry, and optionally an allow-list of merchants or categories the agent may use (AP2 specification). The Cart Mandate that follows — signed by the merchant once the cart is final — has to validate against that ceiling: the checkout can't clear for more than the human already agreed to, and the ceiling travels with the transaction as a signed artifact rather than a server-side check that something could quietly skip.
The Agentic Commerce Protocol that OpenAI and Stripe built for ChatGPT's Instant Checkout does a narrower version of the same thing. An agent calls Stripe's delegate_payment endpoint with an allowance — a bounded amount, a currency, an expiry, tied to one checkout session — and gets back a Shared Payment Token that's scoped to that session and merchant and usable exactly once (ACP payment-handlers RFC). It doesn't carry a standing allowance across future purchases the way AP2's mandate chain can; it's a single-use, single-purpose credential. But the underlying idea is the same family: a bounded, expiring, non-negotiable number attached to the action itself, checked before the action happens instead of totaled up after.
The gap between them
| Compute spend (tokens) | Money spend (payments) | |
|---|---|---|
| When the cap is set | Admin console, ahead of time | Signed into the transaction itself |
| What the human sees before acting | A running total, if they check | A specific bounded amount, scoped and expiring |
| Enforcement | Server rejects requests once the workspace cap is hit | Cryptographic or token validation against the signed ceiling |
| Granularity | Per workspace, seat, or organization | Per transaction, per merchant, per session |
The two payment protocols solved the harder half of this before the API-provider tooling did: a bounded, pre-committed number attached to one specific action. AP2's Intent Mandate is, structurally, close to what a "this will cost about $X, go ahead?" prompt should look like for an agent about to run an expensive tool call. Nothing in the compute-billing tooling does that yet. The closest equivalent is a workspace ceiling that halts the whole session rather than a quote for the single step you're being asked to approve.
What this suggests for interface design
If you're building an approval gate around an agent that costs real money to run — API spend, not only payments — the payments protocols are worth borrowing from directly rather than watching from a distance:
- Attach a bounded estimate to the specific action, not just a running total for the session. "This will read roughly 40 files and cost about $0.60" is a decision a human can make in advance. "You've spent $12 today" is not.
- Make the cap expire. Both AP2's mandates and ACP's tokens carry an
expires_at. A forgotten spend authorization from three sessions ago is a bigger risk than no authorization at all. - Scope the cap narrowly. A single workspace-wide ceiling catches a runaway loop but says nothing about which action was expensive. Per-transaction bounds — the way both payment protocols do it — let a human approve the specific merchant or tool call, not just a total.
The pattern is still young enough that most teams building agent products are choosing between no spend visibility and a dashboard nobody opens until the invoice arrives. The payments protocols show a third option already exists: put the bounded number in front of the human at the moment it matters, before the agent acts, not after. AP2's status is still early on our tracker, but the mechanism is worth stealing well before the protocol itself is something you'd bet a stack on — and the graduated-autonomy ladder coding agents already ship is a reasonable model for where that approval step belongs; see our guide on permission modes.