10/17 上午速报：CLIProxyAPI 往 Gemini 转工具 schema 时，多一个 contentMediaType 就回 400；Claude 侧给 Opus 4.7/4.8 与 Fable 5/5.1 发数字预算同样被拒
10 月 17 日北京 08:55 到 10:00 这六十多分钟里四个仓库都没发新版本，今天能动手的只有三处参数：Claude 协议的工具 schema 里多一个 contentMediaType 就让 Gemini 请求整条 400，给 Opus 4.7/4.8 与 Fable 5/5.1 发数字预算同样被拒，而 Claude 回 429 或 529 时上游的重试头这一版还传不到客户端。
sub2api 仍是 v0.2.17、CLIProxyAPI 仍是 v8.0.32、codex-proxy 仍是 v2.1.18、codex2api 仍是 v3.1.1。
四条主干也没动：sub2api 的 main 停在 10 月 16 日 12:42（北京），CLIProxyAPI 的 dev 停在 10 月 17 日 03:57，codex-proxy 的 dev 停在 03:28，codex2api 的 main 停在 05:355678。
主干没动，窗口内也就没有合并落地。
今天要处置的只有两处参数，外加一张刚开的 PR。
北京 09:53 的新单：走 Claude 协议进来的工具定义，只要 schema 里带一个
contentMediaType，转发到 Gemini 就整条 4009。北京 09:10 的一条回复：给 Opus 4.7 / 4.8、Fable 5 / 5.1 发数字预算，同样被拒10。
北京 09:58 的新 PR：Claude 回 429 或 529 时，上游的重试头到不了客户端11。
一、工具 schema 里多一个 contentMediaType，Gemini 就整条 400
先给结论。
你的中转站如果有客户端走 Claude 协议、模型落到 Gemini，而工具定义里带着 MCP 那类 schema 注解，这个请求会稳定 400。
跟额度无关，跟模型能力也无关，是本刊转过去时没把这个注解摘掉。
他的复现是一句话：带着
contentMediaType 回 400，只删这一个字段就回 2009。上游原话是
Unknown name "contentMediaType" ... Cannot find field。出错位置在他真实请求里是
function_declarations[61] 的 parameters.properties[2].value.any_of[1]，同批还有 function_declarations[106] 的第 3 个属性9。多出来的不是业务字段，是 JSON Schema 的一个注解。
为什么这一版会把它原样转发
contentMediaType 与 contentEncoding 两个都没进去。
internal/util/gemini_schema.go：第 1507 行起的 removeUnsupportedKeywords，第 1509–1515 行是要删的关键字全表，$comment、enumDescriptions、discriminator、contentSchema 都在，没有 contentMediaType12另一侧还有一处让它更容易被放过。
这张表的用途是：出现表外关键字，就把 schema 判成不可分析、不许做破坏性清洗13。
contentMediaType 在表内，于是这一层认定它无害，清洗照常放行。一层认为它无害，另一层不认识它，结果就是它原样出现在发往 Gemini 的请求里。
不止 Claude 那一条路
三处入口用的是同一个清洗函数，只是拿到的字段名不同。
Responses 那侧拼 Gemini 的 functionDeclarations 时，在
responses_tools.go 第 496 与 517 行清16。所以不是某一家客户端的问题。
受影响的模型也不止报障里那一个，凡是从这三条翻译进 Gemini 的调用都走同一段代码。
今天怎么办
没有开关能关掉这层清洗，也没有配置项能指定保留哪些关键字。
三条路，按代价排。
一是客户端把工具 schema 里的
contentMediaType 去掉。报障人验证过，删掉即 2009。二是把这类请求路由到不吃这个字段的模型，别让它落进 Gemini。
报障人在一份可弃的 v8.0.32 检出上试过，加上后能递归删除，相关两个包的测试通过9。
补的时候留个心：名单删关键字前会先判断同名路径是不是一个属性定义，是就跳过12。
这条保护让"业务里真有一个字段叫 contentMediaType"的情况不会被误删，也正是报障人期望的行为9。
本刊没有在实例上复现这条链路，依据是 v8.0.32 的源码与报障人给出的对照结果。
二、Claude 这四款模型收档位、不收数字预算
上一期报的 #6698 讲"客户端要关掉推理，却被写成 disabled"；北京 09:10 的这条回复补上了同根因的另一半。
回复来自 fredcamaral，写得比原单更具体。
他的判断是这几款只收 adaptive。
边界也给得清楚：Opus 4.6 与 Sonnet 4.6 仍然收
budget_tokens10。为什么校验没拦住
这几款的模型目录同时写了预算区间与档位。
v8.0.32 的内置目录里，
claude-opus-4-7、claude-opus-4-8、claude-fable-5、claude-fable-5-1 的 thinking 都是 min: 1024、max: 128000 加一列 levels17。能力判定就按这两样分类：有预算也有档位，算 hybrid18。
而校验函数里，hybrid 这一支是空的，什么都不转换19。
internal/thinking/validate.go：第 86 行先判能力；第 102 行的"只有档位"一支会把预算换算成档位；第 114 行的 hybrid 分支是空的，所以同时声明了预算与档位的模型原样保留数字预算19这就解释了那处错位：目录写了预算范围，上游却不收这个形状。
默认值是按目录的声明定的，目录的声明与上游的实际接受面不是一回事。
目录是能在线上换的
这一点对这个题有用：模型目录不是编译死的。
校验要求它只能是 http(s) 或绝对路径23。
按上面这条链路，那类改动有可能不经过版本就到手上。
但别指望单靠改目录解决这一条。
今天怎么办
给这四款发档位，不发数字预算。
模型名后缀写
(high) 这类档位，或者干脆不写 thinking，让上游用自己的默认。已经在踩的，先看请求是怎么落到这几款的：带 OpenAI
reasoning_effort 数字的、或带 Claude budget_tokens 的，都可能被算成正数预算。三、Claude 回 429 或 529 时，这版不把重试头交给客户端
北京 09:58 开出的 PR #6700 修的是另一类症状。
作者 cyhhao，对着 dev，4 个文件 +89/−1，open、非 draft、与 dev 无冲突，1 笔提交11。
它描述的现象对中转站很实际：
passthrough-headers 打开时，成功的 Claude 响应会把上游头带给客户端，错误响应却不带11。丢的是
Retry-After、Retry-After-Ms 与 Anthropic-Ratelimit-Unified-*。Anthropic 回 429 或 529 时，客户端拿得到状态码和正文，拿不到该等多久11。
原因是错误分类函数把上游头读进来算冷却，然后构造一个装不下头的错误对象。
classifyClaudeUpstreamErrorWithCooling 第 809 行先解析重试时间，第 811 行把它塞进 statusErr。这个结构体有 code、msg、retryAfter，没有 headers25。
internal/runtime/executor/claude_executor_request.go：第 807–810 行读上游头算 retryAfter，第 811 行构造出错误对象之后就再用不到头，响应侧也就没有任何头可以往下传25影响面与今天的做法
如果你的客户端或脚本按
Retry-After 做退避，现在这条链路拿不到真实值。只能自己拍一个间隔。
多人、多客户端共用一个出口时，这会变成重试挤在一处：上游还在 429，下面已经在重放。
这个 PR 给错误对象加了一个可选的头字段，只带重试相关的那几个，别的头不放。
passthrough-headers 关掉时行为不变，它还没合并，本刊也没有在实例上验证过端到端结果11。今天能做的：客户端退避用固定值加抖动，别指望头部。
等它进版，再改成读
Retry-After。四、上游与额度侧
OpenAI 状态页 All Systems Operational，活动事件 0 条26。
最近一条有记录的仍是 Compliance API 成本数据延迟，北京 10 月 16 日 18:44 已 resolved27。
Anthropic 状态页同样 All Systems Operational，10 月 17 日那栏写着 No incidents reported today28。
Google Cloud 的事件列表仍是 7 条，最近一条仍是 10 月 8 日到 9 日的 Cloud Storage29。
Codex 重置口径没变。
今天 UTC 仍未重置，最近一次已验证的全局重置在北京 10 月 15 日 14:13，距取数 44 小时30。
累计 54 次全局、10 次 banked，节奏约每 4 天30。
页面上两套概率依旧并列：模型口径 24 小时内 18%、48 小时内 33%；把 10 月 16 日那条回帖计为提示的口径是 45% 与 70%，提示记在 21 小时前30。
另一个追踪站仍记 10 月 15 日 04:55 UTC、62 次、中位间隔 3.1 天、最长 68 天31。
官方开发者社区窗口内有一条新话题，北京时间 09:4232。
标题就是现象：新开一个 side chat、发出第一条消息就立刻触发压缩33。
发帖人的环境是 Codex 桌面端 26.1007.71326，模型 Sol 6.1（1.5x Fast）、Pro 500 计划。
复现方式是先跑一个长任务，再开 side chat 发消息33。
压缩就是重新算一遍上下文，直接吃额度；长任务期间先用别的方式开分支，别用 side chat。
五、下期回看
References
- 1CLIProxyAPI Releases
github.com
- 2sub2api Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5CLIProxyAPI dev 提交
github.com
- 6sub2api 主干提交
github.com
- 7codex-proxy dev 提交
github.com
- 8codex2api 主干提交
github.com
- 9CLIProxyAPI issue #6699
github.com
- 10CLIProxyAPI #6698 回复
github.com
- 11CLIProxyAPI PR #6700
github.com
- 12v8.0.32 gemini_schema.go 第 1507–1516 行
github.com
- 13v8.0.32 translator.go 第 640–653 行
github.com
- 14v8.0.32 gemini_claude_request.go 第 254 行
github.com
- 15v8.0.32 gemini_openai_request.go 第 402 行
github.com
- 16v8.0.32 responses_tools.go 第 496 行
github.com
- 17v8.0.32 models.json 的 claude 段
github.com
- 18v8.0.32 thinking/convert.go 第 162 行起
github.com
- 19v8.0.32 thinking/validate.go 第 86–115 行
github.com
- 20
- 21
- 22v8.0.32 config.example.yaml 第 18–21 行
github.com
- 23v8.0.32 registry/catalog_config.go
github.com
- 24router-for-me/models
github.com
- 25
- 26OpenAI Status
status.openai.com
- 27OpenAI 事件记录
status.openai.com
- 28Claude Status
status.anthropic.com
- 29Google Cloud Status
status.cloud.google.com
- 30codex-reset.com
codex-reset.com
- 31opentherank
opentherank.com
- 32Codex 分区订阅源
community.openai.com
- 33社区帖 1407091
community.openai.com
- 34r/OpenAI 1x7xivb
reddit.com
- 35r/GeminiAI 1x7xpvk
reddit.com
- 36r/ClaudeAI 1x7x6o3
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.