号池耗尽不再一律回可重试 429：CLIProxyAPI 拟加开关，尚未合并 (2026)

北京时间今天 12:14，CLIProxyAPI 仓库开出一张新补丁：给「号池全空时回什么」加一个开关。它不改选号逻辑，只改那一刻回给客户端的东西。1

到发稿时它还没有合并，也没有任何发行版带上它。本窗口四个实现都没有发版。

先说结论：今晚不用改任何配置，也没有可以升的版本。下面三件事按顺序：开关写在哪、打开之后三种协议各回什么、以及打开之后哪些请求仍然拿不到终局答复。

一、本窗口的版本位：四仓零发版

实现	当前版本	发布时间（北京）	分支头与版本的关系
CLIProxyAPI	v8.0.53	11-03 20:27	main 与 tag 同一提交，dev 另有提交
sub2api	v0.2.19	10-28 18:16	main 与 tag 同一提交
codex-proxy	v2.1.23	11-03 19:35	dev 比 main 新，未发版
codex2api	v3.1.3	11-04 10:22	main 与 tag 同一提交

四行就是本窗口的全部版本位。没有一个仓库推新版本，也没有一处改动与本条相关。

这张单的 base 分支是 dev，头分支在贡献者自己的仓库里，49 个文件、+1659/−47、6 笔提交。最近一笔在发稿前半小时内还落过一次。

二、开关在哪儿，默认是什么

键名 quota-response-mode，落在 routing.cooldown 段里，默认值 retryable——也就是什么都不变。2

两个取值说的是同一件事的两种态度。retryable 是原来的可重试 429 加 Retry-After；usage-limit 把它换成终局答复，让客户端停下来。

补丁在 `config.example.yaml` 里新增的注释块（第 237–243 行）：两种取值各是什么，以及只有「每张凭证都报显式耗尽、且最早重置在 5 分钟以外」才走终局。2

旧的顶层扁平键 quota-cooldown-response-mode 由配置迁移搬到这个新位置，老配置不用手改。

没设置时，这个键不会被写进保存或下发的配置；写成未知值，加载即失败。改完热重载就会生效，不用重启进程。

一句提醒：v8.0.53 的 config.example.yaml 里没有这个键，那一版也没有对应的实现。现在把它写进生产配置，只会让下一个接手的人以为已经开了。

三、打开之后，三种协议各回什么

OpenAI 兼容这一路，状态码仍是 429，但语义整个变了。

错误体保留 model_cooldown 原来的五个字段，再补 type: usage_limit_reached、resets_at、retryable: false，知道窗口时再补 limit_window_minutes。3

代码注释写明了为什么留着原来的 code：Codex 认的是 error.type，而老消费者还在读 model_cooldown。

`selector.go` 第 146–162 行：五个原字段原样保留，`usageLimit` 非空时才在下面追加 `type`、`resets_at`、`retryable`、`limit_window_minutes`——老客户端读到的 `code` 不变。3

头部才是关键的两条：X-Should-Retry: false，以及刻意不给 Retry-After。

不给的理由写在代码注释里：照着 Retry-After 睡的客户端会一觉睡过整个窗口，而不是停下来。4

知道窗口时，还按窗口长度选槽位：5 小时走 x-codex-primary-*，周窗口走 x-codex-secondary-*，各三件——已用 100%、窗口分钟数、重置时刻。

不知道窗口就一件都不给。注释里的原话是：猜出来的槽位没有意义。

`usage_limit_refusal.go` 第 71–83 行：`X-Should-Retry: false` 与三件 Codex 头在同一处构造，5 小时与周窗口按分钟数分流；注释说明不知道窗口时宁可一件头都不给。4

Anthropic 这一路的改法不一样：错误类型仍是 rate_limit_error，只在消息文本尾部追加 (reset after 2h19m…)，另给 resets_at 与 retryable: false。5

对照现在的 v8.0.53：同一处只有 code、message、model、reset_time、reset_seconds（后面再挂 provider 与 last_upstream_error）。没有 type，也没有 resets_at。6

所以今天客户端拿到的是一个普通 429 加 Retry-After，只能照着睡、照着重试。

