[BUG] Parallel Claude Code sessions started right after 5-hour limit resets — first 3–4 work, the rest fail with "Server is temporarily limiting requests (not your usage limit) · Rate limited"

Preflight Checklist

• [x] I have searched existing issues and this specific scenario hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.119)

What's Wrong?

When my 5-hour usage window resets and I resume work by bulk-spawning ~10
Claude Code sessions back-to-back via a script (each running in its own
terminal / git worktree for parallel spec implementation), the first 3–4
sessions start normally, but the next 5–6 sessions fail almost immediately
with:

API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited

The error message itself states it is not the user's usage limit — yet it
consistently triggers only on the later sessions of a rapid-fire parallel
launch right after a quota reset. Waiting and retrying the failed sessions
individually eventually succeeds, which strongly suggests a server-side
concurrency/burst limiter that activates aggressively when many sessions
bootstrap simultaneously.

This is reproducible nearly every single time I follow my normal workflow
(a single command that fans out parallel spec implementation across multiple
worktrees), so this isn't a one-off transient.

What Should Happen?

Either:

1. All sessions should be admitted (the message claims it's not a usage-limit

issue), or

1. The CLI should transparently back off and retry the bootstrap requests

with jitter instead of surfacing a hard error to the user, or

1. The error message should clearly state that this is a concurrency/burst

limit and document how many parallel session bootstraps are supported per
unit of time.

Steps to Reproduce

1. Hit the 5-hour usage limit and wait for it to reset.
2. Run a script / wrapper command that spawns ~10 \claude\ processes in rapid

succession across separate working directories (git worktrees in my case).

1. Observe: the first 3–4 sessions initialize and work normally.
2. The next 5–6 sessions return

\API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited\
shortly after startup or on their first prompt.

1. Retrying the failed sessions one-by-one with a delay eventually succeeds.

Error Messages/Logs

\\\
API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited
\\\

Claude Model

Opus 4.7 (claude-opus-4-7, 1M context) — same behavior also observed when
mixed with Sonnet sessions.

Is this a regression?

Not sure — this pattern has been happening for several weeks across multiple
Claude Code versions on the same plan.

Claude Code Version

2.1.119

Platform

Claude Max plan (OAuth, not direct API key)

Operating System

Linux (Ubuntu 22.04, kernel 6.8.0-110-generic)

Terminal/Shell

bash, multiple GNOME Terminal windows launched by a single fan-out command

Additional Information

• The defining trigger is **(a) right after a 5-hour reset, (b) on Linux,

(c) bulk-spawning ~10 sessions back-to-back from a single command, where
the later 5–6 reliably fail while the first 3–4 succeed**.

• Related but distinct: #37436 (Windows, MAX100, multi-session quota

consumption), #40273 (rate limiter when spawning >1 agent), #44481 (Agent
Teams 429/529 with concurrent teammates), #53915 / #53531 (same error
message but different trigger). Filing separately because the existing
issues either don't reproduce on Linux or describe a different trigger.

• This is mildly disruptive rather than fully blocking — failed sessions can

be retried after a delay — but it consistently breaks the "fan out to ~10
parallel worktrees right after a reset" workflow that I rely on for
parallel spec implementation.

• Suggested mitigation on the CLI side: stagger session bootstrap requests

with backoff+jitter, or detect this specific server response and queue the
retry transparently instead of failing the session.