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 账号。它是多供应商大模型聚合网关，站方明确说明自己不是官方授权渠道，套餐见定价页，可用模型以模型页为准。使用任何第三方服务时，请遵守相应服务条款和当地法规。
