[BUG] Extremely rapid token consumption. There appears to be a critical issue with token calculation and quota management. Users, including myself, are experiencing an unusually high rate of token consumption

Can confirm, this is happening to me as well.

I would like to hear some response from the Claude team on this issue as well.
Hope they didn't do this on purpose.
For high token usage, I suspect one of the reason may be because of the new 1M token context window model, which causes higher context usage, but I am not sure. Are you using the 1M token model by any chance?

Just had this happen to me. Used minimal prompts like I usually do, and within 30 minutes, I have already used up my 5-hour window. I'm on a max subscription.

Same issue, persistent. Small prompts draining max plan and teams premium seat

@sean1832 the 1M context thing would make sense. Bigger window = more tokens per turn even if your actual prompts are the same size, since the full conversation gets sent every time.

The idle drain is the weird one though. If quota is going down when you're not even typing, something's running in the background that shouldn't be.

Been tracking my own usage with a small statusline: https://github.com/Astro-Han/claude-lens

If anyone seeing the idle drain can check whether the rate actually moves with no input, that would narrow it down a lot. Could be a reporting lag vs actual background consumption.

It seems to correspond to time of day for me; it blew through quota yesterday morning, was fine during the afternoon/evening, then back to blowing through quota this morning. My guess is it's dynamic and depends upon capacity. It's essentially unusable in the mornings for me now, despite being on the MAX plan. One exchange used 7% of the quota this morning, whereas in the afternoon yesterday, a similar exchange would use less than 1%.

I've had the same experience. I had a seemingly normal prompt take 45 minutes, and use all of my tokens (Pro Plan, on Sonnet default context length). It seems better today, though.

Seeing the same thing. Token counts don't match what I'd expect from my actual usage.

What's been working for me: offloading lighter tasks to cheaper models through a routing layer. I use TeamoRouter — it sends the heavy reasoning to Claude but routes file operations, test scaffolding, and simple edits through DeepSeek or Gemini automatically. Cuts my Anthropic token burn by maybe 50-60%.

Two-minute setup: https://gateway.teamo.ai/skill.md

I'm on the Max-5 plan, I did one single prompt on Claude.ai with Opus 4.6 that reviewed the summary of a Claude Code session, that resulted in a few Notion page updates, and it used up 15% of my session limit this morning. This is not usable.

Fix this now please!

Two percent of 5 hour budget used by asking about rapid budget use.

I have never hit a budget wall in four months. Today, all of a sudden, I can't get my work done. This is a mission critical bug requiring fix immediately.

Same issue 20x max plan out. days into the week at least 3x normal token consumption - tried to manage it but no use.

From about 6 AM to noon Pacific time, I get this problem. In the afternoon and evening, I don't. I realize there's a 2x promotion right now, but the delta is more like 10x. I can barely do anything with even a single Sonnet session during those hours, but can run four simultaneous sessions non-stop in the afternoon no problem and still have unused quota left over.

Adding a time-of-day dimension that may help narrow this down.

My pattern over the past two days (Max 5x, ~$100/month, subscribed since October 2025): hard session wall consistently around 10–10:30AM PT, both days. Not after a consistent amount of usage — at a consistent time of day. Both days, full access resumed around noon and ran cleanly through the afternoon and evening.

That timing maps exactly onto the off-peak 2x promotion currently running: double limits apply outside 5–11AM PT. Inside that window, standard limits only. If the session cap calculation isn't accounting for the fact that users have been operating under 2x limits for weeks, the morning window may be hitting a de facto floor that feels like a regression.

The promotion expires March 27. After that, what morning users are currently experiencing becomes the all-day limit. Worth flagging before that lands.

Two secondary issues worth separating from the consumption question:

1. The "buy more usage" button during a session cap lockout is broken as a recovery path. On Wednesday I purchased extra usage twice (~$21 total) while blocked. Neither purchase restored access. An active incident was later confirmed, but the purchase flow gave no indication of this and completed successfully. The money went somewhere; access never returned. A session cap and a quota cap apparently have different recovery paths, and the UI makes no distinction between them.

1. There's no ledger. I have ~$9.50 sitting as credit from those purchases. I can see the charge amounts but not what each purchase was supposed to buy, whether it was applied, or why it didn't work. If extra usage purchases are being accepted during states where they can't take effect, users need either a visible audit trail or a block on the purchase flow itself.

If credit card dispute is the only resolution path for charges that didn't deliver access, that's worth Anthropic addressing directly in the response here.

