[BUG] Rate Limit Reached without typing anything, and /insights causes insane token usage

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/38224
2. https://github.com/anthropics/claude-code/issues/40199
3. https://github.com/anthropics/claude-code/issues/29579

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

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

Vow - this is crazy, and a very surprising and disappointing drop in quality. Good to know this: I won't be running the /insights command anytime soon after this.

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

Related. Max 20, v2.1.89, April 1: 100% in ~70 min after reset. Token accounting is clearly broken.

Full report: #41788
Related: #38335, #38239, #38896, #41663

My Claude says your issue shares the same pattern as #38239, #37917, #39465, #39938, #40079, #40085, #40128, #40438. The "28% already used when you woke up" matches the phantom usage pattern — tokens consumed without any user activity, likely from background processes, session resume, or metering errors. Issue #39938 confirmed 93% was phantom usage in one case.

Follow-up — confirming the /insights token drain (April 2, 2026)

Your report about /insights causing insane token usage is consistent with what I've found. Both /insights and /dream trigger background API calls that consume tokens without producing visible output in your session. Combined with the cache bug (which makes every token fully billed), these features can burn through your quota silently.

Full precaution list for affected users:

Avoid entirely:

• /insights, /dream — background token drain (as you discovered)
• --resume — replays full conversation history as billable input
• v2.1.89 — cache bug persists + terminal content regression

Be careful with:

• Sub-agents (Haiku = 0% cache read, expensive at scale)
• Multiple simultaneous terminals
• Large CLAUDE.md files (resent every turn)

What helps:

• Fixed older version (v2.1.81) with cache patch
• Fresh sessions + lean CLAUDE.md (never resume)
• Proxy monitoring via ANTHROPIC_BASE_URL

Analysis: 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 Thanks for cross-referencing #40584. The model: "<synthetic>" / input_tokens: 0 finding is compelling — it proves a class of rate limit errors that never touch the API at all.

This is a separate issue from the cache regression I documented (Bug 1: #40524, Bug 2: #34629). The cache bugs cause real API calls to be billed at full price. The #40584 bug causes the client to block requests entirely without making an API call.

Both contribute to the "unusable" experience, but through different mechanisms. This explains why some users see improvement on v2.1.90 (cache bug fixed) while others see no change (hitting the client-side rate limiter instead).

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

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.