What a run costs depends on how the capacity was bought

A cost figure for an agent run is a token count multiplied by a price, and the price depends on how the capacity behind the call was bought: per token, on a monthly plan, as reserved throughput, or on hardware you own. Only the first of those makes the public per-token rate a cost. Under the other three it is a valuation — a defensible one, but not money that moved on that call — and a tool that applies it without saying which basis it used produces a number that is wrong in a direction you can predict from the contract.

Two ways a price table gets the basis wrong

A LiteLLM pull request opened on 2026-08-13 stops per-token billing on a deployment whose capacity is already paid for, and states the failure plainly:

A PTU deployment billed per token on top of its flat capacity cost

Unset per-token price fell back to the public cost map

So the double charge was the default, not an opt-in

Two things are worth separating there. The first is the double count: capacity bought as a flat block, and then every call inside that block priced again from the public rate card, so the same work appears twice in the ledger. The second is the mirror image, in the same pull request — "A closed PTU window now alerts, since capacity is still billed." When nothing is running, a figure derived from usage reads zero while the flat cost continues. A cost model built on tokens cannot see spend that is not made of tokens.

A second pull request the same day makes tiered pricing all-or-nothing and extends it to cache creation, and its list of symptoms is a list of price-table shapes that did not fit the contract:

Cache-creation tokens were never billed at tier rates

Dashscope tiers were billed graduated, not all-or-nothing

Tiered-only models (volcengine) were billed at $0

Graduated and all-or-nothing are both ordinary commercial arrangements — the first prices each band separately, the second reprices the whole request once it crosses a threshold — and a table that assumes one silently produces the other's number. A model priced only in tiers, read by a table that expects a flat rate, comes out at zero. None of this is exotic; it is what happens when the shape of the agreement is richer than the shape of the field storing it. To be clear about the tool: LiteLLM is MIT-licensed and free, and both of these were found and fixed in the open, which is more than can be said for most pricing logic.

A plan is not a price

The same gap runs through how developers talk about their own spend. A Hacker News thread this week on tokens-constrained work describes a per-engineer ration:

We went from virtually unlimited token spend per software engineer, to $150 per month due the recent change in billing terms from GitHub Copilot. Rationed over a month, about $7.50 per day.

Those dollars are the plan's, not the provider API's. A commenter in a separate thread on the credit resale economy puts the divergence at its widest, and marks the basis inline while doing it: "a single $200 subscription to incur $20k+ of usage (if billed at API rates)". The parenthesis is the whole point — the same tokens carry two prices, and which one you quote decides whether a workload looks cheap or ruinous.

Developers compare the bases directly when a tool lets them. Under a thread on a new coding harness, one describes doing exactly that: "I use OpenCode and I like knowing the direct token spend for doing tasks... Then I can spend $1-$2 a day when I'm doing development, and costwise honestly it beats a $200 / month plan." And on the far end, an answer to how much people spend on model subscriptions reads "$0. but I use at least $8,000 worth of monthly tokens" — self-hosted capacity, where the marginal call costs electricity and the eight thousand is a valuation at somebody else's rate card.

The marginal call is where it bites

Pay per token, and refusing a call saves its price. Under a plan or a reservation, refusing the same call saves nothing this month: it returns capacity to the pool and moves the date the allowance runs out. Both are worth doing, and they are different arguments made with the same word. A budget denominated in dollars against prepaid capacity is bounding a valuation, not a payment, and the thing that is actually scarce there is throughput.

Where a contract mixes the two — reserved capacity with per-token spend past it — the price of the marginal call changes partway through the period. Identical runs then cost differently depending on when they ran, which makes cost per run a number that has to carry its basis around with it or stop being comparable to the run beside it.

Four questions to ask of a cost figure

1. Which basis produced it — a public rate card, a negotiated rate, a plan allowance, or reserved capacity?
2. Does the row say so? A cost row that does not record the price basis it used cannot be re-derived later, which is the same failure that tracking tokens is not tracking cost works through for stale price tables.
3. What does refusing the next call save right now — dollars, or capacity? The answer changes what an over-budget alert means.
4. What is billed when nothing runs? Reserved capacity bills through idle periods. Anything derived from usage reads zero across exactly those hours.

Under prepaid capacity the per-agent dollar figure stops being a measurement and becomes an allocation — a fixed cost shared out over the agents that consumed the capacity, which is chargeback and showback rather than metering. That is still worth having. It is just a different claim, and the ratio between agents survives the switch of basis even when the absolute figures do not.

How this works in Capsera

Capsera records token counts and agent identity in-process, per agent and per run, and derives dollars from a price table. The token counts and the identity are basis-independent; the dollar figure is only ever as right as the table applied to it. Capsera has no knowledge of a commitment contract, a provisioned deployment or a seat plan you hold with a provider — gateways in the path are auto-detected, but a purchasing agreement is not something an SDK can observe. If your capacity is prepaid or negotiated, read the per-agent dollars as a share-out and the token counts as the measurement.

Per-agent budgets are checked before the provider call and a blocking budget raises BudgetExceededError, so nothing is spent. Against pay-per-token capacity that stops a payment; against reserved capacity it stops consumption of an allowance you have already bought, which is a real control over when the month runs out and not a saving today. Saying which of the two you are getting is part of stating the control honestly, in the same way a cheaper model is not automatically a cheaper run.

If what you need is a price table you can define yourself, that is a job we do not do. As of 2026-08-17, Langfuse's docs describe cost calculation from ingested or inferred usage, with custom model definitions and support for tiered pricing (Langfuse docs). It is open source and free, and for a team whose problem is that the rate card in the tool does not match the one in their contract, that is the shorter path.