四、三个条件必须同时成立，另有一道 5 分钟门槛

要走到终局答复，三个条件缺一不可。

一、这次请求能用到的每张凭证都在冷却。二、每张都是显式额度耗尽，不是普通 429、也不是指数退避。三、最早的重置时间在 5 分钟以外。

四个平台的耗尽证据各不相同：Codex 的 usage_limit_reached、OpenAI 兼容的 insufficient_quota、Gemini 与 Vertex 的 QUOTA_EXHAUSTED、Anthropic 统一后的 5 小时或 7 天拒绝。

只要有一张凭证不满足，池级判定就整条放弃，照旧回可重试。

`usage_limit_refusal.go` 第 186–229 行：资格循环与 5 分钟门槛。第 190 行跳过空、禁用与状态为禁用的凭证，第 193 行跳过零权重，第 215–218 行的 `skip` 出口让判定不了的情况直接略过该凭证，第 226 行把 5 分钟以内的重置判回可重试。7

第 226 行是整段最该看的一行：早于 5 分钟的重置被当成「马上就好」，不让它变成终局。反过来，它也是这个开关最容易误伤的地方——窗口快到点时，回的还是可重试。

第 193 行排除零权重凭证的理由写在注释里：加权选号根本不会选它，把它算进「全空」就是误判。

五、它够不到的三条路

PR 说明自己划了范围：只覆盖「还没发出任何响应字节之前」的失败，Responses、Chat Completions、Anthropic Messages 三个入口、流式非流式都在内。范围之外还有三条路。

一、Responses WebSocket。PR 说明写得很直白：留给后续一张约 50 行的补丁。而 Codex 默认走 WS——它要先回落到 HTTP，才会看到这个终局。

二、已经发出首字节之后的失败。代码注释写的是「还没流出任何东西，所以用量上限可以顶替掉失败」；反过来说，流一开就换不回来。

*`conductor_execution.go` 第 317–331 行：终局答复只在流还没吐出任何字节时替换失败；三个入口（Execute、ExecuteCount、ExecuteStream）都接在同一层调用上。8*

三、Home 模式。池级判定的第一行就是「开关没开、或 Home 开着，直接返回」。7

评审提出的两条漏洞，第 5 笔提交里已经补上。

Antigravity 的 count_tokens 分支过去只补 retryAfter、不写额度耗尽证据，现在第 364 行也调了配额判定。9

状态为禁用的凭证过去仍被算成「合格」，于是本该回可重试的场合被压成终局；第 190 行现在直接跳过。10

最新一笔（第 6 笔，13:22）继续补覆盖：aistudio 与 OpenAI 兼容执行器也开始记证据，池级判定加了上面那个 skip 出口。

自动评审在发稿时正在这一笔上跑，结论没出来；10 条行内意见也还没有已解决的标记。这张单能不能合、合之前还改几笔，现在都还没有答案。

六、今晚的操作顺序

第一件事是别提前改配置。键在 v8.0.53 里不存在，写进去不产生这个行为，只会误导下一个人。

第二件事是自查哪几张凭证走原生 WS。管理端凭据清单每条带 websockets 字段，为真即说明原生 WS 在跑——对这类凭证，终局答复不生效。11

第三件事是盯 dev 与下一个 v8 版本，看这张单有没有被合并进来。

真要试，先在一个非生产池上开 usage-limit，用三种协议各打一发 429 看实际返回，再决定要不要上生产。

七、上游与重置

上游这半天没有新事故。OpenAI 与 Anthropic 状态页全绿。12 13

Google Cloud 最近一条仍是 10-28 的欧洲西部多服务事件，级别已回到可用。14

Codex 的重置今天没有落地：今日 UTC 未重置，最近一次已验证的全局重置是 10-28 06:35 UTC（北京时间 14:35），已经七天。15

一家追踪站的口径是 61 次全局重置、10 张存票，节奏约每两天一次；另一家统计 71 次、中位间隔 2.9 天、最长 68 天。16

两家的累计数本来就不一致，看节奏、别看绝对值。

今晚的动作只有一个：把这张单存进观察名单。它决定的不是今天回什么，而是下一版里，客户端在额度真正用尽时会不会自己停下来。

