Max 20 plan: rate limit 100% exhausted within ~70 minutes after reset (never happened before v2.1.89)

same issue :(

SAME ISSUE! We are paying customers guys, it's ridiculous, this is happening for days now! DO SOMETHING!

Have you tried downgrading to version 2.1.68? Although you lose some of the recent updates that seems to work for me. No more bleeding tokens.

I tried downgrading to version 2.1.88 and i think its solved

Thanks for the suggestions. I'll be trying a version downgrade after my next rate limit reset (5 PM KST today).

It's somewhat reassuring to hear that some people have seen improvement with older versions, but honestly it's still frustrating that the fundamental issue remains unresolved on Anthropic's end. We're paying $200/month and having to resort to community workarounds and version downgrades just to get basic usability back — that shouldn't be the answer for a premium subscription.

Looking forward to an official fix from Anthropic.

Thanks for the suggestions. I'll be trying a version downgrade after my next rate limit reset (5 PM KST today). It's somewhat reassuring to hear that some people have seen improvement with older versions, but honestly it's still frustrating that the fundamental issue remains unresolved on Anthropic's end. We're paying $200/month and having to resort to community workarounds and version downgrades just to get basic usability back — that shouldn't be the answer for a premium subscription. Looking forward to an official fix from Anthropic.

AGREE :)

There's this thread https://www.reddit.com/r/ClaudeAI/s/AY2GHQa5Z6
The guy basically reversed engineered the binary of Claude and found since when the bug was introduced, that's why that particular version. I feel your pain, it's not cool how Anthropic handles this.

Cross-reference: This is likely related to #41590 (new account immediately hits rate limit with zero usage).

I've also observed that accounts sharing the same billing method appear to have their usage quotas linked server-side. Accounts on the same payment method show identical session utilization percentages and reset times via the OAuth usage API (/api/oauth/usage), while accounts on separate billing have fully independent quotas. This could explain why some users see rate limits hit faster than expected — the quota pool is shared across all accounts under the same billing.

Filed a separate issue for the shared billing quota discovery: #41881

Update: Root Cause Identified + Measured Data

After setting up a monitoring proxy using the official ANTHROPIC_BASE_URL env var, I've identified two cache bugs as the root cause and measured the actual impact.

