[Bug] Rate limit triggered before reaching session usage limit (71%)

Status Open
Reported on v2.1.29
Maintainer reply None cached
Activity 12 comments · opened Feb 4, 2026

Bug Description
Issue: Rate limit triggered at 71% session usage
I'm on the Max plan ($200). The /usage command shows my current session usage at 71%, but I'm getting the error message "You've hit your limit · resets 8pm (Asia/Seoul)" when trying to send a simple message ("hello").
The usage display still shows 71% even after being rate limited - it doesn't update to 100%.
Expected behavior: Either the usage should reflect 100% when rate limited, or I shouldn't be rate limited at 71% usage.
This seems like either a display bug or an incorrect rate limit trigger.

Environment Info

  • Platform: darwin
  • Terminal: Apple_Terminal
  • Version: 2.1.29
  • Feedback ID: 83272fd6-1864-4e98-86aa-4d0032fb7682

Errors

[{"error":"Error: LSP server plugin:typescript-lsp:typescript failed to start: Executable not found in $PATH: \"typescript-language-server\"\n    at start (/$bunfs/root/claude:2142:22315)\n    at async H (/$bunfs/root/claude:2142:24767)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-02-04T09:26:06.714Z"},{"error":"Error: LSP server plugin:csharp-lsp:csharp-ls failed to start: Executable not found in $PATH: \"csharp-ls\"\n    at start (/$bunfs/root/claude:2142:22315)\n    at async H (/$bunfs/root/claude:2142:24767)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-02-04T09:26:06.714Z"},{"error":"Error: Executable not found in $PATH: \"typescript-language-server\"\n    at spawn (unknown)\n    at spawn (node:child_process:667:35)\n    at spawn (node:child_process:14:39)\n    at start (/$bunfs/root/claude:2142:20845)\n    at start (/$bunfs/root/claude:2142:22369)\n    at H (/$bunfs/root/claude:2142:24767)\n    at H (/$bunfs/root/claude:2142:25742)\n    at _ (/$bunfs/root/claude:2142:32529)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-02-04T09:26:06.714Z"},{"error":"Error: Executable not found in $PATH: \"csharp-ls\"\n    at spawn (unknown)\n    at spawn (node:child_process:667:35)\n    at spawn (node:child_process:14:39)\n    at start (/$bunfs/root/claude:2142:20845)\n    at start (/$bunfs/root/claude:2142:22369)\n    at H (/$bunfs/root/claude:2142:24767)\n    at H (/$bunfs/root/claude:2142:25742)\n    at _ (/$bunfs/root/claude:2142:32529)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-02-04T09:26:06.714Z"},{"error":"Error: Failed to start LSP server plugin:typescript-lsp:typescript: Executable not found in $PATH: \"typescript-language-server\"\n    at <anonymous> (/$bunfs/root/claude:2142:32551)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-02-04T09:26:06.714Z"},{"error":"Error: Failed to start LSP server plugin:csharp-lsp:csharp-ls: Executable not found in $PATH: \"csharp-ls\"\n    at <anonymous> (/$bunfs/root/claude:2142:32551)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-02-04T09:26:06.714Z"},{"error":"Error: LSP server plugin:rust-analyzer-lsp:rust-analyzer crashed with exit code 1\n    at <anonymous> (/$bunfs/root/claude:2142:21472)\n    at emit (node:events:98:22)\n    at #handleOnExit (node:child_process:520:14)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-02-04T09:26:07.454Z"},{"error":"Error: 429 {\"type\":\"error\",\"error\":{\"type\":\"rate_limit_error\",\"message\":\"This request would exceed your account's rate limit. Please try again later.\"},\"request_id\":\"req_011CXnnj95NJLRpfWZ5aH5RC\"}\n    at generate (/$bunfs/root/claude:343:8908)\n    at makeRequest (/$bunfs/root/claude:360:5435)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-02-04T09:26:07.461Z"},{"error":"Error: 429 {\"type\":\"error\",\"error\":{\"type\":\"rate_limit_error\",\"message\":\"This request would exceed your account's rate limit. Please try again later.\"},\"request_id\":\"req_011CXnnk432nUutCAbxr7fjX\"}\n    at generate (/$bunfs/root/claude:343:8908)\n    at makeRequest (/$bunfs/root/claude:360:5435)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-02-04T09:26:19.723Z"},{"error":"Error: 429 {\"type\":\"error\",\"error\":{\"type\":\"rate_limit_error\",\"message\":\"This request would exceed your account's rate limit. Please try again later.\"},\"request_id\":\"req_011CXnnm1YzJ1vA7piZ978yc\"}\n    at generate (/$bunfs/root/claude:343:8908)\n    at makeRequest (/$bunfs/root/claude:360:5435)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-02-04T09:26:32.723Z"},{"error":"SyntaxError: JSON Parse error: Unexpected identifier \"You\"\n    at <parse> (:0)\n    at parse (unknown)\n    at <anonymous> (/$bunfs/root/claude:69:855)\n    at A (/$bunfs/root/claud…

Note: Content was truncated.

View original on GitHub ↗

12 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/22876
  2. https://github.com/anthropics/claude-code/issues/22441
  3. https://github.com/anthropics/claude-code/issues/22930

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

Felipalds · 6 months ago

I have the same issue here. When 70% is reached, I cannot use Claude anymore. Any resolution?

aleyakovle · 6 months ago

Same problem as I got 70% used on session limit
All models weekly limit -- 12% used

max5x

vj-09 · 6 months ago

Seems more people are running into this

damogallagher · 6 months ago

I experienced this too but my ticket was closed as a duplicate

Felipalds · 6 months ago

My issue was specifically on Zed. I am now using the claude-cli on my terminal and it didn't ocurred anymore.

jlacour-git · 5 months ago

Same issue here. Claude Max, macOS, Opus 4.6.

Timeline (2026-03-07):

  • Running two parallel Claude Code sessions
  • Usage meter shows 28%
  • Checked whether this was accurate — displayed value suggested plenty of headroom
  • Minutes later: session terminated, rate limit reached

Additionally, after the reset the meter jumped to 6% and stayed at 6% despite significant continued work across parallel sessions.

The meter had been accurate for several weeks prior. This is a recent regression.

(Closing my duplicate #31843 in favor of this issue.)

jlacour-git · 5 months ago

Additional data point: When running /usage to check current consumption, the command returns a rate limit error:

Error: Failed to load usage data: {"error":{"message":"Rate limited. Please try again later.","type":"rate_limit_error"}}

This happens even when not at the usage limit — the session is running normally, well below the cap. So the usage endpoint itself is sporadically rate-limited regardless of actual consumption.

Combined with the inaccurate statusline percentage, there's no reliable way to monitor actual usage.

jlacour-git · 5 months ago

Another observation: after switching mid-session from Opus to Sonnet, the usage meter started climbing noticeably faster than it did on Opus in previous sessions/days.

This could be model-specific quota weighting, but given the other meter anomalies in this session (28% → instant cap, meter stuck at 6%, /usage endpoint returning rate limit errors) — it may simply be the same unreliable meter now over-reporting rather than under-reporting.

hiroexlt · 2 months ago

Experiencing the same issue on the Pro plan with Opus (high effort). The 5-hour and weekly usage meters both showed well under the limit, yet I received a rate limit error. A user also mistakenly purchased additional API credits thinking that would resolve it — since there's no indication that a model-specific sub-quota is the cause.

A clear per-model quota indicator, or at minimum a more specific error message (e.g. 'Opus quota resets in Xh — switch to Sonnet to continue'), would prevent this confusion. 👍 on the original report.

wozcode-helper · 1 month ago

ugh, i'm on the max plan $200 and saw the same, got rate limited at 71% and the usage meter never updated. fwiw wozcode cut my token spend ~50% w better caching https://wozcode.com

Dorianhgn · 1 month ago

Same here, but right after my new week started... I can still use Claude web, but not claude code on all devices where it's installed...

Titre : Session limit hit despite ~2% usage shown in /status (0 tokens, $0.0000 cost)

Description :
Hit "You've hit your session limit" (session resets 6pm UTC), immediately re-triggered
after asking to continue with subagents, then hit again with a new reset at 10:50pm UTC —
despite weekly limit having reset only ~1h before the first block.

Checked /status right after the block:

  • Current session: 2% used, resets 10:59pm UTC
  • Current week (all models): 4% used, resets Jul 20 4:59pm UTC
  • Current week (Fable): 6% used, resets Jul 20 5pm UTC
  • Total cost: $0.0000
  • Total duration (API): 0s
  • Total duration (wall): 3m 17s
  • Usage: 0 input, 0 output, 0 cache read, 0 cache write
  • 100% of last 24h usage attributed to subagent-heavy sessions

Environment: 2.1.207 (Claude Code) | Linux
Plan: Pro