Codex 尖峰時段真的多燒 3–4 倍額度？先自己量，再用夜間排程把 5 小時窗用滿

瀏覽次數: 2

這週 r/ChatGPTCoding 有一篇討論串（〈OpenAI subscription at peak hours can cost you…〉）被轉了很多次。發文者主張：尖峰時段用 ChatGPT 訂閱跑 Codex，同樣的工作會燒掉 3–4 倍額度。底下的留言很快分成兩派，一派說「難怪我下午兩小時就撞 5 小時上限」，另一派說「官方從來沒講過有尖峰倍率」。

我們去對了 OpenAI 的官方文件，結論要先講：截至 2026-09-27，OpenAI 的 Codex 定價頁跟 Help Center 都沒有寫任何「尖峰時段倍率」。3–4 倍是使用者自己觀察到的數字，不是官方規則。

但這不代表可以不理它。額度沒被量清楚，你就會一直用體感在猜，然後在最需要 agent 的下午撞牆。這篇不幫哪一派背書，而是教你三件事：

額度實際燒在哪（有哪些是官方明寫的倍率）
怎麼用 codex exec --json 自己驗「尖峰是否真的比較貴」
不管驗出來結果如何都有用的排程法：互動工作放白天、批次工作丟到你睡覺時閒著的 5 小時窗

本文大綱

一、先把事實釘住：官方寫了什麼、沒寫什麼

官方有寫的：

5 小時窗＋每週上限。 ChatGPT 訂閱的 Codex 用量有兩層限制：一個 5 小時的用量窗，外加每週上限。OpenAI Codex 工程負責人 Thibault「Tibo」Sottiaux 在 2026-08-24 於 X 宣布，隔天（8/25）起 Plus 帳號恢復 5 小時限制，理由是「smoothen load on compute」（把算力負載攤平）。同一則公告裡，他也說 Pro（$100／$200）接下來幾個月不受 5 小時限制，只剩週上限（9to5Mac 報導）。
計量單位是 token，不是訊息數。 2026 年 4 月前後，Codex 定價改成對齊 API 的 token 計價，所以定價頁上的「每 5 小時 N 則訊息」只是估計範圍。以 Plus 為例，官方寫的是 GPT-6 Astra 大約 5–45 則、GPT-6 Luna 大約 350–3,000 則。同一個方案、不同模型，可以差到兩個數量級。
明文寫出的加速消耗： Fast mode 對支援的模型用 2.5 倍標準速率扣點；生圖平均用掉額度的速度是 3–5 倍；雲端（cloud）任務用 GPT-5.6 Sol 可能比本機訊息吃更多額度。
官方的省額度建議： 指令要精準、拿掉不必要的 context；只給相關檔案；把必做和加分項目分開；控制 AGENTS.md 的大小；少開 MCP server（每多一個就多一份 context）。

官方沒寫的：

沒有任何「幾點到幾點算尖峰」的公告，也沒有「尖峰倍率」的數字。
你可能會搜到「尖峰 1.4–1.5×」這個數字。它出自 openai/codex 的 issue #47261，是使用者 nemecekj409-lang 在 2026-09-22 提的功能提案（想要在撞到 5 小時上限後，改用較高倍率扣週額度繼續用）。那是提案，不是現行規則，OpenAI 也還沒回應。別把它當成事實轉述。

為什麼這個傳言有人信？因為隔壁真的做過。 Anthropic 在 2026 年 3 月下旬就這樣調整過 Claude：由 Anthropic 的 Thariq Shihipar 在 X 上說明，平日太平洋時間 5:00–11:00，Free／Pro／Max 的 5 小時 session 額度會燒得比較快，週上限不變，約 7% 使用者會受影響。後來 Anthropic 在 2026-05-06 的官方公告宣布把 Claude Code 5 小時上限加倍，同時移除 Pro／Max 的尖峰限額調整。所以「依負載動態調整 5 小時額度」在業界是有前例的做法，只是 OpenAI 目前沒有公開承認自己也這樣做。

還有一個時間點上的干擾：2026-09-25～26，ChatGPT Work 和 Codex 出現大量錯誤，agent 跑到一半卡在 tool call 失敗、一直重試。Tibo 事後承諾幫付費用戶重置額度。失敗重試也會燒 token，如果你剛好在那兩天觀察到「下午特別貴」，很可能混進了這個因素。

二、額度到底燒在哪：拆成兩層看

要把「尖峰到底貴不貴」這個問題講清楚，可以把一次 Codex 任務的扣額度拆成兩層：

第一層：token 量（你控制）

每一輪 agent loop 送出去的 token 大致是：

輸入：系統提示＋AGENTS.md＋MCP 工具定義＋目前為止的整段對話＋工具輸出（測試 log、檔案內容）
快取輸入：前綴沒變的部分可以命中 prompt cache，通常比較便宜
輸出：程式碼、說明文字
推理輸出：reasoning token，reasoning effort 開越高就越多

