[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"

[NowatariSoma]

Preflight Checklist

• I have searched existing issues and this specific scenario hasn't been reported yet
• This is a single bug report
• 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
2. The CLI should transparently back off and retry the bootstrap requests
   with jitter instead of surfacing a hard error to the user, or
3. 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).
3. Observe: the first 3–4 sessions initialize and work normally.
4. 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.
5. 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: [BUG] MAX100 subscription - abnormal quota consumption and rate_limit_error with multi-session Claude Code #37436 (Windows, MAX100, multi-session quota
  consumption), [BUG] Rate limiter not functioning correctly "API Error: Rate limit reached" when spawning more that one agent #40273 (rate limiter when spawning >1 agent), Agent Teams: 429/529 API errors on Max plan with concurrent teammates #44481 (Agent
  Teams 429/529 with concurrent teammates), [BUG] API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited #53915 / [BUG]  API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited on every request #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.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Rate limiter not functioning correctly "API Error: Rate limit reached" when spawning more that one agent #40273
2. Agent Teams: 429/529 API errors on Max plan with concurrent teammates #44481
3. [BUG] API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited #53915

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

[Manuelreyesbravo]

Concurrent Session Throttling on Max Plans — Architectural Analysis & Fix Proposal

Reproducing the same pattern reported in #53922, #46037, #38335, #41788, #54750, #8449. After eliminating every plausible client-side cause, the bottleneck is per-account concurrent-stream throttling that does not scale with the plan multiplier. Sharing evidence and concrete fixes.

---

Reproduction

Field	Value
Plan	Max 20x (recently upgraded from Max 5x)
Client	Claude Code 2.1.64 (claude-desktop 1.1.5749)
Model	claude-opus-4-7[1m]
OS	Linux Fedora 43

Behavior:

• Morning of upgrade to 20x: N parallel Opus sessions worked perfectly.
• Same afternoon onwards: launching 3–4 Opus sessions in parallel → only 1 advances; the others freeze indefinitely on "thinking" with no error surfaced.
• Sonnet 4.6 in the same parallel scenario works without issues.
• Mixing 1 Opus + 2–3 Sonnet works.
• Quota dashboard shows usage far below the cap throughout.

This matches #53922 verbatim ("first 3–4 work, the rest fail") and #46037 ("only 1 session works while quota is unused").

---

Evidence ruling out client / local causes

I rebuilt the local stack to eliminate every plausible client-side bottleneck before concluding it's server-side:

1. MCP server (118 tools): SQLite migrated to WAL + busy_timeout=30000, dispatch handlers wrapped with asyncio.to_thread for blocking ops. Local benchmark of 4 concurrent tool calls: 66ms → 62ms (1.07× speedup) — concurrency works at the MCP layer.
2. MCP transport: tested both stdio and Streamable HTTP via StreamableHTTPSessionManager. Both connect successfully ([LocalMcpServerManager] Connected to mimir (118 tools)). Not a transport issue.
3. Process layer: replaced uv run with direct .venv/bin/python3 to remove uv's global cache lock. Multi-PID lock file. No single-instance enforcement.
4. DB lock contention: 4 processes × 50 concurrent SQLite writes → 0.23s, 0 errors after WAL.
5. thinkingBudgetTokens: 1500 in ~/.claude/settings.json to minimize per-request thinking tokens.

After all of this: the freeze pattern is identical. The bottleneck is upstream of the client, at the API gateway level.

---

Diagnosis

The throttle:

