10/17 早间速报：codex2api 半小时落下三笔修复——Gemini 多轮工具全挂、积分顶替被阈值盖住、企业号要自己填项目号；Claude Haiku 4.5 将于 10/29 退出模型选择器 (2026)

北京 04:10（上一期刊出时刻）到 05:20 这七十几分钟里，四个仓库都没有发出新版本1 2 3 4。

当前版本仍是 sub2api v0.2.17、CLIProxyAPI v8.0.32、codex-proxy v2.1.18、codex2api v3.1.0，其中 codex2api 的发行版还停在 10 月 12 日4。

这一期的分量几乎全在 codex2api 的主干上：半小时内落进 main 三笔修复，再加窗口边上一笔，一共四笔，其中两条报障单拿到了维护者的实测结论5。

另外三条主干本窗口没有新提交：sub2api 的 main 停在 10 月 16 日 12:42（北京），CLIProxyAPI 的 dev 停在 10 月 17 日 03:57，codex-proxy 的 dev 停在 03:286 7 8。

上游侧这一小时没有状态事件，但 Claude 官方公布了一项会改到下游用户手边模型清单的安排。

一、codex2api 主干上的四笔

单号	报障的现象	落在哪笔提交
#792	`gemini-4-argon` 的多轮工具循环被上游 400 拒掉9	`2b9d2de0`（北京 04:42）10
#791	积分顶替显示已生效，账号却一直不跑11	`57cb67a3`（北京 05:04）12
#793	订阅账号经反代调 `gpt-6.1-sol` 报「不支持」13	`4365b7cd`（北京 04:07）14
#789	Workspace 与企业号拿不到项目号15	`05c74b99`（北京 05:11）16

四笔都只在 main，发行版仍是 10 月 12 日的 v3.1.04。

二、Gemini 的多轮工具循环：签名桩此前只认三个名字

报障写得很具体：gemini-4-argon 走带 function calling 的多轮对话，上游回 400，原文是 Function call is missing a thought_signature in functionCall parts；同一套工具循环换成 gemini-3.8-flash 就完全正常9。

本刊在 main 上核了修法。判定函数从前只在 wire 名里含 flash、pro、thinking，或正好等于 gemini-4-argon-high 时，才给 functionCall 补上重放用的签名桩10。

v3.1.0 里裸名 gemini-4-argon 是原样透传给上游的，走不到那条分支，functionCall 就空着手出门了。

新写法改成前缀匹配：名字以 gemini- 开头就补17。

注释把理由写明了：这个桩是重放字段，不是能力声明；不校验签名的模型会忽略它，而缺了它的模型会让每一轮工具循环都失败，所以没有理由因为版本名陌生就扣着不给17。

Claude 与 GPT-OSS 的 backing 依旧不补。覆盖面是 Responses、Chat、Messages 三条转换路径，加上原生 /v1beta 的请求清洗10。

一段 Go 源码，第 934 行到第 941 行被浅黄色高亮 — *codex2api 主干 `proxy/antigravity_responses.go` 第 934–941 行：五句注释说明这个桩为什么对整个 Gemini 家族一律补上，实现只剩第 940 行一次前缀判断17*

要做的判断只有一条：在 codex2api 上跑 Antigravity 加工具、模型写的是裸名 gemini-4-argon 的，多轮工具循环会整条挂掉。

把模型名换成 gemini-4-argon-high 这类具名档位可以绕开，它一直走的是补桩的那条分支10。彻底修好要等下一个发行版9。

三、开了积分顶替，号却一直不跑

维护者在 #791 里把两种情形都写清楚了11。

面板上那个「已生效」只看两件事：开关开着、账号上有积分。它不看这个号此刻能不能被调度，所以会出现显示生效而号一直不动的情况11。

第一种是自动暂停阈值盖住了积分。账号、分组、全局任意一层设了 5h 或 7d 阈值，用量一到阈值就停止调度。

阈值最高只能设到 100%，窗口走不到「打满之后改扣积分」那一步，积分开关等于没打开；这种账号在列表里还可能同时挂着「使用积分」徽章11。

第二种是先被 5h 限流、后开积分开关。Plus / Pro 一般先打满 5h 窗口，如果 5h 判罚已经落下再打开开关，这条判罚不会被积分释放，要等 5h 窗口重置；7d 判罚本来就能释放，漏的只是 5h11。

修复落在 57cb67a3。开积分顶替且当下确有积分时，自动暂停让位，账号在窗口打满后继续用积分跑；积分用完、或工作区触发消费上限之后，阈值恢复生效11。

代码上是两处。quotaAutoPausedLocked 开头先看一次积分顶替判定，成立就直接返回 false，5h 护栏带的并发上限与调度惩罚也跟着让位18。

另一半是识别口径。本地落下的 5h 判罚 reason 是 rate_limited_5h，/responses 上真 429 记的是另一个 reason，所以按 reason 就能把本地判罚与上游拒绝分开；usageWindowCooldownLocked 补上了这一支19。

