10/17 下午续报：v8.0.32 会把截断的上游流补成正常收尾，管理端改过的模型前缀会被旧快照改回去 (2026)

10 月 17 日北京 14:18 到 15:20 这六十来分钟，四个中转仓库没有发新版本，也没有合并落地。

窗口里开出两条新报障，都值得今天就看完。

一条是 v8.0.32 会在上游流被剪断时，替它补一句「已经说完」。

另一条是管理端刚写进磁盘的模型前缀，运行时可能退回旧值。

修复都有人提了，但都还没合入。

结论与影响面

v8.0.32 的 /v1/messages 会把截断的流补成正常收尾。 客户端读到 message_stop 与 stop_reason: end_turn，与真的说完分不出来。1 2
Claude 直通路径则静默返回。 上游干净掉线时它不报错、不记失败，200 的连接直接结束。3
管理端改过的前缀，运行时会退回旧值。 一份无版本的旧快照能把 generation 抬到比新值更高，之后的正确更新反被判成过期。4
上午那处 contentMediaType 修复已进 dev。 发行版 v8.0.32 与 main 都还没有，带这个注解的 schema 仍回 400。5 6

主线一：断掉的流被补成「已说完」

14:27，作者 xyonium 开了 issue #6707，三秒后把修复开成 PR #6708，base 是 dev。1 2

报障说的是三处缺口，分别落在执行器与处理器上。

第一处，OpenAI 兼容入口。 上游干净 EOF、没 [DONE]、也没有任何 chunk 带 finish_reason 时，v8.0.32 只对一种格式报 502。7

那种格式是 FormatOpenAIResponse，也就是原生 Responses 入口。7

其余格式走另一条分支，注释写的是「保持对省略 [DONE] 的上游的兼容」。7

它给翻译器喂一句合成的 data: [DONE]；翻译器把这句话当收尾，补出 message_delta 与 message_stop。7 8

没拿到 finish_reason 时，stop_reason 的默认映射就是 end_turn。8

v8.0.32 的 openai_compat_executor.go 第 559–608 行

v8.0.32 的 internal/runtime/executor/openai_compat_executor.go 第 559–608 行：第 591–599 行只有 FormatOpenAIResponse 这一种格式落到 502「upstream stream closed before [DONE]」；第 602–603 行给其余格式合成 data: [DONE] 交给翻译器，注释原文是「Other protocols retain compatibility with providers that omit [DONE].」。

同样的写法在另外三处：Gemini 与 Vertex 在干净 EOF 上无条件喂 [DONE]，Kimi 在检查 scanner.Err() 之前就把 [DONE] 翻译掉了。9 10

第二处，Claude 直通。 !upstreamCompleted 成立时，它只在 scanner.Err() != nil 的情况里报错。3

上游代理干净地断在半截，scanner.Err() 是 nil，这段就什么都不做。3

v8.0.32 的 claude_executor_stream.go 第 418–439 行

v8.0.32 的 internal/runtime/executor/claude_executor_stream.go 第 418–439 行：第 421 行进入 !upstreamCompleted 分支，第 422 行先试取消，第 425 行才判断 scanner.Err() != nil；两个条件都不成立时函数直接返回，既没有 RecordAPIResponseError 也没有 PublishFailure。

第三处，处理器。 forwardClaudeStream 没有设 CloseError，所以数据通道关掉时没人核对过收尾事件。11

它的 WriteTerminalError 里还留着 if !c.Writer.Written() 才算状态码的老写法。11

通道	v8.0.32 在干净 EOF 上的表现
OpenAI 兼容 → Claude 格式	合成 `[DONE]`，补出 `message_stop`、`end_turn`
Gemini / Vertex → Claude 格式	同上，无条件喂 `[DONE]`
Kimi → Claude 格式	先翻译 `[DONE]`，再查扫描错误
Claude 直通	静默返回，无错误、无失败用量
原生 Responses 入口	502「upstream stream closed before [DONE]」

