[BUG] Claude Code Usage for Max Plan hitting limits extremely fast

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/34410
2. https://github.com/anthropics/claude-code/issues/28537
3. https://github.com/anthropics/claude-code/issues/33752

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

It is no longer possible to complete meaningful work with Claude Code. Please fix this. @claude

So far it seems better, but only after I started a new Claude Code chat session. My new session is using the same model (Opus 4.6) and same reasoning effort (high) as my previous session that was hitting hourly limits way too quickly.

It does feel like maybe the bug for the usage skyrocketing is more related to continuing a Claude Code session after updating Claude Code.

Before I started this new session, I prompted the old session to create a primer prompt with all the context the new session needed. It read 3 markdown files (totaling about 1,500 lines) and then output a 50 line prompt. And that cost me 55% of my hourly usage on my Max Plan. Insane.

At this point I've hit >50% weekly limit because of this bug.

But so far so good with the new chat session, the usage is going up at reasonable rate and I'm actually able to complete my tasks.

I hope this information helps.

similar issue. woke up this morning, had a terminal loaded already with a bit of context, did like 2 prompts and BOOM 100% and the reset just happened less than 45 mins ago there is no way i used it all!!
seems to be more related to the APP claude Code rather than the terminal (just started using app yesterday and this happened this morning)

UPDATE VERY UPSETTING: MY All models is ALREADY AT 16% used!!!!!! from this same issue i haven't even been able to use it this morning and i'm at 16% all usage!!!?!?!?!?!? its crazy how frustrating this is...

I very much hope they refund this or fix it. i had a lot of tasks this morning to achieve that are now disrupted. appreciate you guys keep up the good work.

Same here, I'm subscribed to 20x but today it burned the 5 hour limit in exact 85 minutes, my work load was exact the same as any other day.

Same here, I'm subscribed to 20x but today it burned the 5 hour limit in exact 85 minutes, my work load was exact the same as any other day.

also on Max. i didn't do anything different either... this is definitely on them. i just keep refreshing the usage page praying its just a bug... what to do with 5 hours of no Claude.... HELP!

Having this issue too! my limit reset and within 2 minutes it maxed out on pro plan! not even a big request - something is definitely wrong here...

URGENT! DO NOT MAKE CLAUDE DO ANY WORK! WILL TAKE MOST IF NOT ALL USAGE IN ONE GO FOR THE 5HR WINDOW AND UP TO 20% IN WEEKLY! THIS IS A LOSS OF $20's payment IN A SINGLE PROMPT!

Haiving the same issue, I have encountered the blockage twice in a row toady in 5 + 5 hours window on $100 Max plan. This never happened before, please fix....

Confirming on v2.1.81, Max plan, Windows CLI, single conversation.

Woke up this morning, started one conversation, typed for ~20 minutes, hit the 5-hour rate limit. This has never happened before — I routinely run multi-hour sessions with heavy sub-agent usage and don't come close to the 5-hour limit.

This was ONE conversation. Not multiple windows, not parallel agents. Normal usage pattern that has worked fine for months.

Something changed server-side. This isn't a client version issue.

Same issue, i'm using MAX significant reach limit x5 times - feel like when use Pro with the same task.

Same issue

same issue

Same again today!! used for 5-10minutes and maxed out... this is ridiculous.

same issue here! just few prompts in max x20, and hitted limit

same issue. it's hitting too fast!

Same here, max x10 and I hit 31% of the limit in 10 minutes

Same issue here, this is a major blocker and is making me reconsider sticking with claude

<img width="627" height="115" alt="Image" src="https://github.com/user-attachments/assets/0250457e-fc81-4ec3-829d-eed43eeb6af6" /> this makes it even more of a joke...

Same problem as well, after a few turns on the 20x plan, doing something that normally takes little usage.

Had to buy api credits because of something time critical that was tied to claude code.

So I guess lesson is not to trust anthropic or switch platforms? Downtime/issues is one thing, but the lack of support and not commenting when this happens makes it almost unusable as a professional product.

I made a little monitor widget on my streamdeck cc-streamdeck-monitor. Helps to see your usage numbers live so you don't have to call /usage.

Couple of things I've been using to at least see what's happening:

1. Someone in https://github.com/anthropics/claude-code/issues/38350#issuecomment-4118235427 wrote a script that audits your local session logs by token type (cache creation, output, etc). Worth running to see where the drain is actually coming from.

