[Bug] HTTP 529 overloaded_error is rendered as "Rate limited" and hard-fails parallel sessions/subagents (no backoff, not logged to errors)

[awaliuddin]

Summary

Running multiple Claude Code sessions in parallel — especially when any run parallel subagents (Task tool / workflows) — repeatedly fails with:

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

The underlying error is actually an HTTP 529 overloaded_error (Anthropic server overload), not a 429 account rate-limit. Three issues:

1. Misleading label — a 529 overloaded_error ("Overloaded") is shown as "Rate limited," implying an account rate-limit when it's actually a server-overload condition.
2. Hard fail, no backoff — the affected operation/subagent dies instead of retrying with backoff, losing in-flight work mid-task.
3. Not captured in telemetry — the /bug errors array is empty ([]); the 529 is logged only as rendered UI text, with no structured type/status/request_id, making it hard to diagnose.

Environment

• Claude Code version: 2.1.176
• Platform: Linux (WSL2) on Windows 11
• Terminal: tmux
• Scale at failure: ~5–10+ parallel Claude Code sessions, several running parallel subagent workflows (Task-tool fan-out)
• Feedback ID: f08c8334-c407-47d4-a28d-2c4f0a940ef8

Steps to Reproduce

1. Run 5–10 claude sessions in parallel (separate tmux panes), all actively working.
2. Have one or more launch a parallel-subagent workflow (Task-tool fan-out of ~6+ agents).
3. Under sustained concurrent load, the error fires (Server is temporarily limiting requests (not your usage limit) · Rate limited), and parallel subagents/operations die rather than retry.

Expected Behavior

529/overload (and rate-limit) responses should be retried with adaptive backoff, and parallel sessions + subagent fan-out should degrade gracefully (client-side request queue + optional concurrency cap) instead of hard-failing and losing work. The message should also be labeled accurately (overloaded vs rate-limited), and the error recorded in the structured errors log.

Actual Behavior

• Hard failure on 529 overloaded_error; the operation/subagent aborts with no retry.
• In multi-agent workflows, the fan-out / aggregation steps fail first (parallel subagents multiply concurrent requests).
• Transient and effectively account-wide — it blocks unrelated sessions (including on other machines), clears after a cooldown, then recurs under sustained parallel load.
• Shown in the UI but not written to the errors buffer → /bug reports errors: [].

The real error (from session transcripts)

When captured structurally, the response is consistently:

{"type":"error","error":{"type":"overloaded_error","message":"Overloaded"},"http_status":529}

171/171 structured occurrences were 529 overloaded_error. Today's occurrences were logged as UI text only (no structured type/status/request_id) — hence the empty errors array. A live request_id can be captured with claude --debug.

Suggested Fix

1. Retry 529 overloaded_error with adaptive backoff instead of hard-failing.
2. Client-side request queue + configurable concurrency cap (e.g. maxConcurrentRequests) so parallel sessions/subagents throttle gracefully.
3. Label accurately — distinguish overloaded_error (529) from rate_limit_error (429) in the UI message.
4. Log the error structurally to the errors buffer so /bug captures it (currently text-only).

Errors

["type":"error","error":{"type":"overloaded_error","message":"Overloaded"},"http_status":529]

Note

• Created by Opus 4.8 / Validate by Human @awaliuddin

[yush-1018]

i want to work on this !

[awaliuddin]

I did a little more digging.. and the agent sprawl was closer to 20+ 🙃 Is there a hard cap?