The number your developers see is not the number you pay

Anthropic publishes what Claude Code costs per developer: around $13 per developer per active day and $150–250 per developer per month, with 90% of users under $30 on any active day (Manage costs effectively). Those are the best public numbers in the category, and they are a benchmark, not a baseline. A benchmark tells you whether your spend is unusual. A baseline tells you what your own spend was before you changed anything — and it is the only thing a savings claim can be measured against.

The gap between those two ideas is where most AI-spend programs quietly fail. Below is what the vendor’s own documentation says about where its numbers come from, four documented ways the figure a developer reads diverges from the invoice an organization pays, and the four properties a savings claim needs before a finance team should accept it.

Claude Code’s cost figure is computed on the developer’s machine

The dollar figure in /usage is calculated locally from token counts at list price — it is an estimate produced by the client, not a reading from the bill. Anthropic states this plainly and points to the Console usage page as the authoritative source. That single design decision produces four divergences, each of which is documented:

List price versus your contract. If your organization negotiated rates, every figure in /usage, the status line, and OpenTelemetry is still computed at list price until an administrator sets the modelPricing managed setting to your contracted rates. Until then the numbers your developers quote in planning meetings are systematically wrong in the same direction, and the error scales with your discount.

The data-residency multiplier. Responses billed at the 1.1× data-residency rate are multiplied by 1.1 in the session figure — but only since Claude Code v2.1.239. On older clients the session figure was lower than the bill for exactly that traffic. A fleet on mixed versions therefore reports mixed arithmetic.

One machine, one client. The /usage breakdown is computed from local session history on that machine: usage from a developer’s other devices and from claude.ai is not included. Sum these figures across a fleet and you are summing partial records, without knowing which parts are missing.

The counter resets. Session totals reset when /clear starts a new session. A developer who clears between tasks — which the same page recommends for cost reasons — ends the day having seen several small numbers and no total.

None of this is a defect. The client is telling a developer what the current session is roughly costing so they can work sensibly. It was never built to be the general ledger. The mistake is organizational: treating a per-developer, per-machine, list-price estimate as the input to a budget or a savings claim.

What you pay depends on how you bought it

The same tokens cost different amounts depending on your billing path, and the largest single lever is not a price at all — it is cache lifetime. Anthropic’s documented behaviour: the prompt-cache lifetime is one hour on a subscription, five minutes once you are drawing on usage credits, and five minutes by default on an API key or a cloud provider.

That matters because of what a miss costs. Claude Code counts a request as a cache miss when it re-processes more than 5% and at least 2,000 tokens of what it could have read from cache. A cache read is billed at a fraction of the input rate; a rebuilt prefix is billed at full price. So the same developer, doing the same work, with the same model, generates materially different bills depending on whether their idle gaps fall inside a one-hour or a five-minute window — a fact that has nothing to do with how well they use the tool.

Two more fleet-level facts from the same source, both of which move a budget more than any prompt-writing advice:

• Agent teams use roughly 7× the tokens of a standard session when teammates run in plan mode, because each teammate carries its own context window.
• Long sessions keep paying for their own history. The full conversation is sent with every request; with caching it is re-read at the cached rate, so a one-line question in a day-old session still draws usage for the whole conversation.

Per-user attribution is a separate system from per-user billing

On cloud providers, Anthropic documents exactly three ways to attribute spend to a person: OpenTelemetry export from each developer’s machine, a self-hosted Claude apps gateway, or an LLM gateway that tracks spend per key. On the Console there is a dashboard and an analytics API; on Teams and Enterprise there is a spend report and, on Enterprise, an analytics API.

Two things follow. First, attribution is infrastructure you deploy, not a report you enable — on a cloud provider, no metrics flow back to Anthropic at all. Second, attribution stops at the person. None of these paths tells you what a repository cost, or a branch, or the pull request that came out of it, because the provider only ever sees an HTTP request. That information exists — the harnesses record the working directory and git branch in their own local logs — but joining it to spend is work someone has to do.

