Claude Max + Claude Code rate limits exhausting abnormally fast / possible metering bug

Found 3 possible duplicate issues:

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

As of today (March 31), the effective rate limit on the Max plan appears to have been significantly reduced. Previously, a typical development session would last through the full 5-hour window. Today, the same workflow (single conversation, Opus 4.6, a few subagents) hit the limit in ~1.5 hours — without any change in usage patterns.

This is a blocking regression for users relying on Claude Code for sustained development work.

OTEL tracking indicates a big cut in the limits on my side too, might be a metering issue ?

Same. Max 20, v2.1.89, April 1: 100% in ~70 min after reset. Light conversational coding only. Support acknowledged Mar 31-Apr 1 incidents but no fix.

Full report: #41788
Related: #38335, #38239, #41663, #40652, #41506

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

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

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 Is it fixed for you? For last 3 months, I have been using claude 5x and never used to hit limits but now it's like I have to use it wisely. think first prompt second. I tried all, even used rtk/headroom but still it's been spending like crazy.

@futurbotconsolidated

Short answer — the cache bug that caused the worst drain is fixed since v2.1.91, but no, the overall situation isn't fixed. I'm on Max 20 ($200/mo), my weekly reset is Friday noon, and it's Wednesday — already approaching 80%. I optimize aggressively (lean CLAUDE.md, short sessions, subagent isolation, proxy monitoring) and it's still tight. So your experience on 5x tracks with what I'm seeing on 20x too.

---

The cache fix — what actually changed

v2.1.89 and earlier had two cache bugs (B1 "Sentinel" and B2 "Resume") that destroyed prompt caching. Normally Claude Code reuses cached context from previous turns, so you only pay for new tokens. When these bugs hit, the cache miss rate spiked — I measured cache read ratio dropping to 4.3%, meaning nearly the entire context was re-sent and re-billed every turn. That alone could explain 20x faster quota drain.

v2.1.91 fixed both. In my proxy data, cache reads stabilized at 98-99% after the update. npm and standalone both have the fix now — the performance gap between them is negligible (benchmark data). Check your version with claude --version and update if needed. The tools you mentioned (rtk, headroom) were targeting this same cache issue, so if you're already on v2.1.91+ they won't add much on top of the native fix.

Full details on what B1 and B2 were and how they were fixed: 01_BUGS §B1-B2

---

What's still broken — server-side quota reduction

This is the part no client update can fix, and it's likely what you're feeling.

Anthropic introduced a dual-window quota system — a 5-hour rolling window plus a weekly cap. On paper this sounds like structure, but in practice the total effective budget has been quietly reduced. Other users in related threads have independently measured roughly 34–143x reduction in effective capacity compared to ~3 months ago, using JSONL forensics and proxy instrumentation. The 5-hour windows reset on a rolling basis, but the weekly cap is the real ceiling, and that ceiling came down significantly.

I've been tracking this through a monitoring proxy (17K+ requests over 8 days). The per-1% cost of the weekly quota works out to roughly 9K-16K output tokens and 1.5-2.1M cache read tokens per percentage point (rate limit header analysis). Context grows at a median rate of ~1,845 tokens per minute in a normal coding session, which means longer sessions get disproportionately expensive — not linearly, but structurally, because each turn re-sends the growing context. Early turns in a session are cheap; by turn 50+ you're paying significantly more per interaction.

What this means in practice: they reshuffled when and how you hit limits, but the actual total you can use went down. If you used to get through a full day without thinking about limits, and now you're rationing — that's not your workflow changing, it's the quota shrinking. See timeline for how this evolved version by version.

---

Silent context mutations eating your quota

There are two unfixed mechanisms that silently degrade your sessions and waste tokens:

Budget cap (B5): Every tool result (file reads, grep output, etc.) gets truncated to a 200K character hard cap before the model sees it. In my proxy dataset, I logged over 72K truncation events across 8 days, with 90% of truncated outputs cut down to just 11-100 characters. That means Claude asked to read a file, got a sliver of it, and then had to make decisions based on incomplete information — leading to wrong outputs, follow-up corrections, and more turns burned. You can't opt out of this; MCP tool results are the only exception. Details: 01_BUGS §B5

Microcompaction (B4): As your conversation grows, older messages get silently compressed mid-session. The model loses detail from earlier context without you knowing. In long sessions (100+ messages), I observed an average of 6.6 items compressed per event. The result is that Claude "forgets" earlier decisions and you end up re-explaining or correcting — each correction is another turn, another chunk of quota. Full analysis: 05_MICROCOMPACT

These two compound: B5 gives the model bad input, B4 makes it forget what it already learned, and you pay for all the extra turns it takes to recover.

---

Anthropic's response

Anthropic's position is that peak-hour capacity was tightened but "none were over-charging you" (Lydia Hallie on X). The measured data tells a different story. My proxy logs show context inflation, silent truncation, and effective capacity reduction that are structurally baked into how the client works — not just peak-hour variance. The full proxy dataset with raw numbers is here: 13_PROXY-DATA

I also cross-validated the proxy data against client-side JSONL logs (532 session files). The JSONL-reported cache_read tokens are consistently ~1.93x higher than what the API actually returned (JSONL analysis). This inflation affects what you see in local usage logs — whether it feeds into server-side metering is unconfirmed, but at minimum it makes your local usage tracking unreliable.

---

What you can actually do

The biggest lever you have left is reducing per-turn cost:

Check your CLAUDE.md and memory file sizes. Every token in CLAUDE.md, memory files, and system context gets loaded into every single API request. I measured ~11-15K tokens per turn with a minimal setup in controlled testing. If your CLAUDE.md has grown to 30-50K+ tokens over months of accumulated instructions, rules, and project context, that's 30-50K tokens baked into every turn before you even type anything. Trim it aggressively — move reference material into separate files that get read on demand, not loaded by default.

Keep sessions under ~50 turns. Context growth is structural — each turn adds to the payload, and the later turns in a long session cost disproportionately more. Starting a fresh session with a well-written CLAUDE.md is cheaper than continuing a 100-turn conversation where half the context has been microcompacted anyway.

Avoid --resume. Even after the B2 fix, resumed sessions still have edge cases that break cache alignment. Fresh sessions are more predictable.

Use subagents for isolated tasks. Each subagent gets its own context window, so a file search or code review in a subagent doesn't bloat your main session's context.

Practical tips in more detail: usage guide. If you want to set up your own proxy to see exactly where your tokens are going: advanced guide.

Context bloat compounds with each turn — sessions silently grow with progress entries, stale tool outputs, and duplicate content. Cozempic keeps this under control with a guard daemon that auto-prunes at 4 thresholds. Lossless — nothing meaningful is removed.

Sessions typically run 3-4x longer and cost 2-3x less.

pip install cozempic && cozempic init

Feedback welcome.

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.