Excessive token consumption after recent updates (Max plan)

https://github.com/anthropics/claude-code/issues/38335#issuecomment-4163393947

i was looking for this. i finished 5hrs token in 1hr an a half on a single session on the max plan.
In previous weeks by using 3 parallel sessions i would finish them after 4 hours and 50 min.

this bug is huge!

/claude-md-management:revise-claude-md just ate up 27% of my session budget. Prompting "hi" took another 2% and just exiting and resuming the session 5%. I'm on a pro plan using mac OS.

use this https://github.com/moltcode/moltcode I just disable all the mcp bs, I mostly don't need it. It's pointless keep em lingering. use those mcp clis why bother pay for those 100 levels of mcps configuration

But honestly .88 has problem, It consumed my last 10 percent last week, like in once 5 hour window in 15 minues, I downgraded to 77

The excessive token consumption after recent updates is likely caused by multiple compounding factors. Here are hook-based mitigations that can significantly reduce token usage:

1. Disable deferred tool loading (biggest single impact):

Add to ~/.claude/settings.json:

{
  "env": {
    "ENABLE_TOOL_SEARCH": "false"
  }
}

Deferred tools inject tool schemas dynamically, which can invalidate the prompt cache prefix. Disabling this prevents mid-session cache breaks.

2. Hook to block reads of excessively large files:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read",
        "hooks": [
          {
            "type": "command",
            "command": "INPUT=$(cat); FILE=$(echo \"$INPUT\" | jq -r '.tool_input.file_path // empty'); if [ -f \"$FILE\" ]; then LINES=$(wc -l < \"$FILE\"); if [ \"$LINES\" -gt 2000 ]; then echo \"{\\\"decision\\\": \\\"block\\\", \\\"reason\\\": \\\"File has $LINES lines. Use offset/limit to read specific sections, or use Grep to find what you need.\\\"}\"; fi; fi"
          }
        ]
      }
    ]
  }
}

This prevents Claude from dumping large files into context, which is a common token waste pattern.

3. Use /compact proactively:

When context grows large, especially before switching topics within a session, use /compact to reset the conversation. This rebuilds the cache cleanly.

4. Avoid --resume (known cache-breaking trigger):

