10/16 傍晚速报：codex-proxy 把按 Key 代理路由发进预发布版；sub2api 关掉思考的 /v1/messages 在转换处就被拦下 (2026)

10 月 16 日北京 16:42 到 17:30 这四十几分钟里，四个仓库里只有一个发出了新版本。codex-proxy 试发了 v2.1.18-beta.d62e172，把 10 月 15 日并进 dev 的按 Key 代理路由与回环绕过折进了一个 tag1。

其余三个仓库没有新版本，主干也没有新提交，当前版本仍是 sub2api v0.2.17、CLIProxyAPI v8.0.31、codex2api v3.1.02 3 4。

要当场决定的是那个预发布版要不要上。另外三条各自要办的事不同：一条是把「关掉思考」的请求为什么必回 400 说清，一条是下次点完「同步上游支持的模型」要回头核白名单，一条是等发版。

一、codex-proxy：按 Key 代理路由有了版本

这个 tag 打在 dev 上，是预发布，发布时间是北京 16:521。

拿它和 v2.1.17 对比，中间只有 5 笔提交：两笔是代码，按 Key 代理路由加回环绕过、把为空的 proxyId 归一化成全局默认并校验代理分配5；一笔是 PR #873 的合并提交6；剩下两笔是 changelog 同步与 v2.1.17 自己的版本号提升5。

版本说明里列的提交比这版真正新增的多，里面 #868 和 #870 两条 v2.1.17 就已经带上了1 5。判断某一版包不包含某项改动，要看这个 tag 和上一版之间的差异，而不是版本说明的提交清单。

第一处行为变化是回环地址恒不过代理。DEFAULT_NO_PROXY 写死为 localhost,127.0.0.1,::1，再把环境变量里的 NO_PROXY 并进来7。

旧版用的是 Undici 的 ProxyAgent，配了外部代理时 127.0.0.1 上的本地后端会一起被送进代理。这一版换成 EnvHttpProxyAgent 并固定绕开回环地址7。

第二处变化同在这段代码里：HTTP_PROXY 与 http_proxy 从这一版起才会被读取，之前只认 HTTPS_PROXY 和 https_proxy7。

你的环境里如果只设了 HTTP_PROXY，升上去之后出口会开始真的走那个代理；反过来说，之前以为在走、其实没走的代理，也是这一版开始生效。

一段 TypeScript 源码，第 1 到 47 行被浅黄色高亮 — codex-proxy v2.1.18-beta.d62e172 的 `src/proxy/fetch-dispatcher.ts` 第 1–47 行：第 5 行是那三个回环地址，第 14–15 行把环境里的 `NO_PROXY` 并进来，第 25 与 34 行是新加的 `HTTP_PROXY`，第 41–46 行的注释写清 `getFetchDispatcher` 三种入参各返回什么7

每个第三方 Key 现在可以单独绑代理策略：global、direct、auto，或某个代理节点的 UUID8。

落地在 resolveProxyUrlById 的三个返回值上：undefined 走全局代理、null 直连、字符串是具体代理节点8。

写这个值的是 PATCH /auth/api-keys/:id/proxy，传非法值时回 400，并把四个合法取值写进错误信息9。

要不要现在换上去：预发布不进 latest 标签，npm i -g 装到的仍是稳定版 v2.1.1710。只有想先吃这两处行为变化的人，才需要手动拿这个 tag。

二、sub2api：关掉思考的 /v1/messages 请求，在转换这一步就被拦下

sub2api issue #8156 在北京 17:02 开出，open、0 评论，报障人是 jiahaoliang11。

单里的环境是：入站 /v1/messages，出站 /v1/responses，入站模型 claude-sonnet-5，出站模型 gpt-6.1-sol，分组 openai-default。分组里已经配了 none → low 与 minimal → low 两条映射，请求仍然回 40011。

那句错误的原文是 gpt-6.1-sol does not support reasoning effort "none"; use low, medium, high, xhigh or max11。

这句不是上游回的，是 sub2api 自己发的。v0.2.17 的 backend/internal/pkg/openai/constants.go 第 219–229 行就是它的出处：模型名命中 gpt-6.1-sol 家族拼写、且档位是 none 或 minimal 时，ValidateGPT61SolReasoningEffort 返回这句话12。

这个校验在转换的最前面就被调用一次，传进去的档位由 anthropicReasoningEffort 算出来13。

档位只有三种来源：客户端把思考关掉（thinking.type 为 disabled）时直接取 none；否则默认 medium；客户端显式给了 output_config.effort 时用客户端那个值14。

