两处 400 都不换号：一个空 part 送上去，一个错位的 functionResponse 本地就断
同一个 Antigravity Gemini 入口今晚冒出两处 400：一处是空 part 被送到上游，一处是错位的 functionResponse 在本地就被拦下；两处都不会换号也不会冷却，清冷却对它们无效。
两张单指向同一个入口：Antigravity 的 Gemini 转换。症状也一样，客户端拿到 400。
两张都还开着，零评论，没有标签，也没有对应的修复分支。
真正要紧的是它们的共同后果：号池既不换号、也不冷却。同一条请求再来一次，仍旧撞同一堵墙。
第一处：空 part 原样送到了上游
客户端在 systemInstruction.parts 里放了一个空对象
{}，转换环节只把它改了个名字就放行。3上游 Cloud Code Assist 直接拒收，原文点名
system_instruction.parts[0].data 缺一个必填字段。1报障人做了对照：去掉 systemInstruction，或者把 parts 写成空数组，同一份请求都回 200。1
request.model、调工具响应修复，最后只把 system_instruction 改名成 systemInstruction，parts 里的空对象原样保留；第 50–52 行修工具响应出错时返回空 body 与 nil 错误。4空声明的清洗是有的，但它只挂在 tools 分支里，函数本体也只处理 tools。5
if tools 分支内，第 197 行起的函数本体读的是 request.tools，与 systemInstruction 无关；两处同一屏可见。6于是同一个请求里两个位置的待遇不同：tools 里的空声明会被删掉，systemInstruction 里的空 part 一路到底。
影响面比一张单大：Responses 入口调的也是这同一个转换函数，两处调用点分别在 59 行与 150 行。7
第二处：这条 400 是本地生成的
第二条单的错误文本里写着
antigravity executor，请求根本没出网。2原文点名
functionResponse.id 是 call_203720，而上一轮 functionCall.id 是 call_153283。触发条件很具体：某一轮里 functionResponse 的条数多于上一轮 functionCall 的条数。2
修工具响应的函数按先来先取配对这些响应，多出来的那条不丢弃，留在队列里等下一轮。8
collectedResponses，第 850 行把本轮响应追加进去，第 853–861 行按最老一组的需求量从头取走，第 886–890 行给下一轮建新组——多余的响应因此跨轮留到了下一个模型回合。9下一轮模型发新的 call，队首那条旧响应被取走，整列就错位一条，原本配对的响应被挤到队尾。
回放前的配对校验逐对核 id，第一处对不上就返回 400。10
所以这一条看上去像上游的错，其实是本地在发请求之前就把它拦下了。
为什么号池一点反应都没有
因为 400 在这套代码里被归成了请求过错：不换号，也不罚凭证。11
internal/clienterror/client_error.go 第 75–122 行（v8.0.48）：第 77 行 IsRequestFault，第 90 行把 402 与 429 排除在请求过错之外，第 116–120 行的 switch 把 400、409、413、422 判为请求过错，其余落 default。12判定里那个例外值得记住：402 与 429 不按请求过错处理，它们才是凭证自己的事。
归成请求过错以后，冷却那一步整段跳过。13
执行循环遇到请求过错也直接停，不会去试下一个号。14
今晚如果在面板上清冷却，接口会告诉你没有可清的内容——这两类 400 从来没进过冷却。
今晚能做的三步
第一，客户端别发空 part：parts 里要么有实际内容，要么干脆不带 systemInstruction。这一条已由报障人对照验证。1
第二，需要绕开时换入口：Claude 格式进来的请求走另一套转换，不经过修工具响应那个函数，而且只在真有系统片段时才写 systemInstruction。15
第三，把会话里多出来的 functionResponse 清掉——它本来就没有对应的 functionCall，留着就会错位一条。2
次条：muse 那条「不落凭据文件」的直连，58 分钟后自己撤了
sub2api 的 muse 大补丁今天上午一度加进一条新路：浏览器会话直连，不落凭据文件。16
58 分钟后整笔回滚，前端连接卡片、导出脚本、打进前端的会话导出包一起撤掉。17
回退后的文档仍是老口径：导出器只在本地存一份 JSON，不把凭据发给远端收集器。16
对运维的含义很直接：这条补丁仍停在评审里，接入方式这一版不变，还是自己导出 JSON 再挂账号。
上游与社区这一窗口
四个仓库窗口内零发版、主干也没动：CLIProxyAPI 仍停在 v8.0.48。18
Codex 重置仍未落地：今天 UTC 没有重置，最近一次已验证重置是 10 月 28 日 14:35（北京）。21
Gemini 官方论坛有一条值得记：antigravity-preview-latest 的思考档位不可配置、也不是自适应，实测 gemini 4 argon 只有 0.2/1。22
r/GeminiAI 另有一条：作者说换了 Chrome 配置档后四个账号被限制，帖子只有一句标题、没有正文，先记现象。23
未闭合
两张单都还开着、零评论，维护者未表态，也没有对应的修复分支。
muse 那条 126 个文件的补丁仍是草稿，自撤之后何时转正没有时间表。
上游「未来两天会有重置」仍是预告，两家追踪站都还没把它算成已落地。
References
- 1
- 2
- 3转换入口只做改名，不清空 part
github.com
- 4antigravity_gemini_request.go 第 38–60 行
github.com
- 5
- 6同文件第 197 行起的清洗函数
github.com
- 7Responses 入口复用同一转换
github.com
- 8收集、FIFO 取用与轮末循环
github.com
- 9fixCLIToolResponse 全文起点
github.com
- 10配对校验所在
github.com
- 11IsRequestFault 的注释与判定
github.com
- 12400 归入请求过错
github.com
- 13shouldSkipCredentialCooldown
github.com
- 14执行循环的两个提前返回
github.com
- 15
- 16
- 17Revert：撤掉浏览器会话直连
github.com
- 18CLIProxyAPI 发行记录
github.com
- 19OpenAI 状态
status.openai.com
- 20Google Cloud 事故列表
status.cloud.google.com
- 21codex-reset 首页读数
codex-reset.com
- 22Bug on Antigravity preview-latest API: hardcoded unchangeable effort level
discuss.ai.google.dev
- 23
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.