Session resume (--resume) is known to cause cache misses (see #40524). Start fresh sessions when possible. If you must resume, expect a one-time cache rebuild cost.

5. Check for the cch= cache poisoning bug (#40652):

If Claude has read its own session files or proxy logs during a session, the cch= billing header substitution can permanently break cache for that conversation. Start a new session if you suspect this.

The core issue appears to be prompt cache invalidation from tool schema changes and billing header mutations — a compounding effect that gets worse in longer sessions.

Same issue. Max 20, v2.1.89, April 1. 100% in ~70 min after reset with light usage.

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

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

5 hours of Claude Code quota gone in 15 minutes. Amazing. Really worth the money. Refund me.

Experiencing the same issue. Max 5x plan, Opus 4.6 (1M context), macOS.

Timeline: Token consumption spiked starting March 31, coinciding with the 2.1.88 update. Previously the same workflow was fine.

Reproduction:

• Opened a fresh session, asked 2 simple questions about a ~940-line C# file → usage jumped to 33%
• Another fresh session today, 2 questions → 66%, then 72% after a third

Environment details:

• 4 plugins installed (compound-engineering, superpowers, frontend-design, swift-lsp) — but these were installed before the spike, so they're not the cause
• alwaysThinkingEnabled: true, effortLevel: high
• Long-running sessions (100-150+ turns over several days) were being resumed

Observations:

• The system prompt overhead from plugins/memory is ~35-40K tokens — significant but constant and was never a problem before
• The spike correlates exactly with the 2.1.87 → 2.1.88 update (March 31) and 2.1.89 (April 1)

Follow-up — precautions to reduce drain (April 2, 2026)

@keefar Your /claude-md-management:revise-claude-md eating 27% is consistent with what I'm seeing — skills/slash commands that rewrite files trigger large context rebuilds. Combined with broken cache, that's an expensive operation.

Here's what to avoid and what helps:

Avoid:

• --resume — replays full history as billable input (500K+ tokens on long sessions)
• /dream, /insights — background token consumption
• v2.1.89 — cache bug still present + terminal rendering regression
• Heavy slash commands that trigger file rewrites mid-session

Be careful with:

• Sub-agents (Haiku calls = 0% cache read, measured 317K/31 calls)
• Multiple terminals (each is independent, drains quota in parallel)

Helps:

• Fresh sessions + lean CLAUDE.md (don't resume)
• Local proxy for monitoring (ANTHROPIC_BASE_URL)
• Older fixed version (v2.1.81 + cache patch)

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

Update (April 2): v2.1.90 has significantly improved cache efficiency — benchmark shows 95-99% cache read in stable sessions (both npm and standalone installations).

If you're still affected:

1. Update: claude update (or npm install -g @anthropic-ai/claude-code)
2. Pin the version: add "DISABLE_AUTOUPDATER": "1" to ~/.claude/settings.json env section
3. Avoid --resume (still broken)

Note: server-side quota issues (org-level pool sharing, accounting mismatches) remain unresolved — the above fixes the client-side cache drain only.

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

Confirming this issue. Max plan subscriber here, running multiple Claude Code sessions on a Linux server for a food processing business.

After updating to v2.1.90 today, the token consumption is still disproportionately high. The same workflows that ran fine a few weeks ago now drain the session budget extremely fast.

The bigger problem: there is no way to measure or monitor token consumption per message. We're flying completely blind. The usage dashboard only shows a percentage bar with no breakdown of what consumed what. For a $100-200/month subscription, this level of opacity is unacceptable.

Additionally, as a European user (Germany), my entire working day (8 AM – 6 PM CET) falls within Anthropic's defined peak hours, which means the peak-hour throttling hits me during 100% of my productive time. There is no realistic way to "shift to off-peak hours" when you're running a business.

What we need:

• Per-message token consumption visibility
• Transparent accounting of what counts toward the session limit
• Fair treatment of European time zones in peak-hour policies

Environment:

• Plan: Claude Max
• Platform: Linux server
• Claude Code version: 2.1.90 (updated today)
• Model: Opus 4.6
• Multiple concurrent sessions

@RegioFrucht Thanks for confirming the issue persists on v2.1.90. At this point, evidence is accumulating that the cache fix alone doesn't resolve all cases. If your workflow involves sub-agent spawning or long sessions, you may be hitting the client-side rate limiter bug (#40584) or a server-side accounting change (#37394). Monitoring your cache read ratio via a logging proxy would help isolate which layer is still causing the drain.

Brief update (April 3): v2.1.91 is out and cache behavior is further improved — npm and standalone now perform identically (Sentinel gap closed). However, testing revealed two additional unfixed bugs: a 200K tool result budget cap that silently truncates older results, and a client-side false rate limiter generating <synthetic> errors without API calls (151 entries confirmed). If you are still seeing drain after updating, these are the likely causes. Details: claude-code-cache-analysis

think the real problem here isn’t tokens, but noise
claude ends up reading too much irrelevant output, so quality drops

filtering what actually matters works way better than just compressing

been trying this: https://github.com/fajarhide/omni

I'm wondering about the tool usage and excessive permissions request overhead and impact to token consumption as well, in that claude writes internal scripts, and then asks for permission over and over again in a way that doesn't allow me to grant "for anything like this". Claude generated the content, created the scripts for analysis, and then asks over and over in a full screen dump of code output for permission. This seems to be excessively wasteful. Even after working with it to open up /permissions this still prompts with full page dumps.

Example:

   Parse JSONL with correct message format

 Contains brace with quote character (expansion obfuscation)

 Do you want to proceed?
 ❯ 1. Yes
   2. No

When going back and analyzing the 10 hour working session the volume of activity seems bloated/skewed

Here's the full breakdown:                                                                                                                            
                                                                                                                                                      
  Session Statistics                                                                                                                                    
   
  Scale:                                                                                                                                                
  - 869 tool calls across main session + 25 subagents                                                                                                 
  **- 24.4M tokens processed (including 22.4M cache reads)**                                                                                                
  - 1.2M tokens of actual input/output generation       
  - 31 Confluence pages published                                                                                                                       
                                                                                                                                                        
  Tool call breakdown:                                                                                                                                  
                                                                                                                                                        
  ┌───────────────────────────────────────┬──────┬───────────┬───────┐                                                                                
  │               Category                │ Main │ Subagents │ Total │                                                                                  
  ├───────────────────────────────────────┼──────┼───────────┼───────┤                                                                                
  │ MCP Atlassian calls                   │ 6    │ 160       │ 166   │
  ├───────────────────────────────────────┼──────┼───────────┼───────┤
  │ Bash                                  │ 19   │ 241       │ 260   │                                                                                  
  ├───────────────────────────────────────┼──────┼───────────┼───────┤
  │ Read                                  │ 17   │ 154       │ 171   │                                                                                  
  ├───────────────────────────────────────┼──────┼───────────┼───────┤                                                                                  
  │ Edit/Write                            │ 14   │ 54        │ 68    │
  ├───────────────────────────────────────┼──────┼───────────┼───────┤                                                                                  
  │ Agent spawns                          │ 21   │ 30        │ 51    │                                                                                
  ├───────────────────────────────────────┼──────┼───────────┼───────┤                                                                                  
  │ Other (Grep, Glob, Tasks, ToolSearch) │ 28   │ 124       │ 152   │
  └───────────────────────────────────────┴──────┴───────────┴───────┘                                                                                  
                                                                                                                                                      
  Permission prompt analysis:                                                                                                                           
                                                                                                                                                      
  The log only recorded 1 explicit permission_request event (the permission-mode entry at session start). But the 191 calls that would have prompted    
  under default permissions tell the real story:
                                                                                                                                                        
  - 160 MCP calls in subagents - each one showing the full page body in the approval dialog                                                             
  - 19 Bash calls in main session
  - 6 Write calls + 6 MCP calls in main session                                                                                                         
  - 21 Agent spawns (which also prompt)                                                                                                                 
                                                                                                                                                        
  The MCP calls were the worst offenders - 112 getConfluencePage reads + 32 updateConfluencePage writes + 13 fetchAtlassian + 3 CQL searches. Each      
  updateConfluencePage call included the full transformed page body (10-20KB each) in the permission dialog. That's where the bulk of the pain was.

I have to say, the context-mode plugin is doing a great job reducing overhead (MCP) in context consumption for claude code... From a working session today (Opus 4.8) this is the stats reported on reduction of tokens passed... from the /ctx-stats plugin command (portion of the output). There was no /compact, a new shell was started continuing the work (using a durable-task-manager skill we implemented in our private plugin marketplace) that recovers context and continues work, the call to context-mode looks like an after compact recovery/read...

─── 1. Where you are now ───

This conversation started 3 Jun 2026 at 08:12 (America/Denver) in ~/synnepha/projects/synnepha-demo.
9 hr alive · still going.

Without context-mode 11.1 MB ████████████████████████████████ 2.9M tokens
With context-mode 432 KB █░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 110.6K tokens
96% kept out of context · your AI ran 26× longer before /compact fired