Cost is a session-tail problem, but token share is not cost share

Spend concentrates in a few long, uncleared sessions, as the docs say. But the corollary that output tokens are a rounding error is arithmetic error: cache reads bill at ~10% of the input rate, so in the docs' /usage example output is 0.53% of tokens and 14% of the cost.

You are trying to bring a Claude Code bill down, and the advice you have been given is prompt hygiene: write shorter prompts, trim CLAUDE.md, ask for terser answers. You do all of it and the number does not move. Meanwhile one afternoon last week — a single session you left open for six hours grinding on a refactor — quietly cost more than the rest of the month's mornings combined.

That asymmetry is real, and it is the useful half of a claim circulating in the community. The other half of that claim is wrong, and the docs let you prove it wrong in about two minutes.

The part that holds up

A developer instrumented 335 of their own sessions over 35 days and published the breakdown: median session $6.51 against a mean of $94.30, with the top 1% of sessions — three of them — carrying 42.4% of total spend. That is a distribution with almost all its mass in the tail.

Nothing in the official docs states a spend distribution, but two things there point the same direction. The costs page tells admins that unexpectedly high spend on an API or cloud plan "usually traces back to long sessions that were never cleared or to Opus left as the default model." And the same page's enterprise baseline is shaped like a tail too: around $13 per developer per active day, with costs staying below $30 per active day for 90% of users — a 90th-percentile figure roughly double the average.

The mechanism is documented in full under Why usage climbs in a long session: Claude Code sends your entire conversation with every request, and every tool call sends another request carrying that history. A one-line question in a session that has been open all day still draws usage for the whole conversation.

The part that does not hold up

The circulating version adds a corollary: cache reads are ~97% of input tokens and model output is ~0.44%, therefore per-prompt frugality operates on a rounding error and cannot matter. The token shares are about right. The inference from them is not, because it counts tokens and not dollars.

The prompt-caching page prices the fields directly. cache_read_input_tokens are "billed at roughly 10% of the standard input rate", while cache_creation_input_tokens are "billed at the cache write rate" — a separate rate the docs name without ever comparing it to the standard input rate, so the write column below rests on published list prices rather than on the docs. Output bills at a multiple of input. So a 97% token share weighted at 0.1x and a 0.44% share weighted at 5x are not remotely the same thing.

You can check this against the docs' own worked example. The costs page prints a /usage Session block reading 1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55). Applying Sonnet-tier list rates ($3 / $15 / $0.30 / $3.75 per million for input / output / cache read / cache write) reconciles to $0.5526 — which rounds to the $0.55 the doc prints, confirming the rates are the right ones. Here is where that money actually goes:

Component	Share of tokens	Share of cost
Cache reads	94.3%	51.0%
Cache writes	5.0%	33.9%
Output	0.53%	14.4%
Fresh input	0.12%	0.7%

Output is a fiftieth of a percent of the tokens and roughly a seventh of the bill. Cache writes are 5% of tokens and a third of the bill, and the popular framing does not mention them at all. Substitute your own model's list rates before trusting the column — the ratios shift, the shape does not.

What to do with both halves

Lever	What it acts on	Worth it when
End or `/clear` a non-converging session	The tail — the only thing large enough to move a monthly bill	The session has run long with no progress. The docs note `/clear` itself costs nothing
Trim `CLAUDE.md` and long-lived context	The cached prefix, re-read every turn	Always. Small saving, multiplied by every request in every session
Lower the effort level or thinking budget	Output tokens, which the docs bill as output at "tens of thousands per request"	Simple tasks. This is the ~14% slice, not a rounding error
Drop Opus to Sonnet for routine work	Every rate at once	The docs name Opus-left-as-default as a top-two cause of surprise bills
`/compact` a large context	Nothing — it is itself a large request	Rarely, for cost. Use it for continuity; use `/clear` for a fresh start
Reflexive session churn	Cold cache writes, billed at the cache write rate instead of the ~10% cache-read rate they replace	Never as a cost strategy