对运维意味着什么

这类请求在面板上记的是成功，用量按已产出的 token 算。1

于是用户拿到的半截回答，在你这边的账上是完整的。

客户端也不会重试：它收到了 message_stop，认为对话正常结束。2

#6708 改了什么

PR 共 9 文件、+664/−25，一笔提交 72ca2f2a7b，base 是 dev，可干净合并。2

四个执行器都加了 sawFinishReason：干净 EOF 且没收到收尾原因时，目标格式是 Claude 的改报 502，不再合成 [DONE]。2

直通路径补上 "upstream stream closed before message_stop"，处理器补 CloseError，诊断函数开始认 event: error。2

仓库的自动评审在 14:27 给出 has_unresolved_findings: true，还没有人工评审。2

今天该做什么

合入之前，先学会认出一条 200 其实是断的。

抓客户端收到的最后几个事件：有 message_stop 才算收尾，只有 event: error 也算断，什么都没有就是流被掐了。

如果上游在自己的日志里记了断连，把那份日志与本地访问日志按时间对齐，就能估出受影响的比例。

记账上别用本地的 2xx 反推用户拿到了完整回答。

修复合入后，这类请求会变成 502 并进入失败计数，客户端的重试策略才会真正生效。2

主线二：旧快照会把新前缀改回去

14:52，作者 TonyYanS 开了 #6709，版本 v8.0.32，只跑合成测试、没用真实凭证。4

报障给出的时序是这样的。

文件快照带着 pfx-8、generation 为 0；运行时是 pfx-8、第 25 代。

管理端随后 PATCH 写入 pfx-9，运行时抬到第 26 代。

那份旧快照这时覆盖运行时，值回到 pfx-8，代数却被抬到 27。4

再来的 pfx-9/26 被判过期；磁盘上是 pfx-9，运行时是 pfx-8。4

源码对得上。isStaleCoreAuth 只在 incoming.Generation > 0 时比较代数。12

紧挨着的注释写明：generation 为 0 的文件监听快照不参与版本比较。12

提交时，updateInternalLocked 又无条件把代数抬到「现有 +1」。13

于是旧内容拿到了比新内容更大的代数，看起来更新。13

v8.0.32 的 sdk/cliproxy/service_auth.go 第 550–571 行：第 556 行先比注册序号，第 561 行才比代数，条件是 incoming.Generation > 0；第 559–560 行注释写明 generation 0 表示「文件监听合成的快照」，因此不比较。

影响面与复现

面板或管理 API 改完前缀之后，模型可能仍以旧名字对外。

这段时间里，带新前缀的模型调不到。报障人观察到的窗口是一秒级，他也写明这是逻辑顺序问题，不是内存竞争。

重启或再改一次能恢复，两次并发时可能反复。

复现用仓库自带的并发测试：go test -count=20 -run '^TestPutOpenAICompatConcurrentWithAuthFieldsPatch_Issue6559$' ./sdk/cliproxy。4

报障人另给了一份确定性测试，落在 internal/watcher/synthesizer 下，v8.0.32 首次断言就失败。4

他同时点明与 #6618 不是同一件事：那次是发布顺序，这次是管理器本身被旧内容覆盖。4

次条：上午那处 schema 修复进了 dev

14:18:55，Luis Pater 往 dev 推了 a43026d75196，2 文件 +86/−1，说明里带 Closes: #6699。5

改动只有一行：删字段名单末尾补上 contentMediaType 与 contentEncoding。5

v8.0.32 的同一行没有这两个名字，main 也没有。6

所以带这两个注解的 Claude 工具 schema，走 Gemini 仍然回 400，直到带这笔提交的版本发出。14

上午那期的绕行不变：让客户端别把这两个注解写进 input_schema。

次条：sub2api 的充值报障出现第三个相同反馈

15:00，maryjeck 在同一张单下留言：「我也碰到这个问题，正常充值成功，显示被取消。」15

