正文之后多出一个空 thinking 块，Claude Code 的 result 就空了

如果你的用户在 Claude Code 里问 Gemini 模型，得到一句空回答，先别怀疑账号。答案已经生成，只是被放在了客户端不读的那一格。

这一小时里，四个仓库只发出一个预发布版，其余三条都是还没合进发行版的报障与补丁。真正会让一整天白排查的是下面第一条。

报障人给出的症状很干脆：claude -p --output-format json 拿回来的 result 是空字符串，stop_reason 却是 end_turn，会话 .jsonl 里最后一条 assistant 消息明明有完整正文。五次复现，五次都空。

原因在流式返回的块顺序上。Gemini 的流有时会以一段「只有签名、没有文本」的 part 收尾。翻译器把它当成一个独立的 thinking 块开了出来，于是客户端收到的块顺序变成 [text, thinking("")]——正文在前、空 thinking 在后，正好违反 Anthropic 对块顺序的要求。(CLIProxyAPI #6835)

Claude Code 取的是最后一块。最后一块是空 thinking，result 自然就是空字符串。

判据可以自己跑：抓流里的 content_block_start，看第二个块的 index 是不是 1、type 是不是 thinking、内容是不是空。同样的请求改成 stream: false，块的顺序是对的；同款模型走 antigravity 路（模型名带 -high 那种），也只有一个 text 块。

问题只在 google 路。internal/translator/gemini/claude/gemini_claude_response.go 第 330–336 行：只有「当前正在 thinking 块里」才追加签名，其它情况一律调 appendCarrierThinkingBlock 开新块——它没判断「当前正在 text 块里」。(源码)

兄弟翻译器早就改过这件事。antigravity 那条路在 #5263 里就改成「签名只在 thinking 块内落地，否则缓存或丢弃」，所以同一个模型换个路由就正常。而现在 gemini 这条路的测试 TestConvertGeminiResponseToClaudeStream_Issue6409_SplitTrailingSignature 仍在断言尾块存在——两条路现在是故意不一致的。

修复单已经开了：#6837，2 文件 +90/−8，把 #5263 的写法原样搬过来，流式四处、非流式两处判定都补上「正文已出就不再开 carrier」，并把 #6409 那个测试的期望改成「没有尾块」。状态是 open、mergeable unstable，自动评审留了未解决意见（has_unresolved_findings: true）。

三档处置，按代价从低到高：

同一天开的另一张单说的是同一段翻译的另一半。Claude 的 tool_result 带 is_error: true 时，转成 Gemini 请求会把失败标记整个丢掉，内容写成 functionResponse.response.result——上游读到的是「工具正常返回」，不是「工具失败了」。(#6838)

这在运维侧的表现是「它明明失败了却还在往下做」：权限拒绝、命令非零退出、文件不存在，模型都当成功继续推理，最后给出一段建立在错误前提上的答案。

源码很直接：gemini_claude_request.go 第 176–184 行的 tool_result 分支只读 content，写出口只有 functionResponse.response.result 一个，全文没有读 is_error。(源码)

patch 里换成了两条路：is_error 为真时写 functionResponse.response.error，否则照旧写 result。作者自述 32 条回归用例通过，也说清了仓库的 translator-path-guard 工作流会对这类改动报红，属预期。

顺带一个可自查的事实：v8.0.37 整包搜 is_error，只有 interactions 与 claude→responses 两个翻译器在读写它，gemini→claude 这条一次都没有。也就是说，走 Gemini 上来的工具结果，失败语义从来就没过去过。

两张单都还 open，都还在 dev 之前。这一节的两条，看的是同一个方向：返回内容本身没问题，问题出在「怎么组织返回」上。

预发布版在 09:13:53Z（北京 17:13）发出，v2.1.20-beta.0543eaa，target 是 dev。

按发行说明它有八条更新。把 v2.1.19 到这一个 tag 的全部提交拉出来看，一共三笔、八个文件：版本号同步、一笔功能提交、一个合并提交。唯一的功能改动是「把 response.incomplete 的截断原因翻成 Anthropic 的 stop_reason」。

以前这个事件在 switch 里落空：用量丢掉、流走通用关闭路径结束、被截断的回答被报成正常的 end_turn，客户端以为模型自己说完了。现在新增终局分支，max_output_tokens 映射成 max_tokens，content_filter 映射成 refusal。

要提醒的是其余条目的归属。八条里有六条与 v2.1.19 的说明逐条重复；「流式请求失败不再返回 200」这条对应的代码在 src/routes/shared/stream-error-response.ts，v2.1.17、v2.1.18、v2.1.19 与这个 beta 四个版本逐字节相同，c.status(status) 从至少 v2.1.17 起就在；「WebSocket 断连后永久 502」这条，在本版的八个改动文件里找不到任何对应实现。

所以这一版的价值只对一种人成立：需要客户端把「被长度截断」和「正常结束」区分开的。在等流式错误状态码的，不必为此升级。

最后一条在 sub2api。#8270 说的是：Messages 桥接分支把 originator 删掉之后，后面的统一收口直接跳过了，身份根本没被改写过。

链条三步。buildUpstreamRequest 在桥接分支里 Del("originator")，非桥接分支才 Set；函数末尾调用 enforceCodexIdentityHeadersWithUA；而这个函数的第一句就是 originator == "" 直接 return。三步连起来，桥接请求带着客户端原始 User-Agent 出站，没有 originator、没有 version。

/v1/messages 这条路不受影响，因为 ForwardAsAnthropic 在构建之后又补了一次身份。会被请求体识别成桥接的 /v1/responses 与 /v1/chat/completions 没有这一步——它们靠 prompt_cache_key 的前缀（anthropic-metadata- / anthropic-cache- / anthropic-digest-）或 todo-guard 标记被认出来，然后就走上了缺身份的那条。

影响面要说准：这不是全局故障。只有当上游对这几条路径的身份头有校验时才会露头，表现是这些路径的 4xx，而不是所有请求一起挂。作者给的两条副作用也值得知道：OAuth 的 /v1/messages 不再发 OpenAI-Beta: responses=experimental；账号级自定义 User-Agent 现在对这些请求同样生效。

单子 open、7 文件 +91/−28，还没合。

sub2api 主干窗口内落了两个合并：08:54Z（北京 16:54）先合 #8142 的账号筛选持久化，再合 #8267 的依赖安全扫描修复——Go 1.27.3 清掉 GO-2026-6809，follow-redirects 升到 1.16.1。后者上一期还挂在 open，现在已经进 main，等下一个版本带出。

复合分组密钥导入 CC-Switch 固定成 Claude：composite 平台在 resolveCcSwitchImportConfig 里落进 default 分支，生成 app=claude；前端也只有 antigravity 会弹客户端选择框。修复单 #8272 已在 09:26Z 跟上，加出 codex 与 gemini 两个选项。要注意的是它的 codex 分支沿用常量 gpt-5.5——这正是 10-16 那期报过、已在 2026-10-14 从 ChatGPT 登录的 Codex 退役的名字，导入后按账号类型可能直接选不到。

上游这一小时是干净的：OpenAI 状态页全绿、零降级组件，最近一次事故已在 03:28Z（北京 11:28）解决；Anthropic 今日无事件；Google Cloud 最新一条仍是 10-20 那次 europe-west2。额度侧今天没有重置，最近一次已验证的全局重置在 2026-10-20 06:33 UTC（北京 14:33），距今 27 小时，累计 56 次。官方社区 Codex 分区窗口内只有一条新帖，讲一次长跑测试把额度耗光，与中转无关，不展开。