【2026 最新】Codex 用量限額怎麼查？7 天稽核 5 小時／每週額度是否變少

Codex 用量限額的兩條進度條突然掉得比平常快，你的第一個念頭可能是：「OpenAI 是不是把額度砍了？」2026 年 8 月 28 日，一位 r/codex 使用者表示自己每 5 分鐘記錄一次用量、累積 14,744 筆輪詢快照；其附圖把 7 月 29 日至 8 月 24 日標成每週約 3.23 億「有效 token」，把 8 月 25 日至 28 日標成約 1.73 億，並報告可能少約 46%。這 14,744 筆是輪詢快照，不是 14,744 個獨立任務；公開頁面可核對的是正文與摘要圖，若要獨立重算，仍需要原始資料、schema 與完整公式。作者也說自己只有少數新制度下的完整週期，未把 46% 當成定論。這只是單一 Business Standard 席位的早期觀察，不是 OpenAI 公布的降額幅度。原始數字可在這篇社群貼文核對。

另一個不能漏掉的背景是：8 月 29 日，OpenAI 的 Thibault Sottiaux 在公開更新中表示團隊修正了多種 usage leak，並替付費使用者重設限額；他估計不同 workflow 可因此多用約 10%～50%。這支持「異常消耗也可能來自計量或工作流 bug」，卻不能反過來驗證 Reddit 的 46%，更不等於官方宣布方案額度下修。

問題不在於社群感受一定錯，而在於同一格進度，可能混進模型、Context、推理強度、工具、快取、重試與執行位置等差異。這篇專為沒有統計或工程背景的讀者寫：不先替任何一方下結論，而是帶你建立一份能重複的 7 天紀錄，用固定任務算出「每個完成任務的額度成本」，再判斷你看到的是正常波動、工作流改變，還是值得向 OpenAI 追查的異常。

Codex 用量限額先說結論：進度條不是判決書

• 一句話錨點：判定額度變少 ＝ 同一固定任務的成本跨期上升 ＋ 多次重複超出自己的正常範圍 ＋ 模型、Context、工具與重設等變因已排除。
• 單看 5 小時或每週進度條下降，最多只能說「這次顯示的消耗較快」，不能直接推成 OpenAI 全面調低方案額度。
• 最有用的單位不是「今天聊了幾句」，而是一個通過驗收的任務用了多少百分點。
• 一個完整 7 天週期可以建立你的現況基線；若要判斷「前後是否改變」，還要拿另一個設定相同的 7 天週期，或可信的舊紀錄，做配對比較。

先把四種數字分開：5 小時、每週、credits、reset

截至 2026 年 9 月 1 日，OpenAI 的官方 Codex 定價與用量頁把 ChatGPT 方案內的本機訊息放在 5 小時視窗中計算，本機訊息與 cloud chats 共用這個視窗，另外還可能有每週限額。官方同時說明：可用訊息數不是固定值，模型、任務大小、Context、推理、工具、retrieval、快取與本機／雲端執行都會改變消耗。

把它想成交通系統會比較清楚：5 小時視窗是短程閘門，每週限額是整週總預算，credits 是方案內用量耗盡後的加值餘額，reset 則是重新開一個可用週期。它們可能出現在同一個 Usage 畫面，卻不能加在一起算。

• 5 小時視窗：記錄畫面顯示的剩餘百分比與重設時間。它不是「登入滿五小時才扣完」的計時器；實際消耗依任務而變。
• 每週限額：獨立記錄剩餘百分比與下一次重設時間。不要用 5 小時進度推算整週總量。
• credits：OpenAI 的個人方案 credits 說明指出，方案內用量先被使用，達到限制後，支援的功能才從可用 credits 扣除；它不是 API credits。
• reset：banked reset、付費 instant reset 與自動重設不是同一件事。官方的banked reset 說明與付費重設說明都指出，完整重設會刷新 5 小時與每週視窗，並可能改變下一個每週重設日；付費 instant reset 是把正常週額度提前，不是多送一份可囤積的額度。

