Claude Code token usage too high? Here's what's actually driving it

If your Claude Code token usage feels too high, the instinct is to blame the code you send or the questions you ask. That is almost never where the cost is. On real, measured usage the expensive part is the context that gets re-sent on every single turn.

Where the cost actually goes

Measured across 1,037 real Claude Code sessions (deduped by message id - raw counts overstate by about 2.5x), the token cost breaks down like this:

• Cache reads - 93.9% of billed tokens, 44% of dollar cost. Every turn re-sends the whole conversation so far. The model reads it back from cache each time, and you pay for that read on every turn.
• Cache writes - 4.9% of tokens, 37.8% of cost. The priciest tokens per unit. Everything new that enters context (a big file read, a long tool output) gets written to cache once - so what you let into context drives the expensive side.
• Output - 0.7% of tokens, 15.9% of cost. What the model writes back.
• Fresh input - 0.5% of tokens, 2.3% of cost. The prompt you actually type. Nearly a rounding error.

So the popular claim that "most of the cost is your input" is wrong. Cache-read is the single biggest slice, and cache-write is the most expensive per token. Both are driven by how much context you accumulate and how long it stays - not by your prompts.

The two fixes that cost nothing

There is a measured floor of savings that is pure cleanup, no judgement call required:

• Dead MCP servers. In the measured setup, 6 of 14 configured MCP servers were never called yet their tool schemas loaded into every session. Disabling the genuinely dead ones is lossless.
• Duplicate file reads. The same files get read more than once in a session - 92 duplicate re-reads in the sample, about 104K tokens that are fully recoverable losslessly.

Honest note: that floor is small - roughly 0.5% of context footprint. It is real and measured, but it is the floor, not the headline. The bigger wins below are modeled, and labeled as such.

The levers that actually move the number

The durable savings come from reducing what compounds. The biggest is offloading exploration to subagents - the reads, greps, and searches that never lead to an edit get re-charged as cache reads on every later turn, so moving them off the main thread removes a compounding cost (modeled at about 22% of the main-thread footprint). The second is slimming an oversized CLAUDE.md. See how to reduce Claude Code's context window usage for the full list, and why sessions fill up in the first place.

Realistically, the modeled band is about 18-22% off the dollar cost and 39-47% more session longevity - shown as a floor-to-ceiling range, never a single guaranteed number.

See your own numbers

These are aggregates from real sessions. Your setup is different - run the free scan and get the breakdown for your own Claude Code history. It runs locally; nothing about your code or prompts leaves your machine.