10/15 清晨续报：没有提示的 429 会把重试轮次烧光，Gemini 多轮思考回放会吃 400
补报 10 月 15 日 04:18 到 05:44（北京）：没有重试时长的 429 会让 Antigravity 请求在一张已经耗尽的凭证上空转，修它的 PR 还没合并；另有一条 Gemini 多轮思考加工具调用吃 400 的报障，以及两条不影响请求成败的传输画像与日志误报修复。
这一期覆盖 10 月 15 日 04:18 到 05:44（北京）。四个仓库这一窗口都没有出新版本，四条新条目全部落在 CLIProxyAPI，其中两条直接关系到请求成功率。
现在就做
- 跑 Antigravity 号池的实例，把
request-retry或max-retry-interval收小。 v8.0.29 收到不带任何重试时长的 429 时，会从 1 秒起退避、把配置的轮次全部用完，再把结果交回客户端；修这一处的 PR #6634 到发稿还开着。1 - Gemini 多轮对话里同时用了思考和工具调用，撞到 400 就换个模型把这个会话跑完。 这条报障到发稿没有人回复，也没有版本修它。2
- 日志里那行
upstream served model ... for requested ...可以忽略。 它是 tier 后缀没被识别的误报，每个成功响应都会写一行。3
CLIProxyAPI：没有提示的 429 会把重试轮次烧在同一张凭证上
上游回一个
429 RESOURCE_EXHAUSTED，消息里既没有 RetryInfo，也没有 quotaResetDelay，只有一句 Resource has been exhausted (e.g. check quota).。这种响应在 v8.0.29 上不会带任何重试时长回到调度器。报告人贴出的日志是这样的：一次客户端请求产生了 6 次上游调用、耗时 25 秒，另一次退掉 30.8 秒；9 分钟里同样的 429 记到 20 条，每次的答案一模一样。1
为什么写成这样，本刊在 v8.0.29 标签的源码里核到了原因。
处理 429 的地方是
internal/runtime/executor/antigravity_executor_credits.go 里的 newAntigravityStatusErr。这段代码只在 helps.ParseRetryDelay 成功解析出时长时才设置 err.retryAfter，没有解析出来就保持空值。4
if retryAfter, parseErr := helps.ParseRetryDelay(body); parseErr == nil && retryAfter != nil { 与 err.retryAfter = retryAfter；这段 429 分支之外，函数里再没有别的地方写过 retryAfter。4再往下看
ParseRetryDelay 认什么，路就只有三条：RetryInfo.retryDelay 字段、ErrorInfo.metadata.quotaResetDelay 字段，以及错误消息里带 after 的时长写法，比如 after 30s、after 1h43m56s。5Antigravity 配额用尽时回的那句
Individual quota reached. Please upgrade your subscription to increase your limits. Resets in 2h39m14s. 里没有 after，所以第二条路也走不通。时长解析不出来，retryAfter 就是空的，调度器只能从 1 秒开始对着一条已经报耗尽的凭证退避。15PR #6634 改的正是这两处：
RESOURCE_EXHAUSTED 且解析不出时长时，给一个 1 分钟的默认重试提示，凭证与模型一起进入冷却，并在同一轮里换到下一条凭证；所有凭证都在冷却时直接回 429 并带 Retry-After，不再空转；同时让 ParseRetryDelay 认 Resets in 2h39m14s 这种写法。1这张 PR 是 10 月 15 日 04:45（北京）开的，非草稿，动 10 个文件、+191/−19、3 个提交。它到发稿仍开着、未合并，GitHub 给的可合并状态是
clean。1眼下能改的两个开关
| 配置项 | 默认值 | 含义 |
|---|---|---|
request-retry（完整键 routing.retry.request-retry） | 3 | 首轮凭证用尽后的额外重试轮次；显式写 0 表示只跑第 0 轮 |
max-retry-interval（完整键 routing.retry.max-retry-interval） | 30 | 两轮之间等待凭证冷却的最长秒数；写 0 或以下表示不为冷却等待 |
两行的默认值与含义逐字来自 v8.0.29 的
config.example.yaml。6这两项本来是为「换一条凭证再试」准备的，落在没有提示的 429 上却只把时间花在已经耗尽的凭证上。把
request-retry 或 max-retry-interval 收小，能缩短每次撞墙的等待；代价是在「换一条凭证真能成功」的场景里也少了重试机会。等 #6634 合进版本，这两项可以改回默认。CLIProxyAPI：Gemini 的多轮思考加工具调用会吃 400（一位报告人的自述）
同一个模型既走思考又调工具，历史再被回放给上游时，请求会被 Google 侧判为 400：
Invalid value at 'request.contents[N].parts[0].thought_signature' (TYPE_BYTES),
Base64 decoding failed for "\x12&\n$e24830a7-5cd6-42fe-998b-ee539e72b9c3"报告人写的是
thought_signature 被当成原始 Protobuf 字节直接塞进了 JSON，没有做 base64 编码，所以他这边每一次带思考的多轮会话都在第一段思考块落上下文之后开始失败。触发条件有三条：模型同时使用思考和工具调用、之前某一轮已经产出过带签名的思考块、这份历史被回放上去。2有两个前提要一起看。报告人跑的是他自建的
ec1ef408（他标为 v8-patched，2026-10-07 构建），上游最新版是 v8.0.29（5fc580b1）。他写的是，这个问题在他的版本上存在，并且按 ec1ef408 到上游 main 的提交比对，可能在上游最新版上也还在。这段话是他的推断，本刊这一窗口没有复现这条 400。2另外两条还没合并的修复
同一张凭证的两套传输画像。 Antigravity 的模型目录探测在没有配代理时用的是裸
http.Client{}（v8.0.29 的 sdk/cliproxy/antigravity_models.go 第 450 行），落到 http.DefaultTransport 后协商出 HTTP/2；同一张凭证的其它请求则被 cloneTransportWithHTTP11 钉在 HTTP/1.1 上。PR #6635 给探测请求换成执行器那套传输，到发稿仍开着、未合并。78tier 后缀引发的每请求一条误报。
gemini-4-argon-low/medium/high 这类带档位的模型 ID，上游回填的 modelVersion 是基名 gemini-4-argon；而 IsModelSubstituted 只认日期与数字版本后缀，于是每个成功的响应都写一行「请求 high、上游给了 gemini-4-argon」。PR #6633 让基名与档位后缀互相匹配，同时保留「请求 high、回 low」这类真替换的告警，到发稿仍开着、未合并。39这两条的后果都限于多出来的日志行和一处传输痕迹，所以不必为此改配置。它们进这一期，是因为下一个 Antigravity 稳定版里会不会带上它们，取决于什么时候合并。
支持 tier 档位本身的 PR #6627 在这一窗口里被重新基到当前
dev、conflicts 已解，到发稿仍是 open、未合并。10 同一窗口里 #6632（把上游 v8.0.29 同步回本站的 chore）已关闭，没有信息量。版本与上游：这一窗口没有新版本
四个仓库都停在原处：CLIProxyAPI 是 10 月 14 日的 v8.0.29，sub2api 是 10 月 13 日的 v0.2.16，codex-proxy 是 10 月 14 日的 v2.1.17，codex2api 是 10 月 12 日的 v3.1.0。11121314
Anthropic 状态页这一窗口各组件正常，0 条事件。15 Google Cloud 的事件源里最近一条仍是 10 月 8 日开始、10 月 9 日结束的 Cloud Storage 上传与写入延迟，窗口内 0 条新事件。16
Codex 的重置记录没有变化，最新一次仍是 10 月 13 日（北京 13:03）。当天 UTC 没有新的重置，也没有新预告。17
References
- 1
- 2
- 3
- 4
- 5json_retry_helpers.go at v8.0.29
github.com
- 6config.example.yaml at v8.0.29
github.com
- 7
- 8antigravity_models.go at v8.0.29
github.com
- 9response_model.go at v8.0.29
github.com
- 10
- 11CLIProxyAPI v8.0.29 · Releases
github.com
- 12Sub2API v0.2.16 · Releases
github.com
- 13codex-proxy v2.1.17 · Releases
github.com
- 14codex2api v3.1.0 · Releases
github.com
- 15Claude Status
status.anthropic.com
- 16Google Cloud Service Health
status.cloud.google.com
- 17Codex Reset — Last Reset Tracker
codex-reset.com
- 18第 006 期 · 2026-10-14 · linux.do 晚报
linuxdo.club
- 19Codex · OpenAI Developer Community
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.