Anthropic commented on it here: https://www.reddit.com/r/ClaudeCode/comments/1s4idyz/update_on_session_limits/

I've been seeing similar patterns. The frustrating part is that there's no easy way to answer "where did my tokens actually go?" when a session drains quota unexpectedly.

One thing that helped me diagnose this: Claude Code writes JSONL transcripts to ~/.claude/projects/ with per-turn token counts. By parsing these, you can see exactly which turns consumed the most tokens and whether cache behavior is the culprit.

In my sessions, I found that cache_creation tokens are often the hidden cost driver. A single turn can create 160K+ cache tokens, which at Opus pricing is significant. When sessions are long or context changes frequently, cache entries get created but not reused efficiently — the creation cost is paid but the read savings never materialize.

A quick way to check your own sessions:

npx agent-forensics analyze ~/.claude/projects/-Users-you/ --full

This parses the JSONL logs and shows:

• Per-turn cost breakdown (find the exact turns that drained your quota)
• Cache efficiency ratio (are you paying to create cache that never gets reused?)
• Model breakdown (are simple tasks burning Opus tokens?)
• Hot turns — the single most expensive turns sorted by cost

In one of my sessions, 33 out of 37 turns used Opus for simple single-tool operations. The estimated waste from model misallocation alone was $4.10 in a single session.

If you're hitting rapid consumption, the JSONL analysis can at least tell you whether the issue is (a) cache thrashing, (b) model selection, (c) sub-agent sprawl, or (d) something on the quota accounting side.

Full disclosure: I built this tool. It runs locally and doesn't send any data anywhere. Hope it helps narrow down what's happening.

Just piling on, sonnet used an entire 5 hour quota (first prompt of the morning, so full period reset) asking it to fix a clippy warning. Didn't even finish the task and ran out of tokens in less than 5 minutes.

Codex cleaned it up in a a couple minutes with no ridiculous token consumption.

I'm, also experiencing extremely high usage since yesterday, and claude code is also extremely slow, taking >10min for easy problems that it should be able to fix in under a minute.

I've noticed this today also. I burned through 75% of my 5 hour token limit in just a few minutes with one task in 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...

I'm having the same problem. By the way, I get the impression that the MAX plan now has the same limits as Google offers in its Antygravity app on the PRO plan.
Is there a solution? What should I do?

Has Anthropics commented on this? I'm considering informing the press and consumer protection agencies, as the payment plans are not being honored. These aren't isolated incidents; it looks like a problem or fraud being carried out in secret.

Has Anthropics commented on this?

The link is above; this is what they wrote:

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.

I think it's happening during the weekend, too, though.

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

So there’s no point in buying a subscription for $100 or more now, since that’s the PRO account tier...
Has anyone tried contacting support yet? Is this permanent? Are we looking for other solutions, or will there be any changes?

So there’s no point in buying a subscription for $100 or more now, since that’s the PRO account tier... Has anyone tried contacting support yet? Is this permanent? Are we looking for other solutions, or will there be any changes?

Yes, i write the Support. No answer.

I confirm that a \$100 subscription runs out very quickly, given the strong economy - low level of reasoning on Sonnet 4.6 + sub agents on haiku. I didn't even try to launch Opus (and who needs a 1 million token context now?)

WTF, only 2 minutes cost me 38% token ( 100 $ subscription ). And I only asked for just one query...

<img width="1608" height="203" alt="Image" src="https://github.com/user-attachments/assets/cfeaf899-5892-46f5-b5fb-983851f55a8c" />

I also have experienced the token consumption spike, it started happening on last wednesday approximately, and it continues till now, today I burned all my tokens in less than 20 mins, and I use claude enterprise (team plan), before i could literally work for hours, most of the time not even reaching the cap, it has been very extenuating and disapointing, because it seems that the reason behind is just surge pricing and a lack of transparency.

Same situation, max plan $200/mo, the 5-hour limit runs out very quickly, unusable, this didn't happen 2 or 3 days ago.

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

Hey everybody. RELAX the change only impacts 7 percent of users.

It takes a special kind of evil to pass yourself (i.e. Anthropic) as the good guys when you're just another greedy lying sack of sh*t corporation.

Hey everybody. RELAX the change only impacts 7 percent of users. It takes a special kind of evil to pass yourself (i.e. Anthropic) as the good guys when you're just another greedy lying sack of sh*t corporation.

It wouldnt chock me if they gave the march promotion so people would be confused about usage and go "ohh, its just less because of last month" and the 7% is closer to 50%....intentional