References

1
PR #7239 quota-response-mode
github.com
2
补丁新增的配置注释
github.com
3
selector.go 错误体
github.com
4
selector.go 响应头
github.com
5
Anthropic 错误文本后缀
github.com
6
v8.0.53 的同一个错误体
github.com
7
池级资格判定
github.com
8
首字节之前的替换点
github.com
9
Antigravity 状态错误补证据
github.com
10
评审：状态禁用凭证仍被计入
github.com
11
凭据清单的 websockets 字段
github.com
12
OpenAI 状态页
status.openai.com
13
Anthropic 状态页
status.anthropic.com
14
Google Cloud 状态页
status.cloud.google.com
15
重置追踪与统计
codex-reset.com
16
另一家的累计口径
opentherank.com

北京时间今天 12:14，CLIProxyAPI 仓库开出一张新补丁：给「号池全空时回什么」加一个开关。它不改选号逻辑，只改那一刻回给客户端的东西。1

到发稿时它还没有合并，也没有任何发行版带上它。本窗口四个实现都没有发版。

一、本窗口的版本位：四仓零发版

实现	当前版本	发布时间（北京）	分支头与版本的关系
CLIProxyAPI	v8.0.53	11-03 20:27	main 与 tag 同一提交，dev 另有提交
sub2api	v0.2.19	10-28 18:16	main 与 tag 同一提交
codex-proxy	v2.1.23	11-03 19:35	dev 比 main 新，未发版
codex2api	v3.1.3	11-04 10:22	main 与 tag 同一提交

四行就是本窗口的全部版本位。没有一个仓库推新版本，也没有一处改动与本条相关。

这张单的 base 分支是 dev，头分支在贡献者自己的仓库里，49 个文件、+1659/−47、6 笔提交。最近一笔在发稿前半小时内还落过一次。

二、开关在哪儿，默认是什么

键名 quota-response-mode，落在 routing.cooldown 段里，默认值 retryable——也就是什么都不变。2

两个取值说的是同一件事的两种态度。retryable 是原来的可重试 429 加 Retry-After；usage-limit 把它换成终局答复，让客户端停下来。

旧的顶层扁平键 quota-cooldown-response-mode 由配置迁移搬到这个新位置，老配置不用手改。

没设置时，这个键不会被写进保存或下发的配置；写成未知值，加载即失败。改完热重载就会生效，不用重启进程。

一句提醒：v8.0.53 的 config.example.yaml 里没有这个键，那一版也没有对应的实现。现在把它写进生产配置，只会让下一个接手的人以为已经开了。

三、打开之后，三种协议各回什么

OpenAI 兼容这一路，状态码仍是 429，但语义整个变了。

错误体保留 model_cooldown 原来的五个字段，再补 type: usage_limit_reached、resets_at、retryable: false，知道窗口时再补 limit_window_minutes。3

代码注释写明了为什么留着原来的 code：Codex 认的是 error.type，而老消费者还在读 model_cooldown。

头部才是关键的两条：X-Should-Retry: false，以及刻意不给 Retry-After。

不给的理由写在代码注释里：照着 Retry-After 睡的客户端会一觉睡过整个窗口，而不是停下来。4

知道窗口时，还按窗口长度选槽位：5 小时走 x-codex-primary-*，周窗口走 x-codex-secondary-*，各三件——已用 100%、窗口分钟数、重置时刻。

不知道窗口就一件都不给。注释里的原话是：猜出来的槽位没有意义。

Anthropic 这一路的改法不一样：错误类型仍是 rate_limit_error，只在消息文本尾部追加 (reset after 2h19m…)，另给 resets_at 与 retryable: false。5

所以今天客户端拿到的是一个普通 429 加 Retry-After，只能照着睡、照着重试。

四、三个条件必须同时成立，另有一道 5 分钟门槛

要走到终局答复，三个条件缺一不可。

一、这次请求能用到的每张凭证都在冷却。二、每张都是显式额度耗尽，不是普通 429、也不是指数退避。三、最早的重置时间在 5 分钟以外。

只要有一张凭证不满足，池级判定就整条放弃，照旧回可重试。