维护者留了一条边界：上游本身对这个号返回 429 时，网关不会强行放行，那种情况要看具体错误才能判断11。

一段 Go 源码，第 1720 行到第 1730 行被浅黄色高亮 — *codex2api 主干 `auth/store.go` 第 1720–1730 行：三句注释解释了积分顶替为什么必须让阈值停调度让位，第 1724 行的判断成立即返回 false18*

自查的办法是先看徽章：出现「限流 + 使用积分」这种组合，就去账号、分组、全局三处确认有没有设 5h 或 7d 阈值。

如果那条 5h 判罚是在你打开开关之前落下的，得等修复进版本、或者等 5h 窗口自己重置11。

四、`gpt-6.1-sol` 报「不支持」：先查客户端版本，再清冷却

报障原文是：订阅账号在网页端用 gpt-6.1-sol 正常，经反代调用就回 The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account，同步最新客户端也没用13。

维护者在 04:34（北京）贴出的根因是上游的客户端版本闸：上游对「套餐里没有这个模型」和「请求带的客户端版本太低」这两种情况，返回的是同一句话13。

他用一个 pro 账号按客户端版本逐个拉上游模型清单，0.153.0 到 0.158.0 的清单里没有这个模型，0.159.0 及以上才有。

这个模型自己声明的 minimal_client_version 写的是 0.153.0，维护者说这份声明不准；网关内置的模拟版本当时是 0.153.3，所以只要版本同步没成功、或者出站版本被固定在 0.159 以下，所有套餐的账号都会撞上同一句错13。

修复是 4365b7cd，已合进 main，会随下一个版本发出14。它做了四件事13：

内置 Codex CLI 版本与「最低 CLI 版本」默认值从 0.153.3 提到 0.160.0，同步失败时也能越过这道门槛；
版本同步一旦把版本抬高，自动清掉已有的「不支持模型冷却」；
pro 档账号也报这个错时改判为客户端版本过低，不再给账号写冷却；
日志里带上出站版本，方便直接看出是不是版本问题。

等不到版本也可以自己动手，维护者给了四步13：

到「设置 → Codex → Codex 客户端版本同步」点「立即同步」，确认模拟版本不低于 0.159（目前最新是 0.160.0）；同步失败通常是服务器连不上 GitHub 或官方源，配好全局代理再试；
清掉已有冷却：把「设置 → 通用设置 → 不支持模型冷却」临时改成 0 并保存，会自动清除，能用之后改回原值（默认 1800）；也可以到账号详情里对单个模型点「清除此模型冷却」；
检查出站版本有没有被固定：User-Agent 配置里填过「原始 User-Agent 覆盖」或「客户端版本」的，网关会原样使用，同步改不动，要改到不低于 0.159 或清空；下游用官方 Codex CLI 或桌面端、兼容模式选了「保留客户端」的，网关会透传客户端自己的版本；
自查：使用记录里这条请求的「上游 UA」，里面的版本号就是实际发给上游的版本。

顺带纠正一条流传很广的说法：api_key_auth_available=1 只是后台展示用的元数据，不参与路由；gpt-6.1-sol 那一栏显示 1 是内置表漏标，这次也一并改了13。

五、企业号的项目号要自己给

codex2api 的 #789 报的是 Google Antigravity 企业账号拿不到项目 ID：onboardUser 走完没有项目号，配额摘要回一句 You do not have a valid license of this product15。

原因写在账号结构的注释里：Workspace 与企业档（Gemini Code Assist Standard / Enterprise）不会被 onboardUser 分配托管项目，必须跑在调用方自有的项目上20。

05c74b99 加的就是这件事：账号上多一个 user_project_id 字段，凭证键是 antigravity_user_project_id，带格式校验，导入与编辑弹窗都能填16。

取权限与做 onboarding 时，它会作为 cloudaicompanionProject 与 duetProject 带给上游21。

手上有企业号、状态是「存下了但从来不被调度」的，先看它的项目号是不是空的15。

一段 Go 源码，第 647 行到第 672 行被浅黄色高亮 — codex2api 主干 `auth/antigravity_client.go` 第 647–672 行：第 651 行读账号上填的项目 ID，第 652 行带着它取权限，第 665 行把它交给 onboarding，第 672 行写回账号21

六、上游与额度侧

Claude 那边有一条会落到下游用户手上的安排。Anthropic 在 10 月 15 日公布：10 月 29 日把 Claude Haiku 4.5 从模型选择器里移除，范围是 chat、Claude Cowork 与 Claude Design，覆盖 Free、Pro、Max 三档，包括桌面端与移动端；接替它的是 Claude Haiku 5.522。

三处不受影响：Claude Code、Team 与 Enterprise 套餐、Claude Platform（API）22。

已有会话不会删除，10 月 29 日之后继续这些会话时，回答会改用 Haiku 5.5；在那之前，它仍在「More models」里可以选到22。

对中转站的落点在于：按 API 模型名固定 claude-haiku-4-5 的链路不受影响；受影响的是把 chat 侧选择器当作下游入口、按套餐分发 haiku-4-5 的做法22。

