antigravity 上两个并行工具调用被并成一条，回放还能串到别人的会话 (2026)

这一小时四个仓库都没有发新版本。要处理的两件事都还停在主干上。

CLIProxyAPI 的 dev 在北京 18:16 落了一笔 antigravity 工具调用的修复；sub2api 在 17:42 到 17:44 之间把六条改动并进了 main。

上一版 CLIProxyAPI v8.0.37 发在北京 15:54，sub2api 的 v0.2.17 停在 10 月 16 日。这两批改动都还没随任何版本出去。

一、两个并行工具调用被并成一条

报障人 CLIProxyAPI #6825 列了三组现象，共同点是每一组都回 200。

第一组在流式返回上。一个并行工具组拆成两个上游 chunk 到达，A 块只有 call1，B 块有 call2 和 call3。

代理发出去的 index 是 0、1、1。OpenAI 客户端按 index 聚合 delta，call2 与 call3 因此被合成同一个调用，两段参数拼成了一段，客户端拿到的参数多半是段非法 JSON。

源码只有几行（v8.0.37 第 178–183 行）。先取流内计数器 FunctionIndex 并自增。

紧接着，如果本块里已经有 tool_calls 数组，就把值改写成这个数组的长度。块内计数是局部的，流内计数是全局的，两者混用了。

CLIProxyAPI v8.0.37 antigravity_openai_response.go 第 175–189 行

v8.0.37 的 internal/translator/antigravity/openai/chat-completions/antigravity_openai_response.go 第 175–189 行（GitHub 源码页截图，2026-10-21 读取）。第 179 行取流内计数器，第 180 行自增，第 181–182 行在本块已有数组时把值覆盖成数组长度——覆盖之后，同一块里的第二个调用会重新从 1 开始。

判据：抓一帧带两个以上 functionCall 的 chunk，看 choices[0].delta.tool_calls 里的 index 有没有重复。

报障人给了能直接跑的复现，用 sdk/translator 的公开注册表就能拿到 0, 1, 1。

第二组在 tool_choice 上。mode 为 NONE 时，applyOpenAIToolChoiceToAntigravity 会把整个 request.tools 删掉（第 531–533 行）。

上一轮留下的 functionCall 部件带着 thoughtSignature。这一轮回放时工具声明已经不在请求里，签名失去了落点。

同一段逻辑还有第二重影响。回放账本的上下文指纹把 request.tools 与 request.toolConfig 一起算进了哈希（第 1577 行）。

本轮改了 tool_choice，历史条目的签名就对不上，整段回放被丢弃。非流式两轮对话走的是同一套指纹，所以「非流式也不回放」与「改 tool_choice 就不回放」是同一个病根。

第三组最值得警惕：回放账本没有按调用方分隔。

账本键由模型名加一个 sessionKey 组成，取键逻辑在 antigravityReasoningReplayScopeFromRequest（第 99 行起）。

sessionKey 优先取下游会话标识，取不到就用请求体推导出来的 sessionId。

两个下游客户端撞上同一个会话标识——同一个 Session-Id 头，或同一段请求体推出同一个 sessionId——就会共用同一份 Gemini 推理链。A 的推理链会被当成 B 的续写。

修复在提交 80aa2b1d17，5 个文件 +432/−27，提交说明写着 Closes: #6825，其中 362 行是新增的回归测试。

index 统一用流内计数器，去掉块内长度的覆盖。
mode 为 NONE 时保留 request.tools，只改 toolConfig.functionCallingConfig.mode。
上下文指纹拆成两套。OpenAI Chat 这条路只绑 systemInstruction 与前序 contents，带 openai-chat-v1: 前缀；老账本按原算法匹配，互不干扰。
账本键加调用方前缀：取执行元数据里的 caller scope，做一次 SHA-256，拼在 sessionKey 前面。

提交 80aa2b1d17 的 antigravity_reasoning_replay.go 第 104–129 行 — 提交 80aa2b1d17 的 `internal/runtime/executor/antigravity_reasoning_replay.go` 第 104–129 行（GitHub 源码页截图，2026-10-21 读取）。第 114 行标记这是一条 OpenAI Chat 请求，第 115–116 行的注释写明调用方身份只从可信执行元数据取，第 117–124 行把 caller scope 的哈希拼进 sessionKey。

处置按代价排。

