負責 Codex 與 ChatGPT 相關工作的 OpenAI 人員 Tibo Sottiaux 在 2026 年 8 月 24 日於 X 表示，所有付費 Codex／ChatGPT Work 帳號已套用 full reset，前一天發現的部分 usage 問題也已修正。這次不是週末用量沒有被計算，而是原本累積的消耗在全體重置後被新的額度狀態覆蓋，所以畫面看起來像整段用量消失。
這次全體重置也和 8 月 21 日發放的 banked reset 不同。前者隨 usage 修正直接套用到所有付費帳號；後者是慶祝 2,000 萬活躍使用者的福利，可以留到需要時再手動使用。OpenAI 沒有公開說明這次為何不再發一張 banked reset，但從兩種機制的差別，可以推測這次處置優先考慮立即恢復所有帳號。
Codex 與 ChatGPT Work 的共用額度是什麼
Codex 是 OpenAI 的程式開發 Agent，可以讀取 repository、修改程式、執行指令與測試；ChatGPT Work 則把相同的 Agent 工作方式帶到一般任務，用來整理資料、操作工具並交付文件、簡報或分析結果。兩者面向的工作不同，但都會代表使用者執行多步驟任務。
OpenAI 的 pricing 文件 寫明，ChatGPT Work 與 Codex 共用 pricing、credits 和 usage limits。換句話說，在 Work 跑長任務與在 Codex 處理程式，都會消耗同一個 ChatGPT 方案額度池。這也是這次公告會同時點名兩個產品的原因。
這套方案內含額度和 OpenAI API Platform 的 token 帳單是兩套系統。這次公開處置針對付費 ChatGPT 訂閱的 Codex／Work usage，沒有公告回補 API 帳單或調整 API rate limit。
Sottiaux 公開問題前，論壇已出現哪些異常回報
Sottiaux 公開三項 usage 問題前，Reddit 的 r/codex 與 OpenAI Developer Community 已連續出現額度消耗異常的討論。這些貼文不是 OpenAI 的統計，也無法證明每個帳號遇到同一個問題，但回報時間和症狀可以補足事件背景。
| 日期與討論 | 使用者觀察 | 解讀限制 |
|---|---|---|
| 8 月 16 日，r/codex 額度討論 | 一名 20x 方案使用者表示，工作方式沒有明顯改變，但兩天後只剩 49%；約 100 個 turns 後降至 25% | 是使用者自述，沒有一致的模型、工具與任務條件 |
| 8 月 20 日，r/codex 單次消耗討論 | 發文者表示單一 prompt 消耗約 10% 週額度；留言另有人質疑不同模型顯示近似消耗 | 沒有完整 token 紀錄，不能據此判定計費率相同 |
| 8 月 21 日，r/codex 用量重建 | 一名 Pro 5x 使用者比對本機紀錄與 used_percent，推算有效週額度可能從約 18,000 credits 降至約 10,000，差距約 44% | 數字是使用者依公開 rate card 重建，不是 OpenAI 公布的方案上限 |
| 8 月 12～14 日，OpenAI Developer Community | 有人回報無任務期間仍出現大量消耗；另一名 20x 使用者稱兩次重置後只看到約 11,951 與 8,503 credits | 可能涉及背景工作、延遲記帳或帳號額度配置，未必等同處理效率問題 |
這些討論顯示，部分使用者在 Sottiaux 公開問題前已回報額度快速下降，也能解釋為什麼有人形容實際可用量不到過去一半。不過，這些回報混合了兩種現象：一種是額度池不變、但工作消耗速度變快；另一種是重置後疑似取得較小的額度池。Sottiaux 後續列出的 cache、圖片處理、Computer History 與標題生成問題，與第一種現象方向一致，可能解釋部分回報；但沒有資料能確認這些帳號各自受到哪項問題影響。OpenAI 也沒有正式證實付費方案的週額度上限被調降，或重置把帳號分配到錯誤方案。
8 月 23 日公開的三項 usage 問題
OpenAI 的 Tibo Sottiaux 先表示，部分帳號當週的 cache hit rate 低於前幾週穩定狀態；快取命中率降低時，相同工作需要重新處理更多上下文，因此可能讓方案額度消耗得更快。
8 月 23 日 06:11 UTC（台灣 14:11），Sottiaux 在 X 貼文 列出團隊發現的三項問題：
| 問題 | 發生情境 | 可能造成的結果 |
|---|---|---|
| 長對話的圖片處理效率 | 對話包含圖片，而且經過多次 compaction | 處理相同 session 時耗用更多資源 |
| Computer History 高分位用量 | 用量落在 p95 以上的高負載情境 | 少數重度情境的消耗明顯偏高 |
| 自動產生對話標題 | 系統在背景替 conversation 產生標題 | 這項輔助功能消耗的 usage 比預期更多 |
p95 可以理解成第 95 百分位，也就是排除前 95% 後的高用量尾端。Sottiaux 的貼文不是說所有 Computer History 使用者都被多扣，而是高分位情境需要處理。OpenAI 文件也確認 Computer History 會把電腦活動整理成記憶與時間線，產生摘要和記憶時本來就會使用 tokens；這次貼文指出的是尾端用量偏高。
三項問題都發生在 Codex／ChatGPT Work 的產品流程與輔助功能，不代表模型權重出了問題。官方目前也沒有公布每項問題影響多少帳號、額外消耗比例或完整技術根因，因此不能把個別帳號的用量落差直接歸因到其中某一項。
8 月 24 日的補救：修正並重置所有付費帳號
Sottiaux 在 8 月 23 日貼文中表示，團隊已經成立專責小組檢查 usage 流程，會在隔日部署修正，並對所有付費訂閱執行 full reset。8 月 24 日 00:46 UTC（台灣 08:46），他在 另一則 X 貼文 中表示重置已推送到帳號，前一天提到的部分修正也已上線。
這個動作會把帳號目前的方案內含額度恢復，因此週末已經用掉的比例會被新的狀態覆蓋。正確解讀是「用量先被計入，之後獲得全體重置」，不是系統漏算週末工作。貼文仍寫著後續會繼續改善，表示 8 月 24 日部署的是部分修正，不能解讀成所有 usage 效率工作已經完成。
為什麼這次不是 banked reset
OpenAI 沒有公開說明這次為什麼選擇直接 full reset，而不是把一張可自行決定時間的 banked reset 存進帳號。以下是根據兩種機制與事件處置做出的產品層推論，不是 OpenAI 已確認的內部決策理由。
過去有一個可供對照的先例。OpenAI 在 6 月 28 日處理另一波 usage 調查時，Sottiaux 曾在 貼文 中說明，當時改做 hard reset，是因為部分使用者手上已經累積最多三張可自行決定時間的 banked reset。這顯示 OpenAI 當時把兩種 reset 當成不同處置工具，但不能直接當成 8 月 24 日的公開理由。
事故補償需要立即生效
banked reset 需要使用者看到票券後主動兌換。如果異常已經讓部分帳號提早撞到上限，繼續等待或不知道要手動兌換，仍然無法使用 Codex。全體 full reset 可以在修正部署時直接恢復所有付費帳號，不依賴 App 版本、通知是否送達或個人操作。
多項效率問題很難逐筆還原
這次牽涉圖片、compaction、Computer History、標題生成與部分帳號的 cache hit rate，不同使用方式受到的影響並不一致。若要精確計算每個帳號「多消耗多少」，得重建每段 session 在正常效率下原本應該消耗的額度。直接回補整個額度池比較粗略，但能避免低估受影響帳號。
Work 與 Codex 共用額度池
同一個 usage pool 可能同時被 Codex、ChatGPT Work 與背景功能消耗。全體重置讓兩個產品入口一起回到一致狀態，不必判斷某一筆消耗究竟來自程式工作、一般 Work 任務，還是背景輔助功能。
banked reset 與 full reset 解決不同問題
8 月 21 日慶祝 2,000 萬活躍使用者時，OpenAI 發的是 banked reset，目的在於送一份可以延後使用的福利。8 月 24 日則是在修正異常後補回可能被提前消耗的額度，優先順序是讓所有付費帳號立即恢復。前者重視使用時機，後者重視一致且即時的補救。
強制重置也有明顯代價。剛好在 8 月 24 日前兌換 banked reset，或帳號原本還有大量剩餘額度，這次 full reset 能補回的實際價值會比較低。OpenAI 目前沒有公告把剛使用的 banked reset 退回，也沒有提供改成日後再用的選項。因此，這個方案在操作上一致，對每位使用者的補償價值卻不完全相同。可儲存重置的原本設計與使用方式，可參考 Codex 額度重置新制。
8 月 31 日 19:06 的週期時間從哪裡來
全體重置的貼文時間是 8 月 24 日 00:46 UTC，換算台灣時間為 08:46，但帳號顯示的下一次 weekly reset 不一定是 8 月 31 日 08:46。OpenAI Developer Community 上，一則由 OpenAI_Support 帳號提供的 個案說明 提到，全體 reset 之後，新的七日視窗會從下一次使用 Codex 開始，不是從公告時間起算，也不是固定在某個星期幾。這項規則目前沒有找到對應的正式 OpenAI 文件，因此應視為論壇上的支援說明。
若同一項起算方式適用於這次重置，而且帳號直到台灣時間 8 月 24 日 19:06 才第一次再次使用 Codex，新的七日視窗就可能定錨在這個時間，畫面因此顯示 8 月 31 日 19:06。依這項說法，尚未再次使用前，視窗不會立刻從貼文時間開始倒數；一旦開始使用，就不能再自行挑另一個重置時間。
使用者現在需要確認的項目
- 打開 Usage 頁面或 Codex 的
/status，確認方案內含額度與下一次 weekly reset 時間。 - 不要把重置後變成較高剩餘比例解讀成週末用量沒有計算；那是 full reset 的結果。
- 若額度仍異常消耗，保存原始
/status輸出、觀察時間與時區。前述論壇回覆要求提供這些資料，供支援人員追查該帳號狀態。 - Computer History 沒有開啟的帳號不會踩到該功能的用量情境，但仍可能受另外兩項問題或 cache hit rate 變化影響。
ChatGPT Work 的定位、執行位置與 Codex 分工，可參考 ChatGPT Work 完整介紹。這次事件的重點不是兩個產品各自有一套額度故障，而是共用額度池裡有數個效率問題，OpenAI 選擇用統一重置先完成補救，再繼續修正底層流程。
常見問答
週末使用 Codex 的用量是不是沒有被計算？
不是。週末用量先被計入，8 月 24 日的 full reset 再把付費帳號恢復成新的額度狀態，因此舊的消耗比例不再顯示。
這次全體重置會補回 API 用量嗎？
目前沒有這項公告。這次處置針對付費 ChatGPT 訂閱內的 Codex 與 ChatGPT Work usage；OpenAI API Platform 的 token 帳單與 rate limits 是另一套系統。
剛用掉的 banked reset 會退回嗎？
OpenAI 截至 8 月 24 日沒有公告退回或補發。8 月 21 日的 banked reset 與 8 月 24 日的 full reset 是兩次不同處置，不能假設後者會自動恢復前者的票券。