凭证耗尽时 WebSocket 直接断线：一条消息触发 21 次失败、30–45 秒空等
四仓零发版的窗口里，真正要处理的是额度耗尽时 WebSocket 只断线不报错：一条消息触发约 21 次失败上游执行、空等 30–45 秒，另附两条翻译层与惩罚范围的坑，以及今晚就能改的配置。
本窗口四个仓库一个版本都没有发：CLIProxyAPI 停在 v8.0.55，sub2api 停在 v0.2.19，codex-proxy 停在 v2.1.23，codex2api 停在 v3.1.3。没有要升的版本，但这不等于今晚没事。
窗口内真正的新信息是四条新条目。其中最贵的一条不在版本说明里，而在一条 0 回复的报障单里：凭证额度耗尽时，走 WebSocket 的那条转发路径不会告诉客户端原因，只把连接关掉；客户端于是重连，重连再撞同一堵墙。
这条单值得整节展开，因为它改变的是「你怎么知道出事了」——不是报错慢，是根本不报。另外三条分别是一次翻译层的类型错乱，和 sub2api 两条还没合并的补丁所描述的两个坑。
凭证耗尽时，WebSocket 什么都不回
报障人给的环境很具体：单张 Codex OAuth 凭证、开插件调度、客户端是
T3 Code/0.166.0 并开启 responses_websockets=2026-02-06，配置里 request-retry: 0、disable-cooling: true。上游回的是 {"error":{"type":"usage_limit_reached"}}。1他量到的形态是：每条消息触发约 21 次失败的上游执行，耗时 30–45 秒，五段样本分别是 21 次/27 秒、33 次/78 秒、21 次/45 秒、21 次/43 秒、21 次/45 秒。客户端侧看不到任何错误，只看到连接以 1006 关闭；代理日志里反复刷
upstream execution session closed。1代码里这条路径是作者自己写明的设计，注释原文是「Credential, quota and transport failures stay silent so the client simply reconnects and retries; a fresh connection carries no server-side transcript, so reconnecting already implies a full context resend」。也就是说，静默是刻意的：让客户端当作网络抖一下，自己重连。2
shouldExposeResponsesUpstreamError 与它的调用点：第 409–421 行命中静默分支时，只往请求日志时间线追加一条 disconnect，然后 closeWithoutError() 收掉连接。来源：sdk/api/handlers/openai/openai_responses_websocket_forward.go 第 386–424 行（v8.0.55）2「额度类错误进不了可暴露那一支」不是随手写的：判定函数
IsRequestFault 一进门就把 429 与 402 判成「不是请求的错」，注释写明理由——凭证必须仍然可以冷却、可以换号。3
return false。这正是「额度耗尽不会被告知」的那一行。来源：internal/clienterror/client_error.go 第 76–99 行（v8.0.55）3两条链路在这里分岔。HTTP 那条路上，全池冷却时构造的是一个
modelCooldownError，它的 StatusCode() 返回 429、Headers() 会写一个 Retry-After 头。4 WebSocket 那条路上，同一个原因走到静默分支，客户端拿到的只有断开。按上面那句注释的逻辑推算——这一条是推算不是实测——21 次重连意味着 21 次全文重传，那 30–45 秒里除了等待，还在反复把整段上下文塞给一个明确拒绝服务的上游。
还要注意配置帮了倒忙：
disable-cooling: true 时凭证不会进冷却，选号每次都会再把它选出来，于是「同一个失败重放 21 次」成了稳定形态，而不是偶发。现在能做的四件事
一、先把这张凭证从选号里摘掉，别靠重试。 单张 OAuth 加
disable-cooling: true 的组合下没有第二条路可走，重试次数再多也只是把同一堵墙撞更多次；停用这张凭证或临时打开冷却，客户端才有机会拿到「没号可用」。二、把客户端的重连上限压下来。 报障人那边的 21 次是客户端自己的重试预算。既然服务端不会告诉你原因，客户端每一轮都是一次无谓的全文重传；在额度明确耗尽期间把上限调小，至少把单条消息的空等从 30–45 秒压住。
三、排查入口在请求日志时间线，不在客户端。 静默分支唯一的痕迹是
appendWebsocketTimelineDisconnect 写下的那条 disconnect 事件。客户端侧只会显示 1006，照着客户端现象去查代理日志里的 HTTP 状态码会一无所获。四、需要「拿到原因」时，改走 HTTP 的 responses 路径。 同一次额度耗尽在那里会变成 429 加
Retry-After，而不是断开。至于补丁：
#7245 仍是 open，状态 dirty、21 笔提交、改 58 个文件、基于 dev；它依赖的 #7239 已经在昨天 17:29 被关成未合并。56 v8.0.55 的源码包里搜不到这个开关的名字，别等这一版把它修掉。5第二条：Claude 格式的客户端会看到一段 JSON 原文
同一小时里开的另一张单讲的是反方向的问题：不是不回，是回错了形状。上游以 OpenAI 兼容格式返回、
choices[0].delta.content 是数组（按类型分块）而不是字符串时，openai→claude 的流式翻译会把这个数组原样序列化成文本发下去。报障人给的上游实例是 Mistral 承载的 zai-glm-5-3。7
content.String()，第 316 行把结果直接塞进 delta.text。数组因此以 JSON 文本的形态出现在客户端正文里。来源：internal/translator/openai/claude/openai_claude_response.go 第 284–322 行（v8.0.55）8非流式那条路处理得反而「更结构化」，但代价是另一种丢失：它认
text、tool_calls、reasoning 三种分块类型，其余类型落 default 被丢掉。9 所以同一个上游，流式会把数组当字串贴出来，非流式会让不认识的那些块直接消失。作者随后在单子里补了一条容易忽略的差异：非流式在同时有正文与推理时，块的顺序是
[text, thinking]，与流式的顺序相反。7判定方法很直接：在 Claude 格式的客户端里，如果正文中出现
[{"type": 开头的片段，或者一段本应是推理的内容以 JSON 形式出现，就是这条。对同一请求关掉流式再发一次，可以同时确认第二种症状（推理块消失或顺序颠倒）。今晚能做的只有绕：把这类「按分块返回 content」的上游从 Claude 格式路由上摘下来，或者让这些模型只服务 chat-completions 客户端。翻译层本身没有开关可以切换，修法只能等合并。
第三条：一次图像侧 500，会把整个号的文本模型一起带走
sub2api 的这张补丁单描述的是惩罚范围的问题，而且它在当前版本里已经生效：Antigravity 账号连续多轮撞上那个特定的 INTERNAL 500 时，惩罚作用在整条账号上，不看是哪个模型出的错。10
当前的三档写在常量里：第 1 轮临时不可调度 30 分钟，第 2 轮 2 小时，第 3 轮起直接
SetError 停用。11
internal500_account_disabled、第 54 与 64 行日志键 internal500_temp_unschedulable。注意第 31–34 行的注释仍写着「10 分钟 / 10 小时」，与常量不符。来源：backend/internal/service/antigravity_internal500_penalty.go 第 13–70 行（v0.2.19）11动手之前先看门槛，不要被「一次 500 就被停」吓到：它要求一轮重试里 3 次全部命中同一种 500 才递增一轮。12 而「同一种」是很窄的定义：HTTP 500、
error.code 为 500、error.message 恰好是 Internal error encountered.、error.status 为 INTERNAL，四个条件缺一不算。11真正要改的是今晚的处置顺序：先在日志里按
internal500_temp_unschedulable 与 internal500_account_disabled 搜，确认是「临时不可调度」还是「已停用」；两种对应不同的解冻接口——POST /api/v1/admin/accounts/{id}/clear-error 用于 SetError，DELETE /api/v1/admin/accounts/{id}/temp-unschedulable 用于临时不可调度，另外还有 clear-rate-limit 与 batch-clear-error。13顺便提醒一句：那张图里第 31–34 行的注释写的是 10 分钟与 10 小时，与实际常量差了三倍。按注释估算恢复时间的值班表会错，按常量算才对。
补丁的方向是给图像侧一条单独的短冷却（默认几分钟）且不计入账号计数，文本侧保留原档位。在合并之前，最省事的规避是把图像流量与文本流量分到不同 Antigravity 账号上——只要它们共用一个号，图像侧的一次 500 就有机会把文本也拖下线。
第四条：面板上那个占用率，是较紧的那一档
Utilization 与 ResetTime 两个字段。5 小时窗口与周窗口在这里被压成一个数。来源：backend/internal/service/antigravity_quota_fetcher.go 第 137–160 行（v0.2.19）14后果很具体：面板显示 99% 并写着「4 天后重置」时，那很可能是周窗口的读数，而 5 小时窗口可能刚重置、还有得用；反过来「马上重置」也可能只说明较紧的那一档快到了。按这个数字批量停号，容易把还能用的号一起停掉。
补丁给的是分组显示，把每个配额组按 5 小时与周两个窗口分别列出，界面上的读法变成
组·5h 与 组·周 并列。15 在它合并之前，判断办法有两个：看 ResetTime 距离现在多远（几小时是 5 小时窗口，几天是周窗口）；或者用官方 CLI 的 /usage 对照，它调的是上游的配额汇总接口。15版本位与在跟
四个仓库的当前版本与本窗口的发版情况：CLIProxyAPI v8.0.55（北京 11-05 02:03 发布）、sub2api v0.2.19（10-28 18:16）、codex-proxy v2.1.23（11-03 19:35）、codex2api v3.1.3（11-04 10:22），窗口内都没有新版本。16171819
在跟的两条：
#7254（OpenAI 兼容路由丢 tool_search）仍 open、零评论、无标签，上一期写过的三条落点在 v8.0.55 里没有变化；#7236 只有 updated_at 变动，提交数仍为 2、状态仍 dirty，不构成新进展。2021上游与社区
上游三处都安静：OpenAI 状态页全部正常，最近一次事故仍是 11-03 的 File upload errors，已在北京时间 13:39 恢复。22 Anthropic 组件状态全部正常，最近一次事件在 10-28。23 Google Cloud 那边窗口内出现的是一条旧事故（europe-west2，10-20 那条）的最终复盘，状态为 AVAILABLE，不是新的中断。24
Codex 的重置节奏没有变化：今天 UTC 尚未重置，最近一次已验证的全局重置在 8 天前，累计 61 次、可结转 10 次，官方信号未生效。25
OpenAI 官方社区的 Codex 分区在本窗口内没有新话题，最新一条停在窗口开始之前，因此这一节没有社区侧的额度或封号新信号。26
一句话收束今晚：没有版本要升；把额度耗尽的账号从 WebSocket 路径上摘下来、把客户端的重连预算压住、把 Antigravity 的图像与文本分开账号，这三件事今晚就能做完，剩下的都得等合并。
References
- 1CLIProxyAPI #7256：额度耗尽时 WS 静默关闭
github.com
- 2
- 3client_error.go：402/429 不算请求过错
github.com
- 4selector.go：冷却错误带 429 与 Retry-After
github.com
- 5CLIProxyAPI #7245：额度拒绝响应模式
github.com
- 6CLIProxyAPI #7239：已关闭且未合并
github.com
- 7CLIProxyAPI #7255：delta.content 数组被当文本转发
github.com
- 8
- 9openai_claude_response.go：非流式只认三种分块
github.com
- 10sub2api #8521：INTERNAL 500 惩罚按模型作用域拆分
github.com
- 11
- 12antigravity_gateway_retry.go：一轮打满才递增
github.com
- 13sub2api 管理端账号路由：四类清除入口
github.com
- 14antigravity_quota_fetcher.go：每模型只写一个占用率
github.com
- 15sub2api #8522：按配额组显示 5 小时与周窗口
github.com
- 16CLIProxyAPI v8.0.55
github.com
- 17sub2api v0.2.19
github.com
- 18codex-proxy v2.1.23
github.com
- 19codex2api v3.1.3
github.com
- 20CLIProxyAPI #7254：仍 open 无回应
github.com
- 21CLIProxyAPI #7236：仅时间戳变动
github.com
- 22OpenAI 状态页
status.openai.com
- 23Anthropic 状态页
status.anthropic.com
- 24Google Cloud 状态页
status.cloud.google.com
- 25codex-reset 追踪
codex-reset.com
- 26OpenAI 开发者社区 Codex 分区
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.