需要「这轮不许调工具」时，别让客户端发 tool_choice: none。改在代理侧用 payload.override 把 toolConfig.functionCallingConfig.mode 设成 NONE，payload 规则在翻译之后应用，request.tools 会留着。
多租户共用一组凭证的站点，给每个下游客户端一个独立的会话标识，别共用同一个 prompt_cache_key 或 Session-Id。
并行工具调用是常态的客户端，可以改用 /v1/messages 打 antigravity。这条路绕开的是第一条症状，index 那段代码只存在于 chat-completions 翻译器。账本仍由同一个执行器建，第三条症状照样在。
升级要等下一个 tag。这笔提交落在 dev，最近的发行版是 15:54 发的 v8.0.37。单子已打 Fixed 标签，状态还是 open。

二、sub2api 六条同分钟进 main：两条会改你的行为

北京 17:42 到 17:44，sub2api 的 main 连收六次合并，全部没有发版。

PR	合并（北京）	规模	一句话
#8166	17:42	18 文件 +624/−24	Vertex `service_account` 账号支持配额上限
#8167	17:43	22 文件 +691/−46	分组生图开关对 Gemini 系入口生效
#8210	17:43	13 文件 +1728/−206	Anthropic 账号兼容流式断开后读完上游再计费
#8249	17:43	9 文件 +388/−33	单 antigravity 账号分组判定改按需求值
#8250	17:44	2 文件 +139/−16	模型映射签名与遍历顺序无关、零分配
#8251	17:44	7 文件 +1637/−46	调度快照解码结果常驻内存

会改行为的第一条是生图开关。此前它只在 OpenAI 图片接口、Responses 生图工具和 Grok 媒体接口上生效。

Gemini 系的 /v1beta/models、/v1/messages、/v1/chat/completions、/v1/responses 都不检查这个开关。

合并后四条入口一起受约束。命中条件是模型名以 gemini- 开头且带 -image，或者请求体的 responseModalities 含 IMAGE。

拒绝用的是 400，作者在 PR 说明里解释了原因。下游把本实例当 Gemini 上游时，403 会触发换号，并在 handle403 里直接 handleAuthError 永久停号。

一条请求就能把下游整组账号停掉。升级要注意三处。第一处是迁移 246，它会把存量 gemini 与 antigravity 分组的开关统一置为开启：

sub2api 迁移 246 全文 — 合并提交 98f83b7 的 `backend/migrations/246_enable_gemini_image_generation_groups.sql` 全文（GitHub 源码页截图，2026-10-21 读取）。第 1–2 行的注释写明了回填范围，第 5–6 行只更新 gemini 与 antigravity 两个平台、只改当前为 false 的行。

composite 分组不回填。 它身上的同一个开关还管着 OpenAI 生图，整体置开会把 OpenAI 生图一起放开。升级后未勾选的 composite 分组请求 Gemini 生图模型或 responseModalities: IMAGE 会收到 400。
迁移分不清「未配置」与「主动关闭」。 此前在 gemini 或 antigravity 分组上手动关过的，升级后会被置开，得重新关一次。
新分组的平台默认值改成开启，创建时传 false 不生效，与 grok 同口径取 OR，要关只能在创建之后编辑。

会改行为的第二条是断连计费。/v1/chat/completions 与 /v1/responses 走 Anthropic 账号时，客户端断开后原来直接返回。

那时 message_delta 还没读，output_tokens 记 0；在 message_start 之前断开，连 input 也记 0。

原生 /v1/messages、Bedrock 与 OpenAI 侧兼容路径都是读完上游再计费，只有这两条例外。

改法是停写下游、继续读上游、把 ForwardResult.ClientDisconnect 置真，读取间隔卡在 gateway.stream_data_interval_timeout（默认 180 秒）。

这条在 10 月 19 日那期登记时还是 open 的 PR，现在进了 main。上线后你会看到「客户端早断开、用量照记」的请求，账目变了，别当成重复计费。

能力变化一条：#8166 让 Vertex 的 service_account 账号也能设配额上限并累加 quota_used。

用满后停止调度、跨阈值发通知。给 Vertex 账号配过上限的站点，升级后这些账号会真的停调。

三条性能各解决一件事。

#8249 把「分组里只有一个 antigravity 账号」的判定从入口挪到按需，纯 Gemini 与 Anthropic 分组不再每个请求回源一次 PG。

作者在生产上观测到八成以上请求会触发这次回源，空桶的版本号比同组正常 bucket 高出近三个数量级。

#8250 把模型映射签名换成与顺序无关的算法，1000 号分组选号从 27.8 ms 降到 21.5 ms。

#8251 让调度快照的解码结果常驻内存，1000 号分组每请求约 2.5 MB 的 Redis 出口变成读几个标签。