官方對 weekly limit 的措辭是「可能適用」；若你的帳號沒有顯示某一層，就在表格寫「未顯示」，不要自行補一個百分比或重設日。

第 0 天：先建立不會自欺的 Codex 用量限額紀錄表

先打開 Settings → Usage，或在正在執行的 Codex CLI session 輸入 /status。OpenAI 的Codex 方案說明把這兩處列為目前查看剩餘用量與重設時間的入口。注意：/status裡的 Context window 百分比是這個 session 的上下文，不是訂閱額度；本篇只抄 5h limit、Weekly limit與各自 reset time。每次任務都要在開始前記一次，完成後等讀值更新再記一次；若百分比尚未更新，就刷新或重開 Usage 再讀。同時保存截圖，但先遮掉帳號、workspace、專案名稱與其他私密資訊。

每一列至少保留這些欄位：日期時間與時區、方案／workspace、Codex client 與版本、本機或 cloud、模型、reasoning、speed、新或長 session、Context 範圍、MCP／skills／工具、重試次數、任務驗收結果、任務前後 5 小時剩餘、任務前後每週剩餘、credits 前後與兩個重設時間。若同一方案還用 Work、Excel、Workspace Agents，或從 Voice 啟動 Codex 工作，也把時間與任務另記一列，避免共享用量混進測試。重設日不要猜固定星期幾；直接抄錄 Usage 或 /status當下顯示的 reset time，並一併記錄你的時區。

若你有 Git repository，再加上 git rev-parse HEAD 保存固定 commit，並用 git status --short確認起點乾淨。兩次測試請用同一 commit 的兩份可拋棄副本，不要一邊修改同一份專案、一邊把後面的任務當成「相同輸入」。

固定三種任務：小、中、大都要有可驗收終點

「幫我優化這個專案」不是固定任務，因為每次探索路徑都不同。你需要三張像健身房標準砝碼一樣的任務卡：

1. 小任務「單點修改」：在固定檔案改一個明確行為，執行一條固定測試；測試通過才算完成。
2. 中任務「封閉 bug」：在鎖定 commit 的測試專案修一個已知錯誤，允許讀取範圍固定，指定測試全部通過才驗收。
3. 大任務「受限重構」：重構一個固定模組，先寫死三項驗收條件、允許的檔案範圍與完整測試命令；超出範圍的美化不計分。

每張卡都保存原始 prompt、輸入檔案 hash、驗收命令與預期輸出。這個做法和一般「覺得今天用得比較快」最大的差別，是你比較的不是聊天感受，而是同一個可交付結果。

7 天怎麼跑？三天建立錨點，四天拆解變因

正式開始前先做一批不納入比較的 pilot：確認一組固定任務造成的變化大於畫面最小顯示刻度，再把每批重複次數、失敗後是否重試與可接受差異 δ寫死。不要看完結果才追加任務或調整門檻。每次測試也盡量排在距離 5 小時與每週 reset 相近的位置；跨過 reset 的批次直接判為無效。

第 1 天：新 Session 跑三次小任務

三次都固定模型、reasoning、speed、工具與可讀檔案，並各開一個新 session。痛點是單次結果太容易被偶發重試影響；解法是同日重複，操作時每次都記錄 /status 前後值。你要得到的是一小段自己的正常範圍，不是漂亮的單一數字。

第 2 天：原封不動重跑小任務

不要改 prompt，也不要順手升級 client。若相同設定仍有波動，這就是你的背景噪音。把第 1、2 天的結果合併，先找中位數與最高／最低值；樣本很小時，這比硬套一個看似精準的百分比門檻更誠實。

第 3 天：跑兩次中任務，確認規模效應

固定所有設定，只把任務卡換成中型。若中任務明顯吃更多額度，先把它視為任務規模差異，而不是限額縮水。官方也明確說大型專案、長時間任務與較多 Context 可能增加每則訊息的用量。

第 4 天：新 Session vs 長 Session