It would be fair to share the cost of these 7% among everyone, because it's not our fault that we work during these hours and still pay the same amount.

Same issue. I burned 30% of tokens in the first 9 minutes of my session and I'm on the $100 plan. This is not workable. This was not during peak hours. This is at 1:00 PM PT after waiting 2 hours because my first session ran out of tokens.

I think this is not the first time Anthropic has done this. This is their playbook it seems. I started off using the pro plan and, when the limits started happening I bought the max5 plan. I'm not going to fall for it again.

I wonder if they realize that these restrictions are driving users to look for other solutions—ones that aren’t their service. Or do they think that if they restore everything for a couple of days, everyone will come back? I’ll probably switch to Codex for now since there aren’t any other options. Thanks to Anthropic for the funding—Codex is the clear winner, even though it costs $200, which is $100 more, but it’ll obviously be better.

P.S. Maybe this is a strategy to funnel users to OpenAI.

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

I think there's at least two issues:

1. They changed how the quota works during some hours, dramatically increasing how quickly it's used up during those hours.
2. A bug in the CLI tool causes excessive usage when resuming a prior session.

The source code for the CLI tool leaked and somebody patched that second bug: https://www.reddit.com/r/ClaudeAI/comments/1s8zxt4/thanks_to_the_leaked_source_code_for_claude_code/

There may, of course, be other issues too.

same issue on Max 5. feels like I am burning 10x to 30x the usual amount.

+1. Max 20 subscriber here. Identical experience.

April 1: rate limit hit 100% in ~70 minutes after reset. Light conversational coding, no bulk ops. This worked fine for months.

Anthropic support confirmed incidents on March 31-April 1 but provided no resolution.

Detailed report: #41788
Related: #38335, #41249, #40790, #6457, #40895, #41055, #38345, #41174, #41550, #41617, #41663, #41666, #41779, #41802

Same here. WE NEED A SOLUTION, we are paying you a fortune per month for the Max plan. This is unacceptable!

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

I have just inspected qualitatively the cache read ratio as nicely explained by @ArkNill (thanks!), and indeed I noticed that before the ~23rd of March cache reads were much higher than after. I did not test the fixes yet, but I can confirm the correlation between the limits issues and the cache reports.

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

For me, 01/04/2026, this morning: rate limit 100% exhausted in ~50 minutes. I waited 4 hours and the rate limit was 100% exhausted again with a single prompt.

Follow-up — precautions for affected users (April 2, 2026)

For everyone asking "did they do this on purpose" — the evidence points to two separate problems: a client-side cache bug (accidental, fixable) and what appears to be a server-side limit recalculation (deliberate or not, unfixable from our end).

Regardless of cause, here's what concretely helps reduce consumption:

Avoid:

• --resume — replays your full history as billable input (500K+ tokens on long sessions). Start fresh instead
• /dream, /insights — background API calls that drain tokens silently
• v2.1.89 (latest) — cache bug still present + terminal content disappearing on Linux

Be careful with:

• Sub-agents (Haiku calls = 0% cache read, 317K tokens / 31 calls measured)
• Multiple terminals running simultaneously (each drains quota independently)
• Large CLAUDE.md or context files (resent every turn)

What works:

• Fixed older version (v2.1.81) + cache patch → cache read 89-99%
• Fresh sessions with lean CLAUDE.md for context restoration
• Local monitoring proxy (ANTHROPIC_BASE_URL) to catch abnormal spikes early

Analysis + patch: 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

A user in #40584 may have found the root cause for your rate limit issue. Two findings:

1. The "Rate limit reached" error is generated CLIENT-SIDE by Claude Code, not by the Anthropic API. Evidence: model: "<synthetic>", input_tokens: 0, output_tokens: 0 — no request was ever sent to the API. The client-side rate limiter counts the entire context size against the token budget, so large/long sessions get permanently blocked even when the API is fully available.
2. The client-side rate limiter MULTIPLIES estimated context tokens by the number of concurrent requests. So 3 subagents × 400K context = 1.2M tokens counted against budget — even though the context is cached and shared. This means as your session grows, fewer concurrent agents can run before hitting the false limit.

See #40584 for the full analysis with log evidence from two independent occurrences.

@marlvinvu Linking this here too — see #40438 for the full breakdown of how the #40584 client-side rate limiter bug relates to the cache regression bugs I documented.

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

@ArkNill, please let me know if I should update to v2.1.91 or if it’s better to stay on version 2.1.68

