周额度打空后，中转回的是可重试 429 和六天的等待；补丁想把它改成终局
整个号池被 Codex 周额度打空时，CLIProxyAPI v8.0.51 回的是带超长 Retry-After 的可重试 429，客户端因此停不下来；这期拆开它的三处成因、客户端为什么不在那里停，以及一张想改成终局的补丁还差什么。
北京 11-02 06:09，一张补丁单开在 CLIProxyAPI：把打空的周额度报成终局，而不是可重试的 429。1
两分钟后，作者又到十月中旬的旧单复述同一个现场。四仓库这一小时零发版、主干零提交。2
事情本身不新。更早的报障单里，上游回的
Retry-After 是 506177 秒。3新的是有人把它算成了一笔账：这不是几分钟的退避，是六天。今晚该动什么，在第五节。
现在回的是一个还能重试的 429
v8.0.51 的
selector.go 里，modelCooldownError.Headers() 无条件写 Retry-After，值是 ceil(resetIn)。方法定义在第 353 行，写头在第 360 行。4
全池都在冷却时，
resetIn = earliest.Sub(now)，按最早恢复的那张凭证算。第 528–541 行。周窗口是 1440 分钟，于是这个头最长能到 604800 秒。作者实测过一个
Retry-After: 10640，约 2 小时 57 分。这个头由
handlers_errors.go 第 127–129 行写进响应，第 131 行才去判 passthrough 开关。5也就是说，关掉透传也去不掉它。这一条跟你的配置无关。
错误体是
code: model_cooldown，不带 usage_limit_reached。客户端拿到的全部信息就这些。
Retry-After: 506177 换算约 140 小时，旁边是当事人贴的 trimmed 响应体，该单到今天仍是 open。3客户端为什么不在这里停下
Codex 认「额度用尽」的判据是
error.type == usage_limit_reached。model_cooldown 里没有这个字段。它只被当成一次普通限流，按状态码决定下一步。
429 在它们眼里是可重试的，
Retry-After 又给了几十小时，于是等。WebSocket 那条路更差：中转对冷却类错误直接静默关闭连接，不给事件。第 412–419 行就是
closeWithoutError。8放行的只有终局鉴权错与请求过错两类，冷却不在里面。第 396–403 行。
客户端只看到掉线，重连 5 次，退回 HTTPS 才拿到那个 429。作者自述 75 秒时他手动停了。
另一个部署没停，等了 38 个半小时。1
补丁要把它改成终局
第二道是每张凭证都留着 Codex 额度耗尽的证据。第三道是最早恢复距今超过 5 分钟。
三条同时成立才改判终局。任何一条不成立，仍是现在的
model_cooldown。响应体换成
type: usage_limit_reached、resets_at、retryable: false、limit_window_minutes。code 仍是 model_cooldown，外层形状不变。头去掉
Retry-After，改成 X-Should-Retry: false 与一组 x-codex-{Primary|Secondary}-*。窗口 ≥1440 分钟的那一档走 Secondary，否则走 Primary。
WebSocket 侧多认一个
IsUsageLimitReachedError，改发 error 事件，带上同样的头。这是本刊从补丁分支读到的形状，不是发行版行为。它还没合并。
ntindle/CLIProxyAPI @ pr/codex-usage-limit-refusal 的 sdk/cliproxy/auth/usage_limit_refusal.go 第 113–156 行：第 128 行只查 error.type 一种信封，第 147–155 行按 1440 分钟分 Primary / Secondary 拼头。9它现在还不能用
自动评审在同一分钟给出三条意见，状态仍是未解决。1
第一条最要紧：补丁只读
error.type 一种信封。执行器那边读三种。10error.type、type、body.error.type，第 515–517 行依次都读。所以有些上游把类型放在外面，补丁会漏判，退回可重试的 429。这正是要拦的那一种。
internal/runtime/executor/codex_executor_terminal.go 第 504–534 行：第 515–517 行依次读三种信封，下方第 527 行起是 parseCodexRetryAfter，它同样在 error、整 body、body.error 三处找重置时间。10第二条：Home 模式下
Manager.Execute 走另一条路。第三条：错误被
fmt.Errorf 包一层后，payload 取自外层 Error()，不是 JSON。type 于是变成
rate_limit_error。有一处要对上。触发方记的是「评审后作者又推了一笔修正」，本刊没核到。
PR 上只有一个提交，作者时间与提交者时间都是 06:05:10（北京）。06:14:57 是评审完成的时刻。
我从
.diff 读到的仍是单信封版本，与「已修订」对不上。所以两条都摆出来，不下结论。1还有一张更早的单：
#6647，十月中旬开的，23 个文件，11-01 17:31（北京）重基到当前 dev。2两张谁先合，客户端看到的是同一个形状。差别是
#7184 多了 x-codex-* 头与 WS 错误事件。今晚在自己的站上按这个顺序做
先判是不是撞上了。看三处：错误体的
code 与 error.type、响应头的 Retry-After。第三处是客户端日志，看有没有
usage_limit_reached。只有
model_cooldown 配一个巨大的 Retry-After，就是撞上了。第二件：客户端侧没有开关。把
supports_websockets 关掉不改变结果，HTTPS 那条路一样带着这个头。摘号能立刻缓解，但有代价。把冷却中的凭证从池里摘光，下一个请求就没有可用账号，回的是 503。
503 同样停不下客户端，而且这时连「等多久」都没有了。
想要终局语义，眼下只有三条路，每条都不完整。
一是等。
#6647 已经重基，两张都还开着，什么时候合、合哪张，没人给时间。二是自己打
#7184。要接受三个缺口：单信封、Home 模式、包装错误。三是在你能改写响应的一层前置改。把冷却类 429 改成
X-Should-Retry: false 并删掉 Retry-After。这一条本刊没有实测，写法取决于你那层是什么。
第四件，无论走哪条，都把这个记进监控：
X-Should-Retry、reset_seconds、Retry-After 的量级。有这一条，下次客户端「一直在等」时，你不用翻代码就知道是不是这个形状。
这一小时没变的
四仓零发版。CLIProxyAPI v8.0.51 发布于北京 11-02 01:08，tag、main、dev 是同一个提交。12
sub2api 仍是 v0.2.19，停在 10-28。13
窗口内的条目：sub2api 只有一条四月的旧帖被顶起，codex-proxy 与 codex2api 都是零条。
上游三处都干净。OpenAI 全绿，最近一次事故 10-30 已恢复。16
额度侧：今日 UTC 没有重置。最近一次已验证的全局重置在 10-28 06:35（北京 14:35），五天前。19
另一家记的是 70 次重置、中位间隔 3 天、最长 68 天。20
官方社区 Codex 分区最新一条停在窗口前；Reddit 各板块窗口内的新帖是作品展示与普通提问，没有额度或封号线索。21
一条留到下期的：r/OpenAI 有人贴出官方通知，说 ChatGPT 与 Codex 将共用同一份 allowance，「coming weeks」。22
没有日期，也没有具体额度。同一天另一条帖子转述的是同一件事。23
本期不据此下判断，等它落地再算。
References
- 1
- 2PR 6647 上 11-01 的复述评论
github.com
- 3带超长 Retry-After 的原始报障单
github.com
- 4sdk/cliproxy/auth/selector.go at v8.0.51
github.com
- 5
- 6openai-python 的 _base_client.py
github.com
- 7anthropic-sdk-python 的 _base_client.py
github.com
- 8
- 9sdk/cliproxy/auth/usage_limit_refusal.go
github.com
- 10
- 11
- 12CLIProxyAPI v8.0.51
github.com
- 13sub2api v0.2.19
github.com
- 14codex-proxy v2.1.21
github.com
- 15codex2api v3.1.2
github.com
- 16OpenAI Status
status.openai.com
- 17Claude Status
status.claude.com
- 18Google Cloud Status
status.cloud.google.com
- 19codex-reset
codex-reset.com
- 20opentherank 的 Codex 重置统计
opentherank.com
- 21OpenAI 开发者社区 Codex 分区
community.openai.com
- 22
- 23
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.