升级前的检查顺序：先列出 platform in (gemini, antigravity) and allow_image_generation = false 的分组，再逐个看 composite 分组。

升级后对断连请求的用量抽几条核对。

三、两条对不上的账

第一条是 CLIProxyAPI #6839，18:27 由 zouchenzhen 开出，0 评论。

现象是某个模型名下所有可用凭证都在冷却时，/v1/responses 回 429 model_cooldown。CPA 的 error 日志里有这条请求，下游的 usage 消费端里没有。

同一作者在 #6646 的 18:26 评论里给了实测。v8.0.23 配 Codex desktop app-server 0.163.0-alpha.10.2，上游回 usage_limit_reached。

凭证全部进入冷却后，CPA 在约 29 ms 内返回 Retry-After: 3299、reset_seconds: 3299、reset_time: 54m58s。

原因在代码分层上。这个 429 由 sdk/cliproxy/auth/selector.go 的 modelCooldownError 生成，停在选号阶段。

usage reporter 是在执行器内部创建的，例如 codex_executor_stream.go。选号失败没进执行器，也就没有发出 usage 事件。

CLIProxyAPI v8.0.37 auth/selector.go 第 119–152 行

v8.0.37 的 sdk/cliproxy/auth/selector.go 第 119–152 行（GitHub 源码页截图，2026-10-21 读取）。第 142 行的 code: model_cooldown 与第 145–146 行的 reset_time、reset_seconds 都在这里组装，位置本身说明请求止步于选号。

对按用量计费或按请求数对账的下游，「没有失败请求」和「没有请求」在消费端长得一样。

今晚的自保办法是把 CPA 的 error 日志当第二计数源，或者在网关层按终态状态码统计。报障人提的方案是新增一条请求级审计事件，与真实的上游尝试分开记账。

第二条是 CLIProxyAPI #6840，18:31 开出，2 文件 +42，open、mergeable clean。

Anthropic 在 usage.speed 里标明这次响应按 fast 还是 standard 计费，fast 档更贵。

v8.0.37 的 parseClaudeUsageNode（internal/runtime/executor/helps/usage_helpers.go 第 1176 行起）只读 token 字段。

ResponseServiceTier 因此一直是空的，fast 档响应被按 standard 计价。作者已经在 fork 上跑了三周，说没拿线上 fast 流量验过。

两条落在同一层：请求成功与否怎么记，按什么档位计价。

四、简讯

订阅额度全站重置做不到，卡在两条限制上。 sub2api #8273（18:14 开出，10 文件 +911，open、clean）指向 v0.2.17 的 backend/internal/service/subscription_bulk_action.go。

第 12 行是 MaxBulkSubscriptionActions = 100，第 29 行校验「必须显式列 ID 且不超过 100 条」。

活跃订阅超过 100 的站点要重置全站额度，只能在列表页翻页收集 ID、分批提交，中途失败没有续跑入口。

PR 新增 preview、reset-all、retry 三个接口，按「已勾选窗口仍有用量」取范围，天然可中断续跑。

另外两条还在原地。 #8269（账号配额累加按维度选语句）仍 open；CLIProxyAPI #6817（委托式 Codex 启动的配额准备与会话绑定）已有 14 条评论，仍在评审。

上游这一小时是干净的。 OpenAI 状态页全部系统正常，25 个组件零降级，最近一次事故是今天上午 10:26 到 11:28 的 ChatGPT、Codex 与 API 性能下降。Anthropic 今日无事件；Google Cloud 的 incidents 仍 8 条，最新一条还是 10 月 20 日 europe-west2 那次。

额度侧今天没有新的重置。 codex-reset.com 记最近一次已验证的全局重置在 10 月 20 日 14:33（28 小时前），56 次全局重置、10 次 banked，48 小时预测 39%。opentherank 记 64 次、中位间隔 3.1 天、最长 68 天。

codex2api 与 codex-proxy 窗口内 0 条。

这一小时四个仓库都没有发新版本。要处理的两件事都还停在主干上。

CLIProxyAPI 的 dev 在北京 18:16 落了一笔 antigravity 工具调用的修复；sub2api 在 17:42 到 17:44 之间把六条改动并进了 main。

上一版 CLIProxyAPI v8.0.37 发在北京 15:54，sub2api 的 v0.2.17 停在 10 月 16 日。这两批改动都还没随任何版本出去。

一、两个并行工具调用被并成一条

报障人 CLIProxyAPI #6825 列了三组现象，共同点是每一组都回 200。

第一组在流式返回上。一个并行工具组拆成两个上游 chunk 到达，A 块只有 call1，B 块有 call2 和 call3。

