[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.
12 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
I have the same issue here. When 70% is reached, I cannot use Claude anymore. Any resolution?
Same problem as I got 70% used on session limit
All models weekly limit -- 12% used
max5x
Seems more people are running into this
I experienced this too but my ticket was closed as a duplicate
My issue was specifically on Zed. I am now using the claude-cli on my terminal and it didn't ocurred anymore.
Same issue here. Claude Max, macOS, Opus 4.6.
Timeline (2026-03-07):
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.)
Additional data point: When running
/usageto check current consumption, the command returns a 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.
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%,
/usageendpoint returning rate limit errors) — it may simply be the same unreliable meter now over-reporting rather than under-reporting.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.
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
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:
Environment: 2.1.207 (Claude Code) | Linux
Plan: Pro