Does Claude Code cache your startup context? Yes, but fresh sessions pay for CLAUDE.md again

@Cutzilla asked a question we hadn’t measured: Claude Code sends a big fixed block (system prompt and tools) on every session, so is that block actually cached after the first turn, and how much does trimming your own CLAUDE.md change what you pay? They were on a subscription and couldn’t see the bill. We ran it on the API and logged the cache numbers on every request.

Our context audit measured how many tokens a setup loads. This one measures what the prompt cache does with them, and how that changes between fresh sessions and one continued session.

The setup

The small cart module from our /clear test, with the same three tasks in order:

1. Add a discount(items, percent) function, with a test.
2. Add an itemCount(items) function, with a test.
3. Write a README documenting every exported function and how to run the checks.

Two things changed, giving four setups (2×2):

• CLAUDE.md: the full 1,501-word file from the context audit (history, team, workflows, a glossary, with four real rules buried in it), or the trimmed 9-line file with the same four rules. Nothing else under .claude/ in either.
• Session: a fresh session for each task (what /clear gives you), or one continued session across all three.

3 runs of each setup, 12 in all, run one at a time in three rounds; each round ran all four setups back to back. Claude Code 2.1.321, Sonnet 5.5. Seven checks after every run, including hidden tests for discount() and itemCount() that Claude never saw.

For each step we logged every API request the main conversation made: uncached input, cache reads and cache writes. Those per-request numbers add up exactly to the step’s own usage total in every step of every run.

What happened

The first request of each task (what the session loads before Claude does any work):

Token counts are per request, as the API reported them. Averages over 3 runs; ranges are lowest to highest. Every run, check and diff: run data.

What we learned

The fixed block was cached, even on the very first request. In all 12 runs, with both CLAUDE.md sizes, the first request of task 1 read exactly 13,069 tokens from cache and sent only 2 tokens of uncached input. Later fresh sessions read 14,678 to 14,679 on their first request, again with 2 uncached. That held even for the first session of our run, so the cache was already warm from earlier requests on our key. We can’t show you a cold first request, and we can’t say exactly what is inside those 13,069 tokens, only that the number was the same in every run and didn’t change with CLAUDE.md.

CLAUDE.md was paid for again in every fresh session. The full CLAUDE.md added about 3,170 tokens to the first request’s cache write (8,872 to 8,877 vs 5,704 to 5,708). In fresh sessions, the first request of tasks 2 and 3 read 14,678 to 14,679 tokens from cache and wrote 7,280 to 7,281 with the full file, against 4,109 to 4,112 with the trimmed one. That is the same gap of about 3,170 tokens, so the CLAUDE.md part was written to cache again rather than read, even though the previous task had cached it moments before. Cache writes cost more than normal input, so a big CLAUDE.md costs most when you start lots of short sessions.

A continued session mostly read instead of wrote. In the continued sessions, the first request of tasks 2 and 3 read 21,507 to 27,372 tokens from cache (the whole conversation so far) and wrote only 148 to 397. Tasks 2 and 3 averaged $0.013 to $0.023 each there, against $0.029 to $0.046 in fresh sessions.

Both levers saved money, and they stacked. Trimming CLAUDE.md cut the average sequence cost by 22% in fresh sessions ($0.148 to $0.115) and 20% in continued ones ($0.102 to $0.082). Staying in one session cut it by 31% with the full file and 29% with the trimmed one. Trimmed and continued together cost 45% less than full and fresh.

What failed, and the limits of this test

• Nothing failed. All 12 runs passed all 7 checks, so this says nothing about whether trimming loses rules you need. Our trimmed file kept the four rules the checks depend on. Cut a rule your code relies on and it would be a different story.
• We never saw a cold cache. The prompt cache lasts about 5 minutes and is shared across requests on the same key, and our runs went back to back. A first session after a long break would likely write the fixed block instead of reading it. We didn’t measure that, or what happens when you pause more than 5 minutes inside a continued session.
• Small tasks, small repo, related tasks. The three tasks touched the same files, which favors a continued session. On unrelated tasks the trade-off can change.
• Costs are API list prices as Claude Code reports them, not subscription usage. For continued sessions we take each step’s cost as the session total minus the steps before it.
• 3 runs per setup. The averages were well apart, but it’s a small sample, and we can’t tell you exactly which part of the startup context sits where in the cache.

The recipe

1. Trim CLAUDE.md to what almost every task needs. Commands and hard rules. Here that was worth 20 to 22% per sequence, with nothing lost on the checks.
2. Don’t fear the fixed overhead. In our runs, every session’s first request was almost all cache read: 2 tokens of uncached input, the rest read or written.
3. Fresh sessions re-pay for CLAUDE.md. If you /clear a lot, a short CLAUDE.md matters more.
4. Stay in the session for related work. Continued tasks read the conversation from cache and wrote almost nothing new.
5. Check your own numbers. claude -p --output-format stream-json --verbose shows cache_read_input_tokens and cache_creation_input_tokens on every request.