Claude 五款模型同时报错：同一个 529，两家中转停的不是同一件东西
Claude 五款模型同时在报错，同一张 529 在 CLIProxyAPI 里只压住那个模型 60 秒，在 sub2api 里会把整个账号摘走 10 分钟：两条路的源码位置、可改的配置项，以及 Codex 重置已推送的两个口径。
14:14，Anthropic 状态页开出一条 major 级事件：Claude Mythos 5.1、Fable 5.1、Opus 5.5、Sonnet 5.5、Haiku 5.5 五款模型的错误率同时升高1。claude.ai、Claude API、Claude Code、Claude Cowork 四个组件一起转成 partial_outage，状态停在 investigating，没有 ETA。
同一小时里，Codex 那边落了另一条：Tibo 在 14:06 说重置已经全部推送完成2。
两块都要改你今晚的调度。真正容易踩的地方在本地：同样一张 529 进来，CLIProxyAPI 只让那个模型歇 60 秒，sub2api 会把整个账号从号池里摘掉 10 分钟。下面逐行核这两条路。
一、Claude 这一轮：7 天 6 次，30 小时里 4 次
先看频次，它决定这算不算「等一会儿就好」。
| 开始（北京时间） | 等级 | 事件 |
|---|---|---|
| 10-24 07:37 | critical | Fable 5.1、Sonnet 5.5、Haiku 5.5，及 Opus 5.5 的 fast 模式 |
| 10-24 08:31 | major | Opus 5.5 |
| 10-24 13:16 | major | Fable 5、Fable 5.1 |
| 10-25 14:14 | major | 五款 5.1 与 5.5 模型，进行中 |
四条模型类事件挤在 30 小时出头里，全部是 elevated errors。同一周里还有两条：10-22 03:49 的 Fable 5 性能降级、10-22 11:50 的 Connectors 报错，所以状态页上七天内的记录一共六条3。
事件说明只写 elevated errors，不写具体状态码。按 Anthropic 自己的错误码表，这类时段客户端拿到的是 500 api_error 与 529 overloaded_error4。
对中转站的意思很直接：接下来一段时间，Claude 这条路的 5xx 会比平时密。你的实现怎么给 5xx 记账，决定号池是被轻轻碰一下，还是被整段摘走。
二、529 进来，两家中转停的不是同一件东西
CLIProxyAPI：只让那个模型歇 60 秒
v8.0.42 把瞬时错误写死在一个 switch 里：408、500、502、503、504，加上 520 到 5265。
529 不在这份名单上，它落进 default，调用的是同一个时长函数。差别只有一个：default 不读上游给的 retry-after，一律按本地配置算。
关键在作用对象。这个 state 建在 modelKey 里面，所以 529 压住的是「这张凭证上的这个模型」，同凭证的其它模型照常参与调度。
时长默认 60 秒，配置里那句注释只提 408、500、502 至 504 与 520 至 526；写 0 保留 60 秒，写 -1 就干脆不冷却6。
全池都在冷却时，客户端拿到 429，body 里 code 是 model_cooldown，头里带 Retry-After，倒计时是秒数7。
sub2api：把整个账号摘走 10 分钟
sub2api v0.2.18 给 529 单独开了分支 handle5298。它读过度载冷却配置，算出截止时间，写进账号行。
默认开着，冷却 10 分钟；面板里可调 1 到 120 分钟9。
关键同样在作用对象。写的是账号表上的 overload_until，而调度判定一看到它落在未来就直接返回 false10。停的是整个账号，不分模型。
对只跑 Claude 的号，这两种停法是一回事；对同号兼跑别的模型的部署，那些模型会一起不可调度。
第二个差别是 500 不走这条。同一个函数末尾，没启自定义错误码时，statusCode >= 500 只打一条 warn 日志，不写任何账号状态11。今晚上游回 500 你丢的是这一单，回 529 你丢的是这个号十分钟。
池模式干脆不记
如果这个号开了池模式、又没启用自定义错误码，整个处理在更前面就退出了，日志写一句 pool_mode_error_skipped12。529 不写 overload_until，也不产生冷却。
这不是更安全或更危险，是两种取舍。池模式把上游过载当成请求级的事，交给同账号重试和换号消化；单号模式把它当成账号健康的事，宁可停十分钟。
各条路的代价也不同：CLIProxyAPI 在池子冷却空之后回的是 429 加倒计时，sub2api 把号摘空之后回的是 no available accounts 那一类回执13。
| CLIProxyAPI v8.0.42 | sub2api v0.2.18 | |
|---|---|---|
| 529 归属 | default 分支 | handle529 专属分支 |
| 停什么 | 该凭证上的那个模型 | 整个账号 |
| 停多久 | 60 秒，配置 key 可改 | 10 分钟，面板可调 1 至 120 |
| 500 呢 | 同样 60 秒 | 只记日志，不停 |
| 池模式 | 照常冷却 | 完全跳过 |
| 客户端看到 | 429 model_cooldown 加 Retry-After | 池空后 no available accounts |
今天能做的三件事
第一，先确认自己走哪条。sub2api 有现成接口：
GET 与 PUT /api/v1/admin/settings/overload-cooldown，先读一眼 enabled 与 cooldown_minutes14。第二，号多的部署可以把 10 分钟压到 2 到 3 分钟。事件期间 529 会反复来，一轮十分钟的整号下线会把池子摊薄得很快，而回 500 的单子本来就不记状态。
第三，跑 CLIProxyAPI 的看住那个配置项。它同时管 500 与 529，若被写成 600，等于每个模型各歇十分钟；写成 -1 则完全不冷却，代价是同一张坏凭证会被反复挑中。
三、Codex 重置：官方说推送完了，追踪站还没认
14:06 那条帖子的原话是「It is all propagated. Enjoy some mad codexing tomorrow」，它引用的是 11:40 那句 By midnight PST15。承诺的时点是太平洋午夜，按当时生效的夏令时算是北京 15:00，按字面 PST 算是 16:00；实际确认落在 14:06，比承诺早。
13:30 还有一条回复 @theo 的：Not a real improvement, put the reset in the bag16。
追踪站的两个口径都还没跟上。首页仍写今天还没重置（按 UTC 计），最近一次已验证的全局重置还是北京 10-23 01:10，累计 57 次、10 张 banked、节奏约每两天17。
它的接口里，今天这条事件的登记时间已经推到 14:10，验证状态仍是 pending18。
两个口径不必替读者裁定。官方说已推送，追踪站说未验证，你要的是用户自己那一格：让他跑一次
/status 读限额窗口的重置时间，比任何追踪站都准。四、sub2api 两张待审 PR：一张治报错，一张防更新器
两张都在 13:43 左右由 YogurtJ 提交，都对着 main，mergeable 都是 unstable，各只有一笔提交。
#8330：中途换工具会撞 tool_reference_unresolved。作者的触发条件是客户端工具超过五个，然后在对话中途删掉其中一个19。
v0.2.18 的工具名重写只覆盖三处：tools 数组里的 name、tool_choice 的 name，以及 messages 里 type 为 tool_use 的 name20。
tool_addition 与 tool_removal 块里的 tool_reference 不在其中。声明被改名、引用保留原名，两边对不上，上游就回那句 tool_reference_unresolved。
这张单把三类引用一起补上，另加回归测试，3 个文件 +206/−2。你如果见过这条报错且客户端工具超过五个，可以先按它的改法自查，不必等合并。
#8331：自建版本会被更新器覆盖。parseVersion 只按短横杠截断，再按点切分21。
0.2.18+local.1 没有短横杠，第三段是 18+local，转整数失败就变成 0。整串于是被当成 0.2.0，更新器认为官方 0.2.18 是新版本，点一下就把你的自建产物换掉22。
自查很便宜：看后台显示的版本号里带不带加号。带的话先别点更新，或者等这张 2 文件 +73/−1 的单合进来。
五、四仓读数
| 仓库 | 当前版本 | 发布时间（北京） | 主干头 | dev 头 |
|---|---|---|---|---|
| CLIProxyAPI | v8.0.42 | 10-24 22:21 | 10-24 22:17 | 10-25 11:39 |
| sub2api | v0.2.18 | 10-23 15:44 | 10-25 13:32 | 停在 3 月 |
| codex-proxy | v2.1.20 | 10-23 03:56 | 10-21 09:58 | 10-23 03:54 |
| codex2api | v3.1.1 | 10-17 05:42 | 10-24 19:52 | 无 dev 分支 |
窗口内四仓零新版本、零新提交。CLIProxyAPI 的 v8.0.42 停在 10-24 22:2123，sub2api 的 0.2.18 停在 10-2324，codex-proxy 与 codex2api 更早25。
条目侧只有两处动过：上面两张 sub2api 的单，以及 CLIProxyAPI #5764。后者 updated_at 变到 14:09，提交仍是 2026-09-12 那两笔，属作者又一次重基26。
说明
Claude 这条事件在我写稿时仍是 investigating，Anthropic 尚未给出恢复时间。它的等级、受影响模型与组件都可能再变，判断以状态页为准；本文引用的代码行是 v8.0.42 与 v0.2.18 两个发行标签的现状，不涉及 dev 上未发布的分支。
References
- 1Elevated errors for multiple models
status.claude.com
- 2It is all propagated
x.com
- 3Claude status incidents
status.claude.com
- 4API errors
platform.claude.com
- 5conductor_cooldown.go 第 1216-1228 行
github.com
- 6config.example.yaml 第 218-222 行
github.com
- 7selector.go 第 349-362 行
github.com
- 8ratelimit_service.go 第 2018-2052 行
github.com
- 9settings_view.go 第 613-618 行
github.com
- 10account.go 第 194-214 行
github.com
- 11ratelimit_service.go 第 583-596 行
github.com
- 12ratelimit_service.go 第 340-348 行
github.com
- 13gateway_service.go 第 423 行
github.com
- 14routes/admin.go 第 584-585 行
github.com
- 15By midnight PST
x.com
- 16
- 17Codex Reset
codex-reset.com
- 18codex-reset feed
codex-reset.com
- 19PR 8330
github.com
- 20gateway_tool_rewrite.go 第 177-232 行
github.com
- 21update_service.go 第 656-669 行
github.com
- 22PR 8331
github.com
- 23CLIProxyAPI v8.0.42
github.com
- 24Sub2API 0.2.18
github.com
- 25codex-proxy v2.1.20
github.com
- 26PR 5764
github.com
- 27OpenAI status
status.openai.com
- 28Google Cloud incidents
status.cloud.google.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.