第 193 行排除零权重凭证的理由写在注释里：加权选号根本不会选它，把它算进「全空」就是误判。

五、它够不到的三条路

一、Responses WebSocket。PR 说明写得很直白：留给后续一张约 50 行的补丁。而 Codex 默认走 WS——它要先回落到 HTTP，才会看到这个终局。

二、已经发出首字节之后的失败。代码注释写的是「还没流出任何东西，所以用量上限可以顶替掉失败」；反过来说，流一开就换不回来。

三、Home 模式。池级判定的第一行就是「开关没开、或 Home 开着，直接返回」。7

评审提出的两条漏洞，第 5 笔提交里已经补上。

Antigravity 的 count_tokens 分支过去只补 retryAfter、不写额度耗尽证据，现在第 364 行也调了配额判定。9

状态为禁用的凭证过去仍被算成「合格」，于是本该回可重试的场合被压成终局；第 190 行现在直接跳过。10

最新一笔（第 6 笔，13:22）继续补覆盖：aistudio 与 OpenAI 兼容执行器也开始记证据，池级判定加了上面那个 skip 出口。

自动评审在发稿时正在这一笔上跑，结论没出来；10 条行内意见也还没有已解决的标记。这张单能不能合、合之前还改几笔，现在都还没有答案。

六、今晚的操作顺序

第一件事是别提前改配置。键在 v8.0.53 里不存在，写进去不产生这个行为，只会误导下一个人。

第二件事是自查哪几张凭证走原生 WS。管理端凭据清单每条带 websockets 字段，为真即说明原生 WS 在跑——对这类凭证，终局答复不生效。11

第三件事是盯 dev 与下一个 v8 版本，看这张单有没有被合并进来。

真要试，先在一个非生产池上开 usage-limit，用三种协议各打一发 429 看实际返回，再决定要不要上生产。

七、上游与重置

上游这半天没有新事故。OpenAI 与 Anthropic 状态页全绿。12 13

Google Cloud 最近一条仍是 10-28 的欧洲西部多服务事件，级别已回到可用。14

Codex 的重置今天没有落地：今日 UTC 未重置，最近一次已验证的全局重置是 10-28 06:35 UTC（北京时间 14:35），已经七天。15

一家追踪站的口径是 61 次全局重置、10 张存票，节奏约每两天一次；另一家统计 71 次、中位间隔 2.9 天、最长 68 天。16

两家的累计数本来就不一致，看节奏、别看绝对值。

今晚的动作只有一个：把这张单存进观察名单。它决定的不是今天回什么，而是下一版里，客户端在额度真正用尽时会不会自己停下来。

References

1
PR #7239 quota-response-mode
github.com
2
补丁新增的配置注释
github.com
3
selector.go 错误体
github.com
4
selector.go 响应头
github.com
5
Anthropic 错误文本后缀
github.com
6
v8.0.53 的同一个错误体
github.com
7
池级资格判定
github.com
8
首字节之前的替换点
github.com
9
Antigravity 状态错误补证据
github.com
10
评审：状态禁用凭证仍被计入
github.com
11
凭据清单的 websockets 字段
github.com
12
OpenAI 状态页
status.openai.com
13
Anthropic 状态页
status.anthropic.com
14
Google Cloud 状态页
status.cloud.google.com
15
重置追踪与统计
codex-reset.com
16
另一家的累计口径
opentherank.com

号池耗尽不再一律回可重试 429：CLIProxyAPI 拟加开关，尚未合并

一、本窗口的版本位：四仓零发版

二、开关在哪儿，默认是什么

三、打开之后，三种协议各回什么

四、三个条件必须同时成立，另有一道 5 分钟门槛

五、它够不到的三条路

六、今晚的操作顺序

七、上游与重置

References

Related content

号池耗尽不再一律回可重试 429：CLIProxyAPI 拟加开关，尚未合并

一、本窗口的版本位：四仓零发版

二、开关在哪儿，默认是什么

三、打开之后，三种协议各回什么

四、三个条件必须同时成立，另有一道 5 分钟门槛

五、它够不到的三条路

六、今晚的操作顺序

七、上游与重置

References

Related content