用兩份相同起點的專案各跑同一個中任務：A 用新 session，B 放在已累積許多相關上下文的長 session。痛點是很多人先假定「重開一定省」；解法是只改 session 長度，其他設定不動。Context 變短可能降低讀取量，但快取與重新讀檔也會影響結果，所以只接受你自己的配對紀錄。

第 5 天：只換模型，不混進其他改動

截至 2026 年 9 月 1 日，官方定價頁把 GPT-5.6 Sol、Terra、Luna定位成不同負載層級，並表示較小模型可延長本機訊息用量。選一張小任務卡，保持 prompt 與驗收相同，只換模型。這一日的目的不是證明額度被改，而是找出哪些工作能安全切到較省的模型。

第 6 天：工具、MCP 與重試成本

同一張任務卡各跑一次：A 保留平常的工具；B 關掉不需要的 MCP server，並限制資料來源。每次失敗重試都另記一列，不要只記最後成功的那次。OpenAI 的官方節流建議也提醒，每個 MCP server 都會增加訊息 Context；看不到 cache hit 的帳號就填「未顯示」，不要自行反推精準率。

第 7 天：重跑第 1 天錨點並封存

回到第 1 天完全相同的小任務與設定，再跑三次。保存整週表格、截圖、Codex 版本、任務卡與兩個 reset time。不要在結算前使用 credits 或 reset；若中途真的使用，就把前後切成不同區段，不能當成一條連續曲線。

怎麼算每個完成任務的額度成本？

先統一用「剩餘百分比」記錄。單次 5 小時成本是 任務前 5h 剩餘 − 任務後 5h 剩餘；單次每週成本同理。若畫面顯示的是已使用百分比，就先換算成剩餘值，整張表不要混用兩種方向。

每個完成任務成本則是 一組任務造成的每週剩餘下降 ÷ 驗收通過數。失敗的 run 不應消失：它是工作流成本，另外列出「嘗試成本」與「完成成本」，你才看得出額度是花在交付，還是花在反覆探索。

完整追一次：假設小任務是「修復固定測試中的一個錯誤」。開始前保存 W0 與 F0，測試通過後保存 W1 與 F1；這次的週成本就是 W0 − W1，5 小時成本是 F0 − F1。若測試沒通過，完成數是 0，不能把消耗平均到成功任務裡。下一次從同一 commit、同一 prompt、同一設定重來，才是可比較的 replicate（重複試次）。

判定門檻：什麼時候可以說「值得懷疑」？

把匹配試次的差值定義成 d ＝ 後期每任務成本 − 前期每任務成本。δ則是你在看後期結果前，依顯示刻度與第 1、2 天自然波動訂下的容許範圍。沒有變更前的同設定紀錄，就沒有可算的 d；這七天只能建立「目前基線」，不能證明過去曾經被改。

1. 只有一次跳升：結論是「不確定」。先查重試、Context、工具與 reporting delay。
2. 改模型或 session 後才跳升：結論是「工作流差異」，不能算方案變更證據。
3. 第 7 天所有錨點的 d都落在 −δ到 +δ：目前沒有偵測到超出本測試解析度的差異，但這不保證未來不變。
4. 另一個匹配的 7 天週期中，多次錨點的 d都高於 +δ，而且帳號有顯示的 5 小時與每週讀數方向一致：可以寫成「此帳號的每任務消耗出現持續異常」。若有的落在界線內、有的超出，結論仍是不確定。
5. 要寫成「OpenAI 全面砍額度」：你的單一帳號紀錄做不到。還需要官方公告，或多個方案、地區與工作流可比的獨立資料，再排除 client／模型版本與計量方式改變。

這也是社群「46%」數字應該停留的位置：它是一位使用者在特定席位、特定追蹤邏輯與少數週期下的早期估計，足以提出問題，還不足以替所有 Codex 帳號宣布答案。

看到消耗過快，先做這 5 個調整