所以只要入站走 /v1/messages、出站模型是 gpt-6.1-sol 家族拼写，客户端把思考关掉就必然吃这一句 400；不关思考时发出去的是 medium，不在拒绝名单里。

分组映射没兜住的原因在顺序上。400 发生在转换函数里，也就是出站请求体还没成形的时候15。

分组映射是在转换之后才应用到请求体上的16。转换这一步已经返回错误，后面的映射没有机会执行。

这条路还只在客户端显式带了 output_config.effort 时才把分组策略绑上；不带就直接返回，源码注释写明这是刻意为了不让上限改掉桥的默认值17。策略没绑上时，应用函数会把请求体原样退回18。

这也意味着报障人建议的「在转换之后应用分组映射」对这条 400 不管用：错误在转换时就返回了。

现在的处置没有配置项可改，能改的只有客户端行为：不要在这条路径上关掉思考；或者显式带一个 low、medium、high、xhigh、max 的 output_config.effort，让转换不被拒；再或者把这类请求换成不带 gpt-6.1-sol 家族拼写的出站模型。

需要留意的是，单里报的是 v0.2.14，而本刊在 v0.2.17 同址核到了同一处校验、同一处理顺序。升到当前版本不解决这条。

一段 Go 源码，第 161 到 177 行被浅黄色高亮 — sub2api v0.2.17 的 `backend/internal/handler/composite_platform.go` 第 161–177 行：第 166–168 行的注释说明为什么只在客户端显式给了 `output_config.effort` 时才绑定分组策略，第 170–172 行是那个提前返回17

三、模型白名单同步的两个方向

sub2api PR #8155 在北京 16:57 开出，open、可以干净合并，基分支是 main，12 个文件 +255/−14，作者 Larry-Labs19。

它说的是：OpenAI OAuth 账号点「同步上游支持的模型」，仍然会把已退役的 gpt-5.5 加回来，因为那个按钮合并的是一份不带账号凭证上下文的 API Key 目录19。

本刊核对的源码对得上：退役过滤挂在模型列表与 Codex 目录那几条路上，filterRetiredOpenAIModelIDs 按账号判定后逐条剔除20，调用点在 gateway_service.go 与 openai_codex_models_service.go21。

而面板那个按钮走的是 SyncUpstreamModelCatalog，它所在的整份文件里没有任何与退役相关的代码22。

按钮与入口名在面板的中文文案里就是「模型白名单」与「同步上游支持的模型」23。

#8155 合并之前要办的事很简单：在用 OAuth 账号点过同步之后，手工核一遍白名单；普通 API Key 账号不受影响19。

这个 PR 自己写了两条边界：过滤会把一份非空白名单清空时，保留原来的限制、让管理员自己选替代模型，因为空映射等于不限制；已经保存的映射不会自动迁移19。

同一个窗口里，反方向的单被关掉了。sub2api issue #3933 在 7 月 10 日开出，本窗口北京 17:15 关闭，关闭原因标 completed，关单人是报障人自己，4 条评论里没有维护者定性，也没有修复24。

它报的是启用自动透传之后 gpt-5.6-sol 回 404，文案是 Model "gpt-5.6-sol" is not supported by any configured account in this group24。

评论区给出的解法是把 5.6 加进模型白名单再开透传，另一条是重新授权账号；报障人自己回了一句：重新获取模型列表可以解决，但他仍然认为这是个 bug24。

两张单是同一处机制的两面：白名单会在一端把退役模型同步回来，也会在另一端因为少了一条而让请求回 404。

四、CLIProxyAPI：占位参数清理进了 dev

CLIProxyAPI 提交 202b8b8c 在北京 17:21 落到 dev，提交信息带 Closes: #6670，6 个文件 +1938/−20，实现集中在 internal/util/translator.go，单这一份就 +1282 行25。

10 月 16 日上午那一期核过这条单，当时的结论是 v8.0.30、main、dev 三处都搜不到清理函数。现在 dev 上有了 CleanClaudeToolArguments 与 CleanClaudeToolArgumentsWithTranslated26。

报障人自己那份 PR #6669 还开着，1 笔提交、未合并，改法与落地的这份不同：那份按工具名兜底，落地的这份按原始请求里的 schema 判断这个工具到底有没有参数27。

原始单 #6670 也仍是 open。提交挂在 dev 而不是默认分支，GitHub 不会因为它那句 Closes 自动关单28。

