[Bug] v2.1.88 yanked release caused wasted session + significant token loss

Additional: Double/Triple memory injection bug (token waste across ALL sessions)

During the post-downgrade audit, I also discovered a systemic token waste bug that had been affecting every single session for weeks:

The bug

Claude Code's auto-memory system automatically loads ~/.claude/projects/.../memory/MEMORY.md into the conversation context. However, the official hook documentation examples led me to implement:

1. SessionStart hook — injected memory content via stdout → duplicated what auto-memory already loads
2. PostCompact hook — re-injected memory content via stdout after each compaction → tripled the injection

Result: The same memory content was loaded up to 3 times per compaction cycle:

• 1x by auto-memory (built-in, correct)
• 1x by SessionStart stdout (duplicate)
• 1x by PostCompact stdout (triplicate)

Token impact estimate

• Memory content: ~252 tokens per injection
• Per session with 2-3 compactions: ~756 extra tokens wasted (minimum)
• Over weeks of daily heavy usage (multiple sessions/day): thousands of tokens wasted silently

Root cause

The documentation does not clearly state that:

• Hook stdout = tokens injected into context
• Hook stderr = log only (invisible to the model)
• The auto-memory system ALREADY handles memory loading natively

Users following hook examples naturally end up duplicating what the system already does, with no warning or deduplication.

Fix applied (user-side)

• SessionStart: zero stdout, only saves state to files + logs to stderr
• PostCompact: zero stdout, only macOS notification + logs to stderr
• PreCompact: stdout limited to git state only (branch/commit/modified files)

Suggestion

The documentation should explicitly warn that hook stdout consumes tokens and that memory content should NOT be injected via hooks since the auto-memory system handles it. Ideally, Claude Code should deduplicate identical content injected via multiple hooks.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/41387
2. https://github.com/anthropics/claude-code/issues/41497
3. https://github.com/anthropics/claude-code/issues/41530

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

Related — v2.1.88 was installed Mar 31 on my machine, and the rate limit issues started around the same time. v2.1.89 auto-updated Apr 1, problem persists.

Max 20, 100% usage in ~70 min after reset.

Full report: #41788
Related: #38335, #38239, #40790, #6457, #40895, #41055, #38345, #41174, #41550, #41617, #41663, #41779, #41802

News Today?

I've been experiencing the same issue on Max 20 ($200/mo) — rate limit 100% exhausted in ~70 minutes.