1. I built a statusline that shows whether you're burning faster than the clock is ticking. Caught a few turns eating 10%+ in one shot that I would've completely missed otherwise. https://github.com/Astro-Han/claude-lens

Neither is a fix. But flying blind while this is happening isn't great either.

Confirming this. Max x20 subscriber since ~August 2025, Debian Linux, Opus 4.6 high. 5-hour window exhausted in <60 min since ~March 22. Never happened before in 8 months of daily use with unchanged workflow.

Note: issue #36423 reproduces on both v2.1.79 and v2.1.80, ruling out the client-side max_tokens 64k change as the sole cause. Anthropic's own API docs also state that max_tokens does not factor into rate limit calculations. This points to a server-side metering change.

Filed a support ticket referencing this issue.

Same here - on PRO-Plan (Opus Planing / Sonnet as working model) it took about about 8 Minutes to reach the session limit. That token calculation is a showstopper for Claude Code usage.

Main issue was one turn: 2.8M (7.6K in / 2.6M cached / 12K out + 53 tool uses) - that took about 85% (estimated) of session limit.

I believe the March 2026 off-peak 2x promotion is replacing the Max plan multiplier instead of stacking on top of it. The official docs say caps are "replaced by a 2x multiplier" during off-peak — if this also replaces the x20, Max users get x1 during peak hours and x2 off-peak, which matches exactly what we're experiencing (feels identical to the $20 Pro plan). The regression started around March 13 when the promotion went live, pointing to a server-side metering bug.

I'm seeing the same pattern on Max plan. What I noticed is that cache_creation tokens seem to drain the budget disproportionately — even simple file reads create expensive context windows.

My workaround: I set up a multi-model routing layer that sends non-critical tasks (file reads, test runs, simple edits) through GPT-4o or Gemini instead of burning Opus quota on everything. Dropped my Anthropic usage by ~60% and the limits stopped being an issue.

The key insight is that maybe 40% of Claude Code operations actually need frontier-model reasoning. The rest is mechanical.

If anyone wants to try this approach, I wrote up the setup: https://dev.to/sophiaashi/claude-code-rate-limit-on-max-plan-the-workaround-developers-are-actually-using-in-2026-16g2

Also have a small Discord where we're comparing multi-model setups: https://discord.gg/tvAtTj2zHv

Have anyone tried oauth2 with opencode to see if that is a possible workaround? As soon as my counter reset for the second time this unproductive day I will try it.

Yesterday, I used up 84% of my weekly budget (Max x20) on roughly 10 messages in Openclaw, so I stopped and tried again today.
Today, another ~10 messages on the same topic only used 1%.

So it looks like something may have changed or improved?

This is the first time I’ve run into this, but the communication around it has been quite unclear from a user perspective.
Right now it’s hard to tell whether this was a known incident, a silent fix, or just inconsistent accounting. I can’t find any official acknowledgement, and there’s nothing about it on the status page unless I missed it. At the moment, it feels a bit like Schrödinger’s Support: maybe this is known or fixed, maybe it isn’t.

Today it seems to be fixed for me too, but are we getting an early weekly limit reset for this?
At the end of the day, this error consumed our weekly usage. Our tokens were charged extra if you will

Not using Max, using the regular plan. I hit the current session limit in just one prompt with careful context management. Been having this issue intermittently for the past week or so. This is despite working within the temporary 2x usage window.

Just a few weeks ago, I could work for hours with no issues. Now, I can barely work for 10 minutes.

Yep, just got this issue.

3 prompts in and my 5 hour limit is at 100% - didn't do any significant work.

I usually do 5x the same level of work before hitting the limit...

Same issue here, I really can't do any work like this, it is pointless. If this is not fixed, I'm cancelling. At $100 per month for higher tier plan I might as well buy a dedicated AI station and try one of the local models.

After deleting the ~/.claude folder I have not seen this problem anymore.

After deleting Claude Code I have not seen this problem anymore.

Today I also thought about switching to CODEX because the limits are not enough even for primitive prompts.

Within 5 mins got the usage limit hit to 100%. only two prompts. I am on Max plan.

I have do only /compact. This is 20percent of hourlimit and 2Percent Weekly Limit. I cant do work with it,

It happened again. In the morning I worked on three projects for 3 hours, and I hit the limit, now it was reset and I could work.. for just one hour, and I hit the limit again.
Yesterday it was working fine.
Could it be related to peak hours?

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

