自动评审的流量被摊到整个号池，effort 降级那个洞在 dev 补上了
这一小时四仓零新版本：CLIProxyAPI 在 dev 上让 Codex 自动评审跟着父会话挑号，也修好了单独写的 effort 被降成 medium；sub2api 接 Cloudflare AI Gateway REST 的 401 与 400 是两个独立故障，一个面板能改，一个只能靠前置层。
北京 21:00 这一小时，四个仓库一个版本都没发。CLIProxyAPI 停在今天 15:54 的 v8.0.37，sub2api 停在 10 月 16 日的 v0.2.17。
dev 上倒落了两笔修复，都出自维护者 Luis Pater。
18:55 那笔让 Codex 的自动评审跟着父会话挑号，20:19 那笔让客户端单独写的 effort 不再被换成 medium。
同一时段 sub2api 收到一条报障：Anthropic API Key 账号接 Cloudflare AI Gateway 的 REST 端点接不进去。
报障人自己拆开说了，那是两个独立故障：一个今晚能自己解决，一个只能等。
| 事项 | 时间（北京） | 规模 | 现在能做什么 |
|---|---|---|---|
| 自动评审继承父会话凭证 | 18:55 | 4 文件 +533/−18 | 先按凭证量评审请求；异常就摘号 |
| 单独 effort 不再降成 medium | 20:19 | 5 文件 +233/−8 | 客户端带 thinking.type=adaptive 立刻可用 |
| CF REST 接不进 sub2api | 21:09 | 报障 #8274 | 面板切 Bearer；?beta=true 要前置改写 |
| 插件拿到解码后的请求体 | 21:18 / 21:31 两次改写 | 4 文件 +330/−6 | 用 zstd 的客户端加插件，先知道这条 |
这四件都还没进发行版。v8.0.37 之后，dev 累计改了 37 个文件。
两张报障单也都还开着：
#6826 在 19:37、#6827 在 21:02 被维护者打上 Fixed 标签，等改动合进 main 才会自动关。自动评审的请求，落在哪个号上
开了
routing.session-affinity 的实例，同一个会话会钉在同一个凭证上，靠这个复用上游的 KV 缓存。Codex 的自动评审走的是另一条路。报障 #6826 把链路写全了：评审请求带着
x-openai-subagent: guardian 与父线程 ID 进来，被当成一个新会话，由兜底选择器重新挑号。后果是流量一边倒。报障人写的是，某个凭证会在短时间内收到大量
codex-auto-review 请求，同时几乎不服务普通模型请求。他把这种流量模式称为「明显不正常」，并判断可能触发上游对该账号的风控。这句判断没附上游的处罚记录，属于他的推断。本刊核到的是机制那一半。
v8.0.37 的 session affinity 用两个键记绑定：
provider::会话::模型。selector.go 第 1165–1176 行 把 modelKey 算进了键名，父会话是在自己的模型下绑定的。评审的模型是
codex-auto-review。它拿父线程 ID 去查，键里的模型名对不上，查不到任何东西，于是按兜底策略摊到池子里。
sdk/cliproxy/auth/selector.go 第 1161–1198 行：第 1165 行取 modelKey，第 1166 行与第 1176 行把它拼进 cacheKey 与 fallbackKey，第 1178 行的 bind 只在非子代理时写双键。然后按「同一个真实 provider」收集候选，用父会话最近一次选中的凭证去接。父会话那条记录按 provider 存，跨模型也能取到。
guardian 头，第 1237 行按父会话取最近一次绑定，第 1240 行命中后才重新绑。只有自己把
session-affinity 打开过的实例才会撞上这个边界。自查不用翻源码。使用记录里按凭证筛
codex-auto-review，看有没有哪个号在一小时内被灌了一串、同时普通模型请求很少。命中的号就是报障人描述的那个形状。今晚的处置有四种，代价各不相同：
- 停掉客户端的自动评审：流量形状立刻恢复，代价是这段时间没有评审。
- 把被灌满的那个号临时摘出池子：被灌的号先脱身，代价是池子变小。
- 关掉
session-affinity：流量摊开，代价是主会话的缓存复用一起丢掉。 - 等 dev 发版：根治，代价是要等下一个 tag。
effort 那个洞，补在 dev 里了
上一期（今天 15:38）报过同一件事。客户端在 Messages 请求里写
output_config.effort: high、又不带 thinking 对象时，转去 Codex 的路上会被换成 medium。#6827 的记录里，这三种请求都回 HTTP 200，没有任何错误提示。
这一小时它修好了，改在两处。第一处是翻译器。
internal/translator/codex/claude/codex_claude_request.go 第 382–414 行：第 385–388 行先把 output_config.effort 取出来，第 411–412 行补了 else if !thinkingConfig.Exists() && effort != ""。这段的前提没变：
reasoningEffort 的初值仍是 medium，thinking 存在时仍按 type 分支走。补的只是「没有
thinking 时别把显式档位丢掉」这一条。同一文件 第 290–294 行加了一条早退，注释写的是「原生 Claude 的 effort 与是否开思考无关，保留模型默认」。这一条挡住了新解析反过来给原生请求补
thinking 的可能。上一期给的三条处置，现在这样用：
- 客户端带
thinking: {"type": "adaptive"}：仍然有效，立刻可用，B 组请求在报障里就是 200 加high。 payload.override里写reasoning.effort：仍然有效。代价是会盖掉客户端自己选的档位，补丁的测试里专门有一条final override wins。- 等版本：现在有明确对象了，dev 的
009f8d7a，还没发版。
上游文档的口径也站在他这边。Anthropic 写明 effort 对每个输出 token 生效，开不开思考都一样（Effort）。
档位是
low、medium、high、xhigh、max 五档。省略 thinking 时 effort 依然应当生效，报障人正是拿这一条立的案。sub2api 接 CF AI Gateway REST：401 与 400 是两件事
报障 #8274 的场景：Cloudflare 的原生 Anthropic Gateway 对 Haiku 5.5 回 401
x-api-key header is required，而 CF 的 REST 端点 /ai/v1/messages 用同一个 Token 能过。报障人因此想把 REST 端点配成一个 Anthropic API Key 账号。
第一个故障在鉴权头。v0.2.17 对 Anthropic API Key 账号默认写
x-api-key。
backend/internal/service/anthropic_apikey_auth.go 第 26–61 行：第 28–32 行读凭证里的 anthropic_apikey_auth_scheme，第 56–60 行决定发 Bearer 还是 x-api-key，默认落在最后一行。CF 的 API 只认
Authorization: Bearer。请求带着 x-api-key 到它门口，被当成没带凭证。它回的是
Authentication error，外形就是报障人贴出来的那段 success: false 的 JSON。面板上有这个开关。平台选 Anthropic、类型选 API Key 的账号，编辑页会多出一行「上游认证方式」。
两个选项正是
x-api-key 与 Authorization: Bearer（EditAccountModal.vue 第 2239–2252 行）。切成后者，凭证里就会写上 anthropic_apikey_auth_scheme。第二个故障更硬。
?beta=true 拼在四处，全都没有开关：- 转发：
gateway_upstream_request.go第 69 行 - 透传：
gateway_anthropic_passthrough.go第 310 行 - 账号测试：
account_test_service.go第 544 行 - count_tokens：
gateway_count_tokens.go第 408 行
CF 的 REST 把查询串当成未定义字段，回 400
Unrecognized key(s) in object: 'query'。报障人用两条 curl 对照过，只差这一行，200 与 400。
两处叠起来有个容易误判的地方：账号测试也拼
?beta=true。把认证方式切成 Bearer 之后，测试会从 401 变成 400。看起来像更糟了，实际是第一个故障已经修掉、第二个露出来了。
今晚要走通这条路，只能在前置层抹掉查询串。挂一层 nginx 或 Worker，把
/ai/v1/messages?beta=true 改写成不带参数的地址，再把账号的 base_url 指到那层。剩下两条路：等维护者加开关，或者自建一个删掉这四处的构建。
影响面也一样窄。只有把 Anthropic API Key 账号指向第三方 Anthropic 兼容端点的人会踩到。
指向
api.anthropic.com 的账号不受影响：官方端点本来就能接受这个参数，这也是它一直没被发现的原因。简讯
插件那条补丁今天改了两次。PR #6842 在 21:18 与 21:31 各被 force-push 一次，涨到 4 文件 +330/−6，仍 open。
它给插件鉴权回调的
FrontendAuthRequest 加了 DecodedBody：请求体是 zstd 时先解一份给插件，原始 Body 与 Headers 保持原样。解码只对 handler 自己解 body 的 POST 路由做，上限 64 MiB、zstd 窗口 8 MiB、同时最多两份。
值得记一句的原因：pi 与 Codex CLI 会发 zstd body，插件从原文里读
model 读不到，这一条补的就是它。测试文件里写着这句场景。codex-proxy 与 codex2api 窗口内零条被更新的 issue 或 PR。
上游三个状态页都安静。OpenAI 全绿，最近一次降级是今天 10:26 到 11:28。
Anthropic 全绿，今日无事件。Google Cloud 仍 8 条，首条还是 10 月 20 日那条 europe-west2。
额度侧照旧。codex-reset 记今日 UTC 未重置，最近一次全局重置在 31 小时前（北京 10 月 20 日 14:33），56 次全局 / 10 次 banked。
opentherank 记 64 次、中位间隔 3.1 天、最长 68 天。
官方 Codex 分区窗口内只有一条新帖，21:39 的 Codex Cloud 工作区文件恢复功能请求，与中转运维无关，这里只留个记号。
今晚三件事
- 按凭证筛最近一小时的
codex-auto-review请求量。哪个号被灌满，就把它临时摘出池子，或者先把客户端的自动评审停掉。 - 客户端要 effort 真生效，就在请求里同时带
thinking: {"type": "adaptive"}与output_config.effort，或者等009f8d7a发版。 - 接 CF REST 的，先在编辑账号里把「上游认证方式」切成
Authorization: Bearer，再解决?beta=true；前置层没有的话，账号测试那一关还会停在 400。
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.