After setting up a monitoring proxy using the official ANTHROPIC_BASE_URL env var, I identified two cache bugs as the root cause (#40524, #34629) and measured the impact: cache read ratio dropped to 4.3%, meaning ~20x token inflation per turn. After applying workarounds it stabilized at 89-99%.

Full analysis with per-request measured data, safe workarounds, and community references (including cc-cache-fix): https://github.com/ArkNill/claude-code-cache-analysis

Update (April 2): v2.1.90 resolves the cache regression that was present in v2.1.89.

Benchmark confirms v2.1.90 achieves 95-99% cache read in stable sessions (both npm and standalone). If you haven't already, update and pin:

claude update
# Then add to ~/.claude/settings.json:
# { "env": { "DISABLE_AUTOUPDATER": "1" } }

Details: https://github.com/ArkNill/claude-code-cache-analysis

Update: v2.1.90 installed — verifying fixes

I've updated to v2.1.90 and I'm currently verifying the fixes in my environment. Here's what I've confirmed so far:

• Cache read ratio: back to 95-99% (was ~4% on v2.1.88/89) — consistent with @ArkNill's findings
• Autocompact thrashing: resolved natively (removed my custom rapid-refill breaker workaround since v90 handles it internally)
• Hook if compound commands: now working correctly, restored proper pattern matching in settings.json
• CLAUDE.md re-injection: no longer duplicates context on compaction

What we're still waiting on

While v2.1.90 technically resolves the symptoms, the core issue remains: v2.1.88 was a broken release that auto-updated silently, causing significant token waste and degraded sessions for paying users before we could even notice.

For affected Max plan subscribers who lost substantial token budget during the v2.1.88/89 window, it would be fair for Anthropic to consider resetting or crediting the accounts that were impacted by the broken auto-update. We didn't opt into a buggy release — it was pushed to us automatically, and the token drain was invisible until we investigated manually.

This isn't just about the technical fix. It's about trust in the auto-update pipeline and accountability when a bad release ships to paying customers.

Suggestion for Anthropic

1. Identify accounts that ran v2.1.88/89 with abnormally low cache hit rates
2. Credit or reset their usage for the affected period
3. Add a rollback mechanism or at minimum a "hold current version" flag that doesn't require manual DISABLE_AUTOUPDATER workarounds

Looking forward to Anthropic's response on this.

April 3 update: The cache regression (Bugs 1-2) is fixed in v2.1.91. However, systematic proxy testing revealed additional unfixed mechanisms — a 200K tool result budget cap, a client-side false rate limiter (151 synthetic entries found), and silent microcompact clearing (327 events). Anthropic responded on X (Lydia Hallie) acknowledging peak-hour tightening but stating "none were over-charging you" — our measured data shows mechanisms their statement does not cover. Full analysis: claude-code-cache-analysis

Related — we hit the same cost spike ($364.87 extra in a single day on a $200/mo Max plan) and traced part of it to a resume context loading regression in v2.1.91.

Source code analysis (v2.1.88 leaked TypeScript vs v2.1.91 minified cli.js) revealed three changes:

1. walkChainBeforeParse removed — the fork pruning function exists 2× in v2.1.88 source, 0× in v2.1.91. Large JSONL files (>5 MB) now load all fork branches unpruned.
2. New ExY timestamp fallback — tengu_chain_timestamp_fallback (0× in v2.1.88, 1× in v2.1.91) bridges unrelated messages across fork boundaries via a 5-second temporal window.
3. Missing leafUuids check in getLastSessionLog (line 3900) — picks mid-chain synthetic messages instead of actual conversation leaves.

Result: /resume loads 644 tokens (0.1%) from a 20 MB session (5,027 lines, 444 user messages). Each failed resume corrupts the JSONL further by forking the parentUuid DAG.

Full analysis with exact file:line references, suggested fixes, and Claude Code prompts: #43044

We also built a Go tool to recover session context directly from JSONL files (bypassing the broken resume): https://github.com/kolkov/ccdiag

@ArkNill your proxy-based cache analysis is excellent work — the silent microcompact (327 events) and false rate limiter (151 entries) findings are particularly valuable. Our data confirms the same pattern from a different angle (session JSONL forensics vs API traffic analysis).

Good morning everyone, has anyone received a Recette refund on their account following the issues we’ve had over the past few days? Or, even if it wasn’t labeled as a refund, did they credit your account anyway in our favor, considering the problem originated on their side?

@amicicixp Short answer: no. After searching across the major rate limit / token drain threads (#38335, #16157, #38350, #41930, #21601, #5088, etc.), there are zero confirmed cases of Anthropic issuing a voluntary refund or credit for the token consumption bugs.

The only confirmed refunds were automatic refunds tied to account suspensions/disablements — not compensation for service issues. For example:

• #29082 — $105.66 refund, but it came with an account ban
• #5088 — multiple users received refunds only because their accounts were disabled

Users who actively requested refunds through support have been either auto-rejected (#21601 — $440 request rejected, 22 emails with zero human response) or simply ignored (#29108 — 19 days, no human reply). At least two users have filed formal chargebacks through their credit card companies.

Meanwhile, there has been zero official Anthropic response on any GitHub issue regarding refunds, credits, or compensation for the token drain bugs affecting users since March 23. The situation is effectively being left unaddressed.

Important finding for everyone affected by token drain bugs:

Claude Max individual subscribers fall under Consumer Terms, NOT Commercial Terms. The difference is critical:

| | Consumer Terms (Max subscribers) | Commercial Terms (API/business) |
|---|---|---|
| Arbitration clause | NONE | Mandatory JAMS |
| Class action waiver | NONE | Yes |
| Governing law | Irish law | California |
| Courts | EEA consumers can use local courts | San Francisco only |

This means:

1. No forced arbitration — you can go to court
2. No class action waiver — collective action is possible
3. EU Consumer Rights Directive applies — buggy digital service = "non-conformity" = right to price reduction or refund under Directive 2019/770
4. The liability cap (6 months fees / €100) likely doesn't apply to billing corrections for bug-inflated charges — returning overcharged money is not "damages"

What we know about refund attempts

Per @ArkNill's research above: zero voluntary refunds, $440 request auto-rejected with no human response (#21601), 19 days no reply (#29108), at least 2 chargebacks filed.

Recommended steps

1. File refund request through Claude support — frame as billing error caused by confirmed bugs, not as damages claim. Reference #41930 (acknowledged by Anthropic), #38335 (201+ 👍), media coverage (The Register, MacRumors)
2. Document everything — save billing screenshots, session logs. ccdiag proxy can log per-request token usage and cache ratio for evidence
3. If rejected — EU residents can use EU Consumer Dispute Resolution
4. Chargeback — last resort only, Anthropic will likely ban the account

Our data point: $364 extra in a single day on a $200/month plan, caused by resume cache invalidation (#42338), quadratic transcript writes (fixed in v2.1.90 after 20+ versions), and watchdog retry loops (#39755). Rate: $10,920/month.

The token drain bugs are well-documented: resume cache miss lived for 20+ versions (v2.1.69→v2.1.90), cch=00000 Bun attestation bug (#38335) causes 10-20x token inflation, and Anthropic publicly acknowledged that "users hitting usage limits way faster than expected."

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.