I've temporarily switched the model to use opus 4.6 (without 1M) context to see if that fixes part of the problem, still testing but it seems more stable than 1M one

seems to be fixed right now, definelity a bug introduced in claude code!

seems to be fixed right now, definelity a bug introduced in claude code!

Why do you think this?

> seems to be fixed right now, definelity a bug introduced in claude code! Why do you think this?

I’m on the Max plan ($200/mo), which is supposed to have 20x higher limits. However, last Monday, Tuesday, and Wednesday, I was hitting the usage limit after just a few prompts during specific hours. The behavior felt exactly like the standard $20 Pro plan limits rather than the Max tier I’m paying for. Since the issue disappeared and I'm back to normal limits now, it strongly suggests it was a temporary bug in how limits were being applied in Claude Code.

Yeah, I'm in Max 100$, and the limits are ridiculous. The other day, a prompt got me 20%, and my 5-hour session was more of a 6-hour session, who knows how. I can easily reach the limit below 10 opus 4.6 max effort prompts. Claude is no longer reliable. I'm going to switch. This is very iffy...

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

Same issue here. One prompt about parsing ods files (included response below) cause the usage (Max5) to jump from 88% -> 100% in 5 seconds.

`
● SheetJS (require('xlsx')) supports .ods natively — xlsx.read() auto-detects the format. So the "Parse All Sheets" Code node in WF-03b would work without changes.

The question is the upstream nodes. Let me check what would need to change:

● Bash(node -e "
const wf = JSON.parse(require('fs').readFileSync('workflows/medika-preorders/test/01b_process_email.json', 'utf8'));…)
⎿  L4: let xlsxCount = 0;
L5: const xlsxFiles = [];
L20: if (fileName.endsWith('.xlsx') || fileName.endsWith('.xls') ||
… +14 lines (ctrl+o to expand)
⎿  You've hit your limit · resets 4pm (Europe/Zagreb) `

This issue seems to appear on session resume. Any question after a session resume will cause a massive usage spike - probably depending on the length of the session.

For those who haven't seen it, anthropic announced lower usage limits during 'peak' hours (5am-11amPT).

To manage growing demand for Claude, we're adjusting our 5 hour session limits for free/pro/max subscriptions during on-peak hours. Your weekly limits remain unchanged. During peak hours (weekdays, 5am–11am PT / 1pm–7pm GMT), you'll move through your 5-hour session limits faster than before. Overall weekly limits stay the same, just how they're distributed across the week is changing. We've landed a lot of efficiency wins to offset this, but ~7% of users will hit session limits they wouldn't have before, particularly in pro tiers. If you run token-intensive background jobs, shifting them to off-peak hours will stretch your session limits further. We know this was frustrating, and are continuing to invest in scaling efficiently. We’ll keep you posted on progress.

source: u/ClaudeOfficial

If you're having usage problems, they will probably be magnified during those times.

I can't find an announcement anywhere else, seems insane if the only announcement of something so impactful to the majority of users is a single reddit post. Last ~week when these issues started, was probably them messing with rates to see what works.

If the API rates reflect actual delivery cost, then the token subsidy on the $200 max might be around 15x, and for every $200 I give them, they're losing a couple thousand. So at some point that has to end, and is probably going to trend that way across all the big providers.

For those who haven't seen it, anthropic announced lower usage limits during 'peak' hours (5am-11amPT). > To manage growing demand for Claude, we're adjusting our 5 hour session limits for free/pro/max subscriptions during on-peak hours. > Your weekly limits remain unchanged. During peak hours (weekdays, 5am–11am PT / 1pm–7pm GMT), you'll move through your 5-hour session limits faster than before. Overall weekly limits stay the same, just how they're distributed across the week is changing. > We've landed a lot of efficiency wins to offset this, but ~7% of users will hit session limits they wouldn't have before, particularly in pro tiers. If you run token-intensive background jobs, shifting them to off-peak hours will stretch your session limits further. > We know this was frustrating, and are continuing to invest in scaling efficiently. We’ll keep you posted on progress. source: u/ClaudeOfficial If you're having usage problems, they will probably be magnified during those times. I can't find an announcement anywhere else, seems insane if the only announcement of something so impactful to the majority of users is a single reddit post. Last ~week when these issues started, was probably them messing with rates to see what works. If the API rates reflect actual delivery cost, then the token subsidy on the $200 max might be around 15x, and for every $200 I give them, they're losing a couple thousand. So at some point that has to end, and is probably going to trend that way across all the big providers.

