Claude 走 /v1/chat/completions 取不到 reasoning_tokens：v8.0.43 与 dev 都只拷四个计数
CLIProxyAPI 的 Claude→OpenAI chat completions 翻译只搬四个计数，思考 token 在入口处就丢了；补丁开出四分钟后按仓库贡献规则自关，实现搬进 issue。文里给了一分钟判定与三处改法。
上游把思考量报给了中转，中转没往下传。v8.0.43 上，Claude 模型走
/v1/chat/completions，usage 里没有 completion_tokens_details.reasoning_tokens，流式与非流式都一样。1Claude 把思考量放在
usage.output_tokens_details.thinking_tokens。执行器侧的解析写得清楚：注释写明思考是 output_tokens 的子集，回落链先读嵌套字段、再读旧别名。4丢的那一步在翻译层，只发生在这条把 Claude 响应改写成 OpenAI chat completions 的链路上。
影响面
中转自己的账不受影响。用量记录走执行器侧那份解析，思考 token 照旧进账；下游看到字段为空时，上游该记的量仍然记着。
internal/translator/claude/openai/responses/claude_openai-responses_response.go 第 1362–1380 行：第 1371 行把思考文本长度除以 4 得到 reasoningTokens，第 1378 行写进 response.usage.output_tokens_details.reasoning_tokens；非流式的同一算法在第 1765–1776 行。下游若拿这个字段算思考占比或做成本分摊，Claude 这档在 chat completions 是空的，在 responses 是个估数。
丢在哪一步
结构体只声明四个计数，外加一个「有没有收到过用量」的布尔；
Merge 也只认这四个键。9
internal/translator/claude/openai/chat-completions/claude_openai_response.go 第 36–68 行：claudeUsageTokens 只有 input、output、两个缓存计数与 HasUsage，第 52–68 行的 Merge 只读这四个键，output_tokens_details.thinking_tokens 没有落点。三处写出都从这几个字段取值，思考量在入口处就没有地方放。
message_delta 分支里，第 255–260 行依次写 prompt、completion、total、cached、cached_creation、cache_write 六个键，全部来自那四个计数；同样的六行在 message_stop 尾部块与非流式各重复一次。补丁要做的事，就是给结构体加一个计数字段，和一个「有没有报过」的标记。
同一个端点上，别的上游都在写
Gemini 那条链在
thoughtsTokenCount 大于 0 时直接写这个字段。10
internal/translator/gemini/openai/chat-completions/gemini_openai_response.go 第 356–372 行：第 364 行取 thoughtsTokenCount，第 367–369 行在它大于 0 时写 usage.completion_tokens_details.reasoning_tokens。同一台中转上，Gemini 与 Codex 的模型面板能看到思考占比，Claude 的看不到。
补丁为什么没并进来
仓库的贡献规范写在
AGENTS.md 第 50–51 行：默认不要单独改 internal/translator/；确实只需要改这一处时，先确认自己有 WRITE、MAINTAIN 或 ADMIN 权限，没有就开一张 issue，写明目标、理由与实现代码，然后停下。14PR #6990 走的就是这条路。北京 08:33:37 开出，08:37:29 由作者自己关闭，未合并，2 个文件 +99/−0。15
issue #6991 在北京 08:37:27 开出，比那张 PR 关闭早两秒，正文里贴了完整实现和一段 diff。1
作者先提了补丁，读了规范再把它搬进 issue。仓库对「只改翻译层」的改动就是这么要求的。
issue 里还附了一组自测：
claude-sonnet-5 走原生 /v1/messages 并开思考，output_tokens 52、thinking_tokens 32；同一个模型走 chat completions 带 reasoning_effort: high，思考确实跑了，completion_tokens 从 17 涨到 46–53，usage 里却没有 completion_tokens_details。1今晚怎么处置
先判定。拿一台跑 v8.0.43 的中转，用 Claude 模型发一次
/v1/chat/completions，请求里带 reasoning_effort——这条链会把档位翻成 Claude 的 thinking 配置。17 看响应 usage 里有没有 completion_tokens_details，流式与非流式各试一次。计费别跟着改。中转的账照旧，字段为空说明的是翻译层少搬了一个数。
要这个字段，就自己打三处：结构体加思考计数与「是否上报」标记；
Merge 读 output_tokens_details.thinking_tokens；三处写出各补一行 completion_tokens_details.reasoning_tokens。上游没报时留空，写 0 会让下游以为那次没思考。验收用作者分支上的三个用例。不想动代码，就等下一版。盯 #6991 的状态与 Fixed 标签，那是维护者接手后会动的地方。
版本与上游
四仓本窗口零新版本：
- CLIProxyAPI v8.0.43，北京 10-25 23:37 2
- sub2api v0.2.18，10-23 15:44 18
- codex-proxy v2.1.20，10-23 03:56 19
- codex2api v3.1.1，10-17 05:42 20
四仓主干头也都停在窗口之前：CLIProxyAPI dev 停在 10-26 03:25、main 在 10-25 22:45；sub2api main 在 10-25 21:48；codex-proxy dev 在 10-23 03:54；codex2api main 在 10-26 00:39。3
还没闭合
#6991 开着，零评论、没有标签，维护者还没表态。补丁进下一版之前，这条链上的 Claude 模型都会缺这一个字段。
#6990 已由作者关闭，不会再合。
References
- 1CLIProxyAPI issue #6991
github.com
- 2CLIProxyAPI v8.0.43 发行页
github.com
- 3dev 分支 claude_openai_response.go
github.com
- 4v8.0.43 usage_helpers.go 第 1205–1212 行
github.com
- 5
- 6同文件第 277–288 行
github.com
- 7同文件第 444–451 行
github.com
- 8
- 9
- 10
- 11
- 12同文件第 523–529 行
github.com
- 13
- 14CLIProxyAPI AGENTS.md 第 50–51 行
github.com
- 15CLIProxyAPI PR #6990
github.com
- 16
- 17
- 18sub2api 发行记录
github.com
- 19codex-proxy 发行记录
github.com
- 20codex2api 发行记录
github.com
- 21OpenAI 状态
status.openai.com
- 22Claude 状态
status.claude.com
- 23Google Cloud 事故列表
status.cloud.google.com
- 24Codex 重置追踪接口
codex-reset.com
- 25OpenAI 开发者社区 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.