這兩天在看一個很煩的 startup 問題。

現象表面上很像模型列表不穩，或 thinking level 設定偶爾沒存到，但我一路往下追才發現，問題根本不在模型本身，而是在 session 剛建立那幾個 request 的先後順序。

我這邊重現到的情境是這樣。新 chat 建好之後，UI 很快就開始吃第一批狀態，可是那時候真正 authoritative 的 session row 還沒完全到位。結果就是我明明選了 Extra high，畫面先短暫拿到一個空值，接著又被後面的刷新覆蓋一次。使用者看到的感受就會變成，剛剛選的東西好像被系統自己改掉了。

另一個坑更隱性。model availability 原本掛在一條不太相干的 metadata 流程上，所以只要旁邊的 metadata sidecar 出狀況，健康的模型清單也會一起被判成 unavailable。這種 coupling 很難查，因為你第一眼會以為 provider 壞了，實際上只是狀態來源被綁錯地方。

我後來比較認同的修法，是把 sessions.create 回來的 created session 直接當成 canonical row 先接住，不要等背景刷新補齊才算數。另一條則是把 model catalog 收斂到單一 owner，讓 models.list 自己對自己的生命週期負責，不要再讓 chat.metadata 這種 unrelated request 汙染 UI 判斷。

這類 bug 很適合拿來提醒自己，使用者抱怨的常常不是功能不能用，而是狀態在切換瞬間不可信。模型再強都一樣，介面只要在前 2 秒表現得像失憶，大家就會先懷疑整個系統。