[BUG] Server-side rate limits break parallel agent workflows — request transparent auto-retry
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Summary
On the Max plan running parallel multi-Agent workflows, Claude Code repeatedly surfaces server-side rate-limit errors as terminal failures instead of retrying them transparently. This breaks AFK runs and forces manual re-dispatch of up to 7 threads per incident.
Error
API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited
Note the error explicitly states this is NOT a usage-limit issue — it's Anthropic-side capacity throttling, distinct from the plan quota.
Repro
- Dispatch N concurrent
Agenttool calls in a single message (parallel multi-thread workflow). - During peak load periods, a subset of agents fail immediately with the above error.
- Failed agents do not auto-retry — they terminate, losing whatever work was queued.
Hit this three times in ~12 hours across 2026-05-18 evening and 2026-05-19 (Windows, Max plan, 8-thread parallel dispatch pattern).
Impact
- AFK runs lose work silently. When throttle fires while away, the user returns to dead threads with no recovery.
- Manual re-dispatch is high-friction. Re-firing 7+ Agent calls per incident defeats the purpose of parallel orchestration.
- The error UX is misleading. "Rate limited" reads like a quota issue even though the message says otherwise; users on Max reasonably expect their plan to cover bursty workloads.
Requested behavior
Claude Code should auto-retry server-side (non-quota) rate-limit responses transparently with exponential backoff before surfacing a terminal error. The retry behavior should:
- Distinguish server-side throttles (transient, retryable) from account-quota limits (not retryable in-session).
- Use exponential backoff with jitter, capped at a sane ceiling (~60s).
- Apply per-agent so one throttled call doesn't block sibling agents.
- Surface a single user-visible error only after retries are exhausted.
Environment
- Plan: Max
- Platform: Windows
- Workflow: Multi-agent parallel dispatch (8 concurrent Agent calls typical)
- Dates observed: 2026-05-18, 2026-05-19
What Should Happen?
Please fix it
Error Messages/Logs
Steps to Reproduce
Work on several threads in parallel.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
4.7
Platform
Other
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
Thanks for your attention to this matter.
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Mapping this back to a coordinator perspective — the part that's load-bearing is the distinction the error message itself draws ("Server is temporarily limiting requests (not your usage limit)") and treating that distinction as a first-class scheduling primitive, not a UX nuance.
Three patterns that have worked when the platform doesn't auto-retry transparent-throttles:
Agentcall in a coordinator that owns the retry decision, not the agent. Server-side throttle = transient → exponential backoff with jitter, capped ~30–60s, retry budget per agent (e.g. 5). Account-quota = terminal → escalate up to the orchestrator immediately so it can decide whether to pause the whole fan-out or proceed with the partial set. The two error classes look similar in text but have opposite correct responses, so they cannot share a code path.retry_pendingand keep the work envelope intact — samecycle_id, same input — so the re-dispatch is idempotent. Treating a throttle as terminal "loses work silently" exactly because the work envelope is GC'd before the retry decision is made.The AFK-runs-lose-work-silently failure mode you're describing is the canonical reason orchestration state needs to live outside the agent loop — once the lifetime of "the work" outlives the lifetime of "this CLI invocation," in-process retry logic is structurally insufficient. Worth filing under feature-parity rather than just bug if you want the Anthropic team to take it seriously: "non-quota throttles must not be terminal at the SDK layer."
Workflow/ultracode is super unreliable and unusable. It even proceeds with the flow when half of the agents receive stream error and similar. Just poor quality solution which just burns tokens for fun 🙃
Same here, fully reproducible. Max 20x, Claude Code via the desktop app — every dynamic-workflow / agent-teams ("ultracode") fan-out hits:
at just 2–5 parallel subagents, while my usage page reads 6% session / 5% weekly / 0% Sonnet — so it's clearly the infrastructure request-rate / concurrency ceiling, not the plan budget (the error explicitly says so).
The painful part: dynamic workflows are demoed (Anthropic's own Opus 4.8 launch + countless YouTube/Instagram demos) spawning 50–60 parallel sub-agents, but on Max that's unusable — throttled at a handful. I verified it's not a local misconfig: direct
https://api.anthropic.com, OAuth (no API key override), no local proxy in the request path.Same symptom as #62426 (auto-closed as duplicate), #53922, and #40273 (closed not planned). Requests:
yeah this sucks, server side throttles on the max plan are killing 8 thread parallel agent runs so afk workflows just lose work. claude code should auto retry transient rate limits per agent with exponential backoff and jitter before giving a terminal error, tbh wozcode cut my token spend ~50% with better caching https://wozcode.com