• Triggers around the 3rd–4th concurrent session.
• Returns no visible error — sessions hang on "thinking" with no toast, no log entry, no Retry-After.
• Does not scale with plan tier (Max 5x and Max 20x show identical thresholds — this is the bug).
• Is independent of token / RPM quota ([Bug] Anthropic API Error: 429 Rate Limit with Multiple Parallel Sessions Below Usage Cap #46037 confirms users are far below their cap).
• Is also independent of MCP / model / network configuration (verified above).

Root cause: a per-account concurrent-stream cap that is decoupled from the plan multiplier and silently buffers (rather than rejects) requests once exceeded.

---

Proposed fixes (ordered by impact)

1. Tie concurrent-stream quota to plan multiplier (highest impact)

The Nx in Max Nx should grant N× concurrent streams against the Pro baseline, not just N× cumulative tokens. Today the concurrency cap appears constant across tiers, defeating the main reason power users upgrade from 5x to 20x.

Implementation sketch: at the rate-limiter (gateway), key the concurrent_streams bucket by (account_id, plan_tier) and read the multiplier from the same source as token quotas.

2. Surface throttling to the client (low cost, high UX)

Currently throttled sessions hang silently. Return a structured 429 with Retry-After and a clear error.type. Claude Code can then show "Rate-limited: queued, retrying in Xs" instead of an indistinguishable spinner.

Implementation sketch: the gateway already knows it's throttling; emit the error rather than buffering the request silently.

3. Client-side request queue with exponential backoff

Claude Code (CLI) should treat 429s on streaming requests as queueable, not fatal. A small per-process queue with (base_delay × 2^attempt) + jitter would keep sessions alive instead of freezing them, and surface queue position in the UI.

4. Burst allowance for session startup

Most freezes happen on the very first request of a new session (typical pattern: mimir_status / mimir_context calls launched all at once). A small burst credit (e.g. allow 4× steady-state RPM for the first 30s of a new session) would absorb the spike when N sessions launch within the same second.

5. Session affinity at the LB layer

If the throttle is per-edge-node rather than per-account globally, sticky sessions (account_id → consistent backend) would smooth bursts when many sessions launch simultaneously.

---

Reproducibility

Reliably triggers the issue in under 60 seconds on Max 20x:

# In four separate project folders, each in its own terminal:
claude --model claude-opus-4-7 -p "Read README.md and summarize"

Expected: 4 summaries return.
Actual: 1 returns; 3 hang for the remainder of the 5-hour session window with no error.

---

Why this matters for paying customers

The current behavior makes Max 20x effectively equivalent to Max 5x for parallel-workflow users (the exact cohort paying $200/month). The pricing page implies 20× capacity, but the binding constraint is concurrency — which doesn't scale. Fixing fix #1 alone would resolve most of the open issues listed below.

---

Related issues: #53922, #46037, #38335, #41788, #54750, #8449 — all describe the same throttle from different angles. Consolidating into a single concurrency-quota fix would close most of them.

Happy to provide additional telemetry, network-level captures, or test on a different machine if that helps triage.

[cnighswonger]

Adding an independent confirmation that this is account-scoped concurrency, not per-request-size:

We just hit "Server is temporarily limiting requests · Rate limited" on a cache-warmer ping — a request whose entire payload is on the order of 50 tokens (one read of a small status file, one-token output). No heavy concurrent traffic from our session at the time. We're on Max 20x with multiple Claude Code agents on a single account (which is the relevant load).

That request shape can't trip per-request quotas, weight, or model-specific limits. The only mechanism it can plausibly trip is exactly what @Manuelreyesbravo describes above: an account-scoped concurrent-stream cap saturated by other in-flight requests on the same account, regardless of their individual sizes.

Reinforces the architectural argument: the concurrency cap doesn't scale with plan tier, and the symptom shows up across the entire request size spectrum — from heavy multi-tool sessions down to ~50-token pings.

— Chris

[cnighswonger]

Follow-up with hard data from a 15-minute capture last night.

Inserted a logging tee between our cache-fix proxy and the upstream API to catch the next 429 in full HTTP fidelity. Captured 88 consecutive 429s between 2026-05-08 00:06:33 → 00:21:30 UTC. Several findings that sharpen the picture from your analysis:

1. "Silent hang" is actually retry-budget exhaustion. CC retries each rate-limited request 6+ times silently with exponential backoff (~0.86s → 1.4s → 2.2s → 3.8s → 6.9s → 8.4s spacing — textbook) before surfacing the error to the user. The visible "Server is temporarily limiting requests" message represents the final failure on a single logical request that already absorbed multiple silent retries. Reframes the user perception from "one API call failed" to "this entire request is exhausted."

2. The retry signal is x-should-retry: true in the response headers, not Retry-After. CC reads the boolean and infers backoff timing on its own.

3. Anthropic strips anthropic-ratelimit-* headers from error responses. Non-error responses include q5h_utilization, representative_claim, etc. — the 429 strips them. So even sophisticated clients can't see which limit was hit. This is a real observability gap.

4. Confirms account-wide concurrent stream diagnosis. The burst captured here started during a wake-from-idle moment (multiple agents resuming activity within seconds of each other). All requests came from one account, agents on the same host, varying session shapes. Burst occurred at 00:06 UTC — far outside any old-peak schedule. Matches your fix OAuth error on a new project #4 framing precisely.

Capture spans 88 × 429 / 1 × control / inter-arrival mean 10.3s / latency p95 882ms (gateway-level rejection, not deep-backend stalls).

— Chris