[Bug] Subagent killed by 529 Overloaded loses all work — no partial result, full relaunch required

Bug Description

When a background subagent dies with API Error: 529 Overloaded, the parent gets no salvageable partial result — the task is reported failed and the only way forward is to relaunch the whole thing from zero. The second run repeats all the work the first one had already done and paid for.

What happens

Verbatim, as surfaced to the parent session:

Agent terminated early due to an API error: API Error: 529 Overloaded.
This is a server-side issue, usually temporary — try again in a moment.

The notification arrives with status: failed and no usable output. Whatever the subagent had already completed is gone from the parent's point of view.

Why this is worth fixing beyond "529s happen"

A 529 is a server-side capacity signal and will happen. The defect here is the blast radius: a transient upstream error costs the entire task, not the remaining part of it.

In one afternoon on one machine:

• 3 subagents killed by 529 in a single session. One had completed 5 of 7 verification steps before dying; none of that was recoverable.
• 6 consecutive 529s reported by a parallel session on the same machine, same hour.
• 1 additional loss to the 600s stall watchdog (see #85265), same "relaunch from scratch" consequence.

Net result: three paid runs to obtain one result.

Environment

• Claude Code on macOS, Darwin 25.5.0
• Model: Opus 5 (claude-opus-5)
• Date: 2026-08-24, intermittent, several sessions within the same hour
• Paid plan (Max)

Steps to reproduce

1. Launch a background subagent via the Agent tool with a multi-step task (a 5–7 item verification prompt reproduced it reliably here).
2. Wait for the upstream to return 529 mid-run.
3. Observe: task reported failed, no partial output available to the parent.

Suggested fixes, in order of value

1. Surface partial work on abort. If the subagent had streamed anything before the 529, hand it to the parent instead of discarding the task. This alone turns a total loss into a partial one.
2. Retry the subagent transparently on 529, with backoff, before declaring the task failed — the error message itself says "usually temporary", but nothing retries.
3. Checkpoint multi-step subagent tasks so a relaunch can resume rather than restart.

Note: I asked support about billing on these and was told partial output is normally kept and charged proportionally. That is not what the parent session observes — the task comes back failed with nothing usable, which is what makes the relaunch a full repeat.

Related: #85265 (stall watchdog at 600s) — different trigger, same failure mode and same "relaunch from zero" cost.