Cache read tokens consume 99.93% of usage quota - architectural scaling issue with CLAUDE.md re-reads
Describe the bug
Every message in a Claude Code session re-sends the full instruction set (CLAUDE.md files, system prompts, conversation history) as cached context. Cache read tokens count against the usage quota. As CLAUDE.md files grow, cache read token consumption scales linearly with both file size and message count, causing quota to deplete far faster than actual productive I/O would suggest.
Data
I parsed 30 days of Claude Code session transcripts (JSONL files) and extracted token usage from every API response.
30-day totals (Jan 9 - Feb 8, 2026):
I/O tokens (actual work): 3,887,759
Cache read tokens: 5,092,500,074
Cache creation tokens: 176,498,498
Ratio: 1,310 cache reads per 1 I/O token
Cache reads as % of total: 99.93%
Weekly breakdown showing cache reads scaling with CLAUDE.md growth, not workload:
Week of Jan 11: 276,151,498 cache reads
Week of Jan 18: 967,624,068 cache reads (3.5x increase)
Week of Jan 25: 1,192,316,036 cache reads
Week of Feb 1: 1,474,919,498 cache reads (peak)
Week of Feb 8: 1,181,488,974 cache reads (ongoing)
Single-day comparison showing non-linear scaling in longer sessions:
Feb 7: 78,312,699 cache reads | 70,533 I/O tokens
Feb 8: 218,548,562 cache reads | 118,663 I/O tokens
Cache reads increased 2.8x while I/O only increased 1.7x
Environment
- Claude Code version: 2.1.37
- Models tested: Opus 4.5, Opus 4.6 (identical patterns on both)
- OS: macOS Darwin 25.2.0
- CLAUDE.md total size: ~57KB (~15,000 tokens) across global + project files
- Typical session length: 50-150 messages
To reproduce
- Create CLAUDE.md files with detailed project instructions (any size - larger files make the effect more visible)
- Run a Claude Code session with 50+ messages
- Parse the session transcript JSONL for
cache_read_input_tokensin the usage object of each assistant message - Compare cache read total to input + output token total
Token usage is available in each assistant message entry in the JSONL transcript at:~/.claude/projects/<project>/<session-id>.jsonl
Each entry contains:
"usage": {
"input_tokens": ...,
"output_tokens": ...,
"cache_creation_input_tokens": ...,
"cache_read_input_tokens": ...
}
Expected behavior
Cache read tokens should either:
- Not count against usage quota (since they represent re-reading the same context the user already provided), or
- Count at a significantly reduced weight, or
- Be minimized architecturally (e.g., don't re-send unchanged CLAUDE.md content every message, use deltas, or load instruction files on-demand)
Actual behavior
Cache read tokens count fully against quota. Every message re-sends the complete instruction set regardless of whether it changed. This means:
- A 15k-token CLAUDE.md costs 15k cache reads per message
- A 100-message session costs 1.5M cache reads just from instructions
- Multiple sessions per day compound this to hundreds of millions
- Users have no control over the re-send behavior
Why this matters
This explains the widespread "$100 feels like $20" feedback. Users are not consuming more productive tokens. Their quota is being consumed by the architectural overhead of re-reading cached context on every message. As users naturally grow their CLAUDE.md files (the intended workflow for tuning Claude Code), their quota depletion accelerates even with identical workloads.
Additional context
- This is model-agnostic. Opus 4.5 and 4.6 produce identical cache patterns.
- My CLAUDE.md setup (~57KB) is larger than average. But the architecture affects all users proportionally - a 5KB CLAUDE.md has the same pattern at smaller scale.
- I have reported this separately to Anthropic support with the full dataset.
Disclaimer: I used my own AI tool to help parse the token data from session transcripts. The data is real, pulled directly from Claude Code JSONL session logs.
14 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is not a duplicate of the linked issues:
This issue is about the fundamental architecture of re-sending the full instruction set (CLAUDE.md + system prompts + conversation history) as cached context on every single message, and provides 30 days of
quantified data showing it accounts for 93-99% of all token consumption. The scaling is linear with instruction file size and message count, creating a structural quota problem for power users.
None of the linked issues contain usage data at this scale or identify the architectural root cause.
Token Usage Analyzer Script
Since there's no built-in way to see cache vs I/O breakdown, here's the script I used to generate the data in this issue. Drop it anywhere and run it against your own session transcripts.
Usage:
Example output:
The script (no dependencies, stdlib only):
<details>
<summary>Click to expand claude_token_analyzer.py</summary>
</details>
No dependencies, just Python 3 stdlib. Run it and post your results — I want to see if the ratio holds across different setups and CLAUDE.md sizes.
"Cache reads consume 99.93% of quota - 1,310 cache reads per 1 I/O token" - This is a fundamental architectural issue with how CLAUDE.md gets re-loaded every message.
Your analysis is excellent and confirms what many users suspected ("$100 feels like $20"). The problem isn't productive work - it's architectural overhead.
Why this happens in Claude Code:
Every message sends the full context:
Even though it's cached, cache reads count against quota. In a 100-message session, that's 1.5M cache reads just from CLAUDE.md.
The "grows with CLAUDE.md size" problem:
Your data shows cache reads scaling 3.5x as CLAUDE.md grew, even though workload was similar. This is because the architecture couples instruction size to per-message cost.
The mobile approval angle:
While ForkOff doesn't solve the cache read architecture issue (that needs a fix from Anthropic), mobile approvals at least don't add to the problem:
Workaround for Claude Code (until this gets fixed):
But this defeats the purpose of detailed CLAUDE.md tuning.
For power users burning through quota:
The real solution needs to come from Anthropic - caching should either not count against quota, or CLAUDE.md shouldn't be re-sent every message. Your analysis makes this crystal clear.
Just launched mobile approval for Claude Code this week. Waitlist at https://forkoff.app
(Disclosure: I work on ForkOff. Your cache read analysis shows a major architectural issue in Claude Code. We can't fix that, but mobile approvals at least don't make it worse.)
---
P.S. The fact that you did this analysis with "30 days of session transcripts" shows you're a power user. Hope Anthropic addresses this - it's a tax on detailed CLAUDE.md configurations.
Watching this - I couldn't understand how it felt like when I had MORE cache it cost me MORE quota.
Are you sure you are actually being billed for those cache read tokens?
The models are stateless - they don't learn or change during inference time, only when Anthropic runs training. If the Claude.md is going to be used at all, it has to be included in each request. That is why the cache exists, so that the model can save the work of processing that "preamble", but that cache doesn't last forever (5 minute TTL by default), and it costs something to store the data, so you pay for it in the
cache_creation_input_tokenswhich DO count against your quota.See https://platform.claude.com/docs/en/api/rate-limits#cache-aware-itpm for more info (and https://ngrok.com/blog/prompt-caching for a deeper-dive on cached tokens in general).
_Apologies in advance if this is old news - perhaps it will help others._
not billed but its counted towards your session and weekly quota. which quickly adds up if you have a lot of cache tokens
I've done extensive analysis on this exact problem. Using ccusage_go (open-source Claude Code usage tracker), I found that Cache Read tokens consumed 97.7% of my session costs — API actual cost was $1.47, total billed cost was $64.98 (a 44x markup). Cache also degrades instruction following in long sessions, which I documented with per-turn JSONL analysis.
Full write-up with data, community issue references, and Claude Code's own self-analysis report:
https://blog.sd.idv.tw/en/posts/2026-03-25_claude-code-cache-trap/
Tool: https://github.com/SDpower/ccusage_go
I can confirm this pattern since late March. In my case it does not appear to be caused by workflow changes, model changes, long sessions, compaction, or resumed chats. I always start fresh sessions, use the same model, and have not materially changed my workflow.
What has clearly changed is that my quota is now being consumed mostly by context/cache accounting rather than productive tokens, by roughly 4x compared with before. I am getting far less real work out of the same 5-hour window, and the burn is heavily concentrated in context. I am effectively filling a 200k context window in a session where I have only used about 50k productive tokens.
This looks like a bug in how cached or reused context is being counted against quota. The current behaviour is materially worse than before despite no meaningful change in workflow.
I've also seen some change in cache reads and writes in Claude Code using API in AWS Bedrock on Opus 4.6 and Sonnet 4.6. The reported/estimated cost seems to be skyrocketing particularly in longer sessions. Once the context increase a fair amount, the token usage and costs seem to exponentially increase with each message turn $1-$5+ per message. I went from spending $10-15 per day to $60-$100 per day or more.
I'm regularly seeing single messages with 1 or 2 tool calls running $4-10 dollars or more - even with very little input or output tokens. Something has changed in the past week or two.
What’s confusing here is that “cache read” sounds like it should be free, but it’s not.
A cache hit just means the model didn’t recompute the tokens. It still has to process them and they still count toward your quota.
The part that bites people is repetition.
If you have something like a large CLAUDE.md or long session context, that entire block can get re-read every turn. So even if you’re only asking for a small change, you’re repeatedly paying (discounted, but still real) for the same large chunk of tokens.
At a certain size, those repeated reads outweigh the cost of actual output, which is why you see 99%+ of usage going to “cache reads.”
It feels like nothing is happening, but under the hood you’re effectively paying for the same context window over and over.
Curious — has anyone measured how much of their usage is coming from static files like CLAUDE.md vs actual prompt/output?
I'm glad I stumbled upon this because my Cache Read is off of the charts. I noticed this problem was worse while running agent .md files and switching to general use is better.
<img width="636" height="283" alt="Image" src="https://github.com/user-attachments/assets/766dd6d7-68c5-45cd-9408-56627308e3d4" />
this is actually good. it means cache works. otherwise you wouldve literally paid 10s of thousands if hose were NON cache read. this is just cache doing its job. and at that % is doing its job HELLA good.
check the relation:
Cache read tokens: 5,092,500,074
Cache creation tokens: 176,498,498
ugh totally — that 57kb (~15k token) CLAUDE.md getting re-read (1,310 cache reads per 1 i/o token and 99.93% of quota) is exactly what's killing sessions. fyi wozcode cut my token spend ~50% by doing smarter caching, see https://wozcode.com