Auto-restarted session gets stuck on an exhausted default model; 89 min downtime, manual recovery required
Version: 2.1.219
What happens
A long-running session was operating on Opus 5. User settings held Fable 5 as the default model, and the Fable 5 usage limit was already exhausted. The CLI process exited and was automatically restarted. The restarted process issued its request under Fable 5, received a 429, and did not fall back to the model the session had been using. The session stalled, the remote connection dropped, and it only resumed after the user manually reconnected and changed the model — not on its own.
Timeline from one occurrence
Offsets from the last successful message:
| offset | event |
|---|---|
| T+0 | last successful assistant message (Opus 5) |
| T+3.5 min | automatic restart; two 429s, "You've reached your Fable 5 limit" |
| T+7.5 min | restart retried; two more 429s |
| T+87.5 min | two more 429s — still stuck, no progress in the interim |
| T+88.5 min | user updates the saved default to Opus 5 |
| T+89.4 min | session resumes; all subsequent messages Opus 5 |
Every successful assistant message on either side of the outage was Opus 5 — 482 consecutive, with Fable 5 appearing only in the failures.
Expected
A restarted session should issue its first request under the model the session was using. The documented behaviour for --resume, --continue and /resume is that a session keeps the model from its transcript regardless of the current model setting; the automatic-restart path appears to consult the saved default instead. Failing that, a 429 for a model the user did not select should surface a prompt or fall back, rather than leaving the session unable to proceed.
Impact
89 minutes of unattended downtime, and the recovery is non-obvious: the error names a model the user is not using and suggests /model, but the session is already on the right model — what actually has to change is the saved default.
The docs describe model restoration only for manual resume, so the crash-restart path isn't covered either way.
Request IDs available privately if useful.