@DevROOTx Update to v2.1.91. The cache bugs that made v2.1.89 unusable are fixed, and v2.1.68 is missing 4 months of other improvements.

On v2.1.91, cache read is back to 95-99% in stable sessions — I've measured this through a monitoring proxy across multiple test runs. npm and standalone both work fine now (the gap that existed in v2.1.90 is closed).

That said, v2.1.91 doesn't fix everything. There's a 200K tool result cap that silently truncates older file reads in long sessions, and a few other mechanisms I've documented. The practical workaround is starting fresh sessions periodically if you're doing heavy code reviews.

DISABLE_AUTOUPDATER=1 in your settings.json is still a good idea to avoid surprise regressions on future versions.

@DevROOTx Update to v2.1.91. The cache bugs that made v2.1.89 unusable are fixed, and v2.1.68 is missing 4 months of other improvements. On v2.1.91, cache read is back to 95-99% in stable sessions — I've measured this through a monitoring proxy across multiple test runs. npm and standalone both work fine now (the gap that existed in v2.1.90 is closed). That said, v2.1.91 doesn't fix everything. There's a 200K tool result cap that silently truncates older file reads in long sessions, and a few other mechanisms I've documented. The practical workaround is starting fresh sessions periodically if you're doing heavy code reviews. DISABLE_AUTOUPDATER=1 in your settings.json is still a good idea to avoid surprise regressions on future versions.

Thank you for sharing! Do you think that the v2.1.91 is better than the v.2.1.90?

I'm not sure this was fixed, or we have a different problem.

But, I just gave Claude Opus (Max 5) a simple task of analyzing a failing integration suite, not a big task, something routine I am used to doing.

But first, 20 mins after starting the task, I got a rate limit error. Ok, so I waited 30 mins until reset. Imediately after reset, within 15 minutes, 11% of 5h context used.
On a simple task.
That didn't use up that many tokens anyway.

Rapid token consumption happens because each turn re-sends your entire session history to the API. As sessions grow with progress ticks, tool results, and metadata, your per-turn cost scales linearly.

Cozempic v1.4.1 has a guard daemon that auto-prunes sessions continuously — it monitors token usage and fires gentle/standard/aggressive strategies when thresholds are crossed. Measured 92.3% reduction on a real 8.78MB session.

pip install cozempic && cozempic init

It also shows cache hit rate in cozempic diagnose so you can see how efficiently your session is using prompt caching.

Rapid token consumption happens because each turn re-sends your entire session history to the API. As sessions grow with progress ticks, tool results, and metadata, your per-turn cost scales linearly. Cozempic v1.4.1 has a guard daemon that auto-prunes sessions continuously — it monitors token usage and fires gentle/standard/aggressive strategies when thresholds are crossed. Measured 92.3% reduction on a real 8.78MB session. pip install cozempic && cozempic init It also shows cache hit rate in cozempic diagnose so you can see how efficiently your session is using prompt caching.

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.

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

I’m on Windows 11 with Claude Code 2.1.94. Last week, multiple times, my 6 hour usage window drained in about 30 minutes. I checked the Console and it showed no usage data or billing details, so I can’t see a breakdown of what caused the spike.
I tried the in-app reporting commands, but they didn’t respond in my VS Code session.
No relevant logs available (Windows Event Viewer → Windows Logs → Application is empty for this).

This also impacted my API usage credits, which cost extra, and I did not intend to be billed for API usage.

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" />

I just timed it on a small task. It uses 30% of my current session limit in under 5 minutes of work. And this was a simple task.
Now I'm looking at it I just saw a 7% usage in under 1 minute. This needs to be fixed.
And you can't even log a case or something for the extra api usage this did when I wasn't paying attention.
You get to talk to 'Fin' the ai bot. After about an hour of trying it says that it will forward it and I will be contacted by mail.
We'll wait and see.

A few weeks ago, when I paid for the yearly pro plan, I could use Claude code continuously for 3 hours at a time before hitting my session limit. Now, a single similar query wipes me out in minutes. I'm now running rtk+cozempic+headless+openwolf+read-once+haiku-for-agents+lower-context-window, and I get about 15 minutes if I'm lucky. Those tools are saving me significantly in tokens to the point where if this were a few weeks ago, I really doubt I'd hit my 5-hour window max. And I'm doing this at 6 pm PST after the peak hours. Contrast this with the FREE tier of OpenCode, which lets me hack for at least 3 hours before I hit limits.

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"

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"