Resume of long sessions loads disproportionate tokens from opaque thinking signatures

[KenMalloy]

Summary

When resuming a long conversation, thinking block signatures from prior turns are replayed as input tokens. These signatures are base64-encoded, opaque to the user, and can dominate the context budget — making resume impractical for exactly the kind of long sessions where it's most valuable.

Observed behavior

I analyzed the JSONL for a ~24-hour brainstorming session (480 messages, 33 turns). Each assistant turn that used extended thinking stored a block like:

{"type": "thinking", "thinking": "", "signature": "EppNClkIDBgCKkBPOAzXuQ...  (up to 13,184 chars)"}

The thinking field is empty (stripped for local storage), but the signature field contains the encrypted thinking content. On resume, these signatures must be sent back to the API.

Token budget breakdown for this session

Component	Est. chars	Est. tokens
User text messages	62,248	~15,500
Assistant text	157,868	~39,500
Tool results	211,536	~52,900
Tool use inputs	36,200	~9,000
Thinking signatures	207,120	~38,800
Total on resume	~675,000	~156,000

Thinking signatures account for ~25% of the entire resume payload despite being invisible to the user.

Details

• 54 thinking blocks across 33 turns
• Average signature size: 3,835 chars
• Max signature size: 13,184 chars
• Total signature chars: 207,120
• All thinking text fields are empty strings — only signatures remain

Impact

• Resuming a long brainstorming/dialog session costs ~156K input tokens before the user types anything
• ~39K of those tokens are purely from thinking signatures the user never sees
• This makes resume impractical for long sessions — the exact use case where resume is most needed
• Users on metered plans pay for tokens they can't see or control

Expected behavior

Options that might help:

1. Summarize/compact thinking signatures on resume — rather than replaying all 54 thinking blocks verbatim, summarize older ones and only preserve recent signatures
2. Drop thinking signatures beyond a recency window — e.g., only keep the last N turns' thinking intact
3. Show thinking token cost in the resume prompt — so users can make an informed decision about whether to resume vs. start fresh
4. Apply the existing auto-compaction logic to thinking signatures — the system already compresses prior messages as context limits approach, but thinking signatures may not be included in that calculation

Environment

• Claude Code CLI
• Model: claude-opus-4-6 (1M context)
• Platform: macOS Darwin 24.6.0

[KenMalloy]

Related: community-found cache invalidation bug on resume

A community member on Reddit (repo) independently identified a separate but compounding root cause for excessive token consumption on resumed sessions.

The claim

A function in the minified cli.js (called db8 in the minified source) filters what gets saved to session JSONL files. For non-Anthropic users, it strips all attachment-type messages except hook_additional_context. This inadvertently drops deferred_tools_delta and mcp_instructions_delta records.

On resume, Claude Code scans message history to determine which tools were already announced. Because those records were stripped, it finds nothing and re-announces every deferred tool from scratch. This breaks the cache prefix in three ways:

1. System reminders that were at messages[0] in the fresh session now land at messages[N]
2. The billing hash changes because the first message content differs
3. The cache_control breakpoint shifts because the message array has a different length

Result: the entire conversation rebuilds as cache_creation tokens instead of hitting cache_read. The longer the conversation, the worse it gets.

Reported numbers (before/after patch)

Before (stock):

Turn	cache_read	cache_creation	ratio
1	15,451	7,473	67%
5	15,451	16,881	48%
10	15,451	35,006	31%
15	15,451	42,970	26%

cache_read never moved — stuck at 15,451 (system prompt only).

After (patched):

Turn	cache_read	cache_creation	ratio
1 (resume)	7,208	49,748	13%
2	56,956	728	99%
3	57,684	611	99%

The proposed fix

Two lines added to the attachment filter allowlist:

if(A.attachment.type==="deferred_tools_delta")return!0;
if(A.attachment.type==="mcp_instructions_delta")return!0;

How this relates to the thinking signature issue

These are compounding problems:

1. This issue (thinking signatures): ~39K tokens of opaque thinking signatures inflate the raw payload size on resume
2. The cache bug: Even after paying for those tokens, they don't benefit from prompt caching because the cache prefix is invalidated by missing deferred tool records

Together, a resumed long session pays full price for a bloated payload that should have been partially cached.

Related issues

• [BUG] Conversation history invalidated on subsequent turns #40524
• [BUG] Prompt cache regression in --print --resume since v2.1.69(?): cache_read never grows, ~20x cost increase #34629
• https://github.com/Rangizingo/cc-cache-fix/tree/main

Note: I have not independently verified the minified source analysis. The reported cache ratio numbers are from the community member's testing on v2.1.81.

[jmarianski]

That's a very interesting issue there you've found. Analyzing my conversations I've had with claude code, I've found that thinking blocks weren't a dominant factor, but I ran mostly on medium effort, so I disregarded them. However, I've gathered some statistics (data coming from 2.1.68 and 2.1.77+):

• thinking blocks accounted for 1.4% of my tokens (2.1.68)
• signature accounted for 2.6% (still 2.1.68)
• which totals to 4% of body
• in some sessions I was able to reach up to 20% of total body size with signatures alone

However, it should be accounted that these numbers could relate to the fact, that when working on 2.1.68 I was forcing claude to work mostly explicitly by writing stuff, not making stuff up. So less chances for thinking. In more thinking intensive tasks it could be thinking more, and I've had such sessions where it could have risen to 20-40%.

---

Although it's not necessarily related to resumes. They are a separate breed of issues that need to be resolved as well, however the issue you're pointing at (the increased costs through thinking block signatures) is related to EVERY POSSIBLE TURN.

I couldn't find anything in my findings, analysis and their source code that could refute your points. This means that in fact we're paying some percent of our tokens meaninglessly. Great find!

[ArkNill]

Great analysis on the thinking signature replay. This is closely related to a broader set of --resume token issues I've been tracking.

The resume problem is multi-layered

1. Thinking signatures as input tokens (what you found) — base64-encoded thinking blocks from prior turns get replayed as input. In long sessions these can dominate the context budget.

2. Cache invalidation on resume ([BUG] Prompt cache regression in --print --resume since v2.1.69(?): cache_read never grows, ~20x cost increase #34629) — the deferred_tools_delta feature (v2.1.69+) reorders tool results when reconstructing the conversation for resume. This reordering breaks the cache prefix, so the entire replayed history (including those bloated thinking signatures) is billed as fresh input tokens with zero cache hits.

3. Compounding effect — without cache, a 480-message session like yours could easily send 500K+ tokens as fully-billed input on the first resumed turn alone. This is why --resume can act as a "token bomb" that instantly drains your rate limit.

Practical recommendation

Until these are fixed, I'd strongly recommend avoiding --resume entirely for long sessions. Starting a fresh session with a well-structured CLAUDE.md to restore context is significantly cheaper than resuming, because:

• Fresh sessions build cache incrementally (each turn caches the prefix)
• Resumed sessions replay everything at once, often with broken cache

Related work

I've documented the cache bugs, token inflation mechanics, and workarounds here:
👉 https://github.com/ArkNill/claude-code-cache-analysis

Your JSONL analysis approach is excellent — that's exactly the kind of evidence Anthropic needs to prioritize these fixes.

[ArkNill]

Update (April 2): v2.1.90 fixes the main cache regression but this specific issue (--resume / session replay) remains. Avoid --resume entirely — fresh sessions with a structured CLAUDE.md are the workaround.

For non-resume usage, v2.1.90 now achieves 95-99% cache read on both npm and standalone. Details: https://github.com/ArkNill/claude-code-cache-analysis