agent 每跑一輪都要把整段 context 重送一次，所以對話越長，每一輪越貴，而且是逐輪累加。第 40 輪的單輪成本可能是第 3 輪的好幾倍，這跟你是幾點跑的完全無關。

第二層：換算成額度百分比（OpenAI 控制）

token 會依模型係數（Astra 比 Luna 貴很多）、速度係數（Fast 2.5×）換算成你在 /status 或用量頁看到的百分比。如果真的有尖峰倍率，它只可能存在於這一層。

把兩層分開看之後，驗證方式就很清楚了：固定第一層（同任務、同模型、同 effort、同 commit），只改變時間，然後觀察第二層的換算結果有沒有不同。 很多人的「3–4 倍」體感，其實是第一層在變：下午的 session 比較長、開比較多 MCP、順手切到比較貴的模型，最後卻都怪到時段頭上。

三、實作：自己量「尖峰是否真的比較貴」

codex exec（非互動模式）加上 --json，每一輪結束都會吐出一個 turn.completed 事件，裡面有 usage：input_tokens、cached_input_tokens、output_tokens、reasoning_output_tokens（從 openai/codex 原始碼 exec_events.rs 確認的欄位名）。這是第一層的精確讀數。第二層則用用量頁（chatgpt.com/codex/settings/usage）或互動模式的 /status 看百分比。

步驟 1：準備一個可重複的基準任務

挑一個確定性高的任務，例如「幫 src/utils/date.ts 補齊單元測試直到覆蓋率 90%」。固定一個 commit，每次都在乾淨的 worktree 裡跑：

git worktree add /tmp/bench-$(date +%H%M) <固定的commit-sha>

步驟 2：把變因鎖死

codex exec \
  -m <固定模型> \
  -c model_reasoning_effort='"medium"' \
  --sandbox workspace-write \
  --ephemeral \
  --json \
  "為 src/utils/date.ts 補單元測試，跑 npm test 直到全部通過，不要修改非測試檔" \
  > run-$(date +%Y%m%d-%H%M).jsonl

--ephemeral 讓這次執行不寫入 session 紀錄，-c 則是直接覆寫 config 值。記得關掉 Fast mode，不然 2.5× 會蓋過其他訊號。

步驟 3：跑之前、跑之後各記一次額度百分比

在用量頁記下「5 小時窗已用 %」。同一個 5 小時窗裡不要做別的事，否則百分比會被污染。

步驟 4：整理 token 量

jq -s '[.[] | select(.type=="turn.completed") | .usage]
  | {in: (map(.input_tokens)|add),
     cached: (map(.cached_input_tokens)|add),
     out: (map(.output_tokens)|add),
     reasoning: (map(.reasoning_output_tokens)|add)}' run-*.jsonl

步驟 5：分時段各跑 3 次

例如台灣時間早上 9 點（美西深夜）、晚上 10 點（美西早上，最可能是尖峰）、凌晨 3 點各跑一次，連跑 3 天。算出兩個比值：

「額度 % ÷ 總 token」：如果這個比值在不同時段差到 3 倍，那就是換算層真的有尖峰倍率
如果比值差不多、只有總 token 差很多，問題就出在你的任務或 context，跟時段無關

要誠實看待的限制： 用量頁的百分比精度有限，單次小任務的誤差可能很大，所以基準任務要夠大（至少吃掉 5% 以上）。而且 agent 本身有隨機性，同一個任務的 token 量也會浮動，這就是為什麼每個時段至少要跑 3 次。我們還沒有用這個流程跑出結果，這裡提供的是方法。有數字的讀者歡迎回報。

另外注意「尖峰」是指 OpenAI 那邊的負載尖峰，不是你的上班時間。對台灣使用者來說，美國上班時段落在我們的晚上到凌晨。Anthropic 當初公告的尖峰（平日太平洋時間 5:00–11:00）換算成台灣時間，大約是晚上 8 點到隔天凌晨 2 點（夏令時間）。如果 OpenAI 真的有類似機制，台灣使用者最可能被影響的反而是晚上加班的時候。

四、省額度排程法：不管有沒有尖峰倍率都值得做

這套排程的核心不是「離峰比較便宜」（還沒被證實），而是另一個已經確定的事實：5 小時窗是會過期的額度。Plus 的週上限才是總量，5 小時窗只是限速器。你睡覺的那 7–8 小時裡至少有一個完整的 5 小時窗，不用它也不會留到明天。把可以非同步完成的工作搬過去，白天的窗就能留給需要你在旁邊盯的互動工作。

第 1 招：把工作分成「要你在場」和「不用你在場」

類型	例子	放哪
互動型	設計討論、debug、需要你判斷的重構	白天，互動模式
批次型	補測試、改 lint、依賴升級、批次改 API 呼叫、寫 docstring	夜間，`codex exec`

判斷標準很簡單：能不能用一段 prompt 講清楚完成條件（例如「npm test 全綠」）。可以的話，就丟進夜間批次。

第 2 招：用 profile 把批次任務的設定鎖死

