Codex 額度重置時間線：兩次有公開來源的 reset 與跟蹤方法
截至 2026 年 10 月 17 日，cdnping 時間線裡收錄的 Codex 額度重置只有兩次：2026 年 4 月 8 日和 2026 年 7 月 29 日。兩次都是 OpenAI 方面臨時宣佈的全員重置，沒有固定週期。想盡早知道下一次 Codex 額度重置，可以訂閱 cdnping /changes 的 RSS，同時留意 /down/codex 上的使用者報告。
Codex 額度重置過幾次？
時間線只收錄同時滿足兩個條件的事件：有公開報道或官方表態，並且重置範圍是所有使用者。社交平臺上“我的額度好像被重新整理了”這類個人反饋不計入。
| 時間（UTC） | 北京時間 | 事件 | 來源 |
|---|---|---|---|
| 2026-04-08 | 2026-04-08 | Sam Altman 宣佈 Codex 周活躍使用者達到 300 萬，為此重置所有使用者的用量限額，並承諾此後每增加 100 萬使用者重置一次，直到 1000 萬 | Business Today 報道 |
| 2026-07-29 04:33 | 2026-07-29 12:33 | Codex 負責人 Tibo 宣佈：所有 ChatGPT Work 與 Codex 使用者的用量限額已重置 | KuCoin 快訊轉述 |
第一條的報道只精確到日期，所以表裡沒有寫具體時刻。兩條都來自媒體轉述，原始表態以 OpenAI 官方渠道為準。
4 月那次和使用者數里程碑有什麼關係？
4 月 8 日的重置以周活躍使用者達到 300 萬為由。宣佈時還附帶一個承諾：每多 100 萬周活就再重置一次，到 1000 萬為止。照字面理解，之後可能還有多次重置，但時間取決於使用者數什麼時候越過下一個整百萬，外部沒法預測。
我們沒有找到其餘里程碑對應重置的可靠來源，所以時間線裡只有這一條。如果你看到有文章列出了 400 萬、500 萬時的重置，先找到原始出處再採信。
7 月那次有什麼不同？
7 月 29 日的重置由 Codex 負責人宣佈，範圍寫明是 ChatGPT Work 與 Codex 使用者，沒有提使用者數里程碑。可見重置不一定只跟里程碑掛鉤。
能不能從這兩次推算下一次？
- 兩次間隔大約 3 個半月，但樣本只有兩個，不能據此推算下一次的時間。
- 兩次都是負責人先公開宣佈，媒體再轉述。官方渠道和更新日誌是最早能看到訊息的地方。
- 重置之後原有的計算週期有沒有跟著變，兩份報道都沒有細說。下次遇到時，可以自己記下額度顯示的前後變化。
短視窗恢復和周額度重置怎麼區分？
很多“額度被重置了”的討論，其實把兩種限制混在了一起。下面只講一般概念，具體時長和數值隨套餐與時間變化，以 OpenAI 官方文件和賬戶裡的實際顯示為準。
短視窗限制（社羣常說的“5 小時限制”就屬於這一類）：限制一段較短時間內的用量，視窗到期後自然恢復。連續用了幾個小時被限流，等一陣又能用，這是視窗恢復，不是重置。
周額度：覆蓋更長的週期。短視窗恢復了，但周額度用完，仍然會被限制，要等週期結束。全員重置時，被提前恢復的通常就是這部分，具體以官方說明為準。
對照表：我遇到的是哪種情況？
| 你看到的現象 | 更可能的原因 | 建議做法 |
|---|---|---|
| 用了幾個小時後提示達到限制，過一陣自己恢復 | 短視窗到期恢復 | 不需要處理，記下恢復時間即可 |
| 短時間內恢復了，但很快又被限制，提示等待時間較長 | 周額度接近用完 | 檢視賬戶中的周額度顯示，調整使用節奏 |
| 沒到週期結束，周額度突然回滿 | 可能是一次全員重置 | 去 /changes 和官方渠道確認，在 /down/codex 看其他人是否同時遇到 |
| 額度沒變，但請求大量失敗或很慢 | 服務故障，與額度無關 | 看 /status/openai 和 OpenAI 官方狀態頁 |
最後一行最容易誤判。限流報錯和服務故障在客戶端裡看起來可能差不多，下一節的狀態頁記錄可以說明這一點。
最近 OpenAI 有哪些故障容易被當成額度問題？
cdnping 每 15 分鐘同步一次 OpenAI 官方狀態頁，結果展示在 /status/openai。按同步到的資料，自 2026 年 9 月 17 日起，OpenAI 狀態頁共記錄了 4 起 major、19 起 minor、2 起無影響級別的事件。最近一週與 Codex 相關或影響面較大的幾起如下（來源：OpenAI 官方狀態頁，經 cdnping 同步；持續時間為狀態頁記錄值）：
| 開始時間（UTC） | 事件標題 | 級別 | 持續 |
|---|---|---|---|
| 2026-10-15 16:29 | Widespread feature degradation | major | 約 146 分鐘 |
| 2026-10-14 07:05 | Degraded performance in Codex and ChatGPT Work | minor | 約 167 分鐘 |
| 2026-10-13 08:10 | 某模型在 Codex 與 Work 模式下效能下降 | minor | 約 506 分鐘 |
10 月 13 日那起持續了 8 個多小時。這段時間裡如果 Codex 任務一直變慢或中斷，原因更可能是服務降級，不是額度。先看狀態頁，再判斷額度。
API 入口的連通性方面，cdnping 在 2026 年 10 月 17 日 UTC 08:40–10:05 這段視窗裡，從 Cloudflare 丹佛節點（DEN）探測 api.openai.com，全部成功，延遲中位數 96 ms，P95 為 194 ms。cdnping 當天才開始採集，這組資料只能說明這一個半小時裡入口可達，不能用來判斷長期穩定性。
怎樣第一時間知道下一次重置？
下面的做法只用到公開頁面，cdnping 本身也不需要登入。
第 1 步：訂閱 /changes 的 RSS
/changes 監控 DeepSeek、OpenAI、Codex、Claude、Gemini 等 11 個官方更新日誌、價格頁和新聞頁，逐行記錄增刪內容。Codex 更新日誌裡如果新增了和用量限制有關的條目，會出現在這裡。
- 開啟 /changes，在頁面上找到 RSS 訂閱地址並複製。
- 加到常用的 RSS 閱讀器裡。
- 閱讀器支援關鍵詞過濾的話，可以設定
Codex、usage、limit、reset、額度。
習慣用終端的話，可以先用 curl 拉一次 RSS，確認能正常訪問，再交給定時任務：
# 把 <RSS地址> 換成 /changes 頁面上給出的實際地址
curl -s "<RSS地址>" | grep -iE "codex|usage|limit|reset" | head -20
第 2 步：收藏 /down/codex，並參與報告
/down/codex 綜合了官方狀態頁、每 5 分鐘一次的 API 探測和使用者一鍵報告。報告型別裡有“額度被重置”，也有“限流”“很慢”“被登出”等。
- 額度突然回滿時，點一下“額度被重置”。如果短時間內很多人同時報告，大機率是一次全員重置，而不是你自己的週期到了。
- 被限流時，先看頁面上其他人有沒有報告同類問題，再決定是等待還是排查自己的配置。
第 3 步：請求出錯時看 /status/openai
/status/openai 顯示官方 API 入口的邊緣探測結果和 30 天內的狀態頁事件。額度看起來正常、請求卻頻繁出錯時，先到這裡看。
第 4 步：每週看一次穩定性週報
/reports 每週一自動生成，可以訂閱。不想每天盯著的話，每週一看一遍，確認上週有沒有和 Codex 相關的事件。
自查清單
額度表現異常時，按順序過一遍：
- 賬戶裡顯示受限的是短視窗額度還是周額度？
- /changes 最近有沒有 Codex 或 OpenAI 的新條目？
- /down/codex 上，過去一小時有沒有其他人報告“額度被重置”或“限流”？
- /status/openai 和 OpenAI 官方狀態頁上有沒有進行中的事件？
- 本地網路是否正常？可以用 cdnping 首頁（/）的線上測速看到 OpenAI API 的首次連線和往返時間，排除自己網路的問題。
另外，在筆記裡記一次當前的額度顯示和時間點。下次重置發生時，就能對比出它到底改了什麼。
額度經常不夠用怎麼辦？
如果工作流經常卡在額度上，除了等重置，也可以考慮其他接入方式。例如 AGI Plan（AGI Plan 是 cdnping 的商業合作方）提供 Codex 的分步接入教程，改一處介面地址即可使用，不需要 ChatGPT 賬號。它是多供應商大模型聚合閘道器，站方明確說明自己不是官方授權渠道，套餐見定價頁，可用模型以模型頁為準。使用任何第三方服務時，請遵守相應服務條款和當地法規。