Claude Code will do some of this diagnosis for you. On Pro, Max, Team, and Enterprise plans the /usage breakdown flags any behavior — long context, cache misses — accounting for 10% or more of recent usage, with a tip attached. From v2.1.251 the Session block also carries a Prompt cache (main) line giving the share of input tokens served from cache and the miss count, so you can see your own version of the 94% figure rather than borrowing someone else's.

What is unverified here

Nobody has run this. Be clear about which claims sit where:

Documented: that cache reads bill at roughly 10% of the standard input rate and cache writes at their own write rate, the long-session mechanism, the /usage example, and the admin guidance that surprise spend traces to uncleared long sessions. All of it is on the costs and prompt-caching pages. The docs do not print per-million list prices, and they never say how the cache write rate compares to the standard input rate.
Arithmetic, not measurement: the cost-share column. It is derived from the docs' own example plus published list prices, and it reconciles to the printed total — but it is one 12-turn session, not a corpus.
One person's data: the 335-session distribution, the $6.51 median against the $94.30 mean, and the 42.4%-in-three-sessions concentration. That is a property of one developer's habits and workload, not a law.

What would settle it is your own history, not anyone's blog post. The third-party ccusage tool (unaffiliated with Anthropic — read it before you run it) reads your local session transcripts and will rank your sessions by cost:

bash

npx ccusage@latest session --order desc | head -20

Compare the top three rows against the median row. If the top three are a large fraction of the total, the tail thesis holds for you and session discipline is your highest-value lever. If your rows are flat — a fleet of short scripted claude -p runs has no tail to cut — then this tip does not describe your workload and the per-request levers are all you have.

For a properly instrumented answer rather than a local estimate, the monitoring page exposes claude_code.cost.usage over OpenTelemetry with a session.id attribute, which is the same question asked of real billing data across a whole team.

Checkpoint

In the docs' /usage example, output tokens are 0.53% of tokens. What share of the cost are they, and why is the gap so large?

Show answerAnswer
14.4% — roughly a seventh of the bill, about twenty-seven times their token share. The gap is rate weighting: the prompt-caching page bills cache_read_input_tokens at roughly 10% of the standard input rate, while output bills at a multiple of input, so a 94.3% token share weighted at 0.1x and a 0.53% share weighted at 5x are not comparable quantities. Counting tokens instead of dollars is the whole error in the "output is a rounding error" corollary.
Two things to keep straight about that column. It is arithmetic, not a measurement — published list rates applied to the docs' own 1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55) block, reconciling to $0.5526. And the row the popular framing never mentions is cache writes: 5% of the tokens, 33.9% of the cost.
You have a warm session at 300k context that is still making progress. Does /clear save you money? What does the next session pay?

Show answerAnswer
No — it most likely costs you more. /clear itself is free, as the docs note, but the next session starts cold and pays a cache write, billed at the cache write rate rather than the ~10% cache-read rate it was replacing. That is why the lever table marks reflexive session churn as never worth it as a cost strategy.
The signal to clear is a session that has stopped converging, not one that is still moving. That is the tail event — a session left running for hours with no progress — and the tail is the only thing large enough to move a monthly bill.
Which of your context costs is multiplied by the number of turns in the session, and does that make trimming it more or less worthwhile than the token-share framing suggests?

Show answerAnswer
The cached prefix — your CLAUDE.md and any other long-lived context. Claude Code sends the entire conversation with every request, and every tool call is another request carrying that history, so the prefix is re-read on each turn of the session.
That makes trimming it more worthwhile, not less. The circulating version files CLAUDE.md under the 0.44% "rounding error", when it actually sits in the ~94% cache-read slice and is multiplied by turn count. The saving per turn is small, but it is one of the few per-prompt actions whose effect compounds across every request in every session.