[BUG] ClaudeMax - Session Throttling in Daily Limit

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/39880
2. https://github.com/anthropics/claude-code/issues/40532
3. https://github.com/anthropics/claude-code/issues/38350

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

Same here. I just asked one question in an active session on Claude Code a few minutes ago. Jump from 0% usage to 15% usage for the active session. It was NOT a coding task, just a question for something that was in the context. Something is off. I am on the MAX 100 Plan. Not running parallel agents.

Same here. I just asked one question in an active session on Claude Code a few minutes ago. Jump from 0% usage to 15% usage for the active session. It was NOT a coding task, just a question for something that was in the context. Something is off. I am on the MAX 100 Plan. Not running parallel agents.

And were not even in the peak hours..and its the weekend something is off.

I tried it with the newest version as well (2.1.87) and via "npx @anthropic-ai/claude-code", but no effect. Still the ~10% jumps for very basic tasks / questions.

Yeh, im hitting abnormal usage too...
Normally 1x 5 hour limit is 8% for my total week.. During promo it was 5-6%...
Today? Its 14 fking percent... Thats HALF my usage per week...
What the actual fk is going on here???????
Max20 here...

Confirming on MAX plan — exact same throttling behavior. Session limit hit at 17% elapsed, weekly at only 31%. The session counter is not tracking actual consumption.

Second issue on same plan: 10+ consecutive ENOTFOUND api.anthropic.com DNS errors, no self-recovery whatsoever.

Detailed report: #40745 Also confirmed across: #38350, #34413, #40532, #40445
Both bugs appeared around March 22. Anthropic needs to acknowledge, fix, and compensate MAX plan users for lost productivity.

I think for everyone's benefit, Anthropic should just say that the session is throttled so we don't waste tokens while this is being worked on, it's not happening for everyone but it seems there are subsets of users getting hit randomly.

Now im also getting this...
Ive always, for over a year worked in 10+ terminals without a single issue...
Its also not consistent, sometimes its on 7 terminals sometimes on 10... the only thing that is consistent is that it kills ALL MY terminals AND ALL my work.... blanket on every single client...
"API Error: Rate limit reached".... Cant even find info on it...

Related to this — I built two scripts to analyze token consumption from local Claude Code session logs (~/.claude/projects/**/*.jsonl):

• claude_token_dashboard.py — interactive HTML dashboard with daily stacked charts (input / cache_creation / cache_read / output), zoomable hourly timeline, cache hit ratio per day, anomaly detection (calls > mean + 3σ), and Claude Code version correlation
• analyze_tokens.py — CLI text report with the same breakdown

Running these showed some patterns consistent with what's described here: cache_read tokens dominate on heavy days, and certain sessions have anomalously large individual calls that inflate the apparent "consumption" significantly.

Repo: https://github.com/xaviguardia/claudedashboard

Might be useful for others trying to understand what's actually being counted toward limits.

Real usage data — possible token accounting anomaly between billing cycles

I've analyzed my actual consumption comparing the week of Mar 20 vs the week of Mar 27 using local logs (~/.claude/projects/**/*.jsonl).

Usage pattern: similar in both weeks — same types of projects, same agent stack, same predominant model (Opus 4.6).

What the Claude Max usage indicator shows:

• Week of Mar 20 → by Monday: ~60% consumed
• Week of Mar 27 → by Monday: 86% consumed

Same point in the cycle, same work pattern, +26% difference in the meter. That alone tells the story.

What the local logs show (effective tokens = input×1 + cache_write×1.25 + cache_read×0.1 + output×5):

• The current week is more intensive than the previous one, but not by a factor of ~1.4×
• One "heavy" Java project generated significant cache_creation (large fresh contexts) which could inflate the metric if accounted differently

Hypothesis — cache miss counting bug:
If cache_read_input_tokens are being counted server-side as fresh input_tokens (i.e. a cache hit on the client side is being billed as a cache miss), this would explain exactly the observed behavior:

• Client logs show: high cache_read → low cost (0.1×)
• Anthropic meter counts: same tokens as fresh input → full cost (1×)
• Net effect: same usage pattern, but the Max usage meter shows ~26% more at the same day of the cycle

The Java project would amplify this specifically because it creates large new contexts each session (high cache_creation) — if subsequent cache reads of that context are then mis-accounted, a jump from 60% → 86% at the same point in the billing cycle is mathematically consistent with a cache accounting bug.

I've published analysis scripts here: https://github.com/xaviguardia/claudedashboard — includes a weekly billing cycle burndown chart (claude_burndown.py) that allows visual week-over-week comparison.

Question: Is there any change in how tokens are accounted starting from a specific Claude Code version that could explain this jump?

i've consumed 69% of my weekly in 3x 5 hour sessions, its been 1.5 days since reset... at this rate? its all gone tomorrow with sunday to wait... At worst? normally get to wait 12-36 hours if its been an INSANE week lol.... what the fk?!?!
I think we should all cancel our subscriptions, even if you intend to keep using it? cancel and resub, send them a message measured in statistics and money for them... Im personally going over to codex...

I'm deeply exploring codex right now.

+1. Max 20, v2.1.89. April 1: 100% in ~70 min after reset. Light usage only. Anthropic support acknowledged Mar 31-Apr 1 incidents but no fix.

Full report: #41788
Related: #38335, #38239, #41055, #41663

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

April 3 update: v2.1.91 fixes the cache regression that caused the worst drain. If you are still hitting limits after updating, there are additional unfixed mechanisms: a 200K tool result budget cap, a client-side false rate limiter, and silent context stripping — all confirmed via proxy testing. Anthropic acknowledged peak-hour tightening on X (Lydia Hallie) but stated "none were over-charging you." Measured data and analysis: claude-code-cache-analysis

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.