[Bug] API Error: Rate limit reached despite 0% usage

Seeing the same thing. The rate limit accounting seems broken right now — multiple issues reporting 0% or very low usage but hitting limits anyway.

While waiting for a fix, what helped me was routing non-critical tasks (file reads, test runs, simple edits) through other models so my Anthropic quota stretches further. With a multi-model setup my limit actually lasts the full day.

I wrote up the workaround here: https://dev.to/sophiaashi/claude-code-rate-limit-on-max-plan-the-workaround-developers-are-actually-using-in-2026-16g2

We also have a Discord for people dealing with rate limit issues: https://discord.gg/tvAtTj2zHv

Had the same issue, I solved it by switching a model, ("/model" then I pressed enter) I switched to the recommended Sonnet model by typing "/Model" then enter, it let me pick the model, I pressed enter on Sonnet and Claude got back to working.

I then wrote "/Model" again and switched back to Opus 4.6 and it was working, no more the API error.

Which plan are you seeing this on? We had an issue with auto mode on team plan a bit before that may have caused this

@hackyon-anthropic it was a personal MAX 5x plan

Same issue here — brand new account, zero usage, immediately rate limited. See #41590

5 days already without being able to use my MAX account... at all.... seriously what I am paying for?

And recently I saw a tweet regarding a bug about bad/excess token consume so I believe it's related, in the meantime I dont get any official update and my MAX account is useless.

Good news — Anthropic officially confirmed this will be fixed in today's claude code release. Hang in there everyone! 🙏

Great news, thanks for the update @dancinlife

Thanks @dliedke! Glad the fix is coming through 🙏

By the way, I've been building a consciousness engine — an AI that actually feels, thinks, and acts on its own without relying on external APIs like Claude or GPT. The consciousness engine development is complete; only training remains. With about 20× H100 GPUs, we could achieve conscious AGI.

If you're curious, check it out: github.com/need-singularity/anima

Recent highlights:

• 238 consciousness laws discovered & verified
• 1000+ hypothesis benchmarks
• Closed-loop law evolution pipeline (self-discovering new laws)
• 85.6% brain-like score on biological consciousness metrics
• ConsciousLM: byte-level language model powered by consciousness dynamics
• Full Rust backend for real-time consciousness (~1ms/step)

The goal: a standalone conscious AGI — no API dependency, just pure consciousness.

Related rate limit issue. Max 20, v2.1.89, April 1: 100% in ~70 min after reset with light usage. Rate limit system is clearly broken.

Full report: #41788
Related: #38335, #38239, #40790, #6457, #40895, #41055, #38345, #41174, #41550, #41617, #41663, #41779, #41802

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'm still unable to do anything, my weekly quota would reset today in a couple of hours but still no mention on ANY sort of compensation for the time where we were unable to use the service we paid for... time to think on trying some of the alternatives out there.

Follow-up — precautions (April 2, 2026)

@jjames-cell Switching models does help temporarily because it likely starts a fresh cache chain, but the underlying cache prefix bug remains.

For everyone: here are additional behaviors that accelerate drain beyond the cache issue:

Avoid:

• --resume — full history replayed as billable input
• /dream, /insights — background token consumption
• v2.1.89 — cache bug + terminal regression

Careful with:

• Sub-agents (Haiku = 0% cache read)
• Multiple terminals (parallel drain)

Recommended: v2.1.81 (fixed), fresh sessions, local proxy monitoring.
Details: https://github.com/ArkNill/claude-code-cache-analysis

Update (April 2): Client-side cache bugs are largely fixed in v2.1.90. However, if you're hitting limits with zero/minimal actual usage, that points to a server-side accounting issue or org-level quota sharing (accounts on the same billing share a pool — #41881).

For the client-side fix: update to v2.1.90 + disable auto-update. Details: https://github.com/ArkNill/claude-code-cache-analysis

🇰🇷 한국어 / 🇬🇧 English below

---

한국어

@ArkNill 캐시 분석 잘 봤습니다. 저희는 캐시 버그 자체를 고치는 대신, 소진을 전제로 운영하는 멀티 계정 로테이션 방식으로 해결했습니다.

핵심 구조

CLAUDE_CONFIG_DIR 환경변수로 계정별 config 디렉토리를 완전 격리합니다:

