[BUG] Rate limit error (429) triggers unexpected plan usage consumption in Claude Code (Windows)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/40445
2. https://github.com/anthropics/claude-code/issues/50389
3. https://github.com/anthropics/claude-code/issues/41583

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

This is a serious accounting-integrity bug because the product is conflating two very different concepts:

• server-side rate limiting / temporary capacity throttling
• user plan consumption / billable usage depletion

If a 429 that explicitly says "not your usage limit" still burns meaningful plan allowance, then the runtime and the billing/control surfaces are effectively charging users for provider-side inability to serve the request.

From the operator perspective, that is infuriating because there is nothing actionable to do:

• user is not over their plan
• user may not even be actively doing work
• server says wait
• plan budget disappears anyway

That makes rate limiting feel punitive instead of protective. Whatever internal accounting path is involved, users should not lose scarce plan capacity when the system itself says the failure was provider throttling rather than their own quota exhaustion.

The worst part is that this has happened multiple times and I have lost so much time and usage because of this despite being on Max 20x plan. So many people would be going through this unfair truncation of their usage.

<img width="1244" height="298" alt="Image" src="https://github.com/user-attachments/assets/d910d30d-bffc-438a-8f00-d2f6199d6e5b" />

So apparently a huge chunk of my plan usage gets mysteriously drained even when I’m not actively using Claude and—wait for it—nothing is running in the background. Magic, right? This circus act has repeated itself all day, wasting hours of paid usage and blocking actual work. And the cherry on top? The rate-limit error message is supposedly “separate” from my plan’s usage cap, but in practice they’re being tied together in the most incompetent way imaginable. Honestly, it feels less like a technical glitch and more like a fraudulent business model dressed up as “limits.”

@emersonbusson @0xbrainkid @afnanmakhdoom7

I don't think the token drain you see is being caused by 429 rate-limit, more the opposite.
It's the sudden token drain that triggers the 429 rate-limit because the Anthropic API thinks you used a high volume of your token budget in very short time and thus decides to rate limit your profile.

Unfortunately the very opaque token accounting from Anthropic is based on estimates, not real token usage.

https://github.com/anthropics/claude-code/issues/47922

I wouldn't call it a "practice" (I have doubts but I hope not), more an "issue" probably due to the high complexity of the back-end infrastructure where cheap shortcuts have been used to workaround issues and performance constraints (Claude-style).
Fact is, proved by evidence, the agents and subagents were accounting 2M tokens at each spawn (now they finally got rid of it), regardless the real context of the agent was filled by a 100K or a 900K context.

This "let's just make a rough estimate and account in excess" approach is probably what is causing random token buckets zap. No one is exempt.
Found out it was a widespread and frequent issue when I suddenly got 20% of my token usage zapped without any reason.
Just got an unjustified 3% zap this morning, so happy about it.

Plus don't forget the creepy token bucket allocation; 50% to Claude Code and 50% to the other tools (Web, Desktop, CoWork, etc.)
So you effectively have only half of the tokens of your subscription now allocated to Claude Code.
And if this wasn't bad enough both the tokens contribute equally to the 100% limit.
So in practice you will never be able to use 100% of the token bucket, the 50% usage on Code will prevent you to use the other 50% on the other tools cause you usage limit will be at 100%.
It's true also the opposite, any other tool usage will drain your usage limit on Claude Code.
Make sure you don't use much or at all the other tools to avoid surprises.

Claude calls this random zapping "delayed accounting"; fancy name.
But it happens also at usage limit restart, sometimes it goes up immediately up at the first request after a limit reset from 100% to 0%.
I call it "pre-emptive accounting"...

I strongly suggest you all to install claude-hooks and enable the API proxy.
Install all the recommended and suggested tools, as you need.

https://github.com/mann1x/claude-hooks

The API proxy shields very well from 429s, makes the client unstoppable from 5xx errors and will provide you and Claude a dashboard and logs to immediately identify issues and investigate upon them.
If you have a similar doubt like with the 429 rate-limit, Claude can investigate and provide you the evidence.

Look at my 7 days stats, not even once.
It was a recurring issue before:

<img width="601" height="266" alt="Image" src="https://github.com/user-attachments/assets/d37a7c21-816b-4877-96f5-17eb73e048f0" />

If you spend time and effort in setting up the environment and maintaining it, it's worth 100% the effort.
You will experience a Claude Code better than ever.
it will not forget stuff, no lazyness, almost no dodging, no reasoning degradation, very few mistakes.

Best of all, works great while using medium effort.
Which compounded with the massive token usage reduction means my Max 20 sub now feels more like a Max 5/10 instead of a useless Pro.
Can do half of what I was doing before but it's real high quality engineering and research work.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

I too am experiencing this and have seen no resolution from Anthropic. I have opened threads, tried to contact customer support but their bot just takes me in circles, never resolving. I think the only way to deal with it is to stop using their services or accept you have to go 1 chat at a time and wait 2 or so minutes before interacting with the next one.

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.