现在没有版本带这条修复：最新发行版 v8.0.31 发布在北京 12:05，早于这笔提交；main 上最新一笔是北京 16:38 的文档提交。要用只能等发版，或自己从 dev 构建。

五、上游与额度侧

OpenAI 状态页仍是 Partial System Degradation，唯一降级组件还是 Compliance API，最后一条更新停在 10 月 15 日 22:36 UTC 的 monitoring29。

Anthropic 状态页是 All Systems Operational，10 月 16 日一栏写着 No incidents reported today30。

Google Cloud 的事件列表最近一条仍是 10 月 8 日到 9 日的 Cloud Storage31。

Codex 重置追踪站今天（UTC）没有重置。最近一次已验证的全局重置是 27 小时前的 10 月 15 日 06:13 UTC，也就是北京 10 月 15 日 14:13；累计 54 次全局重置、10 次 banked，节奏约每 4 天32。

同一页上两套概率并存：模型口径是 18% 与 33%，把提示帖计进去的 counted 口径是 24 小时 50%、48 小时 75%32。

另一个追踪站记最近一次重置为 10 月 15 日 04:55 UTC，自 2025 年 9 月以来 62 次，中位间隔 3.1 天，最长一次 68 天33。

官方开发者社区 Codex 分区本轮 25 条，最新一条是北京 16:02 的客户端崩溃报告占用磁盘，落在窗口起点之前34。

Reddit 三个板块窗口内没有与额度、风控相关的可收条目：r/GeminiAI 只有一条北京 16:45 的五小时窗口提前打满的体感帖，属消费端产品反馈，未收35；r/OpenAI 与 r/ClaudeAI 窗口内是作品展示与使用体验。

六、未闭合项（下期继续跟，不作结论）

codex-proxy：本窗口发出预发布 v2.1.18-beta.d62e172；继续跟 #873 之后的正式版会不会打上 latest
sub2api：本窗口登记 #8156、#8155，#3933 关闭；继续跟 #8155 会不会合并、#8156 有没有人给出改法、#8151、#8139、#8135、#8136、#8142、#8143、#8141、#8144、#8146、#8147、#8127、#8125、#8123、#7962、#7398
CLIProxyAPI：本窗口 202b8b8c 进 dev、#6670 未关；继续跟 #6669 会不会被这份实现取代、#6676、#6677、#6515、#6675、#6605、#5764、#6661、#6667、#6659、#6671、#6673、#6625、#6603、#6500
codex2api：本窗口 0 条

下期优先回看三条：#8155 会不会合并、合并后同步按钮的行为变不变；#8156 有没有人把分组映射挪到转换之前；CLIProxyAPI 下一个发行版会不会带上 202b8b8c。

References

1
codex-proxy v2.1.18-beta.d62e172
github.com
2
sub2api Releases
github.com
3
CLIProxyAPI Releases
github.com
4
codex2api Releases
github.com
5
Compare v2.1.17...v2.1.18-beta.d62e172
github.com
6
codex-proxy PR #873
github.com
7
fetch-dispatcher.ts 第 1–47 行
github.com
8
proxy-pool.ts 第 222–240 行
github.com
9
api-keys.ts 第 461–473 行
github.com
10
codex-proxy CHANGELOG
github.com
11
sub2api #8156
github.com
12
openai/constants.go 第 219–229 行
github.com
13
anthropic_to_responses.go 第 15–24 行
github.com
14
anthropic_to_responses.go 第 437–445 行
github.com
15
openai_gateway_messages.go 第 150–160 行
github.com
16
openai_gateway_messages.go 第 296–312 行
github.com
17
composite_platform.go 第 161–177 行
github.com
18
openai_reasoning_effort_policy.go 第 448–459 行
github.com
19
sub2api #8155
github.com
20
openai_model_retirement.go 第 40–48 行
github.com
21
openai_codex_models_service.go 第 214 行
github.com
22
upstream_models.go 第 205–220 行
github.com
23
accounts.ts 第 947 行
github.com
24
sub2api #3933
github.com
25
CLIProxyAPI 202b8b8c
github.com
26
dev 的 translator.go 第 1715–1775 行
github.com
27
CLIProxyAPI #6669
github.com
28
CLIProxyAPI #6670
github.com
29
OpenAI Status
status.openai.com
30
Claude Status
status.anthropic.com
31
Google Cloud Status
status.cloud.google.com
32
codex-reset.com
codex-reset.com
33
opentherank
opentherank.com
34
Codex - OpenAI Developer Community
community.openai.com
35
r/GeminiAI 1x7ayu2
reddit.com