[BUG] Prompt Cache Invalidation on Session Resume: Tool-Use Content Not Cached, Plugin State Changes Cause Full User Content Rewrite

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/24121
2. https://github.com/anthropics/claude-code/issues/26330
3. https://github.com/anthropics/claude-code/issues/22107

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

The problem still occurs in Claude Code 2.1.71

The problem still occurs in Claude Code 2.1.81

Also getting this with llama.cpp and Qwen 3.5 27B:

slot update_slots: id  0 | task 1810 | erased invalidated context checkpoint (pos_min = 24270, pos_max = 24270, n_tokens = 24271, n_swa = 1, size = 149.626 MiB)
slot update_slots: id  0 | task 1810 | erased invalidated context checkpoint (pos_min = 27150, pos_max = 27150, n_tokens = 27151, n_swa = 1, size = 149.626 MiB)
slot update_slots: id  0 | task 1810 | erased invalidated context checkpoint (pos_min = 27662, pos_max = 27662, n_tokens = 27663, n_swa = 1, size = 149.626 MiB)
slot update_slots: id  0 | task 1810 | erased invalidated context checkpoint (pos_min = 29952, pos_max = 29952, n_tokens = 29953, n_swa = 1, size = 149.626 MiB)
slot update_slots: id  0 | task 1810 | erased invalidated context checkpoint (pos_min = 30464, pos_max = 30464, n_tokens = 30465, n_swa = 1, size = 149.626 MiB)
slot update_slots: id  0 | task 1810 | erased invalidated context checkpoint (pos_min = 30984, pos_max = 30984, n_tokens = 30985, n_swa = 1, size = 149.626 MiB)
slot update_slots: id  0 | task 1810 | erased invalidated context checkpoint (pos_min = 31496, pos_max = 31496, n_tokens = 31497, n_swa = 1, size = 149.626 MiB)

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'm getting the same issue. If I step away for more than 10 mins then come back, the first message (even before any work is done) uses 10-20% of my $100 max plan.

I'm not sure both of you mean the same issue I described. The issue I notices is an inconsistency in the caching behavior.
The cache holds for the most part when existing and resuming a session within the 5min cache window but there are irregular behaviors which shouldn't occur:

1. On resume there is always a small token count which should be cached read tokens but are added as new write cache tokens. This is most likely due to a timestamp, version or other variable which sometimes chances and rewrites part of the cache. The portion increase with the conversation length and sometimes the portion randomly is the entire conversation after the system prompt, Claude.md and system tools. Maybe this has also something to do with point 2 but I'm not sure about this.
2. Changing plugin registrations mid conversation invalidates the cache which is a design decision by Anthropic. The available slash commands, agents and skills which are found in these plugins are added somewhere at the start of the conversation properly alongside the system tools. These are most likely modified through that which invalidates the whole conversation afterwards. The problem is that this is nowhere documented as far as I know and Claude Code supports /reload-plugins to load them without existing and resuming. This is bad for users trying to optimize the context and the model should be able to handle plugin changed if a "new available plugin tools" message would be appended at the reload/resume point in conversation.

The two issues from you two seem like a misunderstanding in how the cache and the conversation work. On each message, the entire conversation history is sent back to the model and the whole conversation is processed to calculate the next response. If this was done without any optimization the compute time and cost would be a getting more with each added message. That's why this process is cached to reduce time and compute which is the reason why cache read tokens will be most of the token usage and also why these tokens are "cheaper" than the input, cache write and output tokens. By default the cache is a rolling 5 minute window which is invalidated 5 minutes after the last response from the user/model. On your next message after the cache is invalidated the conversation is written to the cache again which results in cache write tokens instead of the cache read tokens.

Hope this rough explanation helped and if one of you meant something different then it might help to explain it in longer format here or if it is not related to this issue in a new issue by itself.

Both issues described here are addressed by our cache-fix interceptor (npm install -g claude-code-cache-fix, v1.2.0).

Tool-use content not cached across resume — This is caused by attachment blocks (skills, MCP, deferred tools, hooks) drifting to the wrong position in the message array on resume, breaking the prompt cache prefix match. The interceptor scans the full message array on every API call, relocates the latest version of each block type back to messages[0] in a deterministic order, and stabilizes the cc_version fingerprint in the attribution header. This preserves the prefix across resume.

Plugin state changes triggering full rewrite — Plugin enable/disable changes the skills and deferred tools blocks, which changes the prefix bytes. The interceptor normalizes these blocks on every call: skills entries are sorted alphabetically, tool definitions are sorted by name, and ephemeral content (session_knowledge) is stripped. This makes plugin state changes invisible to the cache prefix.

Eliminating the resume cold start entirely — Even with the relocation fix, the first post-resume API call used to trigger a cache rebuild because CC reassembles messages differently on resume. As of v1.2.0, the interceptor includes a prefix lock feature (CACHE_FIX_PREFIX_LOCK=1) that saves the exact messages[0] content and replays it on resume, producing a byte-identical prefix. In our testing, this achieved 99.4% cache hit rate on the first post-resume call vs 44% without.

Your heavy-read scenario (20+ Read ops, 99% → 17% hit rate, 91k rewrite) is the exact pattern the relocation fix prevents. Your plugin toggle scenario (113k invalidated) is what the block sorting and tool stabilization prevent.

The interceptor works as a Node.js preload module — requires the npm installation of Claude Code, not the standalone binary.

I read through it and yes that might help with the drifting messages on resume if these are the cause but I'm unsure how sorting the tools and skills by names would actually fix the plugin state changes. It might improve the cache hit rate because drift in the order is avoided but the plugin tool registration is logically wrong in Claude Code. The registered plugin tools are always at the conversation start and there is no intermediate message logic informing the model of changed registrations but instead the conversation is rewritten by modifying the changed plugin tools at the start.
If your interceptor addresses that too and I missed it let me know because I would be interested how you solved that.

Other than that your interceptor is a nice idea but I would prefer if the Claude Code team would actually address these issues in their code instead of adding a wrapper around the API calls. These harnesses like Claude Code change so quickly that adding more external complexity might only be helpful for one or two versions or prevent internal fixes from working.

Good questions. Let me address both.

Plugin tool registration: You're right that the issue goes deeper than just ordering — CC rewrites messages[0] with modified plugin/MCP blocks but doesn't inform the model via intermediate messages. Our interceptor does handle this. The normalizeResumeMessages function scans the entire message array backward on every API call to find the latest version of each block type (skills, MCP, deferred tools, hooks), removes all instances from wherever they've drifted, and consolidates them into messages[0] in a deterministic order (deferred → mcp → skills → hooks) matching fresh session layout. So when CC rewrites a plugin registration into a later message position, we catch it and move it back. Skills entries and tool definitions are also sorted alphabetically so that enable/disable toggling doesn't change prefix bytes.

It doesn't fix the logical problem you're describing (the model not being told about registration changes via intermediate messages) — that's an architectural issue CC needs to address. But it does prevent the cache bust that results from the rewrite.

Fragility concern: Completely agree. This is a stopgap, not a solution. We'd much rather see Anthropic fix the root causes in CC itself. The interceptor exists because these bugs have persisted across multiple versions (confirmed through v2.1.92) and the cache cost impact is significant — our performance data shows 52–73% of API calls need block relocation and 98% need tool reordering. That's a lot of unnecessary cache rebuilds on every resumed session.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.