源码只有几行（v8.0.37 第 178–183 行）。先取流内计数器 FunctionIndex 并自增。

紧接着，如果本块里已经有 tool_calls 数组，就把值改写成这个数组的长度。块内计数是局部的，流内计数是全局的，两者混用了。

判据：抓一帧带两个以上 functionCall 的 chunk，看 choices[0].delta.tool_calls 里的 index 有没有重复。

报障人给了能直接跑的复现，用 sdk/translator 的公开注册表就能拿到 0, 1, 1。

第二组在 tool_choice 上。mode 为 NONE 时，applyOpenAIToolChoiceToAntigravity 会把整个 request.tools 删掉（第 531–533 行）。

上一轮留下的 functionCall 部件带着 thoughtSignature。这一轮回放时工具声明已经不在请求里，签名失去了落点。

同一段逻辑还有第二重影响。回放账本的上下文指纹把 request.tools 与 request.toolConfig 一起算进了哈希（第 1577 行）。

第三组最值得警惕：回放账本没有按调用方分隔。

账本键由模型名加一个 sessionKey 组成，取键逻辑在 antigravityReasoningReplayScopeFromRequest（第 99 行起）。

sessionKey 优先取下游会话标识，取不到就用请求体推导出来的 sessionId。

修复在提交 80aa2b1d17，5 个文件 +432/−27，提交说明写着 Closes: #6825，其中 362 行是新增的回归测试。

index 统一用流内计数器，去掉块内长度的覆盖。
mode 为 NONE 时保留 request.tools，只改 toolConfig.functionCallingConfig.mode。
上下文指纹拆成两套。OpenAI Chat 这条路只绑 systemInstruction 与前序 contents，带 openai-chat-v1: 前缀；老账本按原算法匹配，互不干扰。
账本键加调用方前缀：取执行元数据里的 caller scope，做一次 SHA-256，拼在 sessionKey 前面。

处置按代价排。

需要「这轮不许调工具」时，别让客户端发 tool_choice: none。改在代理侧用 payload.override 把 toolConfig.functionCallingConfig.mode 设成 NONE，payload 规则在翻译之后应用，request.tools 会留着。
多租户共用一组凭证的站点，给每个下游客户端一个独立的会话标识，别共用同一个 prompt_cache_key 或 Session-Id。
并行工具调用是常态的客户端，可以改用 /v1/messages 打 antigravity。这条路绕开的是第一条症状，index 那段代码只存在于 chat-completions 翻译器。账本仍由同一个执行器建，第三条症状照样在。
升级要等下一个 tag。这笔提交落在 dev，最近的发行版是 15:54 发的 v8.0.37。单子已打 Fixed 标签，状态还是 open。

二、sub2api 六条同分钟进 main：两条会改你的行为

北京 17:42 到 17:44，sub2api 的 main 连收六次合并，全部没有发版。

PR	合并（北京）	规模	一句话
#8166	17:42	18 文件 +624/−24	Vertex `service_account` 账号支持配额上限
#8167	17:43	22 文件 +691/−46	分组生图开关对 Gemini 系入口生效
#8210	17:43	13 文件 +1728/−206	Anthropic 账号兼容流式断开后读完上游再计费
#8249	17:43	9 文件 +388/−33	单 antigravity 账号分组判定改按需求值
#8250	17:44	2 文件 +139/−16	模型映射签名与遍历顺序无关、零分配
#8251	17:44	7 文件 +1637/−46	调度快照解码结果常驻内存

会改行为的第一条是生图开关。此前它只在 OpenAI 图片接口、Responses 生图工具和 Grok 媒体接口上生效。

Gemini 系的 /v1beta/models、/v1/messages、/v1/chat/completions、/v1/responses 都不检查这个开关。

合并后四条入口一起受约束。命中条件是模型名以 gemini- 开头且带 -image，或者请求体的 responseModalities 含 IMAGE。

拒绝用的是 400，作者在 PR 说明里解释了原因。下游把本实例当 Gemini 上游时，403 会触发换号，并在 handle403 里直接 handleAuthError 永久停号。

一条请求就能把下游整组账号停掉。升级要注意三处。第一处是迁移 246，它会把存量 gemini 与 antigravity 分组的开关统一置为开启：

composite 分组不回填。 它身上的同一个开关还管着 OpenAI 生图，整体置开会把 OpenAI 生图一起放开。升级后未勾选的 composite 分组请求 Gemini 生图模型或 responseModalities: IMAGE 会收到 400。
迁移分不清「未配置」与「主动关闭」。 此前在 gemini 或 antigravity 分组上手动关过的，升级后会被置开，得重新关一次。
新分组的平台默认值改成开启，创建时传 false 不生效，与 grok 同口径取 OR，要关只能在创建之后编辑。