It is worth noting how Anthropic frames the gateway option: they name LiteLLM as the tool several large enterprises reported using, with the caveat that the project “is unaffiliated with Anthropic and has not been audited for security.” That is the correct posture for anything that terminates your API keys, and it is one of the five questions worth asking before you put a gateway in front of coding agents.

What a savings claim has to survive

A savings number is only credible if it can answer four questions, and most cannot answer the first one. If you are evaluating a vendor — including us — these are the questions to ask, and the answers should be mechanical rather than rhetorical.

Against which model? Spend falls when a cheaper model is used. That is not a saving if the work moved to a weaker model; it is a substitution, and it belongs in a different conversation than “we removed waste.” The honest form is a per-request counterfactual: price the exact same usage under the model the request originally asked for, and count only the difference. Comparisons that let the model mix drift can manufacture any number you like, in either direction.

Over what coverage? A comparison across two periods is only as good as the share of traffic present in both. If 40% of requests fall outside the comparable set — new teams, new models, missing rows — the honest report prints the coverage figure next to the delta rather than quietly averaging over the gap.

In which direction does the estimate err? Every measurement has failure modes: an unknown model, a missing price, a request that can’t be matched. Each one is a fork, and the choice of what to do when resolution fails is the whole character of the system. Counting zero when we cannot prove a saving means our number is a floor. Guessing means it is marketing.

Was it the unit cost or the usage? Total spend moving is not evidence of anything on its own — adoption grows, headcount changes, a new team onboards. The claim worth making is that cost per unit of work fell, with the volume terms separated out. Uber’s public numbers are the clean example: cost per session down 52% while agentic requests grew 9.4×, with the model held constant. We wrote up how they did it and which levers are configuration rather than engineering.

A report that answers all four is boring to read and hard to argue with. That is the point: the person who has to defend the number in a budget review did not choose to be excited.

What we build

decost is a passthrough gateway in your VPC plus a measurement engine, and the measurement is the part that makes the rest sellable. Spend is priced per request from the response’s own usage numbers, written to a plain NDJSON log you own; savings are per-request counterfactuals under the originally requested model; the report prints its coverage, its data-quality counts, and the drift between provided and recomputed prices; and every resolution failure counts as zero saved. The repository and branch a request came from are joined in from the harnesses’ own local logs, by request id — the one identifier both sides record.

We charge a share of savings measured this way, which is a strong incentive to inflate them and the reason the method is fixed in the code rather than in a slide. If you want the numbers for your own traffic before installing anything, the spend audit reads your provider’s billing data read-only and reports what each lever is worth per year.

Frequently asked

Can we just use the numbers in /usage for budgeting? Only as an order of magnitude. They are computed on the developer’s machine, at list price, from that machine’s history, and they reset when a session is cleared — four documented divergences from the invoice. For a budget you need per-request records from a place that sees every request.

What is the difference between a benchmark and a baseline? A benchmark is what comparable organisations spend — Anthropic publishes around $13 per developer per active day and $150–250 per month. A baseline is what you spent before you changed anything, on your own traffic, and it is the only thing a savings claim can be measured against.

Why does a savings claim have to hold the model constant? Because spend falls whenever work moves to a cheaper model, and that is a substitution rather than removed waste. Pricing the same usage under the model the request originally asked for is the only form that cannot be gamed by drifting the model mix.

What does “the estimate errs downward” mean in practice? Every measurement has failure modes — an unknown model, a missing price, a request that cannot be matched. Counting zero saved whenever resolution fails makes the reported figure a floor rather than an estimate, which is the property that lets a finance team accept it.

Can spend be attributed to a repository or a pull request? Not by the provider, which only ever sees an HTTP request. The harnesses record the working directory and git branch in their own local logs, so the join is possible — it is work someone has to do, and it is what turns spend into a unit cost per merged change.

---

Figures and behaviours cited here are from Anthropic’s Manage costs effectively documentation as of 31 August 2026; client-version-specific behaviour changes, so check the page against the version your fleet is running.