It's not the issue here, however it looks like bad timing that was announced around the time this bug started appearing.

The bug eats up usage when resuming a large session, and it eats up tokens (I'm guessing) proportional to that session. That is why a single question like "How are you doing?" after a session resume will cause the usage to go from 1% to 15% in a matter of seconds.

Why would there be this new thing where resuming a conversation eats up your usage if Claude is still just as dumb? This should be an option somewhere.

It's not the issue here, however it looks like bad timing that was announced around the time this bug started appearing. The bug eats up usage when resuming a large session, and it eats up tokens (I'm guessing) proportional to that session. That is why a single question like "How are you doing?" after a session resume will cause the usage to go from 1% to 15% in a matter of seconds.

Agreed, but I have noticed a difference in how bad the issue is at 9am vs 3pm, and the usage change is something people probably aren't aware of. The bugs seemed to start in the run-up to this announcement

I just had a $7 session use 20% in 20mins, and tested resuming an old session that did $4 at 3%. One session was ~4x more 'expensive' in limit usage per equivalent api dollar cost.

Usage % vs actual token cost is inconsistent

Session A (c5ca9f17) — ~20% usage reported

• 131 API calls (22 Opus top-level + 109 Sonnet subagent)
• Ran for 20mins
• Estimated API cost: $6.97

Session B (1cebec31) — ~3% usage reported

• 4 API calls (all Opus, no subagents)
• Resumed old session with 350k context, sent trivial messages to test caching
• Estimated API cost: $3.93

Token breakdown

| | Session A (20% usage) | Session B (3% usage) |
|---|---:|---:|
| Model(s) | Opus + Sonnet | Opus only |
| Calls | 131 (22 + 109 subagent) | 4 |
| Input | 26,874 | 12 |
| Output | 103,208 | 21 |
| Cache write | 405,368 | 339,474 |
| Cache read | 6,218,885 | 1,063,840 |
| Est. API cost | $6.97 | $3.93 |
| Reported usage | ~20% | ~3% |

Per-call detail — Session B (the 3% one)

Caching seemed to work properly here, was not working consistently for me last week

| # | Time (UTC) | Input | Output | CacheCreate | CacheRead | CacheHit% |
|---|---|---:|---:|---:|---:|---:|
| 1 | 17:37:42 | 3 | 6 | 339,434 | 11,374 | 3.2% |
| 2 | 17:38:52 | 3 | 5 | 14 | 350,808 | 100.0% |
| 3 | 17:40:16 | 3 | 5 | 14 | 350,822 | 100.0% |
| 4 | 18:05:24 | 3 | 5 | 12 | 350,836 | 100.0% |

Whatever formula is behind the usage % meter, it doesn't seem to correlate with actual token spend. Or, the throttling is pretty sporadic and high.

Refunded Claude Max after 11 days of use. Yummy. Back to ChatGPT.
You can do it on the desktop app on the Get Help.

<img width="59" height="98" alt="Image" src="https://github.com/user-attachments/assets/8882c3d0-26e1-4c04-a85b-2e17db72b65b" />

Still ongoing as of April 1 2026. Max 20, v2.1.89 — 100% in ~70 min after reset. Getting worse, not better.

Full report: #41788
Related: #38335, #38239, #40790, #6457, #40895, #41055, #41663

Same here. Max 20x plan, hit 100% after ~2 hours of normal work today (April 1st). 5 commits, no agents, no excessive sessions. This started around March 23 and hasn't improved. Paying $200/mo for a fraction of the advertised capacity.

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

Same issue: I tripped into extra usage within a short time today and had to turn it off, or I'll burn through it in minutes ($100 overage buffer on top of the Max x20 plan). And now we wait. The accidental source release yesterday was probably a symptom of them working overtime on trying to fix this.

v2.1.89 Update — Fix Not Confirmed

Upgraded to v2.1.89 today (Windows, Max plan, Opus 4.6). The changelog states:

Fixed nested CLAUDE.md files being re-injected dozens of times in long sessions that read many files

The issue persists. Two observations on v2.1.89 within the first hour of use:

1. Agent tasked with updating a single planning doc (~200 lines) ran for 10 minutes 41 seconds before completing. Simple doc write should take seconds.

1. Agent tasked with reading a single planning doc read the same file 9+ times over 15 minutes 5 seconds, consuming 16k tokens (↓), then had to be manually killed. Token counter froze — agent was spinning, not making progress.

