10/16 晚间速报：关掉思考的 /v1/messages 有人提了修复但只管到一条路径；CLIProxyAPI 把先回 200 再报坏调用的那条流开成草稿
10 月 16 日晚间这七十来分钟里四个仓库都没发新版本：sub2api 上一期那张关掉思考就报 400 的报障拿到了修复 PR，但它只管到两条失败路径里的一条；CLIProxyAPI 把「先回 200 再报坏调用」的那条流开成草稿补救，另关掉一条挂了五周、修挂起后凭证被锁的 PR。
10 月 16 日北京 19:31 到 20:40 这七十来分钟里，四个仓库还是没有发出新版本。
动静都在条目里：sub2api 与 CLIProxyAPI 各新开一条，CLIProxyAPI 还关掉一条挂了五周的修复。
今晚要当场决定的是三件事：关掉思考的请求报 400，该等这张新修复还是照旧绕行；Claude Code 走 Gemini 后端「开头正常、中途报错」这个组合今晚有没有可用的修复；跑在会休眠主机上的转发进程，醒来后凭证不可用要不要动配置。
一、sub2api：给那个档位报障的修复开出来了，但它只管到一条路径
上一期登记的报障 #8156 在本窗口拿到了第一条评论，也拿到了第一张修复 PR5。
PR #8161 在北京 20:32 开出，open、非草稿，2 个文件 +28/−15，基分支
main，head 分支是 wucm667:fix/issue-8156-synthesized-reasoning-mapping，正文写 Fixes #81565。改动只有一处：删掉 handler 里那段早退。v0.2.17 的
backend/internal/handler/composite_platform.go 第 166–168 行是一段注释，写着「转换会给一个默认档位，所以只在客户端显式带 output_config.effort 时才绑定分组策略」6。第 169–171 行就是那句判断，第 177 行才把分组策略绑进请求上下文6。删掉之后，这条绑定不再看客户端带没带那个字段。
报障人写下的怀疑也拿到了别人的验证。评论者 ongsh 在北京 19:46 回帖，说自己在 v0.2.17（源码基线
b0a02a33）上复现了两条路径，并给出了自己的候选补丁7。第二条是显式带了 effort、同时又带
thinking.type: "disabled"。关掉的思考在转换里优先级更高，先产生 none；在配置的 none → low 映射跑起来之前，它就被兼容性校验拦下7。评论者特意写了一句：他们观察到的那个
high 只是当时的档位设置，不是必需值、也不是桌面端的通用默认7。所以「显式带 effort 又关掉思考」这条路径在转换里就先回 400，删掉早退够不着它。这张 PR 管到的是另一条。
今晚的处置不变，还是那三条：客户端不关思考、显式带一个合法的
output_config.effort、或者换掉 gpt-6.1-sol 家族的拼写。这张 PR 还在 open，等它合并、再等一个版本。
backend/internal/handler/composite_platform.go 第 158–182 行：第 166–168 行是那段说明为什么不绑的注释，第 169–171 行就是被 #8161 删掉的早退，第 177 行才把分组策略绑进请求上下文6二、CLIProxyAPI：把「先回 200 再报坏调用」的那条流开成草稿
CLIProxyAPI 新开的 PR #6686 在北京 20:18 出现，是草稿，8 个文件 +1088/−142，基分支
dev12。它处理的现象是：Gemini 先以 HTTP 200 接下一条 Claude Messages 流式请求，然后在给出可用输出之前以
MALFORMED_FUNCTION_CALL 收尾12。要命的是转发时机。这个错误在 Claude 的
message_start 握手之后才送给客户端，Claude Code 于是把它当成「回复到一半出错」，而不是去重试工具循环12。这条线上更早的一次改动是 10 月 14 日的 #6606。它把这条结束原因的拒绝映射改对了，也就是不再让它以
refusal 收场；错误什么时候转发，那次没有动13。这个错误不是把上游报文原样转出去，是翻译层自己发的。v8.0.31 的
internal/translator/gemini/claude/gemini_claude_response.go 第 39 行是那句固定载荷14。第 41–43 行判定什么样的结束原因算坏调用：
MALFORMED_FUNCTION_CALL，且这一轮没有工具调用14。顺序在 v8.0.31 自带的测试里就能看到：一段 SSE 先是
message_start，紧接着就是那条 error15。改法是先接住、再重试一次。它只缓冲有界的、只有元数据的那一小段流前缀12。
它明确不做两件事：不重建坏掉的参数、不删工具声明。目标有歧义、已经吐过输出、工具选择约束不兼容这三种情况，仍走原来的报错路径12。
同一张补丁里还添了一个共用的终局判断（新文件
internal/translator/gemini/common/finish.go），把原先「报文里出现 finishReason 字样就算终局」的判法换掉12。v8.0.31 第 374 行就是那个老写法。作者自述的边界有四条：只限走 Gemini 后端的 Claude Messages 流；依赖
finishMessage 里可识别的调用头格式12。另外两条是：首个元数据握手会晚一点到；符合条件时会多打一次上游生成，外层重试预算不变12。
作者还写明，Windows 上全量
go test 不绿，是两个与本改动无关的已知失败在挡12。处置：这是草稿，今晚没有可用修复。遇到「Claude Code 开头正常、中途报错」的组合，先把它记成候选，别改配置。
internal/translator/gemini/claude/gemini_claude_response.go 第 30–58 行：第 39 行是那句固定错误载荷，第 41–43 行判定什么样的结束原因算坏调用，第 45 行起是它平时怎么写回 Claude 的结束原因14三、CLIProxyAPI：挂起后凭证被锁那条修复，今天被关掉了
它要修两半。一是后台刷新循环的计时器改用
CLOCK_BOOTTIME 口径，让 Linux 挂起之后仍按真实时间到期16。二是让 access token 已过期、但 refresh token 还有效的凭证继续留在可选项里，由请求去触发刷新16。
两半都没有落地。v8.0.31 的
sdk/cliproxy/auth/auto_refresh_loop.go 第 155 行还是 time.NewTimer(time.Hour)，dev 的同一行也一样，整个文件里没有 BOOTTIME 字样17。上游那条报障更早，9 月 8 日就被以 completed 关闭、0 评论；今天关掉的是它的修复 PR18。
处置：转发进程跑在会休眠的主机上的（笔记本、按需唤醒的容器），唤醒后如果出现「凭证带着 refresh token 却一直不可选」，现在只有重启进程或手动触发一次刷新。这条没有版本支持可以等。
四、同一窗口里的短条目
sub2api PR #7036 在北京 19:33 被更新，open，标题是让 Codex 出站身份画像对齐；本刊仍没有在这张单子里核到新内容19。
codex-proxy 与 codex2api 窗口内 0 条更新；codex-proxy 的预发布版仍没有占上
latest4。官方开发者社区 Codex 分区本窗口新增一条，北京 20:09 发出，说的是 Codex 0.163.0 把 MCP 的
cwd = "." 解析到 app-server daemon 的工作目录20。这是客户端侧行为，与中转运维没有直接关系，登记不展开。五、上游与额度侧
OpenAI 状态页在本窗口保持全绿：All Systems Operational、活动事件 0 条、没有降级组件21。上一期那条 Compliance API 事件转正之后没有再反复。
Anthropic 状态页是 All Systems Operational，10 月 16 日一栏写着 No incidents reported today22。Google Cloud 的事件列表仍是 7 条，最近一条仍是 10 月 8 到 9 日的 Cloud Storage23。
Codex 重置追踪站上，今天（UTC）没有重置。最近一次已验证的全局重置在 30 小时前，即 10 月 15 日 06:13 UTC、北京 14:1324。
累计是 54 次全局、10 次 banked，节奏约每 4 天24。页面上的 counted 口径仍是 24 小时 50%、48 小时 75%，那条提示帖已经过去 8 小时；公告区写着当前没有官方公布的窗口24。
另一个追踪站记最近一次为 10 月 15 日 04:55 UTC、自 2025 年 9 月以来 62 次、中位间隔 3.1 天25。
Reddit 三个板块窗口内与额度沾边的只有 r/GeminiAI 两条：北京 19:59 一条说连 Flash 3.8 的用量都变差26，20:19 一条给出自己的实验读数「Argon 4 High 每次调用吃 10–15%」27。
两条都是个人订阅侧的体感，按收录口径不收为条目。r/OpenAI 与 r/ClaudeAI 窗口内没有额度或风控条目。
六、未闭合项（下期继续跟，不作结论）
- sub2api：本窗口登记 #8161，#8156 拿到第三方复核；继续跟 #8161 会不会合并、合并后关掉思考的那条路径还会不会报 400，以及 #8160、#8157、#8158、#8159、#8155、#8151、#8139、#8135、#8136、#8142、#8143、#8146、#8147、#8127、#8125、#8123、#7962、#7398
- CLIProxyAPI：本窗口登记 #6686、关闭 #5585；继续跟 #6669 与 #6670 的关系，以及 #6676、#6677、#6515、#6675、#6605、#5764、#6661、#6667、#6659、#6671、#6673、#6625、#6603、#6500
- codex-proxy：本窗口 0 条；继续跟 v2.1.18 正式版会不会打上
latest - codex2api：本窗口 0 条；继续跟 #793 有没有维护者定性28
下期优先回看三条：#8161 会不会合并、ongsh 那条候选补丁会不会被采纳；#6686 会不会从草稿转正；#5585 被关之后，挂起后的刷新计时器有没有别的实现接上。
References
- 1sub2api Releases
github.com
- 2CLIProxyAPI Releases
github.com
- 3codex2api Releases
github.com
- 4codex-proxy Releases
github.com
- 5sub2api #8161
github.com
- 6composite_platform.go 第 158–182 行
github.com
- 7#8156 评论
github.com
- 8anthropic_to_responses.go 第 18–24 行
github.com
- 9anthropic_to_responses.go 第 433–445 行
github.com
- 10openai_gateway_messages.go 第 153–160 行
github.com
- 11openai_gateway_messages.go 第 298–306 行
github.com
- 12CLIProxyAPI #6686
github.com
- 13CLIProxyAPI #6606
github.com
- 14gemini_claude_response.go 第 36–44 行
github.com
- 15code_handlers_error_test.go 第 407 行
github.com
- 16CLIProxyAPI #5585
github.com
- 17auto_refresh_loop.go 第 150–170 行
github.com
- 18CLIProxyAPI #5584
github.com
- 19sub2api #7036
github.com
- 20Codex 0.163.0 帖
community.openai.com
- 21OpenAI Status
status.openai.com
- 22Claude Status
status.anthropic.com
- 23Google Cloud Status
status.cloud.google.com
- 24codex-reset.com
codex-reset.com
- 25opentherank
opentherank.com
- 26r/GeminiAI 1x7e9r7
reddit.com
- 27r/GeminiAI 1x7eow0
reddit.com
- 28codex2api #793
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.