AI 科技新聞

Codex 用量上限出錯：約 4 萬帳號套用錯誤方案，Tibo 公告了什麼與怎麼查額度

Codex 用量上限出錯，OpenAI 的 Tibo 說約 4 萬個帳號套用的上限與所選方案不符，已修正並以點數補償。本文整理這則公告寫了什麼、沒寫什麼，對照官方額度文件與過去的額度公告，說明如何檢查自己的 Codex 用量。

OpenAI 官方 Codex 定價文件頁的通用橫幅圖片，不是這起事件的專屬圖，非本站拍攝／實測。圖片來源：官方原文。

10 月 21 日台灣時間凌晨，OpenAI 的 Tibo 在 X 說，約 4 萬個帳號的 Codex 用量上限和所選方案對不上，已經修正，受影響的人會收到點數。Tibo 的 X 簡介寫著 Codex 與 ChatGPT、@OpenAI。

這則貼文到傍晚已有超過一百三十萬次瀏覽。

據 Tibo 說，起因是上週末有使用者反映，Codex 額度消耗得比預期快。這類抱怨在 Codex 並不少見，Tibo 過去幾次公告多半把原因歸給軟體行為或事件，這次則直接點出帳號層級的上限套用不一致。

X 上另一位使用者把這則公告寫成電表壞了，並附上一串對 GPT-6 Astra 與每日更新的批評。其中有些是個人感受，有些帶有數字，但只有 4 萬帳號這件事能在官方貼文裡找到原文。

我的看法是，這則公告有三個具體訊息，分別是帳號數、問題類型與補償方式，值得認真看。但它沒有寫出哪些方案受影響、方向是多扣還是少扣、持續多久，所以能不能對上你的情況，得自己去查。

要判斷該查什麼，先看官方到底說了哪些話。

Tibo 的公告說了什麼？約 4 萬個帳號、方案不符與點數補償

這則貼文發布在 10 月 20 日 UTC 17:10，也就是台灣時間 10 月 21 日凌晨 1 點多。內容可以拆成四個重點：週末有使用者反映額度消耗比預期快，團隊找出約 4 萬個帳號出現不一致，問題已修正，並會個別聯繫受影響的人。

不一致的說法是，實際套用的用量上限與帳號所選的方案不相符。這裡的方案，我的理解是 ChatGPT 的訂閱等級，例如 Plus 或 Pro，貼文沒有明說，而不同方案的額度不同。

補償的說法是，受影響的使用者會在帳號中加入點數。Tibo 在結尾用一句話道歉，說他們這次做錯了。貼文只有這幾句，本身沒有附連結或圖片。

貼文沒有寫的內容更值得留意。它沒有說是哪些方案、哪個模型受到影響，沒有說是被套用較低的上限還是較高的上限，沒有說問題從什麼時候開始、持續多久，也沒有說點數的數量。

我另外查了 OpenAI 的狀態頁。10 月 21 日查看時，頁面列出的事件紀錄涵蓋 7 月下旬到當天，其中沒有與用量上限有關的條目，Codex 相關的紀錄包括 GitHub 審查失敗、API 身分驗證錯誤與回應延遲。

所以目前能確認的，只有 Tibo 這則貼文。

計算規模時要小心：Tibo 在 8 月 21 日說，Codex 在那一週的某個時間點達到 2,000 萬活躍用戶，沒有說明統計期間。若拿 4 萬除以這個數字，約是 0.2%，但這是兩個不同時點、不同口徑的數字相除，只能當量級參考。

延伸閱讀：Codex 快取更新：同一份額度能做更多事，長任務該怎麼安排？

OpenAI 官方 ChatGPT 文件的 Pricing 橫幅圖片，藍色漸層背景 — OpenAI 官方 Codex 定價文件頁的通用橫幅圖片，不是這起事件的專屬圖，非本站拍攝／實測。圖片來源：官方原文。

Codex 的用量上限怎麼算？官方文件的五小時額度與點數

要理解方案不符為什麼會讓人感覺額度蒸發，得先知道 Codex 的額度怎麼運作。OpenAI 的 Codex 定價文件說明，ChatGPT Work 與 Codex 共用額度，額度依方案、模型、任務大小與執行位置而變。

文件給 Plus 與標準 Business 的估計，是每五小時可送出的本機訊息數。GPT-6 Astra 約 5 到 45 則，GPT-6.1 Sol 約 15 到 160 則，GPT-6 Sol 約 15 到 150 則，GPT-6 Luna 約 350 到 3,000 則。

文件特別寫明，這些是估計值而不是固定上限，同樣長度的提示，也可能因模型、上下文、推理、工具使用與快取而消耗不同。另外，Pro 方案目前沒有五小時限制，但每週限制可能仍然適用。

方案之間的規則本來就不同，所以方案被套錯，額度就會跟著錯。依同一份文件，Enterprise 與 Edu 若採彈性計價，沒有固定的額度上限，用量隨點數而定，沒有採彈性計價的方案則與 Plus 的每席位上限相同。