Both operations involve a project with 3 nested CLAUDE.md files (global, user, project). The re-injection pattern appears unchanged — every file read triggers CLAUDE.md re-injection, inflating context and burning tokens on what should be trivial operations.

Impact: This is a production trading system with overnight pipeline agents. A 10-15 minute overhead on every file read makes multi-agent orchestration unusable. We burned through a 5-hour Max quota in 20 minutes last week (original report). v2.1.89 has not changed that trajectory.

Environment:

• v2.1.89, confirmed via claude --version
• Windows, PowerShell / Windows Terminal
• 3 nested CLAUDE.md files (global + user + project)
• Max plan, Opus 4.6 with high effort

Would appreciate clarity on whether the fix targets a specific subset of re-injection scenarios, or if this is a partial fix that doesn't cover the full problem.

Respectfully Pushing Back on the invalid Label

This issue should not be closed as invalid. Here's why:

The v2.1.89 changelog itself acknowledges this is a Claude Code bug:

Fixed nested CLAUDE.md files being re-injected dozens of times in long sessions that read many files

That changelog entry is a direct acknowledgment that Claude Code had a bug causing excessive token consumption through CLAUDE.md re-injection. The fix was shipped in v2.1.89. But the fix doesn't work (see my comment above -- 15-minute file reads, 9+ repeated reads of the same file, verified on v2.1.89).

This is not a billing issue. This is not a capacity issue. This is a Claude Code client-side bug where:

1. Nested CLAUDE.md files are re-injected into context on every file read operation
2. This inflates token consumption by 5-10x over what the operation should cost
3. A simple file read that should consume ~2k tokens consumes 16k+
4. This burns through quota at 5-10x the expected rate

There are 40+ users in this thread confirming abnormal token consumption. Anthropic's own v2.1.89 changelog confirms the root cause was a Claude Code bug. The fix was attempted but is incomplete.

Closing this as invalid while the bug remains unfixed -- and while the changelog proves Anthropic identified and attempted to fix the exact issue -- would be dismissing a real, impactful bug that affects paying Max plan customers.

Please remove the invalid label and re-triage.

@claude I second the call for the "invalid" label to be removed.
Max plan could not finish a planning document before hitting the limit. That is ridiculous.
I'm using version 2.1.86 btw

Follow-up — precautions update (April 2, 2026)

Since my earlier root cause analysis, I've identified additional behaviors that dramatically speed up quota drain. Sharing for anyone still affected:

Avoid:

• --resume — replays entire conversation as billable input (token bomb on long sessions)
• /dream, /insights — hidden background token consumption
• v2.1.89 — cache bug unresolved + terminal rendering regression

Watch out for:

• Sub-agents: Haiku calls = 0% cache read (317K tokens / 31 calls)
• Multiple terminals = multiple independent sessions draining in parallel
• Large context files resent every turn

Recommended: v2.1.81 (fixed) + fresh sessions + local proxy monitoring. Details: 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

I just need to mention.
I haven updated my claude-code in all this time.
I have it installed in a docker container in two computers.
versions are (2.1.74, 2.1.86).
yesterday I was using v2.1.74 when I hit the limit in one hour, that same version had no problems before this all started

@pablofuenzalidadf This is a significant data point. If v2.1.74 and v2.1.86 in Docker containers (never updated) started exhibiting the same drain recently, that strongly suggests a server-side change in how usage is accounted or billed — independent of any client-side cache bug.

My v2.1.90 benchmarks confirmed the client-side cache regression is fixed (cache read ratio back to 95-99%+), but if old versions that never had the cache bug are now draining fast too, the root cause is upstream.

Could you share:

1. Approximate date when the old versions started showing this behavior?
2. Whether you can capture the actual API response headers (specifically x-ratelimit-* fields) to see if the server is reporting higher consumption per request?

This would help isolate whether it's a billing/accounting change vs. a rate limit calculation change on Anthropic's backend.

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

Session context bloat is a major factor here — every API call re-sends the accumulated conversation, and sessions silently grow with progress ticks, file-history snapshots, stale tool results, and base64 images.

Cozempic v1.4.1 prunes this automatically. 17 strategies across 3 tiers strip different bloat types. The guard daemon auto-starts on every session and keeps context lean before each API call.

Quick start: pip install cozempic && cozempic init

