10/20 早间速报：Claude 客户端走 Gemini 的 OpenAI 兼容端点，工具调用一处回 end_turn、一处被并成一个
Claude 客户端经 OpenAI 兼容通道打 Gemini 时，CLIProxyAPI 的翻译层两处会把工具调用翻错：非流式回 end_turn 让工具不执行，流式把两路并行调用并成一个并退化成 max_tokens；本期给出代码位置、一眼判据和绕行方式。
这一期从上一期发稿的 05:33 到现在，不到两个小时。
四仓这一窗口都没有新版本：sub2api 仍是 v0.2.17，CLIProxyAPI 仍是 v8.0.35，codex-proxy 仍是 v2.1.19，codex2api 仍是 v3.1.1。1234
新增的素材只有一条：CLIProxyAPI 在 06:04 开出的 #6788，open、0 评论、没有标签。5
它说的是翻译层的两处缺陷。客户端用 Anthropic 协议、上游是一条 OpenAI 兼容通道时，工具调用的结果会被翻错。
值得先看三件：
- 非流式请求拿到的消息里有
tool_use块，stop_reason却是end_turn，客户端按规矩不去执行工具。 - 流式请求里两路并行调用被并成一个
tool_use，参数拼在一起，stop_reason退化成max_tokens，看起来像回答被截断。 - 内置的
gemini通道走另一套翻译，第一条在它身上不会发生。
值班动作：翻一眼那条 Claude→Gemini 的通道类型。
接在
openai-compatibility 上的，下面两节就是你要核的那几行；接在内置 gemini 上的，直接看处置那一节。中间隔着两层协议，缺陷落在翻译层
客户端打
/v1/messages，说的是 Anthropic 那一套；上游是一条 OpenAI 兼容通道，说的是 Chat Completions 那一套。两边靠一个翻译器对接，注册方向写的是 Claude 到 OpenAI。6
Gemini 的 OpenAI 兼容端点
https://generativelanguage.googleapis.com/v1beta/openai 是这类通道最常指向的地方。7它在工具调用上有两个习惯，正好各踩一处。
工具调用那一轮，它把
finish_reason 写成 stop。OpenAI 自己的接口在同样的轮次写的是 tool_calls，差别就在这里。并行调用的时候，它给每个调用单独发一个 chunk。chunk 里只有一个
tool_calls 元素，而且不带 index。这两条都来自报障人附在上游报文里的实际响应与流记录。
前一个习惯只伤非流式，后一个只伤流式。
影响面比 Gemini 宽。任何 OpenAI 兼容上游，只要在带
tool_calls 的轮次写 finish_reason: stop，非流式这条路就翻出 end_turn；只要流式的并行调用不带 index，两路就会被并成一路。打 OpenAI 官方接口的通道两种写法都碰不到。这也是这类问题一直没被普遍发现的原因。
非流式：工具块在，stop_reason 却是 end_turn
翻译文件是
internal/translator/openai/claude/openai_claude_response.go，v8.0.35 里 1010 行。这一层有两个非流式入口。一个在
convertOpenAINonStreamingToAnthropic，第 454 行起；另一个在 ConvertOpenAIResponseToClaudeNonStream，第 805 行起。
convertOpenAINonStreamingToAnthropic，v8.0.35：第 501 行把工具块收进 content，第 510 行起才决定 stop_reason，中间没有一处看这个回复里有没有工具。问题出在顺序。第 823 行先把标记置成已设置，第 958 行的兜底就进不去了。11
于是返回体里同时出现两样东西：
content 里一个完整的 tool_use 块，stop_reason 写着 end_turn。工具不跑，这一轮对话到此为止。客户端那边看起来就是模型说完了，却什么也没干。
判据落在返回体上：非流式请求，搜
stop_reason。有 tool_use 块却是 end_turn 的，就是这一条。流式：两路并行调用被并成一个 tool_use
流式转换从第 219 行起，工具调用那段在第 325 到 381 行。13
转换器先看 delta 里有没有
index，没有就退回数组下标。每个 chunk 里只有一个调用，数组下标就都是 0，两路都写进同一个累加器。
后到的
id 会盖掉前一个。那几行只挡住了非字符串和空串，同位置换了个 id 这件事没有被当成新调用。参数则往同一个累加器里追加。
起始块只发一次。第一路把
content_block_start 用掉之后，第二路进来时已经有一块开着，就轮不到它自己开场。收尾拼出来的是一个
tool_use：id 是第一路的，input 是两段 JSON 首尾相接。参数解析不过，校验函数就判失败。14
客户端看到三样东西叠在一起：一个工具、参数解析失败、回答被 token 上限截断。
报障人把第三样形容成「像是被截断了」。三样里任何一样都会让人往错的方向查。
判据同样在返回体上：流式里只出现一个
tool_use，input 是两段 JSON 接着写，stop_reason 是 max_tokens。先确认自己中没中
三条同时成立才会中。
- 客户端打的是 Anthropic 协议的
/v1/messages，Claude Code 与 Anthropic 的 SDK 都是。 - 这条请求落到一条
openai-compatibility通道，比如 base-url 指着 Gemini 的/v1beta/openai。17 - 这一轮里模型要调工具。
resolveGeminiClaudeStopReason，v8.0.35：第 49–50 行见过工具就给 tool_use，第 57–58 行才轮到 STOP 映射 end_turn。同一个 Gemini 账号，接在
openai-compatibility 上中招，接在内置 gemini 上走的是另一条路。这个差别决定了下面怎么处置。现在能做什么
最彻底的一条：把这条 Gemini 上游从
openai-compatibility 换回内置 gemini 通道。两条缺陷都在「客户端说 Anthropic、上游说 OpenAI」这段翻译里。换了通道类型，这两处代码就不在链路上了。
换不了的话，先别用非流式。这一轮的
finish_reason 是 stop，非流式就必然回 end_turn，跟模型和工具都没关系。流式这条只在并行调用时坏。单次调用时第二路不存在，下标回退到 0 也只写一个累加器，收尾照样是
tool_use。并行是模型那边的行为，代理侧只有一个间接开关。
要不要押它，得拿自己的账号发一次会并行调两个工具的请求，看回来的是一个还是两个。
工具重的客户端，比如 Claude Code，直接挪到内置
gemini 或别的原生通道上最省事。修复还没有开始
单子是 open，0 评论，没有标签，也没有对应的修复合单。5
作者说两处补丁都写好了，各带一个测试。测试在 dev 的代码上失败、打上补丁通过。
go test ./internal/translator/...、go vet、gofmt 在他那边都干净。他没开 PR 的原因写在单里：
internal/translator/** 的改动会被 path guard 拦下。20这个工作流在 v8.0.35 里就有，命中这个目录的 PR 直接判失败。
就算今天有人接，也要等下一个 tag。v8.0.35 是 03:02 发的，本窗口没有更新的版本。2
上游与额度
OpenAI 全绿，活动事件 0 条，没有降级组件。24
Anthropic 全绿，今天没有事件。25
Google Cloud 仍是 7 条，最近一条还是 10 月 8 日到 9 日的 Cloud Storage。26
Codex 今天 UTC 仍未重置。最近一次已验证的全局重置在北京 10 月 18 日 04:41，距今约 50 小时。27
页面记 55 次全局、10 次 banked，24 小时概率 45%、48 小时 70%；把提示帖算进去的另一套口径是 21% 与 37%。
opentherank 记 63 次、中位间隔 3.1 天、最长 68 天（2025-12-25 到 2026-03-03）。28
社区这一侧，Codex 分区最新一条在昨晚 21:24，落在窗口之前，窗口内 0 条。29
Reddit 窗口内有一条 Plus 额度掉得快的自述，发在昨晚 23:04，属消费者订阅档位，与中转运维无关，未收。30
r/ClaudeAI 窗口内是作品展示与桌面端交互吐槽，同样没进。31
未收与待跟
codex-proxy 与 codex2api 窗口内 0 条。sub2api 只有置顶的交流群帖被顶起，内容没变。
#6788 有没有人接、path guard 会不会为它开口子，待跟。
修好之后还要等下一个 tag。这一轮没有可以升的版本，要动的只有你自己那条通道类型。
References
- 1sub2api Releases
github.com
- 2CLIProxyAPI Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5CLIProxyAPI issue #6788
github.com
- 6openai/claude 翻译器的注册
github.com
- 7Gemini 的 OpenAI 兼容层文档
ai.google.dev
- 8
- 9finish_reason 的映射表
github.com
- 10第二个非流式入口与它的兜底
github.com
- 11兜底分支第 958 行起
github.com
- 12stop_reason 的官方语义
platform.claude.com
- 13流式转换里的工具调用段
github.com
- 14hasValidToolCallArguments
github.com
- 15effectiveOpenAIFinishReason
github.com
- 16收尾时写进 message_delta 的那一行
github.com
- 17openai-compatibility 通道的配置写法
github.com
- 18原生 Gemini 通道的收尾判定
github.com
- 19请求侧的 disable_parallel_tool_use 映射
github.com
- 20拦 translator 改动的那个工作流
github.com
- 21main 分支上的同一个文件
github.com
- 22CLIProxyAPI main 的提交时间轴
github.com
- 23sub2api main 的提交时间轴
github.com
- 24status.openai.com
status.openai.com
- 25status.anthropic.com
status.anthropic.com
- 26status.cloud.google.com
status.cloud.google.com
- 27codex-reset.com
codex-reset.com
- 28opentherank Codex 重置追踪
opentherank.com
- 29community.openai.com Codex 分区
community.openai.com
- 30r/OpenAI 那条额度自述
reddit.com
- 31r/ClaudeAI
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.