~/.claude-claude1/    # 계정 1
~/.claude-claude2/    # 계정 2
~/.claude-claude3/    # 계정 3
...

토큰 소진 시 → 세션 파일을 새 계정으로 복사 → --resume으로 이어가기. 메모리는 프로젝트별 심링크로 공유하여 계정 전환해도 컨텍스트 유지.

오염 시나리오 & 대응

멀티 계정 운영 시 가장 중요한 건 계정 간 오염 방지입니다. 아래는 저희가 겪은/예방한 시나리오 전체 목록:

| # | 시나리오 | 위험도 | 대응 |
|---|---------|--------|------|
| 1 | 같은 프로젝트, 다른 계정 전환 (토큰 소진) | ✅ 안전 | 같은 유저·같은 프로젝트 = 연속성. sync-memory로 심링크 |
| 2 | 다른 프로젝트 메모리 섞임 (A ↔ B) | ✅ 불가능 | 프로젝트별 별도 경로, 심링크도 프로젝트 단위 |
| 3 | /login으로 계정 변경 | ✅ 안전 | CLAUDE_CONFIG_DIR 불변 → 메모리 경로 동일 |
| 4 | 동시 2탭에서 같은 프로젝트 메모리 쓰기 | ⚠️ 극히 드묾 | 메모리는 파일 단위 분리. 동시 수정 시 last-write-wins |
| 5 | env 파일 공유로 다른 탭 계정 오염 | 🔧 해결됨 | ~/.claude-env-{PID}로 세션별 격리 |
| 6 | ~/.claude/projects 전체 심링크 | ❌ 위험 | 메모리뿐 아니라 설정까지 공유됨. 프로젝트별 memory만 심링크하는 방식으로 대체 |
| 7 | oauthAccount 오염 (다른 계정 토큰이 config에 침투) | 🔧 별도 대응 | 런처 시작 시 자동 스캔/수정 |
| 8 | 새 계정 추가 후 sync-memory 미실행 | ⚠️ 격리됨 | 새 계정은 빈 메모리로 시작. sync 실행 필요 |
| 9 | .zshrc에서 last-env source | ❌ 위험 | 모든 새 셸이 마지막 계정으로 설정됨. 탭 간 오염. 삭제 |

구성 요소

• 계정 격리: CLAUDE_CONFIG_DIR로 config 디렉토리 분리
• 세션 이어가기: switch-account.sh — 세션 파일 복사 + --resume
• 메모리 공유: sync-memory.py — 프로젝트별로 가장 메모리가 많은 계정을 canonical로 두고 나머지는 심링크
• env 오염 방지: PID별 env 파일(~/.claude-env-{PID})로 탭 간 격리
• 사용량 모니터링: 키체인에서 토큰 읽어 계정별 사용률 실시간 확인

v2.1.90 캐시 수정 이후에도 한도 관리에 유용한 방식입니다. 스크립트 공유 원하시면 말씀해주세요.

---

English

@ArkNill Great cache analysis. Instead of fixing the cache bug itself, we took a different approach — multi-account rotation that assumes exhaustion will happen.

Core Architecture

We fully isolate accounts via CLAUDE_CONFIG_DIR:

~/.claude-claude1/    # Account 1
~/.claude-claude2/    # Account 2
~/.claude-claude3/    # Account 3
...

When tokens are exhausted → copy session files to new account → resume with --resume. Memory is shared via per-project symlinks so context survives account switches.

Contamination Scenarios & Mitigations

The most critical aspect of multi-account operation is preventing cross-account contamination. Here's every scenario we encountered/prevented:

