Opus 4.6 (Max $100) — Quota reaches 93% after minimal prompting in a single session

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/39938
2. https://github.com/anthropics/claude-code/issues/37436
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

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

Update (2026-03-31, off-peak hours)

Updated to v2.1.88 which fixed 'misleading rate limit message' and 'prompt cache misses in long sessions'. Issue persists.

Test conditions

• Time: 10:27 AM KST (Monday, off-peak)
• Version: v2.1.88
• Model: Opus 4.6 (1M context)
• Plan: Max $100
• Session context: ~400K tokens
• MCP channels disabled (tested with and without)

Results

• Session start + MCP load: 5% consumed
• Single text response (no tools): 4~5% per turn
• WebSearch (3 calls): 4%
• ~10 turns total → session limit hit

Key observations

1. Off-peak hours (KST morning) — Anthropic's peak-hour throttling should NOT apply
2. v2.1.88 prompt cache fix did NOT resolve the issue
3. Disabling MCP channels made no difference
4. This is NOT a display bug — actual session quota depletes rapidly
5. Weekly quota also draining abnormally fast

Community reports

This aligns with widespread complaints across Korean and global communities:

• 뉴스1: '돈냈는데 30분만 쓰라니'
• #38335 - Same issue since March 23
• #38239 - Extremely rapid token consumption

Anthropic's official response ('peak hour adjustment, 7% affected') does not explain off-peak overconsumption. Please investigate.

I agree; this is a widespread issue. On the official Claude page on X.com, the comments section is flooded with posts about this problem.

i've consumed 69% in 3x 5 hour sessions 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...

Found a contributing factor on my end that others should check: my ~/.claude/settings.json was bloated with redundant permission entries. This caused ~100k tokens of overhead on every single prompt just from the config being sent as context.

How to check: Open your settings.json and look at the permissions section. If you've been using Claude Code for a while, it accumulates allow/deny rules over time — many of which are duplicates or overly broad. Cleaning up the redundant entries significantly reduced my per-prompt token usage.

This isn't documented anywhere and likely affects anyone who's been hitting usage limits unexpectedly fast.

Same on Max 20 ($200/mo). v2.1.89, April 1: 100% in ~70 min after reset. Opus 4.6 quota consumption is broken across all Max tiers.

Full report: #41788
Related: #38335, #38239, #40895, #23706, #41663

<img width="889" height="601" alt="Image" src="https://github.com/user-attachments/assets/583d6f9d-9eee-4bf3-8da5-f20b405aa977" /> Even the Sonnet model has stopped working. Although it shows that there are still limits available. And there’s no one to turn to—the boilerplate responses in the chat aren’t helpful.

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

<img width="583" height="360" alt="Image" src="https://github.com/user-attachments/assets/2cea7f11-1d83-4a8b-8301-7f9456da7905" />

Done in ~3 days and i slowed down the last day and i was on .88. and .89...
Zero difference for me... Thats about HALF my usage this week...

This is max20... 200 usd per month... Unacceptable....

Everyone should cancel their sub, even if you intend to resume it in x weeks? Cancel it... If 10-100k of us do it? It will be statistically big enough to force their hand... Its the only way at this point...

Follow-up — precautions (April 2, 2026)

93% after minimal prompting = classic symptom of the cache prefix bug. Additional behaviors that make it worse:

Avoid: --resume (replays full history as billable input), /dream & /insights (background drain), v2.1.89
Careful with: sub-agents (Haiku = 0% cache read), multiple terminals
Use: v2.1.81 fixed + fresh sessions + proxy monitoring

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

Update (April 2): Much of the perceived Opus 4.6 consumption spike was likely compounded by the cache bug (Sentinel regression in standalone binary). v2.1.90 fixes this — benchmark shows 95-99% cache read in stable sessions, dramatically reducing effective token cost.

Update to v2.1.90 to isolate actual model cost from cache bug overhead: 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

93% quota after minimal prompting means the context payload is massive. Cozempic v1.6.11 auto-detects 1M context for Opus 4.6 and keeps sessions lean with 4-tier guard pruning. compact-summary-collapse alone saves 85-95% on compacted sessions.

pip install cozempic && cozempic init

<img width="604" height="273" alt="Image" src="https://github.com/user-attachments/assets/12e0abee-a9b1-477c-9c41-dbdeda32a65d" />
This is 1 hour on max20... not pro... not max5.... Max20... their highest tier...
Using up 79% of the 5x hour limit in 1 hour.... Make it make sense and how this is the new normal... :(
Even started using sonnet lol...

What an utter scam lmao.... So... The free credits you are given? The 200 usd "extra usage" they give you?
Turns out... they are only "extra" and "useable" long as you have an active subscription... If it runs out? You cant use the extra usage when "limits are hit".... Cant confirm as it was free but thats pretty wild if it works the same if you added cash manually....

In any case? Total scam company...cancelled and went to codex.

<img width="553" height="225" alt="Image" src="https://github.com/user-attachments/assets/b910e6b7-353d-4a01-8c62-f964c7450e56" />

So insane you cant use cash money credits without an active sub lol...

<img width="986" height="331" alt="Image" src="https://github.com/user-attachments/assets/3ae2c624-7d98-4c82-8d49-338d48bbc3fb" />

👍 #45333

I’ve been meaning to leave a comment here with my observations for a while.

1. I agree with the people above — it’s time to move away from these guys in favor of OpenAI Codex. It’s become practically impossible to work like this.

1. After the so-called cache fix was released, I decided to test it. I gave the agent a task of medium complexity, using Opus 4.6 with a Max x5 ($100) subscription — and within 15 minutes, all limits were completely drained.

What stood out immediately is that Opus 4.6 now seems to spawn a larger number of background AI agents. This ends up burning through your quota extremely fast. In my case, for a fairly average task, it launched 9 agents just for analysis — and each one consumed limits like crazy.

My workaround: strictly limit the number of background agents to 1.
The idea is simple — now that caching exists, a single agent can reuse that cache efficiently. It doesn’t need to generate as many new requests, since it pulls heavily from cached data.

But if you have 10–20 background agents, they all generate separate requests, which instantly eats through your limits.

It’s a shame to leave — my first impression was genuinely excellent. But something broke along the way, whether intentionally or not, I don’t know. Either way, it’s no longer workable — the quota is just too small.

Recommendations:

Limit background agents
Set a 200k token cap
Rely on cache compression
Use “compact” more often — it compresses data and keeps it in cache

I was forced to upgrade to max $200. Very unhappy as this appears to be punishment for max users that attempted to manage token use. I do not agree that this is purely from many background agents. My coding behavior has not changed in months.

I will be experimenting with Codex now as a alternative as Anthropic has broken my trust. I need tools that will be there when I need them. Anthropic has failed to manage their cash burn now that they just lost their biggest customer.

Just be honest instead of playing hide the token ball.

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.