10/20 夜间速报：付费 20X 档整批 503，本地只有一条路会把账号标掉
付费 20X 档账号成批回 503，本期给出本地判断的两条路：过载那条不写账号，带 code 的账号态错误才留下提示与落选；另附 TTFT 口径已进 dev 与新的选号策略。
北京 17:13 到 18:27 这七十多分钟，四个中转仓库没有新版本发布。
CLIProxyAPI 的 dev 主干往前挪了一格，还合掉一张补丁；main 没动。sub2api 的主干停在昨晚，codex-proxy 与 codex2api 窗口内一条条目都没有。
真正要看的是同一张报障单：一小时里又来了八条同类回复，把开单时的档位结论推翻了。
下面的记号只说明改动走到哪一步。标「已进 dev」的还在分支上，标「未合并」的连 dev 分支都没进。
影响面：从一个人的自述变成一整档号
单 #8239 是 15:38 开的，标题问的是 pro200 为什么频繁回 503「Our servers are currently overloaded」1。
开单时的一句话是「pro100 的反而没事，在同一个服务器网段下」。
到 18:01，这句话被推翻：有人回「10 个号都是……pro 100 跟 pro 200 从早上 10 点就开始 overloaded 了」2。
17:56 的另一条给了边界：「大都是 20X 的账号出问题，plus 没问题」3。
于是现在能写下的只有：付费 20X 档（pro100 与 pro200）集中中招，plus 这一档还没有人报。
哪个档位更重、从几点开始，这批自述彼此对不上，先按方向看。维护者到现在仍是零回应、0 标签，回复数停在 14 条。
窗口内那八条，除了上面两条判档位的，其余都是同一句：3 个 200 刀的号一直 503、「一样」、「刚刚出现，隔一会就报 503」，外加两张截图。
报障人 small-xiexu 在 17:29:01 刷新的面板截图（原图 2368×1440，本人在 17:29 那条回复里贴出）。近 1 小时 131 个请求、26 个错误、请求错误率 19.85%、SLA 80.15%；上游错误占比 25.95%，其中「429/529」这一栏记的是 0；TTFT 的 P99 是 21,200 毫秒，请求时长 P99 是 210,584 毫秒。
这张图给了两条判据。
头一条：429 与 529 都是 0。限流会落在这两栏里，这里空着，说明上游没按速率拒它。
第二条：上游错误 34 条，最后算成请求错误的 26 条。差的 8 条，被同一次请求里的重试吃掉了。
重试在起作用，只是没救回全部。
本地只有一条路会把账号标掉
sub2api 收到上游非 2xx 之后，先过同一个函数。
第一条分支认的是过载：响应里出现「servers are currently overloaded」这几句，函数直接返回，账号上什么也不写4。
那句注释写得比文档清楚：容量让渡描述的是这次请求，与账号健康无关。
第二条分支认的是账号态：上游回了一个「账号不可用」的 code，它才把提示写进账号、把该号从可选集合里摘掉5。
同一文件第 104–125 行。上半段第 106–107 行命中过载就
return false，一行状态都不写；下半段第 117 行写账号错误、第 120 行调 BlockAccountScheduling 把这号摘出去，第 122 行 return true。两条路的分歧就在这十几行里。哪些 code 算账号态，代码里是逐条列出来的：
deactivated_workspace，以及 workspace、account、organization、org 与 deactivated、disabled、suspended 的组合6。判它的时候不看 HTTP 状态码，只看这个 code 在不在响应体里7。
封锁也不是永久的：调用时传的是零值时间，函数里会兜成两分钟8。
于是开单人自问的那句「是不是 8 月前开通的老号被标记了」，可以按事实拆成两种情形。
真被标记时，上游会给一个上面那类 code，本地留下两样东西：账号上的一句提示，和至少两分钟的落选。
只回 overloaded 的那种，账号上什么也不会多。你在账号表里查不到痕迹，原因是它压根没写进那本账。
今天怎么处置
按顺序，四步。
- 先看两个数：近一小时的上游错误率，以及面板里 429/529 那一栏。像上图那样两成以上的上游错误、429/529 记 0，就是上游降载。
- 再去账号详情找那句提示，看该号有没有从可选集合里消失。两处都干净，说明本地把它判成了请求级，账号这一层不用动。
- 批量停号在这一类里是白费。这条错不写账号状态，停掉只会把本就不足的池子改小。
- 临时不可调度规则按错误来加，加到这一类上会把正常号一起隔离出去。
还有一个数字值得先算一遍：整档被打中时，一次客户端请求会打出多少次上游调用。
同账号先重试，默认 3 次9。这句过载被标成了请求级瞬时故障，所以退避会翻倍：500 毫秒、1 秒、2 秒。
换号上限默认 10 个10。
两者串起来，最坏情况是 40 次上游尝试、仅等待就超过 30 秒，最后才把 503 还给客户端。
整档都中招时，把
gateway.max_account_switches 调小更实用：客户端早点拿到 503，连接能腾给别的模型。这是一个取舍，用更快的失败换更短的等待。账面上倒安心：没有产出，就没有可记的用量，用量只在拿到上游返回的用量数字时写入11。
所以这一批 503 落在错误率与 SLA 那一栏，消费金额那一栏基本不动。对外解释的时候，把这两栏分开说。
CLIProxyAPI：TTFT 的口径换了，已经进 dev
17:35 那张补丁合进了 dev：
c6447551，2 笔提交、5 个文件 +353/−312。第二笔提交（17:17，
f434192）补的是同一件事的另一半：只写在「完成项」里的推理内容，以前不计入首个有效输出。结果报出来的是「首个 body 读完」的时间，而上游开始吐内容要晚得多。
作者给的回归数字可以对照：响应头 10 毫秒到、首个 body 100 毫秒到、首个有效内容 1000 毫秒到。修之前报 100 毫秒，修之后报 1000 毫秒。
dev 现在改调共享的判定函数，那个函数新加的一段专门管推理项：
response.output_item.done 里属于 reasoning 的，会读 item.summary 与 item.content，文本非空才算有效输出14。
dev 分支
responses_ttft_helpers.go 第 77–100 行：第 84–92 行是 reasoning 分支，只认 summary 与 content 里非空的 text；空的、只有密文的仍然返回假，继续等终局事件。对读者只有一个动作：升到含这笔改动的版本之后，Meta 那条路径的 TTFT 会往上跳一个数量级。
历史曲线和新数字摆在一起会失真，切换后要重新取一次基线。
v8.0.35 里还是旧写法，现在的发行版照旧。
新的选路策略：三种选择器，可以按 provider 覆盖
18:07 开了一张新补丁 #6796，8 个文件 +529/−14、mergeable clean，还在门口15。
它加三种选择器，三种都建立在同一个量上：这张凭证在这个模型上、最近 60 秒里已经发出的请求数。
random 均匀抽。least-used 取最近发得最少的那个。p2c 随机抽两张，挑其中较少的那个。三种都保留优先级层与冷却，行为跟内置的轮询一致；平手时按候选顺序取。
PR 头分支的
config.example.yaml 第 149–156 行：第 150 行把三个新名字接在原有的三个之后；第 154–155 行是 provider-strategies 的缩进层级，示例给 codex 用 p2c。两个细节值得记住。
它计的是「已开始的请求数」这一个量：请求发出去就计数，跟并发数和延迟无关。所以它均匀的是发起频率。
会话亲和仍然优先：绑定赢，策略只管首轮与重绑。
未知的策略名会被丢掉，与全局策略相同的条目也会被丢掉，这样重载配置时选择器状态才可比。
这版还没合并，今天的配置里写不了它。发行版现在能用的是 round-robin、weighted-round-robin、fill-first 三种。
上游：伦敦区出了 workaround
谷歌云那条仍在进行的事故，17:24 的更新第一次给了处置办法：如果可行，可以把受影响的负载迁到其它可用位置，zone 或 region17。
受影响产品从上一版公告的 31 个增加到 38 个，受影响区域仍然只有 europe-west2 一个。
清单里仍然没有 Vertex AI，也没有 Gemini API。
下一次更新承诺在北京 19:00。
对中转站，要动的还是那两处：Vertex 凭证把 location 钉在 europe-west2 的，和自建服务跑在伦敦区的。其余继续看数字就行。
这一小时的其余状态
| 仓库 | 当前发行版 | 主干最新提交 | 窗口内 |
|---|---|---|---|
| CLIProxyAPI | v8.0.35，10-20 03:02 发布18 | main 12:23、dev 17:35 | 一张补丁合进 dev |
| sub2api | v0.2.17，10-16 12:41 发布19 | main 10-19 20:45 | 三条条目变动 |
| codex-proxy | v2.1.19，10-20 05:10 发布20 | dev 10-20 04:57 | 无 |
| codex2api | v3.1.1，10-17 05:46 发布21 | main 10-17 05:35 | 无 |
sub2api 那三条里只有 #8239 是新的。#6906（TOKEN 计费为 0）与 #764（交流长帖）都是被顶起来的旧条目。
CLIProxyAPI 窗口内三条：#6794 已合、#6796 新开、#6715 被顶起。
上游与额度
- OpenAI 状态页全绿，0 个活动事件、0 个降级组件22。
- Anthropic 全绿，今天没有事件23。
- 谷歌云见上一节，事故仍在进行，已给出 workaround。
- Codex 重置：最近一次仍是今天 14:33，四小时前，窗口内没有新重置；两家追踪站分别记 56 次与 64 次2425。
- 官方社区 Codex 分区窗口内 0 条新话题，最新仍是 14:51 那条用量归属帖26。
这一小时没有版本可升。
能带走的是那个分界：过载走一条路，账号上什么都不留；带 code 的账号态错误走另一条，留下提示与落选。下次再遇到整片 503，先在账号表里找那句提示，找不到就把力气放在等和分流上。
References
- 1sub2api issue 8239
github.com
- 2yuanhaoliang 18:01 的回复
github.com
- 3zdy-zg-QQ 17:56 的回复
github.com
- 4
- 5同一文件第 111–125 行
github.com
- 6
- 7同文件第 443–447 行
github.com
- 8
- 9v0.2.17 failover_loop.go 第 34–41 行的常量
github.com
- 10v0.2.17 config.go 第 2435 行
github.com
- 11v0.2.17 openai_gateway_usage.go 第 94 行
github.com
- 12CLIProxyAPI PR 6794
github.com
- 13
- 14dev responses_ttft_helpers.go 第 77–100 行
github.com
- 15CLIProxyAPI PR 6796
github.com
- 16PR 头分支 config.example.yaml 第 149–156 行
github.com
- 17Google Cloud 事故 Xs2XTHzAVC9YnafnPyzj
status.cloud.google.com
- 18CLIProxyAPI releases
github.com
- 19sub2api releases
github.com
- 20codex-proxy releases
github.com
- 21codex2api releases
github.com
- 22OpenAI Status
status.openai.com
- 23Anthropic Status
status.anthropic.com
- 24codex-reset.com
codex-reset.com
- 25OpenTheRank Codex Reset Tracker
opentherank.com
- 26Codex usage chart attributes ~80% of usage to gpt-6-astra
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.