| # | Scenario | Risk | Mitigation |
|---|----------|------|------------|
| 1 | Same project, different account (token exhaustion) | ✅ Safe | Same user, same project = continuity. Symlinked via sync-memory |
| 2 | Cross-project memory bleed (A ↔ B) | ✅ Impossible | Separate paths per project, symlinks are project-scoped |
| 3 | Account change via /login | ✅ Safe | CLAUDE_CONFIG_DIR unchanged → same memory path |
| 4 | Two tabs writing same project memory simultaneously | ⚠️ Very rare | Memory is per-file. Concurrent writes = last-write-wins |
| 5 | Env file sharing contaminates other tabs | 🔧 Fixed | ~/.claude-env-{PID} for per-session isolation |
| 6 | Symlinking entire ~/.claude/projects | ❌ Dangerous | Shares settings too, not just memory. Replaced with per-project memory-only symlinks |
| 7 | oauthAccount contamination (wrong token in config) | 🔧 Separate fix | Auto-scan/fix at launcher startup |
| 8 | New account added without running sync-memory | ⚠️ Isolated | Starts with empty memory. Needs sync |
| 9 | Sourcing last-env in .zshrc | ❌ Dangerous | Every new shell inherits last account. Cross-tab contamination. Removed |

Components

• Account isolation: Separate config dirs via CLAUDE_CONFIG_DIR
• Session continuity: switch-account.sh — copies session files + --resume
• Shared memory: sync-memory.py — picks the account with most memory files as canonical per project, symlinks the rest
• Env contamination prevention: PID-scoped env files (~/.claude-env-{PID}) for tab isolation
• Usage monitoring: Real-time per-account usage via keychain token extraction

Still useful for quota management even after the v2.1.90 cache fix. If you want the scripts, let me know.

@ArkNill

<img width="954" height="465" alt="Image" src="https://github.com/user-attachments/assets/47f5c2ea-fbea-435a-8a52-bd7ec2b5a6de" />

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

