同一段话被念两遍：Codex→Claude 不读 message.phase，v8.0.39 与 dev 都没修
Codex→Claude 翻译层把 commentary 前导当成正文，同一段话被念两遍，v8.0.39 与 dev 都没修；另附 sub2api 漏记网页搜索与 advisor 轮次、codex2api 同步后丢 context_window 两张未合并的修复单。
窗口内四个仓库都没有新版本，也没有新的合并。
04:33 之后却开出三条单，每条都带着能核到行号的代码，症状是同一个形状：东西在悄悄丢，报错里看不出来。
先看第一条，它直接摆到用户面前。另外两条一条丢钱、一条丢字段。以下时间都是北京时间。
一、同一段话被念两遍，v8.0.39 与 dev 都没修
05:18 开的 #6895 描述了一个很好认的现象。1
用 Claude 协议的客户端（Claude Code 这类）经 CLIProxyAPI 打 Codex 上游时，GPT-5.x 一次回答会给两个 message 项：一个
phase 为 commentary 的前导，一个 phase 为 final_answer 的正式答案。翻译层把两个都做成 text 块。客户端于是把前导念一遍、再把答案念一遍；接了 TTS 的是真念两遍。
流式与非流式两条路都中。
证据在发行版里。v8.0.39 处理
response.output_item.added 时，switch 只有 function_call、reasoning、web_search_call 三个分支，没有 message。2
internal/translator/codex/claude/codex_claude_response.go 第 180–205 行：output_item.added 的 switch 到 web_search_call 就结束，第 206 行直接进了 output_item.done，中间没有读 phase 的地方。4整包也查了：v8.0.39 里
"phase" 只有 3 处，全在插件与 homeplugins，跟翻译无关。所以升级解决不了这件事，dev 上同样没有。
修法在 PR #6894：把 commentary 那一项映射成 thinking 块，正式答案仍是唯一的 text 块。7
它同时处理三件事：reasoning 的
encrypted_content 不挂到 commentary 上；没有 phase 的 message 原样走；流式与非流式都改。改动是 2 文件 +262/−20，含 5 个测试。代价是 commentary 会进 reasoning 通道，部分客户端会把它当思考内容展开。作者在 issue 里给了替代方案：整段丢掉 commentary，代价是连「模型在做什么」的提示也一起没了。
这张 PR 现在只能当补丁看。自动评审在 05:23 挂了一条 P1：当 commentary 流过 delta、而 final_answer 只在
output_item.done 里整段到达时，HasTextDelta 会留着上一项的 true，正式答案被跳过；commentary 那时已经成了 thinking，这一轮就没有任何可见文本。8同一个
HasTextDelta，也是 v8.0.39 本来就有的第二处缺陷：output_item.done 的 message 分支第一句就是 if params.HasTextDelta { return }。9上游只要有一项只在 done 里给整段文本、而前一项流过 delta，这一段就会被跳过。这条比「念两遍」更隐蔽，它丢的是内容。
同一条病根上还有一张更早的单：#6191 在 09-29 开出，讲 codex→chat 这条路把多个 message 直接拼接、同样不读
phase，到今晚仍未关闭。10今晚能做的两步：不改源码的就等，先跟客户端说清楚重复来自翻译层；要立刻止血的，本地打 #6894，并把 done 分支的
HasTextDelta 一并复位，否则会出现空回答。顺带一句，作者 05:18 自己写了这张 PR 为什么停在这里：仓库的路径守卫只让
internal/translator/** 的改动走 issue，PR 留作参考补丁。7二、sub2api 少收两笔钱：网页搜索次数与 advisor、compaction 轮次
04:51 开的 #8306 补的是两个从来没进过账的字段。11
第一笔是
usage.server_tool_use.web_search_requests，记这次请求用了几次网页搜索。官方价每 1000 次 10 美元，每次算一次、不看返回几条，报错的搜索不计费。12第二笔是
usage.iterations[]。开着 advisor 或压缩时，有一部分 token 只出现在这里、不在顶层用量里；advisor_message 按 advisor 模型的价格结算。1314v0.2.17 里这两样都不存在。
AnthropicUsage 结构体只有 input、output、缓存三类，外加几个 OpenAI 风格的兼容字段。15整包里搜不到
web_search_requests；iterations 只在测试代码里作循环变量出现。两个字段在反序列化时就丢了，SSE、JSON 与透传三条路都拿不到。
backend/internal/pkg/apicompat/types.go 第 170–183 行：结构体到 PromptCacheMissTokens 就结束，没有给 server_tool_use 与 iterations 留位置。16修法的计费口径写得很克制：搜索价先读分组配置，没配就按每 1000 次 10 美元兜底；iterations 只算
advisor_message 与 compaction，message 项已经在顶层算过、不重复；advisor 模型查不到价格时按 executor 的价算，注释里写明这是下界，不从零记。17缺口也清楚：作者本地没有 Go 工具链，测试没跑；机器人要求先签 CLA；状态是 5 文件 +145/−3、mergeable unstable、未合并。
今晚能自己做的先是对账：拿上游控制台这个账号的用量，与 sub2api 记的比，差出来的若是搜索费，就是这一条。
三、codex2api 同步完账号，context_window 反而没了
05:36 开的 #819 修的是另一件事：下发的模型清单里，
context_window 与推理默认值这些标量整项消失。18链条有三步。
第一步，清单下发前会与能力快照求交集：同一个 API key 能看见的所有账号，各自的能力声明取交集。
第三步，数字与字符串类字段拿到
null 之后会被 delete(model, name) 删掉，布尔类置 false、列表置空。20 所以 context_window、max_output_tokens、default_reasoning_level 会整项不见。
proxy/model_capabilities.go 第 204–231 行：只要有一个候选缺字段，complete 就是 false，非布尔项直接打成 null，交给下游删掉。21那快照为什么会缺。
v3.1.1 的同步上游模型入口只做三件事：记 Responses Lite 支持、保存 Daybreak 状态、把新模型学进注册表。里面没有保存能力快照这一步。22
读取侧还有一道：
ListModelCapabilities 的 SQL 要求账号当前代次与快照代次相等，令牌换过一次，旧快照就读不到。23最容易被打到的，恰好是换过令牌、又被共享 key 看见的账号。
admin/handler.go 第 4767–4783 行：同步函数保存了 Daybreak 状态、把新模型学进注册表，全程没有 SaveModelCapabilities，缺的那一步就在这里。24#819 把三处入口都接上：导入账号预热、
sync-upstream、refresh-all 的 codex 频道；抓取前把令牌与代次一起锁下来，读完 body 再记观察时刻，代次轮换后不会把响应挂到新代次上。两个自动评审都提了意见，作者 05:49 一笔提交修了三条，coderabbit 05:58 确认那条已修。18 状态是 6 文件 +130/−12、unstable、未合并。
修复合入之前能做的只有一件：让那个账号真跑一次模型清单，靠请求路径的异步学习把快照写进去。用共享 key 请求一次
/models 就会触发。25四、上游与社区：这一窗没有新的
四仓的版本与主干都停在窗口之前。CLIProxyAPI 的最后一次发行是 v8.0.39，dev 头停在 02:44。26 codex-proxy 的 v2.1.20 在 03:56。27 sub2api 的主干停在 10-22 10:33，codex2api 的主干停在 10-21 01:01。2829
另有一张一直挂着的：CLIProxyAPI #6715 在窗口内只多了一次把 dev 并进来的提交，最后一笔真实改动停在 03:19，仍是 35 笔提交、未合并。30
OpenAI 状态页窗口内有两条更新，都在产品侧：Dots on Enterprise 的降级 04:55 恢复，新广告账户分配管理员失败 05:30 仍是 identified。31
重置信号这边，两站口径照旧对不上。codex-reset 首页写的是今天 01:10 那次已验证重置、距今 5 小时、累计 57 次、10 张 banked；opentherank 同一时段给 65 次、中位间隔 3 天。3435 两家的统计范围不同，并列看就行。
官方社区 Codex 区窗口内没有新帖。最近一条是 04:15 发的「Can't redeem a banked reset!」，落在窗口之前，讲的是消费端账户兑换 banked reset。36
五、今晚的处置表
| 处境 | 今晚做什么 | 依据 |
|---|---|---|
| v8.0.39 加 Claude 协议客户端打 Codex，用户说答案重复 | 先确认是两个 text 块；要立刻止血就本地打 #6894，并补上 HasTextDelta 复位 | CLIProxyAPI #6895 |
| sub2api 有 Anthropic 协议流量，开了网页搜索或 advisor | 先对上游用量；要现在就算对，试 #8306 分支 | sub2api #8306 |
| codex2api 有共享 key 的 Codex 账号池 | 用该 key 请求一次 /models 让快照落库，或等 #819 合 | codex2api #819 |
| 只想知道要不要升版本 | 三条都还没进发行版，升级不解决问题 | CLIProxyAPI v8.0.39 发行页 |
References
- 1CLIProxyAPI #6895
github.com
- 2
- 3同一文件第 206–215 行
github.com
- 4codex_claude_response.go 第 178–210 行
github.com
- 5v8.0.33 的同一文件
github.com
- 6dev 的同一文件
github.com
- 7CLIProxyAPI #6894
github.com
- 8#6894 的 P1 评审意见
github.com
- 9第 210–213 行
github.com
- 10CLIProxyAPI #6191
github.com
- 11sub2api #8306
github.com
- 12Anthropic 网页搜索文档
platform.claude.com
- 13Anthropic 成本文档
platform.claude.com
- 14advisor 工具文档
platform.claude.com
- 15v0.2.17 的 types.go 第 170–183 行
github.com
- 16types.go 第 168–195 行
github.com
- 17#8306 的补丁
github.com
- 18codex2api #819
github.com
- 19
- 20同一文件第 372–386 行
github.com
- 21第 202–232 行
github.com
- 22v3.1.1 的 admin/handler.go 第 4767–4783 行
github.com
- 23
- 24第 4765–4792 行
github.com
- 25请求路径上的异步学习
github.com
- 26CLIProxyAPI 发行页
github.com
- 27codex-proxy 发行页
github.com
- 28sub2api 主干
github.com
- 29codex2api 主干
github.com
- 30CLIProxyAPI #6715
github.com
- 31OpenAI 状态页
status.openai.com
- 32Claude 状态页
status.claude.com
- 33Google Cloud 状态
status.cloud.google.com
- 34codex-reset
codex-reset.com
- 35opentherank 的 Codex 重置页
opentherank.com
- 36OpenAI 开发者社区的这条帖
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.