A 28KB CLAUDE.md costs 7,379 tokens and no measurable time
Across 20 paired runs, the version with a 28KB CLAUDE.md was slower 13 times and faster 7. That is a coin flip. You pay for config size in tokens, not in waiting.
A 28KB CLAUDE.md costs 7,379 tokens on every session, and that cost is paid again on every tool call. The obvious follow-up: does all that context also make Claude Code slower?
No. Not measurably, and not by an amount you could feel.
The result
Twenty paired runs, alternating between a project with no CLAUDE.md and the same project with a 28,000-byte one, both warm, interleaved so that network conditions affect both conditions equally.
| Measure | Value |
|---|---|
| Pairs where 28KB was slower | 13 of 20 |
| Sign test | p = 0.263 |
Median time to first token, no CLAUDE.md |
1,986 ms |
| Median time to first token, 28KB | 2,373 ms |
| Median per-pair difference | 178 ms |
Thirteen out of twenty sounds like a trend until you run the test: p = 0.263, which is what a fair coin does about a quarter of the time. There is no effect here that this experiment can distinguish from chance.
Why the medians look further apart than the pairs are
The two medians differ by 387ms, which is larger than the 178ms median of the paired differences. That gap is the noise talking.
Run-to-run variance on identical configurations was enormous:
| Condition | Range across runs |
|---|---|
No CLAUDE.md |
1,584 – 6,126 ms |
28KB CLAUDE.md |
1,527 – 8,337 ms |
The fastest run with 28KB of extra context beat the slowest run without it by four seconds. A single outlier moves an unpaired median by hundreds of milliseconds, which is why the comparison has to be paired and why six samples were not enough to say anything.
Cold caches are not slower either
A related intuition also fails. Invalidating the cache makes the next run cost about 15x more, so it is natural to assume it is slower too. Four paired cold/warm runs, where cold meant writing 47,825 tokens of fresh cache:
| Median time to first token | |
|---|---|
| Cold cache | 2,223 ms |
| Warm cache | 2,358 ms |
The cold runs came out marginally faster, which with four pairs means only that there is no visible effect. Treat this one as preliminary rather than settled: it is four samples, not twenty. But it points the same way.
What to take from this
Optimise config size for cost, not for speed. The token argument for a lean CLAUDE.md is strong and measured. The speed argument does not appear to exist. If you have been keeping instructions out of your config because you thought it would slow Claude down, that concern is not supported here.
And be sceptical of anyone benchmarking this casually. With variance of 1.5 to 8.3 seconds on identical inputs, two runs will tell you whatever you want to hear. If you see a latency claim about Claude Code that is not paired and not repeated a dozen or more times, it is measuring the network.
What this does not claim
It does not claim a 28KB CLAUDE.md is free of latency cost. It claims that any such cost is small enough to hide inside normal run-to-run variance at twenty paired samples. A much larger config, a slower connection, or a more sensitive measure than time-to-first-token could all surface something this did not.
It also measures only the first token of a trivial one-word reply. Longer generations and tool-heavy sessions were not tested.
Measured on Claude Code 2.1.224, headless mode, ttft_ms from --output-format json, paired and interleaved, 20 pairs for the CLAUDE.md comparison and 4 for the cache comparison.