Two cache bugs (#40524, #34629) cause the cache read ratio to drop to near 0%, meaning every token on every turn is billed at full price — roughly 10-20x token inflation.

My measured data:

• Before workarounds (v2.1.89): Cache read ratio as low as 4.3% across 168 turns — poor sessions were the primary cause of rate limit exhaustion
• After workarounds: Cache read ratio stabilized at 89-99.5% per request, rate limit usage back to normal

I've published a full analysis with per-request measured data, safe workarounds (no binary modification), and community references:

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

@anthropics — These are measurable, reproducible client-side bugs with clear data. An official fix would be greatly appreciated.

Update — additional precautions from continued investigation (April 2, 2026)

Updating my own issue with the full precaution list I've been sharing across related threads. These are behaviors that accelerate drain on top of the cache bugs (Bug 1: #40524, Bug 2: #34629):

Avoid

• --resume — replays entire conversation as billable input, including opaque thinking signatures. Token bomb on long sessions (#42260)
• /dream, /insights — background API calls, silent token drain
• v2.1.89 — cache bug still present + terminal content disappearing regression (#42244)

Quantified risks

• Sub-agents (Haiku): 0% cache read, 317K tokens / 31 calls measured
• Multiple terminals: independent sessions, ~2x drain
• Slash commands rewriting files: 20-27% per invocation

Current status

• Client-side: cache patch on v2.1.81 works (89-99% read ratio)
• Server-side: drain still faster than 2-3 weeks ago even with perfect cache. Likely a limit recalculation.
• Anthropic response: zero across all rate-limit issues (2 months+)

Shared precautions across 20+ active issues today.
Analysis repo: https://github.com/ArkNill/claude-code-cache-analysis

Update (April 2): Resolved on my end after benchmarking.

v2.1.90 has largely fixed the cache regression that caused my original 70-minute drain. Controlled test results:

| Version | Cache Read (stable) | Sub-agent cold start | Usage for full test |
|---------|--------------------|--------------------|-------------------|
| v2.1.89 standalone | 90-99% main, 4-17% sub-agents | Never recovers | 100% in ~70 min |
| v2.1.90 standalone | 95-99.7% | 47-67% → recovers to 94-99% | 5% for 4 heavy scenarios |
| v2.1.90 npm | 95-99.8% | 79-87% | 7% for 7 scenarios |

Action items if you're still affected:

1. Update to v2.1.90: claude update
2. Disable auto-update: add "DISABLE_AUTOUPDATER": "1" to ~/.claude/settings.json env
3. If on standalone binary, consider npm install -g @anthropic-ai/claude-code for marginally better sub-agent performance

Full benchmark data: BENCHMARK.md

Server-side quota issues remain unresolved — but the client-side cache bug is now manageable.

Update (April 2): Resolved on my end after benchmarking. v2.1.90 has largely fixed the cache regression that caused my original 70-minute drain. Controlled test results: Version Cache Read (stable) Sub-agent cold start Usage for full test v2.1.89 standalone 90-99% main, 4-17% sub-agents Never recovers 100% in ~70 min v2.1.90 standalone 95-99.7% 47-67% → recovers to 94-99% 5% for 4 heavy scenarios v2.1.90 npm 95-99.8% 79-87% 7% for 7 scenarios Action items if you're still affected: 1. Update to v2.1.90: claude update 2. Disable auto-update: add "DISABLE_AUTOUPDATER": "1" to ~/.claude/settings.json env 3. If on standalone binary, consider npm install -g @anthropic-ai/claude-code for marginally better sub-agent performance Full benchmark data: BENCHMARK.md Server-side quota issues remain unresolved — but the client-side cache bug is now manageable.

Really appreciate the work. Thank you very much.

Thanks for getting to the bottom of this.

May AGI Bless you

I’m experiencing the exact same issue on the Max plan. My weekly usage is being exhausted in just 2–3 days, which is a massive departure from previous performance. It feels like there is a lack of transparency regarding how these limits are being calculated or if there's a bug in how prompt caching is being applied. We need more honesty and clarity on what has changed

Same issue on v2.1.90 (it became worse) with Max x20 subscription - all the limits are gone within 45-90 minutes of moderate usage, given I use Sonnet for all light and medium tasks. Haven't had these problems with similar workflows 2-3 months ago. Claude Code became unusable

@halimabdi I use rtk for token savings and it seems to help, at least to me.
These are the savings that I have so far across all sessions:

RTK Stats Summary: >- 1,608 commands processed globally - 7.5M tokens saved out >of 8.7M input (86.1% reduction)

> - Top savers: Playwright tests (99%+), curl responses (98-99%), Vitest (98%)
> - Total exec time: ~320 minutes across all commands

You should try it if you think it could be usefull.

@nikitakreskinsemrushcom Sorry to hear v2.1.90 made things worse for you. A few things that might help narrow down the issue:

1. Sonnet cache behavior may differ — my benchmarks were on Opus. If you're primarily using Sonnet for light/medium tasks, the cache dynamics (breakpoint placement, TTL) could behave differently. Worth checking if the drain correlates with specific model switches.

1. Measure your actual cache ratio — set ANTHROPIC_BASE_URL to a logging proxy (e.g., mitmproxy or a simple Express/FastAPI passthrough) and check the cache_read_input_tokens vs input_tokens in API responses. If cache reads are near 0%, that confirms Bug 1 (#40524) or Bug 2 (#34629) is still active on your setup.

1. Known accelerators to avoid (from my investigation):

• --resume replays entire conversation as billable input (#42260)
• Frequent sub-agent spawning — each cold start has 0% cache until it warms up
• /dream, /insights — silent background API calls

If you can share your cache ratio numbers, it would help confirm whether it's the same root cause or something else entirely.

@karytabilu Thanks for sharing rtk — the token savings numbers look impressive.

One distinction worth noting for others reading this thread: rtk reduces input token count by trimming tool outputs (test results, CLI responses, etc.), which is valuable on its own. But the core issue in this thread is cache miss, not token volume. When Anthropic's prompt caching works correctly, 90-99% of input tokens are billed at 1/10th price — so the effective cost is already heavily reduced.

The bug (#40524, #34629) causes cache reads to drop to near 0%, meaning every token is billed at full price. rtk would reduce the base of that full-price billing, which helps as a mitigation, but doesn't fix the underlying cache regression.

TL;DR: rtk = good for reducing absolute token count. Cache fix (v2.1.90) = good for reducing per-token cost. Best results come from both working together.

I have not used a single time today, still showing 3% used.
I subscribed to claude code pro plan 2 days back and i really have very bad experience with it, as just for 10 files of code review took 20% of usage.

<img width="1512" height="982" alt="Image" src="https://github.com/user-attachments/assets/d1f8593b-d116-4e99-a79b-1dbc386ac825" />

It's not limited to Claude Code, it happens also on Claude.ai:

Pro Subscription:

• 1st prompt in Claude.ai Opus 4.6 Extended 31%
• 2nd prompt in Claude.ai Opus 4.6 Extended 60%
• 3rd prompt in Claude.ai Opus 4.6 Extended 100%

<img width="937" height="133" alt="Image" src="https://github.com/user-attachments/assets/12cb080f-04ad-4c98-b506-c61db5370498" />

I hit 87% in an hour outside of peak hours, and 100% shortly after. As a test, I'm using Opus 4.6 1M context with max effort, and I'm testing differences in usage from the peak hours and now. This morning I hit 100% in 30 minutes. I can say with certainty that my session limits are hiting much quicker in the past few days than they did previously, even outside of the marketed "2x usage". I'm not doing anything differently in my workflows compared to the past month and I'm on a 20x plan.

This is also after implementing changes in my env variables to try to limit usage, using brand new sessions without resuming, using v2.1.90, and using the npm version mentioned above. Didn't seem to help.

<img width="842" height="112" alt="Image" src="https://github.com/user-attachments/assets/283ebdda-7534-4368-a7c5-d9e863f9e5bd" />

I'm at 10% 5h usage after 1 plan prompt, on 100$ max plan. This is far from normal. 69907 tokens used = 10% of 5h limit? This is off the peak ours as well. Just a few days ago it would be maybe 1-2% used.

Yeah, this is usually where it gets confusing because reducing file size doesn’t always fix the actual cost driver.

Even if CLAUDE.md is smaller, the per-session cache can still get invalidated depending on how the context is being constructed each turn. Things like tool schema changes, nested context injection, or how attachments are positioned can cause the prefix to shift, which means it stops reusing previous tokens and effectively reprocesses more than expected.

So it ends up feeling like you’ve optimized everything locally, but the underlying request pattern is still breaking cache reuse.

Have you checked whether the cache_read vs cache_write behavior is changing mid-session?

I just switched from Cursor and within an hour my limit was reached. I started regretting why did I buy claude code if the limits are too small. I didn't even use Opus, I was sparing using Sonnet and mostly Haiku, I was so confused how did this happen. Then I found this bug here 😑.

Status update — April 3 (v2.1.91 tested)

Since my original report and subsequent analysis, I've completed systematic proxy-based testing across v2.1.89 through v2.1.91. Summary of where things stand:

What's fixed

• Cache regression (Bug 1 + Bug 2): v2.1.90-91 restored cache efficiency. My original 70-minute drain was primarily caused by the Sentinel cache corruption (standalone binary) and resume cache breakage. Both are now addressed — measured 95-99% cache read in stable sessions on v2.1.91.
• v2.1.91 npm vs standalone gap closed: On v2.1.90, standalone cold start was 47-67% vs npm's 79-87%. On v2.1.91, both hit 84.7% on first real request — the Sentinel issue is effectively neutralized.

What's NOT fixed (measured on v2.1.91)

• Bug 3 — False rate limiter: 151 <synthetic> entries found across 65 sessions on my setup. Client blocks API calls without server involvement (#40584)
• Bug 4 — Silent microcompact: 158+ tool result clearing events detected via proxy. Doesn't affect main session cache (99%+), but degrades context quality — model can't reference earlier tool results (#42542)
• Bug 5 — Tool result budget enforcement: 200K aggregate cap on tool results. After ~15-20 file reads, older results truncated to 1-41 chars. The maxResultSizeChars override in v2.1.91 is MCP-only — built-in tools unaffected
• Bug 8 — JSONL log duplication: Extended thinking generates 2-3x PRELIM entries per API call. Unknown if server counts these against rate limits (#41346)

Practical advice (updated)

1. Update to v2.1.91 — either npm or standalone is fine now
2. Start fresh sessions rather than resuming
3. Be aware of the ~200K tool result cap — for long code review sessions, start a new session periodically
4. DISABLE_AUTOUPDATER=1 until Bugs 3-5 are addressed

Full data, per-request benchmarks, and test methodology: claude-code-cache-analysis

Multi-Account Rotation — a practical workaround for rate limit exhaustion

Instead of fixing the cache bug itself, we built a system that assumes exhaustion will happen and rotates across multiple MAX accounts seamlessly.

How It Works

Isolate each account via CLAUDE_CONFIG_DIR into separate config directories:

~/.claude-claude1/    # Account 1
~/.claude-claude2/    # Account 2
~/.claude-claude3/    # Account 3
...

When one account's tokens are exhausted → copy session files to the next account → resume with --resume. Project memory is shared via per-project symlinks so context survives account switches.

Contamination Scenarios & Mitigations

The hardest part of multi-account operation isn't switching — it's preventing cross-account contamination. Here's every scenario we encountered and how we handled it:

| # | Scenario | Risk | Mitigation |
|---|----------|------|------------|
| 1 | Same project, different account (token exhaustion) | ✅ Safe | Same user, same project = continuity. Symlinked via sync-memory |
| 2 | Cross-project memory bleed (A ↔ B) | ✅ Impossible | Separate paths per project, symlinks are project-scoped |
| 3 | Account change via /login | ✅ Safe | CLAUDE_CONFIG_DIR unchanged → same memory path |
| 4 | Two tabs writing same project memory simultaneously | ⚠️ Very rare | Memory is per-file. Concurrent writes = last-write-wins |
| 5 | Env file sharing contaminates other tabs | 🔧 Fixed | ~/.claude-env-{PID} for per-session isolation |
| 6 | Symlinking entire ~/.claude/projects | ❌ Dangerous | Shares settings too, not just memory. Replaced with per-project memory-only symlinks |
| 7 | oauthAccount contamination (wrong token leaks into config) | 🔧 Separate fix | Auto-scan/fix at launcher startup |
| 8 | New account added without running sync-memory | ⚠️ Isolated | Starts with empty memory. Needs sync |
| 9 | Sourcing last-env in .zshrc | ❌ Dangerous | Every new shell inherits last account. Cross-tab contamination. Removed |

Components

• Account isolation: Separate config dirs via CLAUDE_CONFIG_DIR
• Session continuity: switch-account.sh — copies session files + subagent dirs to new account, resumes with --resume
• Shared memory: sync-memory.py — per project, picks the account with the most memory files as canonical, symlinks the rest
• Env contamination prevention: PID-scoped env files (~/.claude-env-{PID}) for tab isolation
• Usage monitoring: Real-time per-account usage dashboard via keychain token extraction

This approach is complementary to @ArkNill's cache analysis — fixing cache helps each account last longer, and rotation handles the remaining exhaustion gracefully. Still useful even after v2.1.90.

If you want the scripts, let me know.

<img width="954" height="465" alt="Image" src="https://github.com/user-attachments/assets/6f7026c8-a794-45ed-b20c-b47fc18ce61e" />

Post-v2.1.91 status — what's fixed, what's not

Based on @ArkNill's systematic proxy testing and our own multi-account monitoring:

✅ Fixed in v2.1.91

• Cache regression — 95-99% cache read restored. The 70-minute drain on v2.1.89 was caused by Sentinel cache corruption + resume cache breakage. Both addressed.
• npm vs standalone gap — both hit 84.7% on first real request now. Standalone cold start penalty eliminated.

❌ Still open (measured on v2.1.91)

| Bug | Issue | Impact on rate limits |
|-----|-------|---------------------|
| False rate limiter | #40584 | Client blocks API calls without server involvement — 151 <synthetic> entries across 65 sessions |
| Silent microcompact | #42542 | Tool results cleared silently — degrades context quality, forces re-reads that consume tokens |
| Tool result 200K cap | Built-in tools unaffected by maxResultSizeChars fix | After ~15-20 file reads, older results truncated to 1-41 chars — triggers re-reads |
| JSONL log duplication | #41346 | Extended thinking generates 2-3x PRELIM entries per API call — unknown if server counts these |

Practical impact

The cache fix significantly reduced drain speed — our multi-account rotation now lasts much longer per account. But Bugs 3 (false limiter) and 8 (log duplication) still cause unexpected quota consumption. For heavy users:

• Update to v2.1.91 (npm or standalone both fine now)
• Start fresh sessions rather than resuming — avoids cache chain breaks
• New session every ~15-20 file reads — works around the 200K tool result cap
• DISABLE_AUTOUPDATER=1 until remaining bugs are addressed

Full per-request benchmarks: claude-code-cache-analysis

Post-v2.1.91 status — remaining bugs affecting rate limits

@dliedke @hackyon-anthropic Cache regression is fixed in v2.1.91 (95-99% cache read restored) — great work. However, @ArkNill's proxy testing identified 4 remaining bugs that still cause unexpected quota consumption:

| Bug | Issue | Impact |
|-----|-------|--------|
| False rate limiter | #40584 | Client blocks API calls without server involvement — 151 <synthetic> entries found across 65 sessions |
| Silent microcompact | #42542 | Tool results cleared silently, forces re-reads that consume extra tokens |
| Tool result 200K cap | (no dedicated issue) | After ~15-20 file reads, older results truncated to 1-41 chars. maxResultSizeChars fix in v2.1.91 is MCP-only — built-in tools unaffected |
| JSONL log duplication | #41346 | Extended thinking generates 2-3x PRELIM entries per API call — unknown if server counts these against rate limits |

Bugs 1 (false limiter) and 4 (log duplication) are the most likely to cause rate limit exhaustion even with good cache behavior.

Full per-request benchmarks & methodology: claude-code-cache-analysis

I'm on the 20x plan using the latest version and it's been three hours. My session reset at 7:00 and around 10:00 I ran out of my session limits. I'm just doing code reviews, man; I'm not even doing crazy stuff and I'm already at the end of my session. I have to wait. Plus this happened earlier today and all of it happened outside of the peak hours. The supposed peak hours, I can't even imagine how fast it would have drained if I was in the peak hours. Also this was the first day of my week and I already hit 30% of my usage for the whole week and because the rate limits I only got six hours worth of work done. I had to take a two hour break this afternoon.

Come on Anthropic, what are you guys doing, man? Look I mean everybody likes your stuff and I feel like now you guys are feeling yourselves and now you are charging the crap out of everybody. This is unacceptable. You are just gonna make everybody jump ship and use something else.

Credit usage is insane. At a coworking space, while doing my usual tasks, my session limit has expired 3 hours early.

Just open Claude Code session without doing anything (idle) will consume weekly limit. Anyone experience this?

100% exhausted in 70 minutes points to context inflation — each turn re-sends your entire session, and bloat compounds. A session at 45MB sends that payload on every API call.

Cozempic v1.4.1 keeps sessions lean with a guard daemon that fires pruning strategies at configurable thresholds. 17 strategies across gentle/standard/aggressive tiers. Measured 92% reduction on real sessions.

pip install cozempic && cozempic init

Would be interested to hear if this extends your session duration on Max 20 plans.

i am not using claude code right now - they drain the usage and it feels kinda ripoff ... frustrating its the same on MAX5 not only dedicated to MAX20

Not only were tokens being consumed far too quickly, but the releases this week also seem to have made Claude Code noticeably less reliable. It started making arbitrary decisions, proposing a series of incorrect solutions, and ultimately wasting even more tokens.

We also observed that Claude Code no longer proactively loads skills from the internal marketplace. Instead, it scans the ~/.claude/ directory to find the skill. In many cases, it fails to follow instructions altogether, skipping >50% of the defined steps. This behavior did not occur previously.

It also noticeably stops short in digging deep into traces on issues,
instead, it just starts guessing now to conserve tokens.

Regards,
Junaid Ali Qureshi

On Sat, 4 Apr 2026 at 10:48 AM khacminh @.***> wrote:

khacminh left a comment (anthropics/claude-code#41788) <https://github.com/anthropics/claude-code/issues/41788#issuecomment-4186605124> Not only were tokens being consumed far too quickly, but the releases this week also seem to have made Claude Code noticeably less reliable. It started making arbitrary decisions, proposing a series of incorrect solutions, and ultimately wasting even more tokens. We also observed that Claude Code no longer proactively loads skills from the internal marketplace. Instead, it scans the ~/.claude/ directory to find the skill. In many cases, it fails to follow instructions altogether, skipping >50% of the defined steps. This behavior did not occur previously. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/41788#issuecomment-4186605124>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFVALNJOP2SZ733ZWNFPS5L4UCV2FAVCNFSM6AAAAACXIT525SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOBWGYYDKMJSGQ> . You are receiving this because you commented.Message ID: @.***>

Same issue here. Didn't changed my workflow or anything but I'm reaching 50% after ~2 days

Same here x20 plan usage is gone after 1h with jsut one session i can cry!!!

Wrote something to help me retain my context across session /clears and /compacts (and work between cowork and code CLI while at that).

https://github.com/NominexHQ/pmm-plugin/

It kept my context relatively small, was almost never affected by limit overruns on max 20 plan. Until recently....

Same issue (MAX 20), my weekly reach 100% (Never before), so i bought extra usage to finish my deadline project (is not happy to me)

Environment

• Plan: Max 20 ($200/month)
• Claude Code: v2.1.92 (VSCodium Extension, NOT CLI)
• Model: Opus 4.6 (1M context)
• OS: Fedora 43, Linux 6.19.10-200.fc43.x86_64

Problem

Same issue here. Session limit at 57% after moderate usage, weekly limit already at 45% — and it's Monday (resets Friday). At this rate I'll hit 100% weekly by Wednesday.

My workflow hasn't changed: conversational coding, file reads, occasional subagent spawns. No bulk operations, no abuse. This is a $200/month plan that's becoming unusable for normal professional work.

What makes my case notable: VSCodium Extension

Most reports here are from CLI users. I'm running Claude Code as a VSCodium extension — same problem. This rules out CLI-specific overhead like terminal rendering or shell integration as the cause. The issue is server-side token accounting, not client behavior.

The transparency problem

/cost in the extension shows only "You are currently using your subscription to power your Claude Code usage" — no token counts, no breakdown, no per-turn consumption. We're paying $200/month with zero visibility into what's actually consuming our quota. This makes it impossible to optimize usage or even verify whether the consumption is legitimate.

Anthropic: if you're going to charge premium prices, provide premium transparency. Show us input/output/thinking token counts per turn, cache hit rates, and how peak-hour multipliers affect our limits.

Status update — April 6

A lot has happened since my April 3 update. Responding to recent comments first, then sharing what's come out of continued proxy monitoring and community analysis.

---

Responses

@NexusOne23 — Your VSCodium extension report matters. Every other report in this thread (mine included) has been CLI-based, so confirming the same drain on an IDE extension effectively rules out CLI-specific overhead — terminal rendering, shell integration, standalone binary quirks. The problem sits at the API or billing layer. Good to have this documented.

@xullul — Idle session consuming weekly quota is something I haven't seen in my proxy logs. What version are you running, and do you have hooks or MCP servers configured? Those can trigger background API calls. If it's genuinely idle with no activity, that's a separate bug worth filing.

@khacminh — The quality regression (skipping instructions, arbitrary decisions) is a different axis, but it compounds the rate limit problem — wrong answers mean wasted turns, which means more tokens burned for the same result. I've been seeing similar patterns.

---

v2.1.92

Haven't done a controlled proxy test yet. The changelog doesn't reference direct cache or billing fixes, so I'm going to set up a clean benchmarking environment for it rather than burn production quota on an unverified build. Will report back with real numbers.

---

April 6 analysis update — the data so far

I've been running a transparent monitoring proxy (cc-relay, using the official ANTHROPIC_BASE_URL env var) since April 1. As of today, that's 8,794 total proxy requests, 3,702 with rate limit headers, plus 110 main sessions + 279 subagent sessions worth of JSONL logs analyzed. The full analysis is published and kept updated at claude-code-hidden-problem-analysis.

Here's what the data shows:

Dual sliding window quota system (02_RATELIMIT-HEADERS.md)

The API returns anthropic-ratelimit-unified-* headers on every response. Claude Code only reads representative-claim for the usage bar and throws away the rest. From 3,702 captured responses:

• Two independent counters: 5-hour window and 7-day window
• representative-claim = five_hour in 100% of requests — the 5h window is always the bottleneck, regardless of time of day
• 7d accumulates proportionally to 5h usage (ratio ~0.12–0.17)

Per-1% utilization cost (measured across 5 active windows, Max 20x):

| Metric | Range |
|--------|-------|
| Output per 1% | 9K–16K visible tokens |
| Cache Read per 1% | 1.5M–2.1M tokens |
| Total Visible per 1% | 1.6M–2.1M tokens |

Cache read is 96–99% of what makes up each percentage point. A full 5h window (100%) corresponds to only ~0.9M–1.6M visible output tokens — suspiciously low for several hours of Opus work.

Thinking token blind spot

Extended thinking tokens are not included in the output_tokens field from the API. They're invisible to clients — you can't see them in JSONL logs, you can't see them in proxy captures. But the gap between visible output and observed utilization cost is consistent with thinking tokens being counted against the quota at a significant weight. I'm planning a thinking-disabled isolation test this week to try to quantify this.

This isn't just my hypothesis. Two independent community analyses reached the same conclusion through different methods:

• @fgrosswig (#38335 comment): dual-machine JSONL forensics over 18 days. March 26 consumed 3.2 billion tokens (combined, both machines) with no limit hit. April 5 consumed 88 million and hit 90%. After normalizing for per-machine splits and utilization, fgrosswig estimates a ~64x effective budget reduction — see their full breakdown for methodology.
• @Commandershadow9 (#41506 comment): confirmed cache fix working, but measured a 34–143x capacity reduction independent of the cache bug. Same thinking token hypothesis.

JSONL cross-validation: 1.93x client-side inflation (03_JSONL-ANALYSIS.md)

By comparing hourly totals from JSONL session logs vs proxy-captured HTTP responses (33 overlapping hours, April 4–6):

| Source | Cache Read Total | Ratio |
|--------|-----------------|-------|
| JSONL (client-side) | 663M tokens | 1.93x |
| Proxy (server response) | 344M tokens | 1.0x (baseline) |

JSONL records nearly 2x the cache_read that was actually returned by the server — because extended thinking generates 2–5 PRELIM entries per API call, each carrying 0.56–0.97x the cache_read of the FINAL entry. If the server-side rate limiter uses the same accounting, users could be charged double for cache_read. We can't confirm this from the client side, but the 1.93x ratio is consistent with the hypothesis.

Session lifecycle: long sessions drain disproportionately faster

From the longest session analyzed (990 turns, 336M visible tokens):

| Turn | Cache Read per turn | Cost per turn relative to Turn 1 |
|------|--------------------|---------------------------------|
| 1 | 25K | 1x |
| 100 | 145K | 5.8x |
| 500 | 347K | 14x |
| 990 | 595K | 24x |

Growth is linear at ~+575 cache_read tokens per turn. Combined with the per-1% cost data: a 100-turn stretch in the late half of a long session costs roughly 17–40% of your entire 5h window in cache_read alone. This is why people feel like the drain accelerates — it does, mathematically, even if your work pace stays constant.

Current bug status (7 confirmed, 5 still unfixed)

Full technical details: 01_BUGS.md

| Bug | What | Status (v2.1.91) |
|-----|------|-------------------|
| B1 Sentinel cache corruption | Standalone binary breaks cache prefix | Fixed |
| B2 Resume cache breakage | --resume replays full context uncached | Fixed |
| B3 False rate limiter | Client blocks API calls with fake "Rate limit reached" — 24 synthetic events in 6 days | Unfixed |
| B4 Silent microcompact | Tool results cleared mid-session without notification | Unfixed |
| B5 200K tool result budget | Older results truncated to 1–41 chars after ~15–20 file reads | Unfixed |
| B8 JSONL log inflation | Extended thinking duplicates entries — 2.87x local token inflation | Unfixed |
| Server quota change | 34–143x capacity reduction independent of cache bugs | By design |

The full 14-month timeline (Feb 2025 – Apr 2026) across 91+ related issues is at 07_TIMELINE.md.

---

Being honest about where things stand

It's been almost a week. 40+ people in this thread, $100–$200/month each, detailed proxy data, version-controlled benchmarks, community-built diagnostic tools — and zero official acknowledgment from Anthropic on GitHub. Not a single response across 91+ rate-limit issues spanning 2+ months. The only communication has been personal X posts and changelog entries.

Anthropic's Lydia Hallie said on X: "Peak-hour limits are tighter and 1M-context sessions got bigger, that's most of what you're feeling. We fixed a few bugs along the way, but none were over-charging you."

Our data says otherwise. Bug 5 silently truncates tool results to 1–41 characters. Bug 3 generates fake rate limit errors without making an API call. The 34–143x capacity reduction exists independently of the cache bugs that were fixed. These aren't feelings — they're measurements from 8,794 proxy requests and 1,735 JSONL files.

We're paying customers filing detailed technical reports, and the response is silence. That's not a partnership — it's a one-way street.

---

What I'm doing about it

Data collection: I'm continuing to collect proxy and JSONL data through April 10 (when my first full 7-day cycle completes). The goal is a comprehensive, reproducible dataset that can't be dismissed as anecdotal — something solid enough to publish on HN and dev.to so this gets the visibility it deserves.

Building alternatives: For context, I've been developing a local-first autonomous agent framework for air-gapped environments well before this rate limit situation started. This experience has made it clear that depending on a single vendor's CLI is a risk in itself — so I'm now also working on an open-source LLM proxy and orchestration layer designed for the open internet, with multi-provider support, session diagnostics, and recovery built in. Alongside that, I've set up OpenAI Codex CLI and Gemini CLI and have been evaluating which tool genuinely performs best for which type of task. I'd like to get these alternatives into your hands as soon as possible — nobody should have to put their work on hold because one product silently changed the rules.

If you have proxy logs, JSONL data, or usage API snapshots showing the weekly drain — especially from plans other than Max 20 — share them here or in the analysis repo. More data points, more plan tiers, stronger case.

I can confirm the issue. I'm using the $200 plan, but for the last two weeks, my allowance has been depleted significantly faster than before. The 5-hour window is used up in 90 minutes. This is clearly an error on Anthropic's part, and I'm expecting a fix as soon as possible.

Having the same experience. Something changed about 18 hours ago that feels like a real inflection point and the system is no longer usable. I'm on the 20x sub and my 5h quota reset recently, after a few short conversations it is now at 40% 16 minutes later. Never seen anything even close to this before with Claude Code. Something seems very broken. Have almost never hit a 5h limit before even with extensive usage, this is a massive change. Also seeing a lot of 429 rate limit errors even at off peak times.

I've been experiencing this for the last two weeks as a Claude Max ($200/month) subscriber. At 12% session (5h) and 34% weekly (7d) usage I get constant "API Error: Rate limit reached" on every request, even a simple single prompt. This has never happened before. I could easily work across 5 sessions at once, while now it struggles with even one.

Everyone here all up with problems. Anyone has contacts in anthropic to discuss about this? or are we going to just accept it?
where 100$ plans acting like 20$ plan.

Issue came back just today. Burning through tokens like last week!... Again just 1/5 of what I normally can do with the same amount of tokens (no change in my working model whatsoever). Version v2.1.92. Additionally Claudes quality decreased dramatically, almost feels like Claude has just a fraction of its reasoning power... this is serious! A lot of people, including me are relying on this paid service for our business!

Reproducible local instrumentation (JSONL + optional ANTHROPIC_BASE_URL proxy)

This issue’s pattern — Max 20, normal conversational work, yet 100 % in ~70 minutes after a fresh 5 h reset — matches what we only see clearly when client logs and API-side signals are looked at together. The opener’s suspicion list (cache / thinking / accounting around 2.1.88–2.1.89) is exactly where per-request data helps.

To give everyone a shared, local way to measure (not just gut feel or the status bar), we maintain Claude Usage Dashboard:

~/.claude/projects/**/*.jsonl — what Claude Code actually wrote to disk (forensics / session totals).
Optional transparent proxy via official ANTHROPIC_BASE_URL — NDJSON per request, latency/cache hints, and the anthropic-ratelimit-unified-* headers that @ArkNill’s update shows are returned by the API but mostly discarded by the client UI. That lines up with @ArkNill’s Apr 6 write-up here: dual 5 h / 7 d windows, per‑1 % cost ranges, and the thinking / JSONL inflation angles that don’t show up in one source alone.
We aggregate only claude-* models (no <synthetic>). You can run node server.js / node start.js both or Docker; CI is in docker.yml on the repo. Idea is: same stack for CLI and IDE workflows — @NexusOne23’s extension report in this thread matters because it pushes the same quota question off “CLI quirks” and toward API/billing transparency; the dashboard is meant to be a portable complement to @ArkNill’s claude-code-hidden-problem-analysis (deep methodology + primary datasets stay there).

This is deliberately more than “JSONL forensics only”: it wires JSONL + proxy + UI so people hitting the 70 minute / post‑reset wall can compare numbers across machines and versions (e.g. your 2.1.86 → 2.1.89 timeline) without a one-off script each time.

Related community thread with similar triangulation: #41506; earlier forensics context: #38335.

I am maybe thinking to get the claude versions bumped into but was not on my priority for now to craft this dashboard. I hope this helps some to get visuals instead feel frozen by drained working hours in minutes.

This happend to me also and i have no idea how I zipped though 87% of my weekly in 2 hours and didnt accomplish anything TBH, Agents were all created by Claude.

Data point: cache behavior breaks in-session, then 429 hits immediately

Hitting this on Max 20x ($200/mo). I was running 6 concurrent Claude Code sessions (which is why I upgraded from Max 5x → Max 20x in the first place — that's what the plan was sized for and it worked fine for months). I've since cut back to 2 concurrent sessions specifically because of this bug — one for general PAI / infrastructure work, one for a separate product dev project — and I'm still tripping rate limits.

I dug into my local JSONL session files (~/.claude/projects/**/*.jsonl) to see what the client was actually being charged for, and found a clear failure mode: prompt caching works normally for most of a session, then abruptly stops — and the 429 hits within minutes of that happening.

Session 8b5f4a21 leading up to today's 429 (2026-04-10 11:12:29 UTC)

Hourly breakdown, same session, same model, same conversation context:

| Hour (UTC) | Turns | Total tokens | Cache-write | Cache-read | write:read ratio |
| ---------- | ----: | ------------: | ------------: | ---------: | :------------------- |
| 08:00 | 109 | 94,186,615 | 1,724,575 | 92,432,099 | 1 : 54 (healthy) |
| 09:00 | 77 | 71,174,663 | 1,877,321 | 69,271,166 | 1 : 37 (healthy) |
| 10:00 | 130 | 25,261,377 | 842,825 | 24,357,252 | 1 : 29 (healthy) |
| 11:00 | 6 | 1,221,551 | 1,201,161 | 18,670 | 66 : 1 (broken) |

At 11:00 UTC, cache behavior inverted. 6 turns generated 1.2M cache-writes but only 18K cache-reads — normally those same 6 turns should have produced ~30M cache-reads against the session's existing ~13M cached state. Every message was being rebuilt from scratch as if there were no prior cache. 429 hit 12 minutes later.

This is the same session, same assistant, same claude-opus-4-6 model. Nothing in the client-side context changed between 10:59 and 11:00 that should have invalidated the cache.

Cumulative context when the 429 hit

Session 8b5f4a21 (single session, ~4 days old at time of hit):

• Turns: 3,261
• Raw input tokens: 96,036
• Output tokens: 684,993
• Cache-write tokens: 52,421,031
• Cache-read tokens: 1,477,859,218
• Total: 1,531,061,278
• Cache-read ratio: 96%

96% cache-read is exactly what you'd expect from a healthy long-running session on Opus 4.6 — the cache mechanism was applying correctly throughout. The problem is the cache stops applying sometime in the final hour, and the effective cost per turn jumps by ~50x.

7-day aggregate across all my Claude Code sessions

Aggregated from ~20,000 JSONL session files under ~/.claude/projects/:

| Day | Turns | Sessions | Input | Output | Cache-write | Cache-read | Total |
| -------------------- | ----: | -------: | ------: | ------: | ----------: | ----------------: | ------------: |
| 2026-04-10 (partial) | 1,304 | 158 | 181,589 | 447,141 | 39,051,809 | 560,546,890 | 600,227,429 |
| 2026-04-09 | 998 | 193 | 243,179 | 203,055 | 19,482,708 | 328,103,274 | 348,032,216 |
| 2026-04-08 | 1,214 | 202 | 400,319 | 269,630 | 20,371,313 | 232,366,019 | 253,407,281 |
| 2026-04-07 | 482 | 139 | 152,436 | 82,299 | 14,573,361 | 122,022,440 | 136,830,536 |
| 2026-04-06 | 1,672 | 446 | 419,017 | 292,154 | 10,875,932 | 648,540,577 | 660,127,680 |
| 2026-04-05 | 722 | 158 | 142,558 | 137,540 | 6,078,688 | 175,299,964 | 181,658,750 |
| 2026-04-04 | 2,799 | 545 | 638,311 | 559,647 | 45,902,917 | 1,259,302,194 | 1,306,403,069 |

7-day total: 3.55 billion tokens, 95% cache-read.

On April 4 (my heaviest day in the window) the cache-read ratio was 96%. If caching were broken at the underlying Anthropic infrastructure level, these ratios would be much lower. Caching IS applying server-side — but something is invalidating it under certain conditions, at which point per-turn cost explodes and a 429 follows quickly.

Observations

1. This is not a volume problem. I'm currently running 2 concurrent sessions — down from 6 — and still hitting limits on Max 20x ($200) faster than I ever did on Max 5x ($100) at full 6-session load. 33% of my normal workload is now tripping rate limits on a plan that's 4x the capacity of the one that handled my full workload.
2. Caching works fine for the bulk of a session — 95-96% cache-read ratio across my 7-day window.
3. When caching breaks, it breaks mid-session — no client restart, no model swap, no context reset.
4. The switch to "no cache applied" mode correlates strongly with the 429. In session 8b5f4a21 the cache broke at 11:00 and the 429 hit at 11:12.
5. The client's local JSONL accounting is consistent — 3,261 turns with 96% cache-read shows the cache was being honored by the server on every turn up to the break point.

Repro hypothesis

Whatever invalidates the cache mid-session is the root cause. From the 11:00 vs 10:00 hour comparison in session 8b5f4a21, possible triggers include:

• Cache TTL expiring mid-turn and not being renewed
• Some server-side tool result exceeding a threshold that evicts the cache
• A race between cache-write and cache-read on consecutive rapid turns
• A silent downgrade to non-cached mode on the server when a specific upstream error happens

Happy to share more raw data if it helps narrow this down. The JSONL files are the exact source of truth the client writes during normal operation — no extra instrumentation needed on my end.

@Mutdogus Hey! Man this is crazy information but whatever you provide, claude will never acknowliedge this. So yeah we are efed.....

I am managing the Claude AI for our team and we are on the Team Plan. After reaching our weekly usage limit I added extra usage cost.

However, despite adding the extra usage, I am still unable to use the additional resources after our limit was hit.
Could you please guide me on how I can use this extra usage after the limit has been reached?

<img width="343" height="113" alt="Image" src="https://github.com/user-attachments/assets/3e46d47c-6b64-452d-8439-c262942a3f3b" />

Additionally, I would appreciate it if you could explain how the extra usage limit works for each user on the plan and how we can manage this effectively.

<img width="446" height="198" alt="Image" src="https://github.com/user-attachments/assets/3c6c0f89-c85d-4500-a716-1ba073248e25" />

<img width="831" height="352" alt="Image" src="https://github.com/user-attachments/assets/10efa0d6-818d-477f-b6b4-f72b92c7d68f" />

Same thing is happening to me. I keep hitting my session limits despite not much changing in my workflow. I typically have 2-3 active claude conversations going now I'm hitting my limits in only 2 hours.

I have the same issue on a pro subscription - 5 hour allotted depletes fast!

https://www.anthropic.com/engineering/april-23-postmortem

Adding quantified data from a parallel sub-agent orchestration workload on Windows (v2.1.124, pinned — tested 2.1.126 and 2.1.128, both worse).

Analyzed 30 days of local JSONL session data using a simple Python script that reads ~/.claude/projects/**/*.jsonl and aggregates message.usage across all turns:

Summary across all sessions:

• 318,866 total turns
• 29,097 flush events (turns where cache hit rate < 50%)
• 9.1% of all turns are full cache misses
• 95.2% aggregate hit rate (cache works when stable)
• 32 sessions with 50+ flush events each

Workload pattern: heavy parallel sub-agent orchestration — one orchestrator coordinating multiple concurrent worker agents per task. Each flush in this pattern is disproportionately expensive because the orchestrator's full accumulated context reloads from scratch.

Platform specifics:

• Windows 11, native Claude Code (not WSL)
• v2.1.124 pinned — v2.1.126 worsened the flush rate, v2.1.128 is worse still per #56293
• The flush events cluster in specific sessions rather than distributing uniformly, suggesting the trigger may be tied to context handoff boundaries or spawn events rather than raw context size

The script used to generate this is a pure Python port of cc-cache-monitor (which pointed me to this thread). Happy to share if useful.

Same issue here, still happening on v2.1.161.

• Plan: Pro ($20/mo)

• Version: anthropic.claude-code-2.1.161-linux-arm64

• Platform: Raspberry Pi 5 (Debian aarch64), VS Code extension

• Symptom: 5-hour session quota depleted in ~20 minutes with normal editing work. Currently showing 95% used with a 4-hour reset timer after a single short coding session.

• Usage pattern: VS Code extension only, no CLI, no heavy tool use — just regular file editing and conversation.

• Started: approximately 2 weeks ago. No changes were made to my CLAUDE.md or configuration between when it worked normally and when it broke.

This confirms the issue is not related to CLAUDE.md size or memory files — I verified that my config hasn't changed, and the problem appeared suddenly mid-usage. Seems like a server-side token accounting regression that's still present months after the initial reports. Affecting Pro plan users too, not just Max.