最后一帧被丢掉、取消记成成功、401 变断连：CLIProxyAPI 三处流式缺陷同夜开单
同一人在 22:02–22:03 连开三条流式缺陷单：AI Studio relay 丢末帧、取消被记成成功、WebSocket 的 401 被本地 408 顶掉；三张补丁都没合，另有分组按张计费合入主干与一张外部调度诉求被关成 not planned。
北京 21:25 到现在这一个半小时，四家仓库都没有发出新版本1。CLIProxyAPI 上，同一位报障人 eaxeax 在 22:02 到 22:03 之间开了三条流式缺陷单，每条都配了一张 base 指到 dev 的修复 PR：2、3、4。
三条的症状各不相同，落点却都在流的最后一段：一条让流永远收不了尾，一条把取消记成成功，一条把真正的 401 换成本地造的 408。三张补丁到发稿时都还开着。
同一天晚上，上一期报的那条「Gemini 格式流每轮缺 finishReason」已经被维护者修进 dev，还没发版。
一帧里塞两帧，只译第一帧
走 wsrelay 的 AI Studio 通道，把一个 relay chunk 整块交给 Gemini 流式翻译器。翻译器只读一行：gjson 取到第一个 JSON 对象就停。
所以一个 chunk 里带两帧 SSE 时，第二帧整段丢掉。丢掉的常常是末帧，那一帧装着
finishReason 与 usageMetadata。作者拿同一段内容做了两种发法的对照2：
- 一帧一个 chunk：三种下游格式都正常收尾。
- 两帧挤进一个 chunk：openai chat 丢了第二段文本，没有 finish reason，usage 0/0。
- 两帧挤进一个 chunk：openai responses 没有
response.completed，claude 没有message_stop。
CLIProxyAPI v8.0.42，
internal/runtime/executor/aistudio_executor.go 第 383–412 行：wsrelay.MessageTypeStreamChunk 分支拿到 event.Payload 后，只调一次 TranslateStreamWithClaudeInputTokens，chunk 内部没有再按 SSE 空行切分。这条通道的现场判断不难：回答看上去完整，流不结束，用量显示 0/0。换一条不走 relay 的通道，同样的请求正常。三个信号同时出现基本可以锁定它。
这条单来自读代码加假 relay，作者没有在真实浏览器会话里复现过。仓库侧的
wsrelay.decodeChunk 把 payload["data"] 原样返回，现有测试也是一帧一个 chunk。自己的链路会不会把多帧打进一个 chunk，取决于你那一侧的上游实现2。
补丁 PR #6978 的改法是对症的。chunk 以 SSE 字段（
data:、event:、id:、retry:、注释）开头时按空行切帧，每帧单独走完观察模型、用量、翻译、错误捕获和 apply_patch 停止这一整套。以 JSON 或
[DONE] 开头的不切，避免把漂亮打印的 JSON 拆坏。两个文件 +266/−17，mergeable clean，自动评审在 22:02 给出的结论是有未解决问题5。取消和通道关闭同时就绪，取消被判成成功
nextStreamChunk 在 ctx.Done() 与数据通道之间做 select。执行器在请求上下文结束时关闭自己的通道，于是取消发生之后两个 case 同时就绪，Go 随机挑一个。挑到关闭的那个通道时，
!ok 会让上游把这一轮当成正常结束。带投递跟踪的流会由 streamDeliveryCompletion 按投递结果纠正。没有投递跟踪的那种流会保留错误结论：插件里的嵌套模型调用，
usage.StreamDeliverySupported 为 false，插件在 CompleteRequest 里收到 succeeded3。
CLIProxyAPI v8.0.42，
sdk/api/handlers/handlers_interceptors.go 第 231–255 行：第 244–248 行的 select 里，取消与读通道两个 case 平级；读到关闭的通道后只把 *closed 置真，第三个返回值仍是 false。作者的数据：v8.0.41 上，Docker
golang:1.27-bookworm linux/amd64（在 arm64 Mac 上模拟）跑 TestIssue6332PluginNestedDelivery/cancel_partial，40 次 -race 挂 2 次。同一份代码在 macOS arm64 上跑 360 次没挂。当前的 dev 与它一致3。
现场怎么看：插件或上游账本里出现
outcome=succeeded，而客户端那条连接已经断开，两边对不上时就值得查这里。取消率高的实例上，这个偏差会被放大。补丁 PR #6980 只动五行：通道关闭且上下文已取消时，直接报取消。另加一个 200 轮的回归测试，取消场景必须全部报取消，活上下文上的关闭不能被误报。四个文件 +71/−11，自动评审 22:03 给出的结论是无问题6。
WebSocket 上真正的错被 408 顶掉
forwardResponsesWebsocket 同时 select 错误通道和 data 通道。生产者把终局错误先塞进带缓冲的 errs，再关掉 errs 与 data；当 select 先读到已关闭的 data，这一轮就以「stream closed before response.completed」收场。那个 408 由本进程造出来。
CLIProxyAPI v8.0.42，
sdk/api/handlers/openai/openai_responses_websocket_forward.go 第 126–150 行：data 关闭且未完成时，第 141–143 行直接构造 StatusRequestTimeout 与那句断流文案。代价落在钉住的凭证上。上游 401 或 429 本该走 replay 关闭（1012，
upstream requires HTTP replay），告诉客户端可以重放；现在客户端只看到一条断开。现场判断：客户端侧
/v1/responses 的 WebSocket 会话莫名断开，服务端日志在同一秒有 401/429 记录。补丁 PR #6982 在 data 关闭或双工流时先非阻塞读一次
errs，把缓冲好的错误取出来。两个文件 +78/−28，自动评审 22:03 结论是无问题7。上一期那条 finishReason 已经修进 dev
上一期报的 CLIProxyAPI #6971（Gemini 格式流对 Codex 与 OpenAI 兼容模型不带 finishReason）在今晚 22:17 由维护者落进 dev：
bdde391d，Closes: #6971，4 个文件 +46/−18。改了两处。Codex→Gemini 在
response.completed 这个正常终局上补 candidates.0.finishReason: STOP，原来只有 response.incomplete 才写。OpenAI→Gemini 那个「有内容块就 return true」的分支，现在遇到非空的 finish_reason 会继续往下走到结束原因处理。这段代码不在 v8.0.42 里：main 仍停在
bc064340，v8.0.42 的这两个翻译器文件没有这几行9。同一批 dev 还有两笔：
27f3abfb 的 session 级 OAuth 代理，3dae075d 把 devin 的 swe-2 lightning 多个 UID 聚成一个模型10。两笔都还在 dev。今晚的处理顺序
- 先确认自己踩的是哪一条。 用量 0/0 且流不收尾 → 看 AI Studio 是否走 wsrelay；插件账本说成功而客户端断开 → 看嵌套调用；WebSocket 莫名断开而日志有 401/429 → 看 Responses 转发。
- 别把这三条当成上游故障处理。 三条都能在本地源码里对上，换号、换 key、加冷却都不会改善。
- 账务侧先按请求数复核。 第一条会让 usage 落成 0，冷却与阈值读的是用量，跟着一起失真。
- 等三张 PR 的评审意见关掉。 #6978 有未解决意见，#6980 与 #6982 已无问题；三张都还没合，合了也要等下一版。
另外几条：一笔钱、一个 400、一处只能搬不能丢的开关、一张被关掉的诉求
sub2api 的分组级按张计费合进主干了。 PR #8323 在 21:48 合入 main，41 个文件 +728/−78，新增迁移 248 给
groups 加一列 image_count_billing，默认 false，面板上叫「按张计费」11。v0.2.18 整包里没有 image_billing_count.go，分组表里也没有这一列，按张计费要等下一个版本。用量记录里的 image_count 在 v0.2.18 已经有了。发版后先把想开的分组逐个勾上，这一列默认是关的。
Command Code 那条 400 不会换号。 PR #8340 报的是：Command Code 的上游用
reasoning_effort: "off" 关思考，OpenAI 兼容客户端把这档写成 none，上游当未知值拒掉，整个请求 40012。优先级池救不了这种情况。sub2api 对 400 按确定性客户端错误处理，直接回给客户端，池里的 Go 与官方账号一次都不会被试到。
这条判断在 sub2api v0.2.18 的
shouldFailoverOpenAIUpstreamResponse 里能直接看到。能触发换号的状态码是 401、402、403、405、429、529 与 5xx。400 只在「模型不存在」这类例外里换号13。
sub2api v0.2.18，
backend/internal/service/openai_gateway_upstream_errors.go 第 302–336 行：第 303–310 行的 switch 只列 401、402、403、405、429、529 与 5xx；第 337–339 行的 400 例外只对 OpenAI 兼容账号的「模型不存在」生效。现在就有一个绕法：把 Command Code 账号单独放进一个分组，在这个分组里用
reasoning_effort_mappings 把 none 映成 off。分组级映射在 v0.2.18 已经存在14；PR 作者没走这条路，理由是同一分组里的 Go 与官方账号会被一起改写。mid-system 消息只有搬家，没有丢弃。 CLIProxyAPI #6985 报的是 Claude Code 2.1.306 起会在
messages[] 里插入 role:"system" 的会话中消息，配置文件里能开的只有 rebuild-mid-system-message，作用是把它们搬进顶层 system 字段，v8.0.42 没有丢弃这一档15。对部分 Anthropic 兼容上游，搬家仍然被拒。报障人实测：一条 system 消息的小请求搬家后 200，561 条消息里带 6 条 system 的大请求搬家后仍 400，直接删掉这 6 条则 200，
input_tokens 458285。今晚在配置里绕不过去。
rebuild-mid-system-message 只有开关、没有模式；payload 规则按路径改字段，删不掉「role 为 system 的那几条」。要么在请求到你看得见的那一层先删，要么换一个接受搬家的上游。外部调度模式被正式关掉了。 CLIProxyAPI #6972 在 21:35 由维护者 luispater 以 not planned 关闭16。
关闭说明里写了两句：不打算实现独立的 client-API-key External Scheduler Mode；外部化调度请走 Home 控制面（
internal/home 与 sdk/cliproxy/auth/conductor_home.go），并建议对接 CLIProxyAPIHome。想自己做调度的，路线从「拿一个受限管理 key」变成「实现 Home 的调度接口」。版本面
| 仓库 | 当前版本 | 发布时间（北京） | 窗口内主干动作 |
|---|---|---|---|
| CLIProxyAPI | v8.0.42 | 10-24 22:21 | dev 三笔（22:17），main 未动 |
| sub2api | v0.2.18 | 10-23 15:44 | main 一笔直接提交（21:30）+ #8323 合并（21:48） |
| codex-proxy | v2.1.20 | 10-23 03:56 | 无 |
| codex2api | v3.1.1 | 10-17 05:42 | 两个合并（22:44）：#832 非流式 Images 不再发 102、#833 HTTP 代理 502/504 回退 IPv6 探测 |
codex2api 那两个合并都进了 main、没有发版：一笔让非流式的 Codex 图片请求不再回 HTTP 102，一笔让 HTTP 代理在 502/504 时退回 IPv6 探测1718。还在 v3.1.1 上的实例要等下一个 tag。
上游与额度
三家状态页都是绿的：OpenAI 全系统正常、无降级组件19；Claude 全系统正常，页面最后更新在北京 19:2920；Google Cloud 仍是 10-23 00:19 那一单 europe-west2 多服务故障，之后没有新的21。
Codex 额度方面，今天 UTC 还没重置，最近一次已验证的全局重置在 10-23 01:10（三天前），累计 57 次全局重置、10 次 banked，节奏约每两天一次22。
未闭合
- #6978 的评审意见怎么改、什么时候合。
- #6980 与 #6982 评审干净，等合并；三张会不会一起进下一版。
- dev 那笔 finishReason 修复什么时候随版本发出。
- sub2api 多图计费发版后，默认关闭的开关要不要按分组打开。
References
- 1CLIProxyAPI Releases
github.com
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9CLIProxyAPI 主分支提交记录
github.com
- 10CLIProxyAPI dev 分支提交记录
github.com
- 11兼容gptimage一次性出多张图的按张计费
github.com
- 12
- 13
- 14sub2api v0.2.18 group.go
github.com
- 15
- 16
- 17
- 18HTTP 代理上游不可达时回退至 IPv6 探测
github.com
- 19OpenAI Status
status.openai.com
- 20Claude Status
status.claude.com
- 21Google Cloud Status
status.cloud.google.com
- 22Codex Reset Tracker
codex-reset.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.