Codex 額度怎麼算：5 小時限額、週限額與 Credit 消耗

Wed, 15 Apr 2026 22:50:00 +0800

很多人第一次看 Codex 額度時，會以為 5 小時限額 是一個短期餘額池，只有它用完之後才開始扣 週限額。

實際不是這樣。Codex 更像是同時檢查多個額度窗口：短窗口防止短時間爆量，週窗口限制一週總量。一次 Codex 使用通常會同時計入這兩個窗口。

所以你看到：

1
2

5 小時額度還剩很多
但 weekly 額度已經下降

通常是正常現象。

01 先記住結論

Codex 額度可以先按下面三句話理解：

5 小時限額 和 週限額 是同時生效，不是先後扣除。
週限額用完後，即使 5 小時額度還有，通常也不能繼續用同一個訂閱額度池。
Codex 不是簡單按訊息條數計費，而是和模型、tokens、任務複雜度、上下文、執行位置有關。

用偽代碼表示就是：

can_use_codex =
    five_hour_remaining > 0
    && weekly_remaining > 0
    && 沒有觸發其它產品策略限制

5 小時窗口重置，只恢復 5 小時額度；不會恢復 weekly 額度。weekly 額度要等自己的 reset，或者在支援的方案裡購買額外 credits。

02 為什麼會同時扣兩個窗口

可以把 Codex 的額度想成兩個閘門：

窗口	作用
5 小時窗口	防止短時間高頻使用
週窗口	控制一週總使用量

每次 Codex 任務都會產生一次實際消耗。這個消耗會反映到目前相關的 rate limit 窗口裡。

因此不是：

1
2
3

先扣 5 小時額度
5 小時額度用完後
再扣週額度

而更像是：

1
2
3

一次 Codex 請求
=> 計入 5 小時窗口
=> 同時計入週窗口

這就是「5 小時額度沒用完，但 weekly 也在下降」的核心原因。

03 現在更應該看 token-based credits

OpenAI 沒有公開一個使用者可以完全複算的 Codex 扣費公式。官方公開的是 rate card、影響因素和不同模型的 credit 單價。

截至 2026-04-15，Codex rate card 的主口徑已經是 token-based credits。也就是根據輸入 tokens、快取輸入 tokens、輸出 tokens 折算 credits。

官方給出的示例價格如下：

模型	輸入 / 1M tokens	快取輸入 / 1M tokens	輸出 / 1M tokens
GPT-5.4	62.50 credits	6.250 credits	375 credits
GPT-5.4-Mini	18.75 credits	1.875 credits	113 credits
GPT-5.3-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.2-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.1-Codex-Max	31.25 credits	3.125 credits	250 credits
GPT-5.1-Codex-mini	6.25 credits	0.625 credits	50 credits

所以一個粗略估算公式是：

本次消耗
≈ 輸入 tokens / 1,000,000 × 模型輸入單價
+ 快取輸入 tokens / 1,000,000 × 模型快取輸入單價
+ 輸出 tokens / 1,000,000 × 模型輸出單價

這不是精確帳單公式，但足夠解釋趨勢：輸出很貴，長上下文很貴，高能力模型更貴。官方還說明 Fast mode 會消耗 2 倍 credits，Code review 使用 GPT-5.3-Codex 的價格。

04 不要再只看「訊息條數」

同樣發 10 次 Codex，消耗可能完全不同。

輕量任務通常更省：

改一個小函式
解釋一段短程式碼
寫一小段文案
在明確文件裡做局部修改

重任務會更貴：

掃描大型程式碼庫
長時間執行 agent
多輪讀取、編輯、測試、修復
產生大量程式碼或長報告
使用 cloud task
開啟 fast mode

因此，訊息數量 只能作為很粗略的感覺，不能用來判斷真實消耗。

05 local task 和 cloud task 的差別

Codex 裡很容易拉開消耗差距的是執行位置。

local task 更像是在你的本地工作區裡讀文件、改程式碼、跑命令。cloud task 則把任務交給雲端環境託管執行，適合更長、更自動化的流程。

從額度角度看，cloud task 往往更貴。原因也很直接：

需要雲端執行環境
任務通常更長
工具調用更多
上下文更大
自動化鏈路更完整

如果只是普通程式碼編輯、文章整理、局部修復，優先 local task 會更省。cloud task 更適合確實需要雲端託管的任務。

06 為什麼 weekly 掉得特別快

如果你覺得「5 小時額度沒怎麼動，但 weekly 掉很多」，常見原因有這些：

使用了 cloud task。
使用了更貴的模型。
開啟了 fast mode。
上下文很大，Codex 讀了很多文件或保留了很長對話。
輸出很長，比如大量程式碼、長報告、長日誌分析。
任務鏈很長，比如搜尋、編輯、測試、修復、再測試。
自己的額度腳本把窗口標籤解析錯了。

如果你是用腳本讀 /backend-api/wham/usage 之類的字段，不要只看加工後的 five_hour%、weekly%。最好先看 raw JSON 裡的：

limit_window_seconds
percent_left
reset_at
bucket / feature 名稱

常見窗口長度可以這樣判斷：

limit_window_seconds = 18000
=> 約 5 小時窗口

limit_window_seconds = 604800
=> 約 7 天窗口

如果腳本把兩個窗口標反，就會誤判額度變化。

07 更省額度的使用方式

想讓 weekly 撐得久一點，可以這樣用：

把大任務拆成小任務。先處理一個文件、一個 bug、一個功能點。
能 local 就 local，謹慎使用 cloud task。
明確告訴 Codex 相關路徑，減少無關掃描。
避免一次塞入巨大日誌、長文件、無關上下文。
輕量任務可以用更便宜的 mini 模型。
長任務前先讓 Codex 出計畫，再進入執行。
不需要長報告時，明確要求「簡短回答」。

最實用的記憶方式是：

是否能繼續用
= 短窗口還有額度
&& 週窗口還有額度

消耗快不快
= 模型價格
× tokens
× 輸出長度
× 任務複雜度
× 執行位置

這個模型不能精確對帳，但足夠解釋大多數 Codex 額度現象。

使用限制 on KnightLi的博客