從 openai/codex 原始碼看，-p/--profile <name> 會把 $CODEX_HOME/<name>.config.toml 疊在主設定上。建一個 ~/.codex/batch.config.toml：

model = "<便宜、夠用的模型>"
model_reasoning_effort = "low"
project_doc_max_bytes = 16384

批次任務大多是模式明確的苦工，用 low effort 加便宜的模型就夠了。至於 project_doc_max_bytes，它會限制 AGENTS.md 這類專案說明被讀進 context 的上限，避免巨大的 AGENTS.md 每一輪都跟著重送。

主設定 ~/.codex/config.toml 則把預設值放在 medium，碰到真正難的題目再手動調高：

model_reasoning_effort = "medium"
plan_mode_reasoning_effort = "high"

plan_mode_reasoning_effort 讓規劃階段想得深一點，執行階段維持 medium，比全程開 high 省很多。

第 3 招：夜間佇列腳本

#!/usr/bin/env bash
# ~/bin/codex-night.sh — 逐一執行 queue/ 底下的任務檔
set -euo pipefail
cd ~/work/myrepo
for task in ~/codex-queue/*.md; do
  [ -e "$task" ] || exit 0
  name=$(basename "$task" .md)
  git switch -c "night/$name" main
  codex exec -p batch --sandbox workspace-write --json \
    --output-last-message ~/codex-logs/$name.summary.md \
    "$(cat "$task")" > ~/codex-logs/$name.jsonl || true
  git add -A && git commit -m "night: $name" || true
  git switch main
  mv "$task" ~/codex-queue/done/
done

crontab（台灣時間凌晨 2:30 開跑，避開假設中的尖峰尾段）：

30 2 * * * ~/bin/codex-night.sh >> ~/codex-logs/cron.log 2>&1

重點有三個：每個任務一條分支（早上逐條 review，不喜歡就直接丟掉）、--output-last-message 留摘要（早上先看摘要再決定要不要看 diff）、jsonl 留 token 紀錄（順便累積第三節那個實驗需要的數據）。

第 4 招：任務檔的 prompt 寫法

夜間沒人盯，prompt 要把邊界寫死，不然 agent 會自己擴大範圍，燒掉整個窗：

目標：為 src/billing/ 下所有 public 函式補單元測試。
完成條件：npm test 全綠，且不修改 src/ 下任何非測試檔。
範圍限制：只讀 src/billing/ 與 test/；不要安裝新依賴。
失敗處理：同一個測試修 3 次仍失敗就跳過，在最後摘要列出來。

「失敗處理」這一行最重要。它能擋掉 agent 對同一個錯誤無限重試。9 月 25–26 那種服務異常期間，沒有這條上限的任務會空轉燒額度。

第 5 招：白天互動時控制 context

一個任務一個 session。 做完就開新的，不要把對話拖到幾十輪。
跑前跑後都打 /status，建立「這類任務大概吃多少 %」的直覺，不要靠體感。
少開 MCP server。 官方文件明講每個 server 都會增加 context。只在需要的專案開需要的那幾個。
AGENTS.md 分層。 官方建議把指示拆到子目錄的 AGENTS.md，不要把所有規則塞進根目錄那一份。
Fast mode 只在真的趕時間時開。 2.5× 是官方寫明的倍率，比傳言中的尖峰倍率更確定。

五、Trade-off：什麼時候別這樣搞

Pro 用戶收益比較小。 依 Tibo 8/24 的說法，Pro 目前不受 5 小時限制，只有週上限。夜間排程對你的意義只剩「把 agent 的等待時間移到你睡覺的時候」，不是搶額度。
任務需要人判斷時別丟夜間。 agent 半夜做錯方向，早上 review 的成本可能比省下的額度還高。夜間只放完成條件能自動驗證的任務。
週上限才是天花板。 夜間多用掉的窗，其實是從週額度裡扣。如果你本來每週就用不完，排程只能讓白天比較不會卡，總量並不會變多。
cron 跑 agent 就是無人監督的自動化。 務必開 sandbox（workspace-write），不要給網路權限以外的高權限，分支隔離，不要直接 push。
傳言驗證前，別為了「離峰便宜」犧牲作息。 目前唯一確定的好處是「用掉會過期的窗」，這個好處用 cron 就能拿到，不需要你熬夜。

六、給工程團隊的可操作清單

本週： 把 model_reasoning_effort 預設值設成 medium、plan_mode_reasoning_effort 設成 high，檢查每台機器上開著的 MCP server 數量。
本週： 建 batch.config.toml profile 跟 ~/codex-queue/，挑 2–3 個「完成條件可自動驗證」的苦工丟進去試跑。
兩週內： 用第三節的方法跑一輪分時段 A/B，每個時段 3 次以上。算出「額度 % ÷ token」的比值，用數據回答尖峰問題，不要再轉傳傳言。
持續： 所有 codex exec 都加 --json 留 log，每週看一次哪類任務最吃 token。多半會發現元兇是長 session 和過大的 context，而不是時段。