OpenAI 的開發工具 Codex 在一個早上出現服務中斷，發帖當時已經恢復。這則貼文出現在 V2EX 程式員討論區，標題直接點出真正的關注點：「重置大概率要來一個吧」。對一般使用者來說，服務掛了等修好就好；對 Codex 的訂閱使用者來說，當機之後真正等的，是額度重置。
額度制把當機變成了帳目問題
Codex 的訂閱採額度制，使用者每月或每週獲得一定的使用額度，用完就要等下一次「重置」才能繼續。這個機制像手機資費：流量用罄，你得等週期歸零，或另外加購。當服務當機，問題就從「我不能用」變成「我付了錢的額度，在你壞掉的時間裡白白蒸發」。這也是為什麼原 po 特別提到，前幾週有一次故障，最後並沒有給補償，這次如果再沒有動作，「說不過去」。
貼文後續的討論證實了這個預期。有網友指出 OpenAI 的 Tibo 已確認會進行重置，但沒有公布具體時間，只說應該在當天以內。同時有使用者抱怨自己的額度已經歸零，只能「乾等著重置」。
有趣的是重置時間點的爭議。有網友認為當天本來就是例行重置日，「今天重置沒什麼意思」；原 po 則回應自己的自然重置日是 30 號，但觀察到很多人的額度都在當天被重置了。換句話說，補償性重置和例行重置混在一起，使用者很難分清楚自己拿到的是補償，還是本來就屬於自己的週期歸零。這種模糊性，是訂閱服務處理故障補償時最常見的信任裂縫。
使用者自己動手蓋了監測站
討論串裡最值得注意的現象，是社羣自建的監測基礎設施。有人分享了 didcodexreset.com 這個網站，可以查詢重置的「排期」與「已完成」狀態，並提供被動的郵件與瀏覽器通知。另一位網友也用自己架的監控服務回報狀態，中間還發生一段小插曲：監測結果一度誤判「已完成重置」，經原 po 指正後，當事人表示是 AI 判斷不穩定，刪掉重跑才準確。
官方不公布明確時間，使用者就自己建工具被動守著。這個畫面對熟悉開發者社羣的人不陌生：當服務的關鍵資訊（額度何時歸零、補償何時發放）不透明，使用者會用自己的工具補上缺口。工具本身甚至也開始依賴 AI 判讀，然後出現 AI 誤判、人工重跑的循環，算是這波 AI 工具熱的另一個縮影。
品質問題和額度問題疊在一起
討論串後半段，話題從「何時重置」轉向「重置之外的事」。有人當場宣布改用 Claude，稱讚 Opus 5.5；也有人認為與其給重置，不如直接把額度上限提高，「比什麼重置都實在」。
還有使用者回報，當天即使額度重置了、開到了付費的高速模式，回應品質依然明顯下滑，「平時不會犯的錯今天頻發」，懷疑自己被路由到了其他模型。另一人附和說開到最高檔位「還是很傻」。這類說法屬於個別使用者的主觀體感，目前沒有官方證實，但它反映了一個結構性疑慮：當服務商在高負載或故障後降級服務，使用者手上沒有任何儀表板可以核對，只能憑感覺猜。
所以呢
對訂閱制 AI 工具的使用者來說，這則討論提供了幾個實際的判斷點。第一，額度制的服務當機時，該追問的是補償方案，而不只是修復時間；第二，例行重置和補償重置若混在同一週期，最好記下自己的自然重置日，才分得清拿到的是什麼；第三，社羣自建的狀態監測網站在這類事件中已經是標配配備，值得先收進書籤。
對服務商來說，教訓更簡單：故障補償的透明度，直接決定使用者把當機記成「一次事故」還是「一筆爛帳」。不講清楚是補償還是例行歸零，使用者自然會自己蓋工具、自己下結論。
主題