Day 21 的重置官宣已出、落地还没验证：此刻清冷却，整张号会被重新钉住
13:21 上游官宣 Day 21 重置，两家追踪站到发稿都没把它记成落地；本期给出一条判落地的字段、两个中转栈各一处一分钟自查、此刻先别清冷却的代价，以及确认落地后的三步顺序。
今天 13:21（北京），Codex 负责人 Tibo 发帖说「今天是一次重置」。到 13:40，两家重置追踪站都还没有把它记成落地。
此刻该做的是等：号池原样放着，本地冷却先不碰。等自己的号读出 0%，再按下面第五节的顺序动手。
这条帖说了什么
原帖发于 13:21:22，正文是「Day 21/ Wonder what happens the remaining seven days. But today is a reset.」，到 13:32 已收到 466 条回复、103 次转发1。
Loading content card…
codex-reset 的接口把这条记成一条全局 reset 事件，置信度 medium，生效时刻为空，验证状态是 pending，观察结果是 unknown2。
同一时刻它的首页仍写着「Did Codex reset today? No — not so far today (UTC). The latest verified global reset was 23 hours ago (Oct 25, 6:10 AM UTC)」，并给出 59 次全局重置、10 张 banked、节奏约每两天一次3。
opentherank 那一页停在 10 月 25 日：自 2025 年 9 月共 67 次、中位间隔 3 天、最长 68 天，10 月的日历里只有 20 日、22 日、23 日、25 日四条4。
两家站的累计数不同，59 与 67 各按各家的口径引用。
判落地，只看一个字段
这份数据集有 79 条事件，其中 59 条 reset、13 条额度授予。
effective_at 全部为空，连已经记成落地的几条，reset_verification_status 也写着 pending。所以「公告」「确认」「已验证」在数据里是三件事，读的时候分开看。
哪些号会动，哪些不会
会动的是用 ChatGPT 账号登录的 Codex 号，它们有 5 小时与周两个窗口。用 API key 计费的号按 token 付费，这两个窗口都不存在，这类重置对它没有影响3。
时间上还有一个坑：每个账号的窗口从自己上一次重置后的第一个请求起算，没有所有人共享的周窗口重置时刻；重启了使用周期的那次重置会把周窗口日期一起推后3。
重置落地之后，排班与阈值按新日期算，旧日期作废。
一分钟自查：两个栈各看哪一处
CLIProxyAPI 看
GET /v8/management/credentials：每张凭证的 status、unavailable，quota 里的 observed_at 与 signals，以及按模型分开的 model_quotas6。整张凭证被拦下的条件是一句判断：额度超限、原因是
credential_quota、恢复时刻还在未来7。
internal/runtime/executor/codex_executor_terminal.go 第 317–330 行：credentialScoped := isUsageLimit && !modelLevelCooling 一句定下凭证级，冷却时长随后从响应体的 resets_at 取。8sub2api 看
GET /api/v1/admin/openai/accounts/:id/quota：这个接口去上游 /wham/usage 取一次真值，只读不写；要把结果写回快照，用同一个路径加 /quota/refresh 发 POST9。
backend/internal/service/openai_gateway_scheduling.go 第 679–698 行：窗口重置时间已过就放行，快照陈旧且没有未来重置时间也放行；存着的 codex_7d_reset_at 还在未来时，这两条放行都不成立。11现在清冷却，代价比等一会儿高
清掉本地冷却，下一个请求会真的打到上游。上游若仍回用量上限，CLIProxyAPI 把这次失败记成凭证级冷却，时长取响应体里的
resets_at，整张凭证随之出池12。sub2api 侧这一步会进入 429 处置；碰上 529，整号停一段时间，默认 10 分钟13。
上游的
resets_at 跟着窗口走。窗口尚未重置，它给出的仍是原来那个到期时刻，重新被钉住的时刻不会比这次更早。等两个信号，再动三步
任意一个成立再动手：codex-reset 把这条标成
reset_observed；或者你自己某个号在面板上读出 0%。- sub2api 先
POST /api/v1/admin/openai/accounts/:id/quota/refresh，把真值写回快照，暂停判定会跟着变。 - CLIProxyAPI 逐张
POST /v8/management/routing/cooldown/reset，body 里放auth_index14。 - 点之前先读列表里的
quota与model_quotas，以这两个字段为准。
带 401 记录的凭证，第 2 步是空转：清理函数第一行就返回15。这类凭证要等刷新成功，凭证层才会松开。
这一小时仓库侧只有一件事
PR #6995 在 12:59:30 由作者请求复审，13:00:36 机器人回「Something went wrong. Try again later by commenting "@codex review"」，附「An unknown error occurred」16。单还开着，机理上期写过，这里留作跟踪。
四个仓库这一小时零新版本、主干零新提交：CLIProxyAPI 的 main 停在 10 月 25 日 22:45、dev 停在 10 月 26 日 03:25；sub2api main 停在 10 月 25 日 21:48；codex-proxy 的 dev 停在 10 月 23 日 03:54；codex2api main 停在 10 月 26 日 00:39。
#6993、#6992、#6994 与 sub2api 的 #8347、#8348，窗口内都没有新回应。
三家上游状态页这一小时无新事件：OpenAI 全部正常，最近一条事故是 10 月 24 日 06:52 至 07:43 的 CIMD 连接问题；Claude 全部正常，页面更新停在 12:34；Google Cloud 的 8 条清单里最新一条停在 10 月 23 日 00:19171819。
OpenAI 官方论坛的 Codex 分区最新话题发布于今天 09:30，在这条帖之前20。
References
- 1Tibo 的原帖
x.com
- 2codex-reset 事件接口
codex-reset.com
- 3codex-reset 首页
codex-reset.com
- 4opentherank 的 Codex 重置页
opentherank.com
- 5codex-reset 时间线数据集
codex-reset.com
- 6v8.0.43 的 auth_files.go
github.com
- 7v8.0.43 的 selector.go 第 823–840 行
github.com
- 8v8.0.43 的 codex_executor_terminal.go
github.com
- 9v0.2.18 的 admin 路由
github.com
- 10v0.2.18 的 openai_gateway_usage.go
github.com
- 11v0.2.18 的 openai_gateway_scheduling.go
github.com
- 12
- 13
- 14v8.0.43 的 quota.go 第 27–70 行
github.com
- 15
- 16CLIProxyAPI #6995
github.com
- 17OpenAI 状态页
status.openai.com
- 18Claude 状态页
status.claude.com
- 19Google Cloud 状态页
status.cloud.google.com
- 20Codex 分区 RSS
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.