这张单 10:19 由 ding-1988 开出，最早的症状是升级 v0.2.17 后充值回调不来。15

中间两条：10:00 有人说「没问题啊」，13:13 只有一句「+1」。15

现在四条评论里三条指向同一件事，症状还比开单时更具体：钱到了，订单状态却是取消。15

sub2api 的 main 停在 10 月 16 日 12:42，没有相关修复。16

维护者回应之前，这类订单要靠人工对账，别只看面板上的成功笔数。

同窗口的形态变化

#6701 在 15:16 再次 force-push，头提交变成 4b5cab3959，提交数从 4 收敛到 1，改动从 11 文件 +514/−37 缩到 8 文件 +162/−30；标题没变，仍开着。17

codex2api 的 #794 是一条定时降智加账号状态展示的提案，没有可执行的版本或配置信息，按排除规则不收。18

上游与额度

OpenAI 状态页全绿，没有降级组件，也没有活动事件；最近一条仍是 Compliance API 成本数据延迟，10 月 16 日 18:44 恢复。19

Anthropic 全绿，10 月 17 日当天没有事件。20

Google Cloud 仍是 7 条事件，最近一条是 10 月 8 日到 9 日的 Cloud Storage。21

Codex 今天 UTC 仍未重置，最近一次已验证的全局重置在 10 月 15 日 14:13，两天前。22

同一页记着累计 54 次全局重置、10 次 banked，节奏约每四天一次。22

另一家追踪站记的是 62 次、中位间隔 3.1 天、最长 68 天。23

官方开发者社区 Codex 分区窗口内没有新话题，最新一条在 12:32，落在窗口之前。24

@thsottiaux 窗口内没有新帖，最近一条还是 10 月 16 日 13:51 的。25

Reddit 三个板块窗口内没有可核的额度或封号条目。26 27 28

只有两条沾边：r/ClaudeAI 说 Claude Code 默认把网页端的技能同步到本地，r/GeminiAI 说 AI Studio 给 Pro 账号开了 Argon。两者都是单条帖子，按未核登记。

本窗口核对过的空状态

codex-proxy 窗口内零条目。

codex2api 窗口内只有上面那条提案。18

CLIProxyAPI 的 main 停在 10 月 17 日 02:56，窗口内只有 dev 上那笔 schema 提交。29

四个发行版仍是 v0.2.17、v8.0.32、v2.1.18、v3.1.1。30 31

References

1
CLIProxyAPI issue #6707
github.com
2
CLIProxyAPI PR #6708
github.com
3
claude_executor_stream.go v8.0.32
github.com
4
CLIProxyAPI issue #6709
github.com
5
CLIProxyAPI dev 提交 a43026d
github.com
6
gemini_schema.go v8.0.32
github.com
7
openai_compat_executor.go v8.0.32
github.com
8
openai_claude_response.go v8.0.32
github.com
9
gemini_executor.go v8.0.32
github.com
10
kimi_executor.go v8.0.32
github.com
11
code_handlers.go v8.0.32
github.com
12
service_auth.go v8.0.32
github.com
13
conductor_lifecycle.go v8.0.32
github.com
14
CLIProxyAPI issue #6699
github.com
15
sub2api issue #8171
github.com
16
sub2api main 提交
github.com
17
CLIProxyAPI PR #6701
github.com
18
codex2api issue #794
github.com
19
OpenAI Status
status.openai.com
20
Anthropic Status
status.anthropic.com
21
Google Cloud Status
status.cloud.google.com
22
Codex Reset
codex-reset.com
23
OpenTheRank Codex Reset
opentherank.com
24
Codex CLI TUI account/read -32603
community.openai.com
25
Tibo (@thsottiaux)
x.com
26
r/OpenAI
reddit.com
27
r/ClaudeAI
reddit.com
28
r/GeminiAI
reddit.com
29
CLIProxyAPI main 提交
github.com
30
sub2api releases
github.com
31
CLIProxyAPI releases
github.com