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

Environment

Plan: Max 20 ($200/month subscription)
Claude Code version: 2.1.89 (auto-updated today, April 1 2026)
Previous versions: 2.1.86 (Mar 28) → 2.1.87 (Mar 29) → 2.1.88 (Mar 31) → 2.1.89 (Apr 1)
Model: Claude Opus 4.6 (1M context)
OS: Ubuntu 24.04, Linux 6.14.0-1020-oem (HP ZBook Ultra G1a)
Node: v22.22.1
Settings: effortLevel: "high", 1 PostToolUse hook (ruff linter, lightweight)

Problem

Starting today (April 1, 2026), my 5-hour rate limit reaches 100% far too quickly. This happened twice in the same day.

This has never happened before. I have been a Max 20 subscriber for months and have never hit the limit this fast, even with identical (or heavier) usage patterns.

Timeline

Time	Event
~08:30 KST	Started working (remote session)
~11:30 KST	Noticed rate limit already at 100% — roughly 3 hours of normal usage
12:00 KST	Rate limit reset confirmed
12:00~ KST	Resumed normal work immediately after reset
~13:10 KST	100% usage again — exhausted in ~70 minutes of light conversational work

What I was doing

Normal conversational coding tasks (not bulk/batch)
Working from home directory with project CLAUDE.md (~17KB) + MEMORY.md (~14KB) auto-loaded
No unusual tool-heavy operations, no massive file reads
Same workflow I've used daily for months without issues

What changed

v2.1.89 auto-updated today (Apr 1, 10:15 KST) — but the morning session (pre-update) also had the same issue
v2.1.88 installed Mar 31 — issue may have started then
No changes to my settings, hooks, or project files before this started

Investigation done

Optimized CLAUDE.md + MEMORY.md from 30KB → 14KB (53% reduction) — did not resolve the issue
Confirmed no heavy background processes or concurrent Claude Code sessions
Checked GitHub issues — found related reports:
- [Bug] Excessive token consumption rate - usage depleting faster than expected #41249 (Mar 31): "Excessive token consumption" — 5-hour limit exhausted in <1 hour
- [BUG] Max 20x: Usage meter climbing abnormally fast since ~March 23 — 1-2% per simple message exchange #38357 (Mar 23~): "Max 20x usage climbing 5-10x faster"

Expected behavior

With Max 20 plan and normal conversational usage, the 5-hour rate limit should last at least 3-4 hours of active use, as it has for the past several months.

Actual behavior

Morning: 100% in ~3 hours
Afternoon (after reset): 100% in ~70 minutes with even lighter usage

Reproducible across two consecutive reset cycles on the same day.

Possible causes

Server-side change in how cached/thinking tokens are counted against rate limits
Prompt cache invalidation causing full re-processing of system prompts each turn
Rate limit calculation regression in v2.1.88 or v2.1.89
Model change (Opus 4.6) affecting internal token accounting

Request

I am paying $200/month for the Max 20 plan, and the service has become practically unusable — 70 minutes of light usage per 5-hour window is not acceptable for a premium subscription. This is severely impacting my daily workflow and productivity. I would appreciate a prompt investigation and resolution of this issue. Thank you.

Related issues

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 (Resume of long sessions loads disproportionate tokens from opaque thinking signatures #42260)
/dream, /insights — background API calls, silent token drain
v2.1.89 — cache bug still present + terminal content disappearing regression ([BUG] 2.1.89 - terminal content disappearing. #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:

Update to v2.1.90: claude update
Disable auto-update: add "DISABLE_AUTOUPDATER": "1" to ~/.claude/settings.json env
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:

Update to v2.1.90: claude update

Disable auto-update: add "DISABLE_AUTOUPDATER": "1" to ~/.claude/settings.json env

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

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!

@ArkNill

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 ). 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

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.
Caching works fine for the bulk of a session — 95-96% cache-read ratio across my 7-day window.
When caching breaks, it breaks mid-session — no client restart, no model swap, no context reset.
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.
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

@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?

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.

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 v2.1.128 caching regression in parallel-team workloads (10x token cost increase) #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.

Same problem – I’m using Claude Code v2.1.226
Last night I terminated a session at 95 per cent of the limit. I have a script that alerts me and automatically terminates sessions.
This morning, I restarted the session; the limit should have been reset to 0 per cent. The limit in Claude Code is at 147 per cent. I checked in the web interface, and the limit is set to 100 per cent.
Every five hours, the limit only decreases by 10 per cent.

Navigation Menu

Repository navigation

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