Claude Code

How to reduce Claude Code token usage

Eight tactics you will find recommended everywhere, measured against 6.3 billion real tokens. Seven of them are rounding errors.

Every figure below comes from four months of transcript data, not estimates.

Search for this and you get the same list every time. Write shorter prompts. Trim your CLAUDE.md. Turn off unused tools. Read fewer files. Use a cheaper model.

The advice is not wrong exactly. It is just wildly out of proportion. We measured each of these against real usage and the ranking is not close.

Where the money actually goes

Before the list, one number explains everything else. Of everything spent across four months of heavy use:

Claude carries the whole conversation with it. Every turn resends the entire history, so the file you opened this morning is still being paid for at five o'clock. Cached, and therefore discounted, but paid for again on every single turn that follows.

That is why most advice misses. It targets what goes in, when almost all the cost is in how long it stays.

The eight tactics, ranked

8. Writing shorter prompts

Effectively zero. Across the whole dataset, uncached input, which includes everything you type, came to less than one tenth of one percent of total cost. You could halve every prompt you write and never see it.

7. Trimming your CLAUDE.md

About 1 percent. This one feels like it should matter, because the file is sent on every request. But it is small, and it is dwarfed by everything the conversation accumulates on top of it. In our data the entire base context, meaning the system prompt, all tool definitions and CLAUDE.md combined, accounted for roughly 1 percent of the bill.

6. Turning off unused MCP servers

Also about 1 percent, and for the same reason. Tool definitions are part of that same base context. Worth doing if you have a dozen servers you never use, but do not expect to notice.

5. Being more specific so fewer files get read

Around 3 percent. This is better advice than the ones above, and file reads were genuinely the largest single category of incoming context we measured. But see the next entry for why the ceiling is so low.

4. Capping how much tool output enters the conversation

Between 1.5 and 11 percent depending on how brutal you are. This is the tactic most optimisation tools are built around, so it is worth showing the measurement in full:

Cap on each tool result	Saving
8,000 tokens	1.5%
4,000 tokens	3.4%
2,000 tokens	6.9%
1,000 tokens	11.2%

A 1,000 token cap is severe. It truncates most file reads and a lot of command output, and you will feel it. That is the price of 11 percent.

The reason the ceiling is so low is a single figure:

Only 26 percent came from outside: file reads, command output, your prompts. The rest is Claude thinking and writing, and you cannot trim that without changing the work it does.

So when a product promises to slash your usage by shortening what Claude reads, that is the ceiling it is working against.

3. Switching to a cheaper model for routine work

Real, but it is a trade not a saving. In our data Haiku handled 454 calls for $3.47 while the heavier models ran into the hundreds. If part of your work is genuinely simple, routing it to a smaller model helps.

The catch is that you have to decide what is simple in advance, and being wrong costs you more in rework than you saved.

2. Starting a fresh session more often

Large, and most people already sense this. A new session starts with an empty history, so every turn is cheap again.

The problem is that it is manual and disruptive. You have to notice, decide to stop, and then re establish what you were doing. In practice almost nobody does it at the right moment, because the right moment does not announce itself.

1. Compacting at the right threshold

Between 22 and 70 percent. Nothing else is in the same class.

Compaction does automatically what a fresh session does manually. When the conversation reaches a threshold, it gets summarised and continues from the summary. The history stops growing and the per turn cost resets.

Threshold	Saving	Worst case
250k	72%	50%
400k	60%	45%
600k	44%	32%
Default	0%	0%

The worst case column assumes summaries come back three times larger than measured and that every compaction costs twenty wasted turns rebuilding context. Even then it beats everything above it combined.

Adding it up

Do every single thing on this list except the top two and you are looking at something in the region of 6 to 8 percent, most of it earned by accepting truncated file reads.

Fix when your sessions reset and you are looking at half your plan back.

This is not a criticism of the usual advice. Every item on it is true in the narrow sense that it reduces tokens. The problem is that it is presented as a flat list, so people work through it from the top, save four percent, conclude the whole thing is not worth the effort, and stop before reaching the one that mattered.

How to check your own numbers

Everything above is one dataset. Yours will differ, sometimes a lot, and the honest answer to what any of this is worth to you is that it depends on how you work.

Claude Code writes a full record of every request to your own disk, including the exact token counts. That record is the only source of truth about your own usage, and reading it is the only way to know which of these eight tactics is worth your time.

One warning if you go digging yourself. Those files contain replayed entries from resumed sessions, forks and subagents. Counting them naively overstates usage badly. On this dataset a straight count came to 11 billion tokens against a true figure of 6.3 billion, an overstatement of 1.7 times.

Next: what the compaction window does, and what the default costs you