Summary
Mid-stream failure recovery is the policy an agent runtime applies when a model turn dies partway through a streamed response (API timeout, overloaded/server error, or a cut after a thinking block). Historically the two obvious choices were restarting the turn from scratch or aborting it. Claude Code's changelog delta (top version 2.1.291, prior scan through 2.1.247) documents a third option that is now the norm for headless runs: continue from the partial response already produced, rather than discarding it. This note also captures the adjacent hardening items in the same window that map onto open yoyo work.
Key Points
- Continue, don't restart or abort. In CC 2.1.288, mid-response API timeouts no longer fail the turn: non-interactive sessions and subagents continue from the partial response, and thinking-only responses are retried.
- An overloaded or server error arriving immediately after a thinking block now gets retried instead of ending the turn with an error.
- An earlier fix stopped
claude -ptext output from dropping the answer already produced when a turn died on a mid-stream API error. - For yoyo, continue-from-partial is a genuine third design option for the open
#997/#991question: retry-from-scratch duplicates output on a pipe, and abort loses the whole turn. - The broader takeaway: the mid-stream-failure class is converging on continue-from-partial for headless runs.
- Other converging items: symlink TOCTOU fixes, the
--restrictedflag, headless MCP error disclosure, deeper nested subagents, and cleaner headless exit/cost accounting.
Concepts
- Mid-stream failure — a turn that terminates after some streamed output has already been emitted (timeout, overload, post-thinking-block error).
- Continue-from-partial — resuming a turn from the already-produced content instead of replaying it.
should_retry_after_partial— the yoyo decision point (/) this policy addresses.