Run cozempic diagnose on a current session to see your bloat breakdown — it shows token count, cache hit rate, and savings estimates per prescription tier.

Session context bloat is a major factor here — every API call re-sends the accumulated conversation, and sessions silently grow with progress ticks, file-history snapshots, stale tool results, and base64 images. Cozempic v1.4.1 prunes this automatically. 17 strategies across 3 tiers strip different bloat types. The guard daemon auto-starts on every session and keeps context lean before each API call. Quick start: pip install cozempic && cozempic init Run cozempic diagnose on a current session to see your bloat breakdown — it shows token count, cache hit rate, and savings estimates per prescription tier.

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

In general? I would warn ANYONE from running any of the "optimization/whatever" things...
This is prime time to get exploited by being desperate... keep that in mind.

Arkhill is also an anthropic bot.

Same issue here, during the last 2/3 days. I hit the limits in 30 min, not even using Opus that much. I use Opus to plan and then Sonnet to execute.

It is unusable as it is. @claude

So what is the current take? Downgrade to .68 or below or latest version? Which one sucks less?

I've downgraded to 2.1.68. It seems to work better (no unexpected spikes), but still there seems to be a mismatch in the usage - even in off-hours it sometimes drains faster than before. So seems this is partly a server-side issue as well.

Status After Five Releases — Still Broken, Still Marked Invalid

v2.1.89 → v2.1.90 → v2.1.91 → v2.1.92. Four releases in four days. Token burn still happening.

This issue is marked invalid. I'd like to understand that decision, because:

1. Anthropic's own v2.1.89 changelog stated: 'Fixed nested CLAUDE.md files being re-injected dozens of times in long sessions that read many files' — this is a direct admission that Claude Code had a client-side bug causing excessive token consumption
2. v2.1.90 fixed a prompt cache miss regression that had been broken since v2.1.69 — 20 releases of degraded cache performance
3. After both fixes, token burn is STILL happening at abnormal rates

If the root cause was purely server-side capacity, Anthropic wouldn't be shipping client-side fixes for re-injection and cache misses. The evidence points to a compound problem with client-side contributions.

Marking this invalid while actively shipping fixes for client-side token inflation is contradictory. Max plan users are paying USD 200/month and watching their quotas drain in 20 minutes. That deserves more than an invalid label and auto-close.

## Status After Five Releases — Still Broken, Still Marked Invalid v2.1.89 → v2.1.90 → v2.1.91 → v2.1.92. Four releases in four days. Token burn still happening. This issue is marked invalid. I'd like to understand that decision, because: 1. Anthropic's own v2.1.89 changelog stated: 'Fixed nested CLAUDE.md files being re-injected dozens of times in long sessions that read many files' — this is a direct admission that Claude Code had a client-side bug causing excessive token consumption 2. v2.1.90 fixed a prompt cache miss regression that had been broken since v2.1.69 — 20 releases of degraded cache performance 3. After both fixes, token burn is STILL happening at abnormal rates If the root cause was purely server-side capacity, Anthropic wouldn't be shipping client-side fixes for re-injection and cache misses. The evidence points to a compound problem with client-side contributions. Marking this invalid while actively shipping fixes for client-side token inflation is contradictory. Max plan users are paying USD 200/month and watching their quotas drain in 20 minutes. That deserves more than an invalid label and auto-close.

I second this... Im at 29% first day of use.. Used little over 2x capped 5 hour limits...
Its gone from 8-8.5% per 5x hour limit, which meant you got about 12.5x per week for your total weekly limit before 23rd march...
Now its closer to 14-16% and its also NOT consistent on 2 capped 5 hour sessions (i had 2 capped in a row today, heavy work) which means the calculation of tokens is inconsistent and seemingly random....
This looks more and more like the community found random cache bugs but the true cause? They switched the tiers... Max20 is now Max5, Max5 is now Pro... and god knows what pro is... Thats how the usage feels and runs out....

-55% of the weekly limit for a 2-hour session with Opus (max 200). This is incredible. They also disabled OpenClaw. In short, Anthropic decided to lose their customers

The hourly usage seems a bit better than when I originally posted this, I'm actually able to complete work now. I think part of the problem was using a 1m Opus session get to 60% usage of its context window, from what I understand now with those large context windows it can eat up usage faster. So I'm going back to starting new sessions more often

But my weekly usage is hitting limits much faster. This weekend I ran Claude for about 7 hours total (never letting it get to over 250k tokens in a single session) and I am already at 60% weekly usage used. That is supposed to be off-peak hours....

