10/16 晚间速报：codex2api 把两笔大改动并进 main；sub2api 的 Antigravity 用量面板只读到一半 (2026)

10 月 16 日北京 17:30 到 18:25 这五十几分钟里，四个仓库都没有发出新版本，当前版本仍是 sub2api v0.2.17、CLIProxyAPI v8.0.31、codex-proxy v2.1.17、codex2api v3.1.01 2 3 4。

codex2api 的主干一次并进两笔大改动，sub2api 与 CLIProxyAPI 各有一批新登记的单子和 PR。

要当场决定的是三件事：Antigravity 的用量面板今天还能不能当数、跑 Claude 的长会话要不要避开跨天闲置、codex2api 要不要自己从 main 构建。

一、codex2api：两笔大改动一次并进 main，发行口还是空的

main 在北京 17:45 的同一分钟内收下两笔合并。第一笔是 PR #788，44 个文件 +4078/−229，合并提交 b6d24de65。

第二笔是 PR #790，66 个文件 +6328/−194，合并提交 49e440786。#790 就是第二十四期报道过的那个「账号智能检查」PR，本期是它合进 main 的闭环。

主干最新提交停在 09:45:49Z，也就是北京 17:45；发行版仍是 10 月 12 日的 v3.1.04。想用这两笔改动，只能等发版或自己从 main 构建。

#788 给 Responses 转发加了严格兼容门禁，用 X-Codex2API-Strict-Compatibility 头或 CODEX_STRICT_RESPONSES_COMPAT 环境变量打开，开启后按实际选中的原生 Codex 账号拒收已知有损字段5。

WebSocket 侧改成同一 stream_id 先进先出、不同流并行，上限 16 个活动轮次与 32 个命名流5。

作者自己写下的边界值得先看。图片盲测没有通过：view_image 返回的 PNG 与原图 SHA-256 一致，但隐藏答案的八位数字被误读一位，原因未定5。

response.append 与 response.steer 仍返回 unsupported_feature；指向同一父响应的分叉可能等待同一条上游连接租约5。

同一个窗口里还有一张新单。codex2api issue #793 在北京 17:24 开出，报的是订阅账号在网页端用 gpt-6.1-sol 正常，经反代调用回 The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account.，同步最新客户端也不解决7。

单下唯一的评论给了一份日志诊断：请求被路由到了几个 plan=free 的 ChatGPT 账号，而模型注册表里 gpt-6.1-sol 标着 api_key_auth_available=1，也就是只对 API key 计费账号开放7。这条诊断出自评论者，单子本身还没有维护者定性。

二、sub2api：Antigravity 用量面板只读到两个共享池的一半

sub2api PR #8157 在北京 17:36 开出，10 个文件 +629/−38，基分支 main，关联报障 #75168。

上游 Antigravity 已经不再按模型独立记配额。v1internal:retrieveUserQuotaSummary 把用量收进两个共享池，每个池各有 5 小时与 7 天两个窗口8。

Gemini 池是 gemini-5h 与 gemini-weekly，覆盖 Gemini 4 Argon、Gemini 3.1 Pro、3.8/3.7/3.6/3.5/3 Flash 以及图像模型8。

Claude 与 GPT 池是 3p-5h 与 3p-weekly，覆盖 claude-opus-5-5-*、claude-sonnet-5-5-* 与 gpt-oss-120b-medium8。

现在的取数只查 v1internal:fetchAvailableModels，它把 gemini-weekly 的比例抄到每一个 gemini-* 条目上，并且没有 gemini-5h8。

本刊在 v0.2.17 里核到了这一步：整包搜不到 retrieveUserQuotaSummary，额度取数只调 client.FetchAvailableModels8。

面板那一端按写死的旧模型 ID 列表匹配读数，列表里是 gemini-3-pro-low、gemini-3-flash、gemini-3.1-flash-image 与一串 claude-opus-4-x，没有 Gemini 4 Argon，也没有 Claude 5.59。

两边叠起来的结果是：一个正在消耗 gemini-4-argon-* 与 claude-opus-5-5-* 的 Ultra 账号，面板上只看得到两条重复的 G3F 85% 与 G31FI 85%，5 小时窗口整个看不见，Claude 5.5 的周配额已经用尽也看不出来8。

