A model upgrade can be a price rise

A posted price is a rate, not a price. What a task costs is that rate multiplied by the number of tokens the model spends getting the task done, and the second term is a property of the model rather than of your prompt. So a new version released at an identical rate can raise what every run costs with no change to your code, your prompts or your rate card — and nothing in a side-by-side price comparison will show it, because the thing that moved is not on the price page.

LLM API pricing is published as a rate per million tokens, per token class, per model. It tells you what a token costs. It does not tell you how many tokens the model will use to answer, and in agent workloads that is the term with the larger variance.

The rate stayed the same and the quantity did not

A Hacker News comment on 2026-11-09, in a thread arguing that model vendors raise prices without changing the rate card, reports the measurement:

They came back and said it costs three times more. Same price per token. It uses more tokens: 439 output tokens on 2.5, 1,449 on 2.6

Read that as one developer's figures for one task on one model pair, posted in a comment rather than measured as a benchmark — the ratio is not transferable to your workload. The thread's framing is that the increase is deliberate, and that is a claim about motive that nobody outside the vendor can check. The mechanism is what survives either way: a per-token rate is a price attached to a quantity the vendor controls and you discover afterwards.

Three things commonly move that quantity across a version boundary, and all three are visible in your own usage records if you keep them separable. Reasoning or thinking tokens are billed as output while never appearing in the answer the user sees. Default verbosity changes, so the same prompt returns a longer response. And a model that reaches for tools more often turns one task into more round trips, which is a change in call count rather than in tokens per call. Checking which of the three moved needs output tokens, call count and the model version recorded on the same row.

Inside a loop, the extra output is billed again as input

In a single-turn application, a model that emits three times the output tokens costs three times the output tokens. In an agent loop it costs more than that, because the assistant's own output joins the transcript and is re-sent as input on every remaining turn. A chattier model therefore raises the output bill once per turn and the input bill on each turn after it, and the multiplier is the number of turns left in the run — which is set at runtime, not in your code. The same arithmetic applies across a handoff, where what agents say to each other is billed twice.

The fan-out widens it again. According to Capsera's July 2026 scan of 133 public agent repositories, the repositories scanned carried a median 2 agents per repository, 8 at the 90th percentile. A change in tokens per call lands once per agent, per turn, per run, which is why the effect shows up clearly in cost per run and barely at all in an average cost per call.

This is the quantity-side twin of a point this site has made from the price side: a model has no single price per token, because the rate is selected by the request. Here the rate is fixed and the token count is selected by the model. Both failures end in the same place — the rate card is not sufficient to price a run — and they can move in opposite directions at once, which is how a genuine rate cut can arrive alongside a higher bill.

A dollar budget does not survive the upgrade unchanged

A ceiling expressed in dollars keeps its number and changes its meaning. If the tokens per completed task rise, the same daily figure buys fewer completed tasks, and nothing in the enforcement layer reports that: the budget still binds exactly where it was set, and the work it permits has quietly shrunk. A Hacker News thread on 2026-11-09 on an employer capping engineers at a $200 daily AI budget is the common shape of that control — a per-person, per-day dollar allowance, set once against the behaviour of whatever model was current when it was written.

The inverse holds for a ceiling in tokens: it keeps its work allowance and changes its cost. Neither unit is wrong, but a budget is only reviewable if you know which of the two it was meant to hold constant, and a model release is the event that forces the choice.

What to record

1. Output tokens per completed task, per agent, with the model id and version stamped on the row. Without the version on the row, a step change reads as a prompt regression and gets debugged in the wrong file.
2. The output-to-input ratio per call. It isolates a model getting wordier from a transcript getting longer, which are different problems with different fixes.
3. Billed calls per completed task. A model that calls more tools raises cost without raising tokens per call at all.
4. Cost per run across versions, held against the same task set, not against the same calendar week. Comparing this week to last week compares two different workloads and attributes the difference to the release.
5. The unit your budget was written in, recorded next to the budget. A dollar ceiling and a token ceiling diverge on the first release day, and which one you meant is not recoverable from the number.

How this works in Capsera, and what it does not do

capsera.init() patches the provider clients — Anthropic messages, OpenAI chat completions, OpenAI embeddings and Google Gemini, sync and async — so the token counts and the model id arrive per call without a request-path change or a per-call edit. @capsera.agent(name="planner") says which agent they belong to, and because the agent stack is a contextvars ContextVar rather than thread-local state, the identity holds per thread and per asyncio task.

Capsera stores hashes and token counts, never prompt or completion content. That is a limitation for most questions and no limitation at all for this one: token counts per class, per model, per agent are exactly the series an upgrade moves. The dashboard carries model comparison, an agent × model matrix and downgrade recommendations over those series.

Budgets are checked before the provider call and are on by default, scoped per agent, per team or globally, with alert, throttle and block actions; a blocking budget raises BudgetExceededError and no tokens are spent. What that does not do is tell you the budget's meaning changed. A dollar ceiling re-prices itself automatically and goes on binding at the same number while fewer runs fit underneath it, so the review is still yours to run. There is no per-run cost ceiling — the scope is the agent, the team or the account. Enforcement fails open: a network or backend error lets the call through.

If the question you actually have is whether the new version is worth its larger token count — a quality comparison across model versions on a fixed task set — that is an evaluation job. Langfuse is open source, free, and built for it. Capsera is not.