This is insane, about a month ago I would almost never hit weekly limits with the same types of tasks.

I built an open-source tool to help with this: context-os

It's a local-first context optimizer that hooks into Claude Code via PreToolUse to automatically compress tool output (test logs, build output, lint results, stack traces) before Claude sees them. Reduces token consumption by 27-42% on those outputs with zero manual work.

How it works:

cargo install --path apps/cli
cd your-project
context-os init    # installs 4 hooks, generates CLAUDE.md
context-os doctor  # verify setup

After init, it's fully automatic:

• PreToolUse hook wraps cargo test, npm build, cargo clippy, pytest, etc. — pipes output through typed reducers. Exit codes preserved.
• SessionStart hook loads handoff notes from previous session (git state, objective, decisions, failures)
• UserPromptSubmit hook injects compact context every turn (branch, uncommitted files, objective)
• Stop hook auto-saves session state for next session continuity

Benchmarked with gates: 7/7 cases pass, 100% protected string recall, 27.3% average reduction. Single Rust binary, no cloud, no network calls.

Not a silver bullet for the rate limit issue itself, but it measurably reduces how many tokens each session burns on repeated/bloated tool output.

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

Same problem here. Max 20 at 6pm the session was restored, now 6:30pm. I've been working with multiple sessions since month and never happen before today. Just thinking to get back to PRO and use Qwen 2.5 local for execution/coding and using Claude just for planning and review.

<img width="938" height="151" alt="Image" src="https://github.com/user-attachments/assets/906a2bd2-1960-4134-8154-a7c1d97ce290" />

Can one of you number crunching guy check a theory i have....
Does any of the numbers correlate to cache read (the 90% discount) being removed.
Thinking since they said to "clear often", "dont run resume idle chats".... maybe they just stopped discounting it, thats why there is so wild jumps seemingly random...
Would tie into what i saw below earlier today....

Ive noticed that pretty much any prompt with meat on it (i.e more than "hello") costs a consistent 10% on the 5 hour limit but working within that problem space has the normal consumption... switching between sonnet/opus is a death sentence as it reloads entire context for entire chat, costing 10-15% of the 5 hour limit....

Its weird because 50% is normal usage and then consitently on new chats/topic eats 10-15% just to "load the convo" up...and then eats 1% slowly and normally and repeat until limit is gone...

I believe there is couple things happening... they lowered limits for everyone, that is obvs but there is also some bug in calcuöation which they are to incompetent to see is happening and think everyone is just complaining over their intended lowered limits and are ignoring it full stop as "noise"

Same here - Max plan

-Started a brand new chat after closing the previous one
-Sent the first message
-Usage immediately jumped to 17% with 4h 1m remaining (timer counting down from 5h)
Just exchanged ~5 short messages Resets in 3 hr 37 min

<img width="999" height="368" alt="Image" src="https://github.com/user-attachments/assets/a6f8e167-942d-4cb0-81dd-9c9611f82ea6" />

(no file edits, no tool calls) — usage jumped
from 17% to 33%. That's 16% for nothing. Definitely a bug.

-Yesterday I had a similar issue: usage jumped from 17% to 78% after just one more message

What Should Happen?
A new chat should start at 0% usage with the full 5h window. Each message
should consume a small, proportional amount of the budget — not 17% on the
very first message.

Steps to Reproduce
1-Close the current chat session
2-Start a brand new chat
3-Send any first message
4-Check /status — usage is already at 17% with reduced timer

Expected: 0% usage on a fresh chat
Actual: 17% usage immediately

Is this a regression? → No (or "Not sure")

Claude Code Version
2.1.107 (Claude Code)

Operating System
macOS

Have the new versions fixed the issue yet?
I personally don't believe this is a client-side error because it didn't start with an update, but, since Claude is still updating the cli I would like to know if someone has found an optimized approach
So far so long, I stuck to Claude Code v2.1.119, use Sonnet only, and place a cron to message a dot to haiku two hours before my shift to have an early reset

Have the new versions fixed the issue yet? I personally don't believe this is a client-side error because it didn't start with an update, but, since Claude is still updating the cli I would like to know if someone has found an optimized approach So far so long, I stuck to Claude Code v2.1.119, use Sonnet only, and place a cron to message a dot to haiku two hours before my shift to have an early reset

