凭证耗尽时 WebSocket 直接断线：一句用户消息换来 21 次重连、30–45 秒空等
四仓本窗口零发版，四条新条目里最该动手的是：凭证耗尽时 Responses WebSocket 不返 429 而是裸关连接，一句用户消息换来约 21 次重连、30–45 秒空等，另附三条翻译层与 Antigravity 号池风险的可执行处置。
四个仓库在这个窗口里都没有发新版本：CLIProxyAPI 停在 v8.0.55，sub2api 还是 10-28 的 v0.2.19，codex-proxy v2.1.23、codex2api v3.1.3 也没动1234。
所以本期没有「该升级的版本」，只有四条新条目：两条 CLIProxyAPI 报障、两条 sub2api 补丁。
今晚真正要动手的是第一条。凭证耗尽时，Responses WebSocket 不告诉客户端「没额度了」，而是把连接直接关掉。
凭证耗尽，WebSocket 选择裸关闭
今晨 06:08 的报障把这件事量化了5。
场景是单张 Codex OAuth、插件调度、客户端 T3 Code 0.166.0 走
responses_websockets=2026-02-06，配置里 request-retry: 0、disable-cooling: true。上游明确回了
{"error":{"type":"usage_limit_reached"}}，但每条用户消息最终变成约 21 次失败的上游执行，耗时 30 到 45 秒。报障人记了五段：21 次失败用 27 秒，33 次用 78 秒，另三段都是 21 次、43 到 45 秒。
客户端看到的是一次异常断开，不是 429；日志里刷的是
upstream execution session closed。原因在错误分类这一层。
shouldExposeResponsesUpstreamError 只放行两类：凭证终局错误，或者请求本身有形状问题6。其余一律保持安静。注释给的理由是：新连接本来就要重放整段上下文，重连即等于全文重发。
429 恰好被排除在「请求形状问题」之外。
IsRequestFault 在 402 与 429 上直接返回 false，注释说这两种状态是权威的、凭证必须留给冷却与轮换7。
sdk/api/handlers/openai/openai_responses_websocket_forward.go 第 386–424 行：分类函数只把请求形状类错误交出去；静默分支先写一条 timeline 的 disconnect，再调 closeWithoutError()，注释明写「否则事后无法诊断」。6
internal/clienterror/client_error.go 第 76–99 行：IsRequestFault 在 402 与 429 上直接返回 false，注释写「凭证必须仍然可冷却、可轮换」——这正是 429 落进静默分支的直接原因。7这个函数直接从服务端关连接、不发 close frame，客户端看到的就是一次异常断开9。
行为还被测试固定住了：用例名就叫
quota exhausted，注释写「凭证轮换已经跑过并输了，客户端只需要重连，因此不产生下游错误」10。代价不止等待。按同一段注释的逻辑，每次重连都要重放整段上下文，一条消息 21 次重连就是 21 次全文重传，吃的是同一份额度。
用户也从头到尾看不到「额度用完了」这句话，看不到重置时间。
今晚能做什么
先说哪些没用。
routing.cooldown.disable-cooling 改不了这件事：它决定本地要不要给凭证记冷却，不影响一条已建立的流在凭证耗尽时被裸关。报障人的配置正是它开着，症状照旧。
能做的有四件。
一是让客户端改走 HTTP：不启用
responses_websockets，请求打到 /v1/responses，耗尽时能拿到 429 与 Retry-After，至少知道该等多久。二是重连预算必须由客户端自己设上限。静默分支不会替你停。
三是换监控口径：按「上游执行次数 / 单条消息」看，而不是按请求数；时间线里的
disconnect 事件是这类静默失败留下的唯一痕迹。四是多凭证只能把症状推后。号池越深，撞到耗尽那一刻越晚，那一刻的行为不变。
openai→claude 流式：推理被当成正文发出去
第二条在同一小时落下：北京 06:00 新开的报障说，翻译层把推理当成正文发了出去14。
有些 OpenAI 兼容上游把推理放进
choices[0].delta.content 的类型化 parts 数组，例如 {"type":"thinking",...} 与 {"type":"text",...}。Claude 路由把整个数组当字符串转发，客户端在
text_delta 里看到原始 JSON，Claude Code 直接把它当正文渲染。
openai_claude_response.go 第 284–301 行：第 286 行只判「存在且非空」，随后三处都调 content.String()，没有任何数组分支。15推理提取器也读不到这些内容，它只看
delta.reasoning_content、delta.reasoning、delta.reasoning_details。于是同一份响应，流式看到一堆 JSON，非流式推理整段消失。
报障人昨夜又补了一条：非流式在同时有正文与推理时，块的顺序是「正文在前、推理在后」，与流式相反。
识别不难：客户端出现原始 parts JSON 就是命中。这类上游暂时别走 Claude 格式入口，或者换承载。
想确认是不是同一个病根，把同一个请求在流式与非流式下各发一次。报障件点名 Mistral 承载的
zai-glm-5-3，但判断依据是上游响应的形状，不是模型名。sub2api：图像端点的一次 INTERNAL 500 会把整个号停掉
第三条是账号级风险。北京 05:06 开出的补丁
#8521 主张，Antigravity 的 INTERNAL 500 惩罚作用在整个账号上，图像侧连续失败会把文本模型一起停掉17。发行版 v0.2.19 的档位：第一轮临时不可调度 30 分钟，第二轮 2 小时，第三轮起
SetError18。
antigravity_internal500_penalty.go 第 13–70 行：第 15–17 行是真实的 30 分钟 / 2 小时 / 第三轮起，第 32–33 行注释还写着旧的 10 分钟 / 10 小时；两个日志键 internal500_temp_unschedulable 与 internal500_account_disabled 也在同一屏。18注释与常量不符这件事要记住：查日志时按 30 分钟 / 2 小时看，别按注释给的 10 分钟 / 10 小时推算。
触发门槛比想象窄：HTTP 500、
error.code 为 500、消息是 Internal error encountered.、status 为 INTERNAL，四个条件同时成立。而且必须一轮 3 次尝试全部命中同一条错误，才算一轮失败19。
惩罚不看模型。同一个号既跑文本又跑图像时，图像侧连续三轮撞上那条 500，文本侧一起进临时不可调度。
监控这两个键就够：
internal500_temp_unschedulable 与 internal500_account_disabled，都带 account_id 与 consecutive_count。解冻分档：第一、二档走
DELETE /api/v1/admin/accounts/{id}/temp-unschedulable；第三档已经 SetError，要用 POST /api/v1/admin/accounts/{id}/clear-error；批量用 batch-clear-error20。#8521 的改法：图像模型的 500 只给该模型设模型级限流（默认 2 分钟），不计账号计数；文本保持原档位，三档时长可用环境变量覆盖。补丁合进去之前，先把图像流量分出去：图像单独一个号，或者不让同一个号同时承担图像与文本。
sub2api：面板上的「99%、4 天后重置」可能不是 5 小时窗口
antigravity_quota_fetcher.go 第 143–156 行：utilization 由 remainingFraction 直接换算，ResetTime 只有一个——两个窗口里更紧的那个决定这个数字，所以「99%」既可能是周额度见底，也可能只是 5 小时用满。22后果是运维把「周额度快没了」误读成「5 小时也没了」，然后去停号。
判别有两个办法。看
ResetTime 的距离：5 小时档在几小时内重置，周档是数天。或者拿官方 CLI 的
/usage 分组读数对照，它调的正是 v1internal:retrieveUserQuotaSummary。#8522 会补上分组字段：每组 5 小时与每周各一份利用率与重置时刻，前端按 G·5h / G·周 / C·5h / C·周 / A·周 显示，旧的按模型字段保持不变。版本位与在跟条目
四仓都没新版本，把当前锚点记一下。
- CLIProxyAPI
v8.0.55，北京 11-05 02:03 发布；tag、main、dev 与 HEAD 指向同一个提交e6e5708e。 - sub2api
v0.2.19，北京 10-28 18:16 发布；main 已到876b96d2。 - codex-proxy
v2.1.23，北京 11-03 19:35 发布；tag 与 main 同提交，dev 已到20a50532。 - codex2api
v3.1.3，北京 11-04 10:22 发布；main 已到a4bbb455。
上游与社区
OpenAI 状态页整体仍是 All Systems Operational，没有活动事故；最近一条还是 11-03 的 ChatGPT 文件上传错误，北京 11-03 13:39 恢复25。
Anthropic 窗口内没有新事故，最新一条仍是 10-28 的26。
GCP 窗口内发了一条更新，但那是 10-20 europe-west2 断电事故的最终报告，状态已回到可用，不是新故障27。
Codex 重置追踪站：今天（UTC）没有重置，最近一次已验证全局重置在 8 天前，累计 61 次、banked 10 次，没有官方信号28。
社区侧没有运维级新信息。OpenAI 社区 Codex 分区窗口内 0 条新话题，最新一条也在窗口之前29。
References
- 1CLIProxyAPI releases
github.com
- 2sub2api releases
github.com
- 3codex-proxy releases
github.com
- 4codex2api releases
github.com
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21feat(antigravity): 按配额分组显示真实的 5 小时与每周窗口
github.com
- 22
- 23
- 24CLIProxyAPI pull 7236
github.com
- 25OpenAI status incidents
status.openai.com
- 26Anthropic status incidents
status.anthropic.com
- 27Google Cloud status incidents
status.cloud.google.com
- 28codex-reset
codex-reset.com
- 29OpenAI Developer Community Codex
community.openai.com
- 30r/ClaudeAI
reddit.com
- 31r/OpenAI
reddit.com
- 32r/GeminiAI
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.