作者在评论里贴了实测图：一个 100U 的 Gemini Ultra 账号跑了两天，Opus 5.5 大约 1 小时就消耗光，Gemini 4 还能继续用8。

这个 PR 还没合并。今天要判断 Antigravity 的额度，面板上的百分比不足以支撑判断，得对着上游那一侧的 /usage 读数看。

一段 Vue 源码，第 900 到 930 行被浅黄色高亮 — *sub2api v0.2.17 的 `frontend/src/components/account/AccountUsageCell.vue` 第 900–930 行：第 907–928 行是按模型 ID 列表取用量的四组，列表停在 `claude-opus-4-8`9*

三、sub2api：分组模板只影响新生成的那批，以及一个 429 连带整类账号

PR #8158 在北京 17:41 开出，43 个文件 +1550/−143，基分支 main10。

它在管理端的分组新增/编辑页加了一块「分组客户端模板配置」。可配的有 Codex 的默认模型、推理强度与目录来源，OpenAI 分组的认证方式，Gemini 默认模型（给 Gemini CLI 与 CC Switch 用），Claude Code 的非必要网络请求策略，以及 CC Switch 的余额查询开关与自动刷新间隔10。

配置按分组的 JSONB 字段保存，省略时保留旧值，传空对象恢复原生默认；用户端同时移除了认证与目录来源的编辑控件10。

作者列了验证范围：5 组 Vitest 共 80 项、vue-tsc、Go 格式化与真实 PostgreSQL 仓储测试都通过；全仓库测试、前端生产打包与真实上游推理没有跑10。

对读者最关键的是它自己写的那句边界：这套配置只影响新生成的模板与导入链接，已经导入的客户端需要重新导入10。

同一窗口内还有一张新单。sub2api issue #8159 在窗口末尾的北京 18:25 开出，open、1 条评论11。

它报的是：同一类型下有多个账号时（例如 20 个来自不同智谱账号的 GLM API key），只要其中一个回 429，所有同类型账号都会被显示成 429 并停止调度11。

报障人补了一句，每次都要手动恢复很麻烦。单子里还没有维护者定性，也没有修复。

四、CLIProxyAPI：闲置超过 1 小时又跨天，早先的思考块会被上游全部丢掉

CLIProxyAPI issue #6682 在北京 18:20 开出，open、0 评论，报障人 edxeth12。

机制在 CPA 自己这一侧。它把 cloak 用的 currentDate 提醒钉在会话上，钉记在 continuity 条目里，而条目带 1 小时滑动 TTL12。

本刊在 v8.0.31 里核到了同一处：claudeDiagnosticsTTL = time.Hour 写在第 21 行13。

PinClaudeSessionDate 的函数注释也写着同一句话：条目过期会重置，同一会话的下一个请求于是重新锚定到当时的那一天14。

超过 1 小时没有请求，下一个请求就会拿到新条目并写入当前的本地日期。会话起始日与当前日不同时，messages[0] 的文本跟着变12。

Anthropic 把每个签名 thinking 块绑在它前面的那一段精确前缀上。messages[0] 一变，之前的思考块全部对不上前缀，被判 prefix_binding_mismatch 丢掉；prompt cache 也从 messages[0] 起整段落空12。

对这个会话来说损失是永久的：之后的每个请求都带着新日期，旧思考块再也匹配不回来12。

报障人贴了他自己的读数：历史里 113 个签名思考块全部被丢，那次请求读到 6,696 个缓存 token、写回 298,531 个，按他的估算约 1.43 美元12。这几个数字出自报障人自述，本刊没有复现。

影响面比看上去大。默认 cloak 模式是 auto，除 Claude Code 之外的每个客户端都走这条路径；把会话挪到另一张凭证会开一把新钥匙，重新钉一次日期12。

客户端基本看不见这件事。只有请求带上 thinking.block_binding.prefix_mismatch_behavior: "drop_block" 与 thinking-binding-controls-2026-08-01 这个 beta 头，上游才会在 message_start.message.input_transformations 里报告丢块；不带这两个字段时返回 200，什么都不说12。