Been on .119 now for couple hours. The token consumption is stable, for now.. (Minus the fact they lowered usage for all tiers but thats a separate business decision, not client bugs).

Have the new versions fixed the issue yet? I personally don't believe this is a client-side error because it didn't start with an update, but, since Claude is still updating the cli I would like to know if someone has found an optimized approach So far so long, I stuck to Claude Code v2.1.119, use Sonnet only, and place a cron to message a dot to haiku two hours before my shift to have an early reset

Srry, I meant v2.1.90

> Have the new versions fixed the issue yet? I personally don't believe this is a client-side error because it didn't start with an update, but, since Claude is still updating the cli I would like to know if someone has found an optimized approach So far so long, I stuck to Claude Code v2.1.119, use Sonnet only, and place a cron to message a dot to haiku two hours before my shift to have an early reset Srry, I meant v2.1.90

Weird client to be on.. You would either have been on .68 or .81 to not have a lot of their bugs.
Anyhow, try .119, its stable for me.

It still doesn't fix that they reduced overall limits by 45% (My anecdotal evidence is that for months prior, 1x capped 5 hours session was exactly 8% on the total weekly limit... This is now 14-16%...)

If that reduction is an "across the board" reduction for all 3 tiers? it effectively made pro unusable and max5 a "work 1-2 hours per day" type of subscription.

On a side note... Anthropic, if you are by any chance reading?
Maybe its time, with all these reductions, bugs and 4.7 increased token use to launch a 400 or 500 subscription?
Max50 or max100?

This way? At least you would make it abundantly clear that 20/100 are explicit hobby tiers.
While 500 usd couldnt be an unlimited tier? It could serve as the bridge between professional and enterprise api.

I cant speak for everyone else... But its very important to me that its a fixed, KNOWN monthly cost... API simply cant provide that level of budgeting and planning... I wouldnt mind paying more though, to get more and you would have to opt that tier into 30 minute TTL cache please.... I dont think you considered that anything from pylint, binary compilation or a host of other things goes above 5 minutes while actively working and there is nothing the user can do to prevent it... even 15min would go a LONG way...

Hi,

Same here.

I am using RTK, it helped, but saw this:

Did an analysis of my session on Friday, which went to 100% amazingly fast.

<img width="961" height="369" alt="Image" src="https://github.com/user-attachments/assets/d9218bfb-9a7b-4fe1-a4b6-0f924ecbdb77" />

Makes no sense at all, I removed the file history, still did not help.

Compacted everything, still does not help. Something def changed.

I can confirm this is not fixed yet. i just started a new 5hr window, ran a single prompt and have spent 14% of my limit. after a second prompt I'm at 35%. I'm not happy with anthropic at all. I have an openAI account as well and this isn't even close to the usage I am seeing there. Same exact work.
Model: sonnet 4.5

Same issue I am facing as well, please fix this on priority, Model Opus. @claude

Same here, it seems connected to continuing work after it was paused by limit usage. Crazy.

Might be a little out of topic, but this issue happens almost exactly on the Pro plan.

Literally 5-6 prompts, at extremely long waiting times, consume 100% of my 5-h limit. It's impossible that I make almost zero progress to my project and instantly burn up my plan.

Guess I will have to switch back to Chatgpt plus

im not even doing anything. just /init to a new FRESH and FROM SCRATCH PROJECTS. it burns from 2% to 100%
how can i work with this piece of shit ? did someone know where i can check where all of my token goes ?

Just Subscribed Pro Plan at Mon, May 25, 7:34 PM

<img width="1420" height="480" alt="Image" src="https://github.com/user-attachments/assets/0010e4a1-ea8a-401d-a51d-79a1e2e6320e" />

burned at 20.01 to 100%

<img width="589" height="486" alt="Image" src="https://github.com/user-attachments/assets/cf2be812-c8b5-4b3c-a026-e2c90545cfc0" />

@claude

the 'one message jumped me to 24%' shape isn't usually the meter, it's cache_creation tokens. every turn re-hydrates the system block + CLAUDE.md + any auto-loaded skill frontmatter, and if those grew between 2.1.7x and 2.1.81 (skill auto-discovery scans more aggressively now) you're paying cache_creation on the delta every session start. the python script being called twice also means two full tool-result roundtrips, each carrying the prior turn's context. check claude_code.token.usage broken down by type=cache_creation vs input in OTEL, that's where the regression actually shows up, not in raw input tokens.

44& weekly used across 3x hour sessions, not even capped lol...