所以一個帳號被套用了別的方案的規則，感受到的額度可能差很多，但貼文沒有說實際發生的是哪一種組合。

模型之間的差距也很大。依官方的點數費率表，GPT-6 Astra 每百萬輸入與輸出詞元的費率是 250 與 1,250 點，GPT-6.1 Sol 是 50 與 250 點，依表格相除，Astra 是 Sol 的五倍。

詞元是模型計算文字量的單位，費率愈高，同樣一段工作就消耗愈多額度。所以用 Astra 做長任務，額度自然比 Sol 或 Luna 掉得快，這是費率造成的差異，和方案被套錯是兩回事。

文件還列出幾個放大消耗的因素。快速模式會以 2.5 倍消耗包含在訂閱中的用量，GPT-6 Astra 與 GPT-6.1 Sol 的超快模式是 8 倍，圖片生成平均比一般回合快 3 到 5 倍用完額度。

想知道自己的狀況，官方指定的方式是 Codex 設定中的用量頁面，在命令列則可輸入 /status 查看剩餘額度。

Tibo 過去的額度公告：這次和以前有什麼不同

這不是 Tibo 第一次為 Codex 額度公開說明。我整理了他在 X 上幾則與額度有關的貼文，表格日期換算成台灣時間，文末資料來源的日期則是 UTC，方便對照這次的處理方式。

日期	Tibo 的說法	處理方式
5 月 18 日	約兩小時內，多數訂閱用戶的實際限制不正確	該段時間的消耗被免除
5 月 24 日	一項優化影響壓縮長對話時的快取命中，已回退	重置所有帳號額度
6 月 4 日	24 小時內有三起小事件影響可靠性	重置所有付費方案額度
6 月 30 日	多個小問題疊加，包括自動審查、子代理與背景建議	重置額度，另給一次可存放的重置
7 月 29 日	說明沒有調降任何訂閱方案的額度，預期 Sol 的用量多撐約 18%	重置額度
8 月 21 日	查看用量上限不同的回報，說不少受影響者使用 sub2api；同日另一則說團隊沒看到異常，仍在調查	宣布發放可存放的重置
8 月 30 日	列出壓縮、記憶、目標、自動化等多項錯誤，稱用量可多撐 10% 到 50%	重置付費用戶額度
10 月 21 日	約 4 萬帳號的用量上限與所選方案不符	個別聯繫，受影響者加入點數

從表格可以看出，前幾次的處理多是全面重置，這次改成找出特定帳號、逐一聯繫並補點數。我推測這個差異與問題的性質有關，因為前幾次多是軟體行為造成的消耗，這次則是帳號層級的設定不一致。

另一個差異是規模與範圍。5 月那次是多數訂閱用戶遇到幾小時的限制錯誤，這次是約 4 萬個帳號，時間長度未說明，兩者不能直接比較。

不過這些貼文也顯示，額度消耗的原因通常不只一個。8 月 30 日那則列出的錯誤，包括壓縮時保留舊圖片、目標功能沒有停止、自動化排程頻率過高，都是會讓人感到額度蒸發的獨立原因。

延伸閱讀：原來 Tibo 的 Reset Button 真的存在！OpenAI 為何一直重置 Codex 額度？訪談 7 大重點

額度掉得快還有哪些原因？Tibo 在 8 月列出的八類錯誤

方案不符只是額度異常的原因之一，所以在懷疑這次事件之前，值得先看 Tibo 在 8 月 30 日那則公告列出的八類錯誤。他說團隊把數千則回報逐一檢查，找出許多長期存在的小問題，並宣布已修正或停用。

其中，壓縮功能在整理長對話時會保留舊圖片，使內容大到又觸發壓縮，修正後，大量使用圖片的人用量下降約 10%。

記憶功能的背景程序可能因為停止掛鉤而不肯結束，影響不到 1% 的使用者，但有一個例子反覆檢查自己能不能停止，多達 1.5 萬次。

目標功能在條件達成後可能繼續執行，或不斷重試壞掉的工具，有例子耗掉一週額度的 15% 到 70%。

自動化排程可能比設定的更頻繁，子代理有時會自己挑選更強的模型，電腦歷史功能則會重複整理重疊的活動，最嚴重時每週吃掉五分之一的額度。

剩下兩項規模較小。一般回合會觸發額外的背景摘要，約多用 1% 的詞元，已被停用，另外 MCP 的工具結果有時被編碼兩次，工具說明也可能被截斷後重新抓取。

這份清單的用處，是讓使用者知道額度掉得快常有多個互相獨立的原因。若你在 8 月之後仍遇到異常，目標、自動化、子代理與 MCP 這幾項值得先檢查，但我沒有逐項驗證它們目前是否還會發生。

另一個原因來自使用方式。Tibo 在 8 月 21 日另一則貼文說，團隊查看「用量上限不同」的回報時，發現不少受影響的使用者在用 sub2api，也就是把訂閱轉成 API 流量再轉售或多人共用。