1. 縮小 Context：只提供必要檔案與日期範圍，並把大型 AGENTS.md 拆成靠近子目錄的局部指令。
2. 把例行工作切到較小模型：先用你的第 5 天結果確認品質仍通過驗收，再把 Terra 或 Luna 用於適合的固定任務。
3. 關掉沒用到的 MCP：不要讓每一輪都攜帶與任務無關的工具描述。
4. 把「必要交付」與「順手改善」拆開：先完成驗收條件，額外美化另開任務，避免一次沒有邊界的長跑。
5. 按接近的是哪一層決策：5 小時視窗用完就看顯示的重設時間；接近每週限額時，先比較縮小任務或切較小模型；若已耗盡，則依限額通知選擇等待、可用 credits、可用 reset 或升級。不要只看到一條紅色進度就立刻買錯資源。

如果你想進一步理解「Context 為什麼會愈聊愈重」，可接著看 AlphaLab 的Claude 省 token 實戰；產品不同，但「縮小輸入、明確驗收、少帶無關工具」的測量思路可移植。若你還在選 Codex 或 Claude Code，先讀Claude Code vs Codex 客觀比較，避免把工具切換造成的差異誤認成額度變動。

Codex 用量限額常見問題 FAQ

1. 兩條進度條掉得快，能證明額度被砍嗎？

不能。它只證明畫面在該段時間顯示較高消耗。先做固定任務配對，排除模型、Context、工具、重試、執行位置、credits 與 reset。

2. 5 小時限額等於 Codex 可以連續使用五小時嗎？

不是這樣理解。官方用「每 5 小時視窗的本機訊息估計」描述它；不同任務每則訊息會消耗不同份量，本機與 cloud chats 也共用該視窗。

3. 可以直接把 token 數換成方案剩餘百分比嗎？

不宜直接換算。官方把可用訊息數列為受模型、cached input、output、reasoning 與工具等變因影響的估計，因此不要把進度條假設成固定 token 桶。若介面提供 token history，就把它當額外欄位，不要取代兩個官方限額讀數。

4. 只記 /status 就夠嗎？

不夠完整。/status適合任務前後快速讀值；Usage dashboard 的重設時間、credits 與截圖則能補足脈絡。兩邊都記，並標註讀取時間。

5. 每次開新 Session 一定比較省嗎？

不一定。較短 Context 可能減少讀取，但重新探索與快取也會改變成本。用第 4 天的 A/B 配對決定，不要把網路口訣當成你的帳號數據。

6. 買 credits 會重設 5 小時與每週限額嗎？

credits 與 reset 是不同機制。credits 是達到方案內限制後，支援功能可繼續使用的加值餘額；完整 banked reset 或符合資格的 instant reset 才會刷新相關視窗。

7. 付費 instant reset 是多買一週嗎？

不是額外疊一週。截至 2026 年 9 月 1 日，官方把付費 instant reset 描述為把正常每週 allowance 提前；購買完成後會立即恢復 5 小時與每週用量，新週期從套用後第一次在 Work 或 Codex 發出請求開始，下一次自動週重設排在該次請求 7 天後。目前只向符合資格的 ChatGPT Plus 與 Pro 個人帳號提供，Free、Go、Business、Enterprise 與 Edu 不提供；實際是否顯示仍依帳號而異。

8. 覺得計量錯誤，向 Support 提供什麼？

提供可核對的最小證據包。OpenAI 建議包含你質疑的限額或 credit balance、畫面顯示的 reset time、去識別化截圖、Codex client、模型、發生時間與時區。再附上固定任務卡與前後讀數，會比「今天掉很快」更容易調查。

給新手的 5 個重點

• 先分清 5 小時、每週、credits 與 reset，再談異常。
• 每次只改一個變因；同一任務必須從同一 commit 與同一驗收條件開始。
• 同時記「嘗試成本」與「完成成本」，失敗重試不能消失。
• 一個 7 天週期建立基線；兩個匹配週期才比較前後。
• 你能證明的是自己的帳號與工作流出現什麼，不是替所有使用者宣布平台政策。