三家状态页这一小时都是干净的。OpenAI 状态页 All Systems Operational，活动事件 0 条，没有降级组件23。

最近一条有记录的仍是 10 月 14 日那条 Compliance API 成本数据延迟，10 月 16 日已经 resolved24。

Anthropic 状态页同样 All Systems Operational，10 月 16 日那一栏写着 No incidents reported today25。

Google Cloud 的事件列表仍是 7 条，最近一条仍是 10 月 8 日到 9 日的 Cloud Storage 上传与写入延迟26。

Codex 重置追踪站上，今天（UTC）没有重置；最近一次已验证的全局重置在 39 小时前，即 10 月 15 日 06:13 UTC、北京 14:1327。

累计仍是 54 次全局、10 次 banked，节奏约每 4 天。两套概率口径依旧并列：模型口径是 24 小时 18%、48 小时 33%，把 10 月 16 日中午那条回帖计为提示的口径是 24 小时 50%、48 小时 75%27。

本刊直接核了 Codex 负责人 @thsottiaux 的时间线，本窗口内没有新帖，最近一条仍是北京 10 月 16 日 13:51 的那句「Either we are out of ideas or we are cooking. Time will tell」28。

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

官方开发者社区 Codex 分区窗口内没有新帖，最新一条仍是北京 10 月 16 日 23:09 那份「用量突然大幅缩水」的报障30。

Reddit 上窗口内有两条。r/ClaudeAI 在 05:04 转发了上面那条 Haiku 4.5 下线的官方公告，6 分、1 条评论31。

r/GeminiAI 在 04:32 有一条讲 Argon 打满之后 3.8 Flash 与 3.1 Pro 一起被挡，8 分、3 条评论；它与 10 月 16 日上午那条是同一个症状，机制本刊此前已经报过32。

这一小时里没有新的重置信号，也没有官方侧的额度事件。

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

codex2api 这一轮的四笔都还没切出发行版，所以下期第一件事是看它们会不会随下一个版本发出4。

维护者在 #791 与 #793 里都写了「下个版本生效」，这两个「下个版本」指的是不是同一版，目前看不出来11 13。

codex2api：本窗口 #791、#793 各有一次更新，#788 与 #790 已在更早的窗口合并；继续跟 #793、#792、#791、#789、#787、#786、#783
CLIProxyAPI：本窗口只有 #6688 新增一条感谢回复，该单已随 v8.0.32 关闭，不构成新动态33；继续跟 #6694、#6693、#6695、#6691、#6616、#6679、#6676、#6677、#6515、#6675、#6605、#6669、#6661、#6667、#6659、#6671、#6673、#6625、#6603、#6500、#6169
sub2api：本窗口 0 条，#8168、#8167、#8166 仍是 open 未合并34 35 36；继续跟 #8165、#8164、#8163、#8161、#8160、#8157、#8158、#8159、#8155、#8151、#8139、#8135、#8136、#8142、#8143、#8146、#8147、#8127、#8125、#8123、#7962、#7398
codex-proxy：本窗口 0 条；v2.1.18 已经占上 latest，这一条跟完了，下一期看 dev 上的后续提交

下期优先回看三条：codex2api 这四笔会不会随下一个版本发出；#793 里那句「下个版本生效」指的是哪一版；CLIProxyAPI 的 #6694 与 #6693 会不会被采纳进 dev。

References

1
sub2api Releases
github.com
2
CLIProxyAPI Releases
github.com
3
codex-proxy Releases
github.com
4
codex2api Releases
github.com
5
codex2api 主干提交
github.com
6
sub2api 主干提交
github.com
7
CLIProxyAPI dev 提交
github.com
8
codex-proxy dev 提交
github.com
9
codex2api #792
github.com
10
提交 2b9d2de0
github.com
11
codex2api #791
github.com
12
提交 57cb67a3
github.com
13
codex2api #793
github.com
14
提交 4365b7cd
github.com
15
codex2api #789
github.com
16
提交 05c74b99
github.com
17
antigravity_responses.go（主干）第 934–941 行
github.com
18
auth/store.go（主干）第 1720–1730 行
github.com
19
auth/store.go（主干）第 1917–1932 行
github.com
20
auth/antigravity_types.go（主干）第 236–239 行
github.com
21
antigravity_client.go（主干）第 647–672 行
github.com
22
Claude 支持页：Haiku 4.5 离开模型选择器
support.claude.com
23
OpenAI Status
status.openai.com
24
OpenAI 事件记录
status.openai.com
25
Claude Status
status.anthropic.com
26
Google Cloud Status
status.cloud.google.com
27
codex-reset.com
codex-reset.com
28
@thsottiaux 北京 10-16 13:51
x.com
29
opentherank
opentherank.com
30
社区帖 1406982
community.openai.com
31
r/ClaudeAI 1x7rzpe
reddit.com
32
r/GeminiAI 1x7r6yq
reddit.com
33
CLIProxyAPI #6688
github.com
34
sub2api #8168
github.com
35
sub2api #8167
github.com
36
sub2api #8166
github.com