写了 high，落到上游是 medium：Claude→Codex 的档位被就地改掉
这一小时里 CLIProxyAPI 新开一条报障：Messages 端点显式写的 effort 在转去 Codex 时被换成 medium，另外三条翻译路则整个丢掉；本期给三组判据、四处源码位置、三档处置，外加 WebSocket 终局与两笔性能合并的进展。
这一小时是北京时间 14:36 到 15:40。四家仓库都没有新版本：CLIProxyAPI 停在 v8.0.361、sub2api 停在 v0.2.172、codex-proxy 停在 v2.1.193、codex2api 停在 v3.1.14。
受影响的是那些在 Messages 端点送 effort、又被路由到 Codex 上游的请求。客户端不会察觉：HTTP 200、SSE 正常收尾、没有错误码，它只会觉得模型变笨了。
同一条判断在另外三条翻译路上结果不一样——那里不是替换，是把值整个丢掉。下面分开讲。
先确认自己这套有没有中
报障人给了三组对照，同一句
Reply exactly OK.，只改 thinking 相关字段，三组都成功计费5：| 请求里带了什么 | 结果 | 被记下的档位 |
|---|---|---|
只有 output_config.effort: high，没有 thinking | 200 | medium |
thinking.type=adaptive 加 effort: high | 200 | high |
thinking.type=enabled 加 budget_tokens: 16000 | 200 | high |
第一行就是中招的样子。三组记下的都不是客户端声明的原值，而是代理翻译之后的值。
翻一遍最近那些「模型变笨」的请求，看这一栏是不是清一色 medium，就能定案。
为什么偏偏这条路变成 medium
output_config.effort 只在 adaptive / auto 这一支里被读。enabled 走 budget 换算，disabled 走 0。请求里根本没有
thinking 对象时，整个 if 被跳过，第 412 行照样把 medium 写进 reasoning.effort。
CLIProxyAPI v8.0.36 的 internal/translator/codex/claude/codex_claude_request.go 第 382–412 行：第 384 行把档位写死为 medium，output_config.effort 只在第 394 行的 adaptive / auto 分支里出现，第 412 行无条件写回。没有 thinking 时这一整段判断都不执行。6Anthropic 的文档把这两件事分得很清：effort 管整条回复花多少 token，thinking 管要不要先想，原文写的是「it works whether or not thinking is enabled」9。
同一页还写
high 是多数支持 effort 的模型默认档，只有 Opus 5.5 与 Haiku 5.5 默认 medium。所以这不是「回退到上游默认」，是代理替客户端挑了一个更低的档，还没留痕。
空配置意味着档位夹取那一步根本不会跑，
medium 原样发出去。另外三条路：不是替换，是丢掉
Gemini 那条的同一段判断，整块被包在「
thinking 存在且是对象」里面11。
internal/translator/gemini/claude/gemini_claude_request.go 第 322–352 行：第 324 行的 if 要求请求里先有 thinking 对象，output_config.effort 才可能在里面的 adaptive 分支被读到。没带 thinking 时，thinkingConfig 一个字都不会写。11四条路合起来是这样：
| 入口 → 上游 | 只带 effort、不带 thinking 时 |
|---|---|
| Messages → Codex | 写成 medium，覆盖客户端的 high |
| Messages → Gemini | 不写 thinkingConfig，上游按自己默认 |
| Messages → Antigravity | 不写 thinkingConfig，上游按自己默认 |
| Messages → OpenAI Chat | 不写 reasoning_effort，上游按自己默认 |
对运维的意味很具体：一个分组里同时挂 Codex 与 Gemini 两路上游，同一份客户端配置会在两路上得到不同的实际档位，而且哪一路都不报错。
今晚能做的三件事，按顺序
第一，客户端侧补一行。在
output_config.effort 旁边带上 thinking: {"type":"adaptive"}，就是上表第二组，实测能把 high 保下来。Copilot 的自定义端点要把模型元数据里的
adaptiveThinking 打开，它才会生成这个组合——这是报障人把 0.70.0 的实际构造代码跑在隔离环境里验证过的5。代价要清楚：它对该模型的所有请求生效，客户端明确要 low 的也会被抬到 high。
第三，等修复。截至发稿，开放 PR 里没有一条是冲这个来的，dev 分支同一行还是
medium15。同窗口另外三笔
凌晨报的那处 WebSocket 终局，第二笔修复补上了
今天凌晨那期写过：下游 WebSocket 的终局判定只认
response.completed / response.done 与 response.incomplete，response.failed 不算16。而同一版的 SSE 侧早就把
response.failed 算进终局了18——一处认、一处不认。
sdk/api/handlers/openai/openai_responses_websocket_forward.go 第 192–208 行：第 198 行的终局条件只有 completed / done 与 response.incomplete，response.failed 落在分支之外，所以走不到第 202 行的 completed = true。16现在 PR #6818 补上了，而且补了两笔：第一笔把
response.failed 并入终局，第二笔处理它后面紧跟的流错误19。第二笔是必要的：流适配器先关错误通道再关数据通道，两条同时就绪时，只认数据通道的写法会把那条错误一起吞掉。这次改成数据通道关闭之前先把错误通道取空。
第二笔提交落在 15:15（北京），PR 仍是 open、base 是 dev、2 文件 +196/−35、合并状态 clean，没有合。
对你：发版前手上这版仍会打 408 并关掉客户端 socket。认得这条日志，就不会把它误判成上游断流，也不会去查账号。
长会话「每块重扫整份请求体」的两处，进 dev 了
作者自测的数字（Apple M 系列、65 万字节历史）：Antigravity→Claude 流从每流 28.3 ms 降到 0.71 ms，工具名查表从每次 378 µs 降到 21 ns，Codex→Claude 流从每流 726 µs 降到 140 µs。
这属于等版本，不是调参。v8.0.36 里每来一个工具调用，都会拿整份原始请求重算一次工具名映射22。
dev 里改成首个工具调用时算一次、挂在请求参数上复用23。
internal/translator/codex/claude/codex_claude_response.go 第 780–800 行：第 787 行的 ToolNamesResolved 让反向映射每个流只构建一次，第 797 行那个每次重建的函数只剩兜底用途。v8.0.36 的同一位置没有这两个字段。23两笔都是 #6816 那张 P0 性能单的批次，那张单还开着，后面还会有同类改动24。
sub2api 的安全门禁：修复单开了，还没合
上期写的 #8266 那两条，现在有 PR #8267：
backend/go.mod 与安全扫描工作流的版本断言一起抬到 Go 1.27.3，pnpm override 把 follow-redirects 从 1.16.0 抬到 1.16.1，没有新增审计例外25。状态是 open、合并状态 unstable、0 条评论；main 上的
go.mod 还是 1.27.226。对运维的实际影响分两种：用发布二进制的，这一条不影响运行；自己从源码构建的，构建镜像得是 1.27.3 以上，否则 govulncheck 这关过不去。
另有 15:30 新开的 #8268：全站一键重置订阅额度现在做不到，因为批量接口一次最多 100 条、且必须显式列 ID27。这不是缺陷，是现状；活跃订阅超过 100 的站只能分批翻页收集 ID。
上游与额度
OpenAI 状态页现在全绿，窗口内没有新事故；最近一条是上午 10:26 到 11:28（北京）的 minor，已恢复28。
codex-reset 记录的最新一次全局重置是 25 小时前（北京 10 月 20 日 14:33），累计 56 次全局、10 次 banked31。
官方社区 Codex 分区窗口内 0 条新帖，最新一条发布于 14:11（北京），在本窗口起点之前32。
还没闭合
- #6827 有没有维护者接，修复会进哪个 tag；
- #6818 何时合，会不会先进 dev 再发版；
- #6828 / #6829 进哪个版本，后面几批什么时候到；
- #8267 的安全门禁何时转绿，#8266 何时关。
References
- 1CLIProxyAPI Releases
github.com
- 2sub2api Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5CLIProxyAPI issue #6827
github.com
- 6codex_claude_request.go 第 384 行
github.com
- 7usage/manager.go 第 50 行
github.com
- 8conductor_execution.go 第 1608 行
github.com
- 9Effort - Claude Platform Docs
platform.claude.com
- 10thinking/apply.go 第 735 行
github.com
- 11gemini_claude_request.go 第 324 行
github.com
- 12antigravity_claude_request.go 第 925 行
github.com
- 13openai_claude_request.go 第 74 行
github.com
- 14config.example.yaml 第 287 行
github.com
- 15dev 版同一函数
github.com
- 16
- 17同文件第 140 行
github.com
- 18responses_handlers.go 第 295 行
github.com
- 19CLIProxyAPI PR #6818
github.com
- 20CLIProxyAPI PR #6828
github.com
- 21CLIProxyAPI PR #6829
github.com
- 22gemini_claude_response.go 第 264 行
github.com
- 23dev 版 codex_claude_response.go 第 783 行
github.com
- 24CLIProxyAPI issue #6816
github.com
- 25sub2api PR #8267
github.com
- 26sub2api issue #8266
github.com
- 27sub2api issue #8268
github.com
- 28Degraded performance in ChatGPT, Codex, and APIs
status.openai.com
- 29Anthropic Status
status.anthropic.com
- 30Google Cloud 事故 Xs2XTHzAVC9YnafnPyzj
status.cloud.google.com
- 31Codex Reset Tracker
codex-reset.com
- 32Codex 分区 RSS
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.