同一句 “Selected model is at capacity”，四家中转判成四种事
同一句「Selected model is at capacity」在窗口内新开六条报障，上游承认是账号路由级准入；本期给出三种来路的判据、四家中转各自的判定与改写位置，以及今晚要动的四处配置。
10 月 21 日凌晨到上午，Codex 用户报的错是同一句：
Selected model is at capacity. Please try a different model.从上一期发稿（03:34）到现在的三个小时里，openai/codex 仓库新开了 6 条同主题的报障：#55784、#55781、#55778、#55758 的标题就是这句话，#55759 是这句加上前缀的完整报障单，#55789 标题换成「Pro 20x 账号跨模型被 server_overloaded 拒绝」，内容还是它12。报障人里有 Pro 20x，也有 Plus。
官方状态页此刻是全绿，组件栏没有降级项。窗口内唯一一条事故是
01M5E4G39TD1BW1QWHZG6RFA5H，02:26 立案，02:48 的更新里宣布各项服务已恢复，标题写的是 ChatGPT、Codex、API 一起降速3。这两件事放在一起，就排除了「平台容量塌了」这个解释。
上游自己说了这是什么
追踪了 13 天的 openai/codex #53569 在 05:50 更新了第 13 天记录。
报障人是 Pro 20x 订阅，用自己的 JSONL 会话日志逐条去重：10 月 9 日以来累计 875 次以上
serverOverloaded 拒绝，10 月 20 日的工作时段约 92% 的轮次被拒，今早又出现新的爆发4。同一份记录里更关键的是支持侧的口径：被拒的尝试通过了用量限制检查，案件被判定为账号与路由层面；10 月 20 日提交的 24 小时升级请求，10 月 21 日到期仍无人接手。
同一账号 92% 被拒、换一个账号就能用——这两条放在一起，指向的是凭证级准入，问题落在那几张凭证上。
社区里两条新帖印证了同一点：一条是 Plus 账号，5 小时额度还剩 77%、周额度剩 96%，只发一句「Hello, reply OK only」也报容量5；另一条是 Pro 账号，Sol、Astra、Luna 三个模型全中6。
所以这批单子的处置顺序，第一步就该落在凭证上：换号，看是不是只有那几张被卡住。
客户端看到的那句话，可能是中转给的
这里还有一层容易搞错的地方：用户屏幕上的这句话，可能由客户端自己翻译出来。
sub2api 和 codex2api 的源码注释各写过一遍同一件事：Codex CLI 对错误码按闭集分类，
server_is_overloaded 与 slow_down 被判为致命错误，客户端就地提示「Selected model is at capacity」并终止会话；落在闭集之外的 server_error 才会进入客户端自带的退避重试78。这两个项目各自独立地写了一行改写：把要发给客户端的降载码换成
server_error。两个仓库都这么干，说明这条客户端行为被反复验证过。于是同一句提示有了三层来路，各自要查的地方完全不同。
| 你看到的形态 | 在上游是什么 | 该往哪查 |
|---|---|---|
| 日志里 400 + 这句 message | 模型或分桶容量拒绝 | 该模型在池内的失败率 |
响应头已 200，流里一条 error / response.failed，code 是 server_is_overloaded | 降载被塞进流内，客户端只能终止 | 中转有没有在提交响应头前换凭证 |
| 同一请求换凭证就成功 | 账号/路由级准入 | 该凭证近 24 小时的拒绝计数 |
三种形态里，只有第三种需要动凭证；前两种动凭证也可能照样失败，因为被卡的是模型或请求本身。
四家中转的四种处置
四家里有三家直接认这句 message，codex-proxy 只认「503 加错误码」这一种形状。认出来之后做的事也各不相同，差别落在三处：判成什么、罚谁、给客户端什么码。
sub2api v0.2.17
sub2api v0.2.17，
backend/internal/service/openai_gateway_upstream_errors.go 第 148–175 行。第 156 行是这句 message 的匹配点，命中即返回 true，走临时错误分支。对账号，它记的是一条 (账号, 模型) 级的瞬时冷却，条件是 API Key 类账号、且不在池模式的可重试状态里10。冷却范围压到这个模型，账号照常接别的模型。
对客户端，它把
server_is_overloaded / slow_down 改写成 server_error，注释写明「保留原始降载码只会让客户端就地终止会话」，监控与账号判定仍用改写前的 payload7。
sub2api v0.2.17，
backend/internal/service/openai_gateway_passthrough.go 第 1343–1372 行。第 1348 行是改写目标码，第 1368 行只挑 server_is_overloaded 与 slow_down 两种原码动手。这一版没有对应开关，行为是默认的。
CLIProxyAPI v8.0.36
判定函数
isCodexModelCapacityError 认 model is at capacity、model_at_capacity 等四种写法，连 body 里同时出现 model 和 at capacity 也算11。认出来之后，它把这条错误一律折成 HTTP 429，但凭证级冷却只给
usage_limit_reached12。容量类错误不背凭证的账。
CLIProxyAPI v8.0.36，
internal/runtime/executor/codex_executor_terminal.go 第 315–330 行。第 320 行的 credentialScoped 只由 usage_limit_reached 决定，第 321–323 行把容量错误的状态码抬到 429。流内的那条终局帧它也认，
isCodexOverloadBootstrapFailure 的第一条判据就是容量错误。但换凭证要在提交响应头之前发生，而这取决于 upstream.codex.stream-bootstrap-buffering——config.example.yaml 第 387 行的默认值是 false13。默认配置下，流内降载会原样送到客户端；打开这一项，才会在提交前换成另一张凭证重试。
还有一处值得注意：
classifyCodexStatusError 里没有容量分支，所以抬到 429 的同时，body 里的 error.code 保持原样。客户端若按错误码判定，看到的仍是那个致命码。codex2api v3.1.1
它的处置写得最细：容量降载先在同一账号上退避重试，上限 2 次，用完才换号，全程不计账号连击与健康度14。
codex2api v3.1.1，
proxy/handler.go 第 2520–2540 行。第 2524 行是改写目标码，第 2529 行是同账号重试上限，第 2533–2540 行是退回旧行为的环境变量开关。给客户端的码同样改写成
server_error。退出这套行为的方法写在代码里：环境变量 CODEX_DISABLE_CAPACITY_SHED_HANDLING=1，退回「当普通 500 罚账号并立即换号」。codex-proxy v2.1.19
命中后换号，并标记
releaseBeforeRetry，注释写明不改账号健康与额度状态。代价是覆盖面：400 带这句 message、或 code 为
slow_down，都不进这条分支。今晚按顺序动的四处
- 先做换号对照。 同一个请求换一张凭证试一次，成功就说明是账号/路由级准入，后面三步按这个前提走。
- CLIProxyAPI 实例打开流内缓冲。 把
upstream.codex.stream-bootstrap-buffering设为true，默认是false；stream-bootstrap-timeout是时间预算，设了才封顶等待。 - 别整号停用。 sub2api 已经把冷却收到 (账号, 模型) 粒度；手工停整号会把还能接别的模型的凭证一起废掉。
- 核对客户端拿到的码。 你跑 sub2api v0.2.17 或 codex2api v3.1.1 时，客户端应收到
server_error；若客户端仍在看到容量提示后立刻终止，说明这条降载是从别的一层过来的，去查前置网关或直连上游那段。
同窗口另外三笔
sub2api #8266（05:31）：
main 分支上的 security-scan 两个 job 全红，且与具体 PR 无关。backend 是 GO-2026-6809，crypto/x509 位于 go1.27.2，修在 go1.27.3，而 backend/go.mod 和 CI 里的版本断言都还写着 1.27.2。frontend 是 follow-redirects 两条 high 级 advisory 没进 audit-exceptions.yml17。从 main 自建镜像的同学，这两条会跟着镜像走。CLIProxyAPI #6826（05:57）：Guardian 自动评审请求不继承父会话的凭证。父会话能正确识别出来（
x-codex-parent-thread-id 加 x-openai-subagent: guardian），但查绑定时用的键是 provider + "::" + fallbackID + "::" + modelKey，这里的 modelKey 是评审模型 codex-auto-review，父会话绑在 gpt-6.1-sol 上，永远查不中18。routing.session-affinity-subagents 默认已经是 true，也救不了这一条。后果落在流量形状上：某张凭证短时间吃进一堆
codex-auto-review，几乎没有正常模型请求，在上游看着像异常账号。要收口，眼下只能从排除名单下手，把 codex-auto-review 从大部分凭证上排掉、只留一小批承担评审。sub2api #8139 的反馈（05:52）：有人把上一期报的那版过载重试 bugfix 单独合并试了一遍，结果「没看到有好转，还是会提示上游报错」19。它说明这版修法只盖住了其中一个入口，这条链上还有第二个地方会把过载挡在重试之外。
上游与额度
status.openai.com 全绿；status.anthropic.com 全绿，今天无事件；Google Cloud 最近一条仍是 10 月 20 日 europe-west2 的那次（06:08 起、14:00 止）。额度侧没有新动静。codex-reset 显示最近一次已验证的全局重置停在 10 月 20 日 06:33（约 24 小时前），累计 56 次全局重置、10 张 banked20；opentherank 记到 64 次、中位间隔 3.1 天，更新至 10 月 20 日21。
换句话说，指望一次额度重置把这批容量拒绝冲掉，没有依据。
下一窗口盯什么
#53569 会不会有工程负责人接手，那句「24 小时升级请求过期未答」之后有没有下文。
四家里谁会先针对「账号级准入」加一个可调的判定：眼下 sub2api 压到 (账号, 模型)、codex-proxy 只认 503 一种形状，两端都还缺中间档。
#8266 的 Go 补丁版本与 follow-redirects 例外什么时候补上；#6826 会被接受还是被当成设计如此关掉。以及
#8139 那第二处入口，什么时候有人定位出来。References
- 1openai/codex #55789
github.com
- 2openai/codex #55784
github.com
- 3Degraded performance in ChatGPT, Codex, and APIs
status.openai.com
- 4openai/codex #53569
github.com
- 5Codex forum: Plus with 77%/96% left
community.openai.com
- 6Codex forum: Pro, all models
community.openai.com
- 7
- 8codex2api: handler.go 第 2520–2524 行
github.com
- 9
- 10
- 11
- 12
- 13CLIProxyAPI: config.example.yaml 第 387 行
github.com
- 14codex2api: handler.go 第 2520–2540 行
github.com
- 15
- 16
- 17sub2api #8266
github.com
- 18CLIProxyAPI #6826
github.com
- 19sub2api #8139 评论
github.com
- 20codex-reset.com
codex-reset.com
- 21opentherank Codex reset tracker
opentherank.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.