Retries handle blips; fallbacks handle outages. On Aug 6 your plan-day retried the same failing call three times over two hours and produced nothing — a fallback chain would have saved the morning.
Aug 6 is the only weekday this week with no plan on PDB.zorc.app. The log shows the runner doing exactly what it was told: three attempts, each killed by 'Connection closed mid-response'. The retry logic you shipped Jul 26 worked perfectly — and couldn't help, because all three attempts hit the same failing resource.
A retry says: same action, a bit later. It wins when the fault is transient — a dropped packet, a momentary rate limit, a server hiccup. A fallback says: different resource entirely. It wins when the fault is systemic — the model endpoint itself is degraded, and no amount of waiting fixes it from your side.
The failure mode on Aug 6 was systemic: 'Connection closed mid-response' three times across two hours isn't a blip, it's a degraded endpoint. Your wrapper's network-wait even confirmed the network was fine between attempts ('network ready') — the fault was on the far side. Retrying the same model was three tosses of the same rigged coin.
Claude Code's headless mode has a built-in answer: `--fallback-model` tells `claude -p` to switch models when the primary is overloaded or unavailable. You accepted this on Jun 9. It has now appeared in this curriculum on Jun 17, Jun 30, Jul 31 — and today, with the freshest corpse yet.
The Aug 6 postmortem, straight from your own log:
grep -A1 'plan-day attempt' /Users/tom/Claude/PDB/logs/plan-day.log | grep -E 'attempt|failed' | tail -8
# What a hardened invocation looks like:
claude -p "/plan-day" --fallback-model claude-sonnet-5When three identical attempts fail identically, the fourth identical attempt is a prayer, not a strategy — give the runner a different door.