A usage limit is not an outage - why three retries hit the same wallConcept

On 9-11 plan-day retried three times against a Fable usage cap and lost the morning. Retry cures blips; a cap needs a different model. The nightly wrapper got that fix on 9-13; plan-day and the weekly review have not.

A retry loop assumes the failure is transient: a dropped connection, a busy server, a DNS hiccup. Wait a bit, try again, the world has probably changed. run_plan_day.sh's run_with_retry does exactly this, and it was built for ConnectionRefused (August), where it earned its keep.

A usage limit is not transient. It is a state: 'this account has spent its Fable budget for this window'. The window clears on the clock, not on your next attempt, so attempts 2 and 3 are guaranteed to hit the same wall - which is why they died in two seconds. The honest response to a cap is not retry but degrade: run the same job on a model that still has budget. Claude Code has a flag for this in headless mode: --fallback-model, 'automatic fallback to specified model(s) when the default model is overloaded or not available', accepting a comma-separated chain.

Where this stands in your fleet: JobHunt/scripts/nightly_wrapper.sh was pinned on 9-13 (--model fable --fallback-model sonnet,haiku) as the 9-11 post-mortem. PDB/scripts/run_plan_day.sh and run_weekly_review.sh pass no --model at all, which means they inherit whatever the CLI default was last set to - a /model change in an interactive session silently re-aims the morning cron. One open question the nightly pin will answer: whether a usage-limit refusal counts as 'not available' to the fallback logic. The first capped night will tell; until then D2 on the 9-13 paper asks whether to pin the other two wrappers the same way.

Worked example

See which wrappers carry a model pin, then read the 9-11 failure with timestamps.

grep -n -- '--model\|--fallback-model' \
  /Users/tom/Claude/PDB/scripts/run_plan_day.sh \
  /Users/tom/Claude/PDB/scripts/run_weekly_review.sh \
  /Users/tom/Claude/JobHunt/scripts/nightly_wrapper.sh

grep -n 'Fable limit\|attempt [0-9]/3\|attempt [0-9] failed' \
  /Users/tom/Claude/PDB/logs/plan-day.log | tail -8

• The first grep prints only the nightly wrapper's line 85 - the other two files have no model flags at all. That absence is the finding.
• The second grep shows the 9-11 block: attempt 1 at 06:17, failure at 06:39; attempt 2 at 06:39:58, failure at 06:40:00. A 2-second failure after a 22-minute one is the signature of a state, not a blip.

Gotchas

• --fallback-model only works with -p (headless print mode). That is fine here; every wrapper uses -p.
• A sonnet fallback day will read differently: shorter brief, plainer lesson. That is the point - a degraded brief beats the data-only page.
• Do not put the pin in ~/.claude/settings.json to cover all three at once: that re-aims your interactive sessions too. Wrapper flags stay per-job.
• The Headless Hardening proposal (on the device since 9-11) edits the same wrapper lines for a different reason (permissions). If you ink both, the edits land together; neither depends on the other.