会改行为的第二条是断连计费。/v1/chat/completions 与 /v1/responses 走 Anthropic 账号时，客户端断开后原来直接返回。

那时 message_delta 还没读，output_tokens 记 0；在 message_start 之前断开，连 input 也记 0。

原生 /v1/messages、Bedrock 与 OpenAI 侧兼容路径都是读完上游再计费，只有这两条例外。

改法是停写下游、继续读上游、把 ForwardResult.ClientDisconnect 置真，读取间隔卡在 gateway.stream_data_interval_timeout（默认 180 秒）。

这条在 10 月 19 日那期登记时还是 open 的 PR，现在进了 main。上线后你会看到「客户端早断开、用量照记」的请求，账目变了，别当成重复计费。

能力变化一条：#8166 让 Vertex 的 service_account 账号也能设配额上限并累加 quota_used。

用满后停止调度、跨阈值发通知。给 Vertex 账号配过上限的站点，升级后这些账号会真的停调。

三条性能各解决一件事。

#8249 把「分组里只有一个 antigravity 账号」的判定从入口挪到按需，纯 Gemini 与 Anthropic 分组不再每个请求回源一次 PG。

作者在生产上观测到八成以上请求会触发这次回源，空桶的版本号比同组正常 bucket 高出近三个数量级。

#8250 把模型映射签名换成与顺序无关的算法，1000 号分组选号从 27.8 ms 降到 21.5 ms。

#8251 让调度快照的解码结果常驻内存，1000 号分组每请求约 2.5 MB 的 Redis 出口变成读几个标签。

升级前的检查顺序：先列出 platform in (gemini, antigravity) and allow_image_generation = false 的分组，再逐个看 composite 分组。

升级后对断连请求的用量抽几条核对。

三、两条对不上的账

第一条是 CLIProxyAPI #6839，18:27 由 zouchenzhen 开出，0 评论。

现象是某个模型名下所有可用凭证都在冷却时，/v1/responses 回 429 model_cooldown。CPA 的 error 日志里有这条请求，下游的 usage 消费端里没有。

同一作者在 #6646 的 18:26 评论里给了实测。v8.0.23 配 Codex desktop app-server 0.163.0-alpha.10.2，上游回 usage_limit_reached。

凭证全部进入冷却后，CPA 在约 29 ms 内返回 Retry-After: 3299、reset_seconds: 3299、reset_time: 54m58s。

原因在代码分层上。这个 429 由 sdk/cliproxy/auth/selector.go 的 modelCooldownError 生成，停在选号阶段。

usage reporter 是在执行器内部创建的，例如 codex_executor_stream.go。选号失败没进执行器，也就没有发出 usage 事件。

对按用量计费或按请求数对账的下游，「没有失败请求」和「没有请求」在消费端长得一样。

第二条是 CLIProxyAPI #6840，18:31 开出，2 文件 +42，open、mergeable clean。

Anthropic 在 usage.speed 里标明这次响应按 fast 还是 standard 计费，fast 档更贵。

v8.0.37 的 parseClaudeUsageNode（internal/runtime/executor/helps/usage_helpers.go 第 1176 行起）只读 token 字段。

ResponseServiceTier 因此一直是空的，fast 档响应被按 standard 计价。作者已经在 fork 上跑了三周，说没拿线上 fast 流量验过。

两条落在同一层：请求成功与否怎么记，按什么档位计价。

四、简讯

第 12 行是 MaxBulkSubscriptionActions = 100，第 29 行校验「必须显式列 ID 且不超过 100 条」。

活跃订阅超过 100 的站点要重置全站额度，只能在列表页翻页收集 ID、分批提交，中途失败没有续跑入口。

PR 新增 preview、reset-all、retry 三个接口，按「已勾选窗口仍有用量」取范围，天然可中断续跑。

codex2api 与 codex-proxy 窗口内 0 条。

antigravity 上两个并行工具调用被并成一条，回放还能串到别人的会话

一、两个并行工具调用被并成一条

二、sub2api 六条同分钟进 main：两条会改你的行为

三、两条对不上的账

四、简讯

Related content

antigravity 上两个并行工具调用被并成一条，回放还能串到别人的会话

一、两个并行工具调用被并成一条

二、sub2api 六条同分钟进 main：两条会改你的行为

三、两条对不上的账

四、简讯

Related content