带 Codex UA 的请求一进插件路就 400：整数改写动到了工具参数类型
这一小时四仓没有新版本，但三条新报障都指向同一件事：本地改写动了不该动的东西。插件路上带 Codex UA 的请求会被整数归一化改坏工具参数而全 400，Claude 条目仍在劝客户端按原图精度发图，而 Fast 的额度类 429 会被当成整号限流。
窗口 2026-11-02 17:08–18:30（北京 11-03 01:08–02:30）里，tracked 的四个仓库没有发出任何新版本：CLIProxyAPI 停在 v8.0.511，sub2api 停在 v0.2.192，codex2api 停在 v3.1.23，codex-proxy 的稳定版仍是 v2.1.214。
但今天凌晨这三条新报障，说的是同一件事：本地那层改写动了不该动的东西——把工具参数的类型改了、把图片精度的那面旗留着、把拒绝的理由翻成了正常收尾。这类故障不会在升级日志里出现，只会在客户端上表现成 400 和「之后每一轮都失败」。
一、带 Codex UA 的请求一进插件路就 400：整数归一化改到了工具参数
条目 #7211，18:16 由 fermumen 报出，截至目前 0 评论、无 PR5。
现象是这样：用插件提供 OpenAI 模型（他跑的是 GitHub Copilot 插件），客户端是 Codex，那么所有
/v1/responses 请求一律 400，插件只把上游那句 Copilot upstream returned HTTP 400 抛出来，看不到更细的原因。他做的对照很干净，也正好是今天的判据：同一份 body，
User-Agent 换成 curl/8.0 就 200；只要 UA 里带 codex 字样就 400。再把 collaboration.wait_agent.timeout_ms 从浮点改成整数，单独改这一处仍然 400；而把请求砍到只剩 exec_command.max_output_tokens，反而 200。这条链路在 v8.0.51 里读得出来。
payload_helpers.go 的 ApplyPayloadConfigWithTrackedPathsForExecutor 在应用规则之前先看两件事：来的是不是 Codex 客户端，目标执行器是不是 codex——只有「是 Codex 客户端、但目标不是 codex 执行器」才跑 NormalizeCodexToolIntegerTypes6。
而插件执行器恰好在 v8.0.42 之后也走同一套最终器：
prepareExecutorCall 里调了一次 helps.NewPayloadFinalizer(...)，紧接着把结果盖回 nativeReq.Payload7。
两件事叠起来，插件路的 Codex 请求就同时满足「客户端是 Codex」和「目标不是 codex 执行器」，于是每个数值型工具参数都被改成整数——上游模型把这些工具名当成保留名，直接拒。
版本二分我自己按 tag 逐版探过，比报障人写的更准：
internal/pluginhost/adapters_executors.go 里出现 NewPayloadFinalizer 是 v8.0.42 起，v8.0.38 到 v8.0.41 都是 0 处。引入它的提交是 e42eee6e1c，主题是「把用户的 payload 规则应用到插件执行器请求上」，提交正文写明只在翻译之后挂一次最终器8。这里要说清与本刊的关系：10-24 那期讲过「payload 规则搬到了插件门口」，那是介绍这次搬迁本身；今天报的是它的副作用——搬迁顺手把 Codex 客户端那套整数归一化也带进了插件路。它不是新功能，是旧改动的滞后账单。同类报障之前也出现过一次，是 #6244，当时是工具名被上游当成保留名挡下9。
今天能做的三件事：
- 先确认是不是它：把出问题的那份 body 原样重放，只改
User-Agent。换成不含 codex 的 UA 就 200，基本可以判定命中。 - 绕开：插件路给的 OpenAI 模型，客户端不要用 Codex；已经必须用 Codex 的，短期只能把这条插件排除在 Codex 的模型列表之外。不要指望用 payload 规则去救——出问题的正是规则执行之后附带的那步归一化。
- 上报：这条链路没有开关可关。要给上游的信息就是上面那组对照（UA、单个字段），比贴四百行日志有用。
二、/v1/models 给 Claude 条目留了「按原图精度发」的旗，多图对话一撞 3000px 就回不来
条目 #7209，17:43 由 lpoto 报出，0 评论10。
Codex 客户端会读
/v1/models 里每个条目的能力字段来决定怎么发图。v8.0.51 给非纯 Codex provider 的条目清理了一批不该广告的键，但清理名单只有六个：apply_patch_tool_type、tool_mode、use_responses_lite、supports_reasoning_effort_updates、upgrade、availability_nux，supports_image_detail_original 不在里面11。
于是 Claude 条目也带着「支持 original 精度」出去。Codex 信了，截图按原图尺寸发；等对话里攒够多张图，Anthropic 整条请求被拒：
At least one of the image dimensions exceed max allowed size for many-image requests: 3000 pixels。图还留在历史里，所以之后每一轮都失败，这个会话等于废掉。之所以会走到这一步，是因为目录里 Claude 模型确实声明了图片输入——v8.0.51 的内置模型表里，
claude-opus-4-6 这类条目带 "supportedInputModalities": ["text","image"]12。图片能力是真的，只是「按原图精度发」这半句对 Anthropic 不成立。3000px 这个上限本身，本刊 10-20 深夜那期已经写过，并明确说了那不是「让中转去压缩图片」的请求。所以这节只补一件事：把客户端推过去的那面旗在哪、怎么关。报障人给的最小改法是在清理函数里补一行
entry["supports_image_detail_original"] = false，因为它跑在两个 setter 之后，模板与非模板两条路都能覆盖；另一条路是加一个默认关闭的开关（upstream.claude.image-detail-original），好处是能逐 provider 关。在补丁落地之前，运维侧能做的只有一条：用 Codex 带图访问 Claude 模型时，先确认这条会话不会塞进第二张原始尺寸截图；已经报 400 的会话不要再重试，换新会话。这个 400 不会被当成「换号的信号」，它在本机就结束了。
三、Claude 的进度旁白在 Codex Desktop 里只剩一行折叠（次要条目）
条目 #7210，17:44 由同一位报障人提出，0 评论13。
Claude 在长任务里会写短进度句（
thinking.display: "updates"），中转把每个 thinking 块统一映射成 Responses 的 reasoning 项，而 Codex 把 reasoning 折叠成一行。结果是一段几十次工具调用的长任务在界面上看起来像沉默。报障人给的数字对比是同长度会话：Claude 侧 38 个 reasoning 项、54 次工具调用、1 条助手消息；GPT 侧 43 条 commentary、231 次工具调用。提案是加一个默认关闭的
upstream.claude.codex-progress-commentary，把 narration 块输出成 phase: "commentary" 的助手消息，回放时还原成原来的 narration 块。v8.0.51 的签名校验已经认 narration 这种块类型14，所以这条路在协议层是通的。它和 10 月底那期是镜像关系：那期讲的是 Codex 的 commentary 被写进 thinking 块、要靠
show-codex-commentary 才看得见；这条是反方向，Claude 的旁白在 Codex 里被折进去。两条都还没落地，方向相反，别把开关记混。四、sub2api：Fast 只过滤了 beta 头，没过滤 body 里的 speed；额度类 429 还会被当成整号限额
补丁 #8488 由 cyhhao 在 17:10 提交，25 个文件 +1412/−80，mergeable clean，未合并15。
作者的自述说了两处，都是现网 v0.2.19 的真实行为：
第一处：Fast 策略配成过滤
fast-mode-2026-02-01 之后，过滤只作用在 beta 头上。请求 body 里带 speed: "fast" 的，照样按 Fast 发出去、按 Fast 计费；只靠 body 声明的请求，也完全绕过了那条 block 规则。这一点在代码里能直接看到：
stripBetaTokens 处理的是「逗号分隔的 header 值」，对 body 一个字都不碰16。策略里那个 token 常量在 settings_view.go 的 BetaToken: "fast-mode-2026-02-01"17。
第二处，也是更贵的那处：
{"type":"rate_limit_error","message":"Usage credits are required for fast mode."} 这种 429 是「这一档速度没权限」，不是「这个号整体超额」。但 v0.2.19 的 429 处理走 handle429，Anthropic 分支按 anthropic-ratelimit-unified-5h-reset / -7d-reset 算出重置时刻就把账号标成限流；当两个窗口都没被标成超额时，它的兜底取的是两个重置时刻里更早的那个18。于是「这一档没权限」会锁住整号，持续时间还是从别的窗口借来的。池模式下，同一个没改过的请求会被反复投到下一个号上。补丁要做的三件事：从实际发出去的 body 反推计费档（被过滤的请求不按 Fast 计费）、把这条 429 从「整号限额」里摘出来、并且不做自动的 Fast→标准重试（匹配是精确且限定 provider 的）。
因为没合并，今晚没有可改的配置。能做的只有观察：如果日志里 Fast 相关的 429 后面跟着整号冷却，那八成是这一条，而不是真的超额。
五、codex2api 三笔并进 main，一个都没发版
三笔都在窗口内合进 main，v3.1.2 之后任何一条都还没有对应的发行版。
#838（17:26 合并，66 文件）。续聊换号这条线补了上下文持久化（
cache/durable_response_context.go），新增 reset_5h_first 调度模式与 next_reset_5h_at 字段，并把 gpt-6.1-terra 的定价补进表里19。对运维的意义是：换号之后不再从零重建对话，代价是本地多了一份上下文存储要管。#839（17:45 合并，7 文件）。这一笔带着破坏性默认值：
STABILIZE_DEVICE_PROFILE 从「默认关」翻成「默认开」——现在只有显式写 false 才关得掉2021。设备指纹稳定化的意思是按「账号 + key」算出一个固定画像，不再每次轮换；对风控是双刃：稳定之后同号画像一致，但一旦被关联也不会自己漂移。同一笔还把刷新 token 的客户端换成 uTLS，.env.example 里的示例值改成了 utls_chrome，而注释仍写着默认 standard——样例和注释现在自相矛盾，升级前别照抄那行注释。
#842（18:00 合并，6 文件）。新增一层 Responses 工具到 Gemini 函数的展平，命名空间、自定义工具、
tool_search、additional_tools 都转成扁平函数并保留别名映射，回程能对回去；它复用 Grok 那套编解码但跳过 Grok 的 schema 归一22。Antigravity 上跑带工具的 Responses 请求会受影响，升级后建议先拿一条带自定义工具的请求验一遍。三笔都不在 v3.1.2 里。要用的只能跟 main，而 main 现在没有 tag。
六、这一小时的行情
| 仓库 | 当前版本 | 本窗口内 |
|---|---|---|
| CLIProxyAPI | v8.0.51 | 无新版本；main 最后一次提交在北京 11-03 00:03，早于窗口 |
| sub2api | v0.2.19 | 无新版本、main 无新提交 |
| codex2api | v3.1.2 | 无新版本；main 前进三笔（见上节） |
| codex-proxy | 稳定 v2.1.21 / 预发布 v2.1.22-beta | 窗口内无动作 |
重置这块也没有新动静：追踪站的 feed 里最新一条帖在北京 11-02 23:51，且不属于重置类信号，
signal.active 为 false26。首页口径是「今天 UTC 还没有重置，最近一次已验证的全局重置在 5 天前（10-28 18:35 北京）」，累计 61 次、存量 10 次26；另一家统计到 71 次、中位间隔 2.9 天27。两家口径不同，按各自标签引用。社区侧这一小时没有取到信号，不等于没有新帖：Reddit 的两个板块接口连续返回 502（XML 解析失败），本轮没读到任何内容；OpenAI 开发者社区 Codex 分区 RSS 能读通，但最新一条话题停在北京 11-03 01:05，落在窗口之外，所以窗口内是 0 条28。
今晚与升版前分开做
今晚（不用动版本就能做的）：
- 插件路跑 Codex 的先做一次 UA 对照，命中就先把这条插件从 Codex 的模型列表里摘掉。
- 用 Codex 带图访问 Claude 的，确认会话里没有第二张原始尺寸截图；已经 400 的换会话。
- Fast 相关的 429 出现后，去日志里看是否同时把整号标成限流——是的话，这不是超额。
升版前（等发行版落地再核）：
- 看 CLIProxyAPI 下一版是否在
nullCodexClientRequiredOptions里补了图片精度那行；补了才谈得上根治。 - 看 sub2api 是否合了 #8488；合了之后重新跑一遍 Fast 策略的过滤测试。
- codex2api 出 tag 时，先确认
STABILIZE_DEVICE_PROFILE的默认值有没有再动——这一笔是默认值变化，不是新功能。
References
- 1CLIProxyAPI releases
github.com
- 2sub2api releases
github.com
- 3codex2api releases
github.com
- 4codex-proxy releases
github.com
- 5CLIProxyAPI issue 7211
github.com
- 6CLIProxyAPI payload_helpers.go v8.0.51
github.com
- 7
- 8CLIProxyAPI commit e42eee6e1c
github.com
- 9CLIProxyAPI issue 6244
github.com
- 10CLIProxyAPI issue 7209
github.com
- 11CLIProxyAPI models.go v8.0.51
github.com
- 12CLIProxyAPI models.json v8.0.51
github.com
- 13CLIProxyAPI issue 7210
github.com
- 14CLIProxyAPI claude_validation.go v8.0.51
github.com
- 15sub2api pull 8488
github.com
- 16
- 17sub2api settings_view.go v0.2.19
github.com
- 18sub2api ratelimit_service.go v0.2.19
github.com
- 19codex2api pull 838
github.com
- 20codex2api device_profile.go main
github.com
- 21codex2api pull 839
github.com
- 22codex2api pull 842
github.com
- 23OpenAI status incidents
status.openai.com
- 24Anthropic status summary
status.anthropic.com
- 25Google Cloud incidents
status.cloud.google.com
- 26codex-reset feed
codex-reset.com
- 27opentherank codex-reset
opentherank.com
- 28OpenAI community Codex 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.