他說這類用法不受支援，並會被反詐欺系統標記，透過 Sign in with ChatGPT 的官方或開源用戶端登入則沒有問題。這是他對特定情形的說明，10 月這則公告沒有提到 sub2api，兩件事不能直接連在一起。了解這些可能的原因後，就能用比較有條理的順序檢查自己的帳號。

怎麼查自己有沒有受影響？一份可以照做的檢查順序

Tibo 說會個別聯繫受影響的使用者，所以第一步是看信箱。檢查註冊 ChatGPT 的電子郵件，包含垃圾郵件匣，看有沒有來自 OpenAI 的通知，並留意信中是否提到點數的數量。

第二步是比對方案與顯示的額度。到 Codex 的用量頁面，確認目前顯示的限制與你訂閱的方案相符，例如依 10 月 21 日的官方文件，Pro 目前沒有五小時限制。這只是對照文件的簡單檢查，不能單靠它判定自己受影響。

第三步是記錄。截圖用量頁面與重置時間，並在 CLI 執行 /status 保存輸出，之後若要向 OpenAI 反映，這些紀錄比「感覺用得快」更有說服力。

看用量圖表時還要留意一件事。Tibo 在 6 月 30 日的公告說過，當時自動審查被錯誤地顯示成舊模型的用量，失敗或被限流的請求也被顯示成回合，雖然被限流的請求從未計費。他說歷史圖表仍可能保留舊標示，所以較早的圖表可能和實際消耗對不上。

第四步是排除其他原因。官方文件建議縮小提示、限制來源資料、精簡 AGENTS.md，並減少不必要的 MCP 伺服器，因為每個伺服器都會增加每則訊息的上下文。模型選擇也有影響，Astra 的費率是 GPT-6.1 Sol 的五倍。

如果檢查後仍覺得額度不合理，可以透過 OpenAI 的支援管道反映。至於補償的點數，官方文件說明點數是額度用完後可繼續使用的單位，數量與使用方式要以 OpenAI 實際通知為準。

限制與風險：這則公告無法回答的問題

首先是資訊量的限制。整件事只有 Tibo 一則貼文，我沒有找到 OpenAI 的正式公告、狀態頁紀錄或文件更新，因此所有細節都停在貼文的字面內容，不能補猜。

其次是因果的限制。貼文先說週末有人反映消耗太快，再說找到 4 萬個帳號不一致，但沒有說兩者是否一一對應。換句話說，覺得額度掉太快的人，不一定都在這 4 萬之內。

再來是方向的限制。若某個帳號被套用較低方案的上限，使用者會覺得額度很快用完，這與週末的抱怨一致，但這是我的推論，貼文沒有說明方向，也不能排除相反的情形。

最後是第三方貼文的數字。X 上批評貼文引用的投票結果、模型價差與使用情境，我都沒有逐項核對，應視為作者的說法，不應和 Tibo 的公告混在一起。

誰需要關心這則公告

必須關心的人，是用 ChatGPT 訂閱方案跑 Codex 的重度使用者，特別是這幾天發現額度消耗異常、需要用 Codex 完成進度的人。公告沒有說哪些方案受影響，所以不同方案的人都值得查一次。他們最該做的是查信箱與用量頁面，並保留紀錄。

可以稍後再看的人，是偶爾使用 Codex 的輕度用戶，以及用 API 金鑰付費的人。API 金鑰的用量依 API 定價計費，與 ChatGPT 訂閱的方案額度是兩套機制。

對團隊管理者而言，這件事也是提醒：額度是共用資源，模型、速度模式與工具都會改變消耗。建立固定的用量檢查習慣，比事後追查原因更省力。

Codex 用量上限常見問題

Tibo 說的 4 萬帳號是全部 Codex 用戶嗎？

不是。貼文說的是約 4 萬個帳號，而 Tibo 在 8 月 21 日說 Codex 達到 2,000 萬活躍用戶，兩者相差很大。但兩個數字的時點與口徑不同，不能當成精確比例。

受影響的人會得到什麼補償？

貼文說受影響者會被加入點數，並會個別聯繫。點數數量、發放時間與使用期限，貼文沒有說明，以收到的通知為準。

我的額度掉很快，一定是這個問題嗎？

不一定。官方文件與 Tibo 過去的公告都顯示，模型選擇、快速模式、子代理、長上下文與工具設定，都會讓額度快速下降，這起事件只是其中一個可能原因。

哪裡可以看到自己的 Codex 用量？

官方文件指定 Codex 設定中的用量頁面，命令列則可輸入 /status。頁面會顯示目前限制與重置時間。

先確認自己的紀錄，再等官方補充

這則公告承認了一個具體問題，約 4 萬個帳號的用量上限與所選方案不符，並給了補償方式。Tibo 給出了明確的帳號數與補償方式，但資訊仍不夠完整，無法判斷範圍與影響大小。

最穩妥的做法是先查信箱與用量頁面，保存紀錄，同時依官方文件調整使用習慣。等 OpenAI 補充受影響方案與補償數量後，再核對自己的情況。

想持續追蹤 Codex 額度、模型與工作流程的官方說明，可免費訂閱 AI 郵報，並以官方文件與貼文原文確認每一項數字。