[BUG] Transient server errors MUST NOT kill subagents

this is a real pain point. A couple of things worth checking before this gets triaged further:

You're on v2.1.165. Several relevant fixes landed after that:

• v2.1.199 added an explicit Agent terminated early due to an API error message instead of silently returning the API error text to the main agent as if it were the subagent's actual result which sounds like exactly the "wrongfully shown as Completed" issue described above.
• There's now a documented resume-subagents mechanism for exactly this case (see the Claude Code docs' sub-agents page, "Resume subagents" and "API errors in subagents" sections).
• A rate limit/overload/server error interrupting a foreground subagent that already produced output now preserves that output marked "incomplete" instead of discarding the tokens spent.
• CLAUDE_CODE_RETRY_WATCHDOG=1 retries 429/529 indefinitely instead of killing the turn.

Could you retest on the latest version (2.1.226) and see if the core "deleted + shown as Completed" behavior still reproduces? If it does, that's a real bug in current versions. If it doesn't, this issue is likely stale and the remaining ask is narrower: a hotkey to revive all paused subagents with a staggered 10s delay between each, and confirmation of whether background (nonforeground) subagents get the same resume path as foreground ones the docs I found don't fully spell that out.

Thanks for the detailed writeup. I tried to reproduce this on 2.1.233 (Linux) by pointing the CLI at a local endpoint that returned 529 Overloaded only for a background subagent's requests, while the main agent kept working normally.

What I saw on 2.1.233:

• The subagent retries the overload with backoff (~11 attempts here) and then stops. So yes — a sustained transient server error does end the agent.
• It is not reported as completed. Its status becomes failed, and both the task entry and the notification the main agent receives carry the reason ("Agent terminated early due to an API error: API Error: 529 Overloaded…"). That part of what you saw on 2.1.165 no longer happens.
• Work is not lost. The stopped agent can be resumed, and on resume it continues with its full prior context — the tool calls and results from before the error were still there — rather than starting from scratch.

What's still missing is what you're actually asking for: it doesn't pause and resume itself once the API recovers, error-stopped agents drop off the active list, and there's no single "revive everything that stopped" action. Your point about spacing revives out so they don't immediately re-trip the rate limit is a good one.

Keeping this open as a feature request for automatic resume-after-recovery and a staggered revive-all.

🤖 Generated with Claude Code

Adding field data on the retry-budget question from @bcherny's repro, since I hit this hard over the last 24h on a real workload rather than a synthetic endpoint.

Setup: Max plan, Claude Code 2.1.217→2.1.229 via the Claude Desktop app, macOS. Orchestrator session that fans work out to subagents and merges the results.

Counts, extracted from my session transcripts (~/.claude/projects/**/*.jsonl, matching the structured api_error / isApiErrorMessage records rather than raw string grep, which false-positives badly on token counts):

• 91 × 529 Overloaded total; 83 of them on 2026-08-18 alone. First one 2026-08-17 23:07 UTC, most recent 2026-08-18 17:50 UTC.
• Zero 529s in the preceding 40 days of logs, so this is a capacity episode, not my steady state.

The part relevant to "does the retry budget hold": these don't arrive as isolated blips, they arrive as sustained walls.

| Window (UTC) | Duration | 529s |
|---|---|---|
| 2026-08-17 23:07:22–23:07:36 | 14 s | 5 |
| 2026-08-18 16:18:34–16:32:55 | 14 min 21 s | 18 |
| 2026-08-18 17:11:27–17:16:01 | 4 min 34 s | 10 |

So a ~11-attempt exponential backoff — which is a perfectly reasonable budget against a blip — gets exhausted well inside a 14-minute overload window. The behaviour you reproduced isn't an edge case; it's the normal shape of a real capacity event. Any bounded-attempt strategy that doesn't outlast ~15 minutes will keep killing subagents in production even though it passes a short-outage test.

Why the wasted-token framing understates it. The original report is about burning 200k–500k re-running subagents, which is real. But the worse cost is structural: when the orchestrator turn dies, every subagent result behind it is stranded un-merged. The lanes did the work, and there's no surviving place to reconcile it from, so the whole pipeline stalls rather than one agent restarting. I lost most of a working day to this on billable client work, and the workaround — escalating to a larger model just to get a turn to complete — consumes plan limits faster, so the outage compounds into a quota problem.

Two smaller observations that may help triage:

• Retries are firing — retryAttempt / retryInMs are present in the transcript records — so this is budget exhaustion, not missing retry logic.
• The 529 bursts correlate with a spike in ECONNRESET / connection-dropped events (~140 across the same two days, vs. a normal baseline near zero). I can't prove those are server-side, so treat it as correlation only, but they cluster in the same minutes.

Anthropic's own support widget was displaying "Degraded performance for multiple models" (updated 2026-08-18 17:12 UTC), which falls inside the third burst above, so the capacity event itself is acknowledged. Filing here strictly about the client-side survival behaviour.

Anyone wanting to contribute their own numbers to this thread:

grep -rhoE '"apiErrorStatus":529|529 Overloaded' ~/.claude/projects --include='*.jsonl' | wc -l

Happy to share the full timestamp list or redacted transcript records if useful for the repro.

I can confirm that on version Claude Code v2.1.234 the bug still exists