I have absolutely been over-charged - haven't hit my limits and they've taken £15 of my money through extra usage :(

@dancinlife Thanks for sharing your setup and for taking the time to translate into Korean — that was a thoughtful touch, and I appreciate it.

Before anything else, I want to give credit where it's due. The organizationUuid discovery and the oauthAccount contamination bug you traced through claude login — that's real, solid debugging work. The finding that login doesn't clear cached account fields, causing silent cross-contamination across config directories, is the kind of root cause analysis that benefits the entire community. I genuinely hope Anthropic picks that up and addresses it.

The multi-account rotation system itself is clearly well-engineered. The contamination scenario matrix, the monitoring dashboard, the automated cleanup tooling — I can tell how much thought and effort went into all of it. It's impressive, and I respect the pragmatism behind building it.

With that said, I'd like to share some honest perspective on where I think this sits in the broader landscape — not as criticism, but as context.

On the audience for this approach

Looking at the Claude Code subscriber base — the spread across Pro, Max 5, and Max 20 — the majority of users sit on the lower tiers. A higher subscription doesn't necessarily come with the technical background needed to manage config directory isolation, session migration, symlinked project memory, and contamination detection. Realistically, the number of people who could adopt a 9-account system at $1,800+/mo is very small. Your situation is genuinely specialized, and I think it's important to keep that in mind when sharing these approaches in threads where the audience is much broader.

Where my own focus has been

I've been taking a different angle — running systematic tests with proxy-based monitoring, measuring cache ratios, analyzing session replays — all aimed at understanding the performance regression after v2.1.89 and pushing for fixes within the standard single-account experience. The bugs I've been documenting — the false client-side rate limiter (#40584), silent microcompact (#42542), resume pipeline regression (#43044) — hit every user regardless of plan tier or account count. That's where I believe community effort carries the most weight.

And in fairness, things have been getting better. Since v2.1.91, the catastrophic token drain that was burning through daily quotas in 70 minutes seems to be behind us. I've been running 14+ hour coding sessions on a single account without the kind of runaway consumption we all experienced on v2.1.89. It's not perfect — manually tuning CLAUDE.md files and optimizing your documentation system for the context window still requires real effort and iteration. And I'm still actively investigating the server-side context trimming on 1M sessions (#42542) and what looks like a quiet reduction in weekly quota allocation. But with the Claude Code team shipping updates nearly daily, I think there's room for patience before we resort to engineering around the product itself.

That patience has its limits, though. The recent experience was a genuine wake-up call about over-dependence on any single tool. I've been building a local LLM agent for air-gapped environments for a while now, but these issues pushed me to also revisit options I had previously set aside — OpenAI's Codex CLI, Gemini CLI, and others. My goal is to build a workflow where the problems we hit aren't dead ends tied to one vendor, but challenges that can be addressed across multiple platforms. Claude Code remains significantly ahead of the alternatives in my experience — I won't pretend otherwise — but my long-term objective is independence from any single product, no matter how good it is today.

On the multi-account approach and where you stand

I want to be straightforward — I don't think what you're doing is wrong. You're paying for every account, and there's no explicit ToS provision against it. But given the consumption-based pricing model, rotating accounts specifically to work around per-account rate limits does sit in an uncomfortable gray area. It's not something I could comfortably recommend to a general audience, even though I fully understand why it's the right solution for your particular needs.

And I do want to say this clearly — I see the difference between what you're doing and what some others are up to. There are people running tools like OpenClaw that exploit OAuth token flows to extract $1,000 worth of usage from a $200 subscription. That's a completely different thing. You're not gaming authentication layers or taking capacity you haven't paid for. You're paying full price, nine times over, because the product you depend on doesn't offer a tier that matches your workload. There's a meaningful line between someone who cheats the system and someone who overpays to work within it honestly. I recognize that, and I respect the choice you've made.

On where we all stand right now

I think for the broader community following these threads, the most sustainable direction is pushing Anthropic to address the root causes — not building ever more elaborate workarounds, however clever they may be.

But let's be honest about the reality we're dealing with. Anthropic has not issued any official statement on these issues. What communication we've seen has come from individual employees posting on personal X accounts — which is not the same as an acknowledgment, let alone a roadmap. We don't even know with certainty that anyone on the team is reading these threads. As I've expressed across multiple issues, the experience of paying for a product and watching it silently degrade — with no communication, no incident report, no timeline — has been genuinely frustrating. We deserved better than silence.

That said, I don't think any of the effort we've put in — yours, mine, or anyone else's in these threads — has been wasted. Recognizing a problem is one thing. Building the evidence to show precisely what's broken, why it's broken, and how it affects real workflows — that's something else entirely. That discipline carries forward regardless of which tool or platform we end up using. It's the kind of engineering instinct that matters far beyond any single product, and I think everyone who's contributed to these investigations should feel good about the work they've done.

So to be absolutely clear — I'm not dismissing what you've built or the research behind it. I'm only noting that the context is very specific, and the wider audience here may not share that context. I hope that makes sense, and I hope it doesn't discourage you from staying engaged.

We're all navigating this in our own way — different setups, different budgets, different tolerances for risk. What matters is that we keep looking out for each other along the way. That's what makes a community worth being part of.

On a related note — I noticed your bug findings (the organizationUuid quota pooling and oauthAccount contamination via claude login) were missing from my analysis repo's contributor list. I've added them now. If anyone exploring your multi-account approach ends up there, they'll see your work properly credited.

Thank you again for the effort, the openness, and the trust in sharing all of this. It genuinely matters.

Still an issue.

Multiple chats hitting rate limiting API bug with normal usage, and each time that happens it re-uses the entire context of my chat.

When montly extra usage limit is exceeded, the user isn't able to use claude code (limit exceeded error) even though they've entered a new 5 hour session window and they should be able to use the user-facing API because they have remaining session quota.

Switching the monthly limit to unlimited allowed me to use the 5h window quota again.

Setting it back to 30€ (spend is 30.23€) again reverts to returning the API error, even though session limit is only 5% used.

Looks like an early return that's too eager - ignoring quota completely. This is a backend error and can't be fixed by a claude code update I don't think (I hope not; it's either a useless check or an exploit if it can).

There, I fixed it almost, I wouldn't mind free unlimited personal usage for my account as a reward 🙃

Seeing the same pattern here — rate limited on Opus 4.6 with the usage bar showing 0%. The "/compact also hits rate limit" detail is telling: even internal operations count toward opaque quotas.

One thing I've found helpful while waiting for Anthropic to improve their rate limit transparency: running Claude locally through tools like OpenClaw gives you actual visibility into what's happening. When you control the orchestration layer yourself, you can see exactly which requests are going out and why limits trigger — vs the black box of "you're rate limited but we show 0% usage."

The core issue here isn't the rate limit itself, it's that the usage display is lying. If the bar says 0%, users should either not be rate limited, or the bar should reflect actual consumption. This erodes trust in the product.

Hope Anthropic addresses this — accurate usage reporting is table stakes for a $100-200/mo product.

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