现在没有配置项能改这个 TTL。能自查的是请求日志里 messages[0] 那个日期，以及 usage 里突然变大的 cache_creation_input_tokens。

一段 Go 源码，第 198 到 216 行被浅黄色高亮 — CLIProxyAPI v8.0.31 的 `internal/runtime/executor/helps/claude_diagnostics.go` 第 198–216 行：第 204–205 行是那句「TTL 过期会把同一会话重新锚定到当时的日期」，第 208 行起是 `PinClaudeSessionDate` 本体14

五、CLIProxyAPI：Meta／Muse 在 Claude 格式请求上丢 reasoning

CLIProxyAPI issue #6679 在北京 17:31 开出，open、0 评论15。配套的 PR #6680 在同一分钟开出，4 个文件 +445/−1，基分支 dev16。

两篇正文的开头都写明由 Claude（Opus 5.5）代笔、@Crazytieguy 复核后再发。下面这一段是本刊按报障人自述的层级转述的。

v8.0.21 的 #6450 让 Meta executor 为 Responses 格式客户端保留了 Muse 的 encrypted_content；Claude 格式客户端（/v1/messages，例如 Claude Code）仍然会丢15。

Muse 的 reasoning 以 thinking 块的形式回给 Claude 客户端，块的 signature 就是 Muse 的 encrypted_content，以 Q-PaD 开头。客户端下一轮回放上来时，Claude 到 Codex 的翻译只保留 GPT（gAAAA…）与 Grok 的签名，Muse 那一块被静默丢掉15。

本刊在 v8.0.31 里核到了那处翻译：appendReasoningContent 定义在 internal/translator/codex/claude/codex_claude_request.go 第 172 行，第 180 行用 DetectSignatureProviderForBlock 判断签名归属17。

报障人抓到的第 2 轮上游输入是 [developer, user, assistant, function_call, function_call_output]，里面没有 reasoning item15。

同一路径上还有第二处更小的丢失：工具调用之前那段 preamble 的 phase: "commentary" 也没带回去15。

量级参考来自 #6450 自己做过的统计：不重放时，Muse Spark 1.3 在 56K 以上的 33 轮里推理了 0 轮15。

修法在 PR #6680 里，只动 Meta executor 与 helps/，internal/translator/ 不动16。

它还顺带给 Claude Code 的请求补上 prompt_cache_key。报障人实测同一个会话里一个 13–15K 的前缀连续几轮拿到 13300、13684、13812、0、14324 个缓存 token16。

这条还没合并。跑 muse-wonder-1.0、客户端又是 Claude 格式的部署，会持续吃这处丢失。

六、CLIProxyAPI：另外三条短条目

issue #6681 在北京 17:46 开出，报的是 Home 模式从不加载配置里的模型目录18。

config.example.yaml 第 17 行确实写着「Home mode never loads the general catalog, even when explicitly configured」19；models.json 也是用 //go:embed 编进二进制的20。

所以给 Antigravity 注册一个像 gemini-4-argon-high 这样的目录条目，在 Home 节点上仍要改代码再发一次。报障人提到的 modelCatalogUpdaterPlan 这个名字本刊在 v8.0.31 里没有找到，这部分按他的自述记。

PR #6683 在北京 18:20 开出，5 个文件 +213，基分支 dev21。

它在 Antigravity 的流式、非流式与 token 计数三条路径上，对关闭了思考的 Claude 目标剥掉 thought 为真的部分、删掉因此变空的轮次，保留可见文本与 functionCall/functionResponse/thoughtSignature21。Gemini 模型不受影响，已开启思考时是空操作。

issue #6674 在本窗口被关闭，理由标的是 not planned22。维护者给出的解释是：openai-compatibility 这一类型按设计只走上游的 POST /chat/completions，也不打算加按模型选择上游协议的开关；只有 Responses 端点的上游，应该配到 Codex API-key 那种凭证类型下22。

还有一条容易被误读的关闭。4 天前的老 PR #6265 在本窗口关闭，未合并、没有维护者留言23。

它想修的是另一件事：Anthropic 的 404 thread_not_found 当时被当作凭证问题，会在号池里轮换凭证，并给每张健康凭证压上 12 小时模型冷却23。

本刊在 v8.0.31 里核到了同向的处置：IsRequestFault 先判 IsClaudeThreadNotFound，命中就返回「请求侧故障」，注释写明这属于过期的续接 ID，让客户端自己重放会话24。所以这条关闭对应的是行为已在发行版里，不是问题还挂着。

七、上游与额度侧

OpenAI 状态页仍是 Partial System Degradation，降级组件只有 Compliance API，处置状态停在 monitoring25。

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

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

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

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

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

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

Reddit 三个板块里，只有 r/GeminiAI 在窗口内有与额度相关的条目，而且是连着几条。北京 17:36 有人报同一条 prompt 的 Argon 用量从昨天的 5%–7% 涨到今天的 30%–40%31。

北京 17:43 有人报 Argon 打满之后 Gemini 3.8 Flash 与 3.1 Pro 一起被挡住32；17:53 有人报一个普通任务吃掉周配额的 21%33。

这几条与第二节那条共享池的说法互相印证：Argon 与 3.8 Flash、3.1 Pro 同在一个池里，Argon 把池子吃掉，同池的其他模型一起停。r/OpenAI 与 r/ClaudeAI 窗口内没有额度或风控条目。

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

codex2api：本窗口 #788、#790 并进 main，#793 新登记；继续跟下一版会不会带上这两笔、#793 有没有维护者定性
sub2api：本窗口登记 #8157、#8158、#8159，#3907 有更新；继续跟 #8157 会不会合并、#8159 有没有人给出改法，以及 #8155、#8151、#8139、#8135、#8136、#8142、#8143、#8146、#8147、#8127、#8125、#8123、#7962、#7398
CLIProxyAPI：本窗口登记 #6679、#6680、#6681、#6682、#6683，#6674 关闭（not planned），#6265 关闭未合并；继续跟 #6669 与 #6670 的关系，以及 #6676、#6677、#6515、#6675、#6605、#5764、#6661、#6667、#6659、#6671、#6673、#6625、#6603、#6500
codex-proxy：本窗口 0 条；继续跟 v2.1.18 正式版会不会打上 latest

下期优先回看三条：#8157 会不会合并、合并后 Antigravity 面板的读数变不变；#6680 会不会带着 prompt_cache_key 那笔一起进 dev；codex2api 下一版会不会补上图片盲测那处已知边界。

References

1
sub2api Releases
github.com
2
CLIProxyAPI Releases
github.com
3
codex-proxy Releases
github.com
4
codex2api Releases
github.com
5
codex2api PR #788
github.com
6
codex2api PR #790
github.com
7
codex2api #793
github.com
8
sub2api #8157
github.com
9
AccountUsageCell.vue 第 900–930 行
github.com
10
sub2api #8158
github.com
11
sub2api #8159
github.com
12
CLIProxyAPI #6682
github.com
13
claude_diagnostics.go 第 14–24 行
github.com
14
claude_diagnostics.go 第 198–216 行
github.com
15
CLIProxyAPI #6679
github.com
16
CLIProxyAPI #6680
github.com
17
codex_claude_request.go 第 172–182 行
github.com
18
CLIProxyAPI #6681
github.com
19
config.example.yaml 第 12–21 行
github.com
20
model_updater.go 第 22–26 行
github.com
21
CLIProxyAPI #6683
github.com
22
CLIProxyAPI #6674
github.com
23
CLIProxyAPI #6265
github.com
24
client_error.go 第 75–165 行
github.com
25
OpenAI Status
status.openai.com
26
Claude Status
status.anthropic.com
27
Google Cloud Status
status.cloud.google.com
28
codex-reset.com
codex-reset.com
29
opentherank
opentherank.com
30
Codex - OpenAI Developer Community
community.openai.com
31
r/GeminiAI 1x7bre3
reddit.com
32
r/GeminiAI 1x7bvca
reddit.com
33
r/GeminiAI 1x7c1e4
reddit.com