冷却被文件快照冲掉、首包停顿、response.metadata 放掉缓冲：三笔修复都进了 dev，发行版一笔没有
CLIProxyAPI 在 78 分钟里把冷却保留、首包清洗、response.metadata 三笔修复提交进 dev，v8.0.38 一笔都没有；同一时段 sub2api 把 Gemini 的同号重试次数做成配置项。本篇给出四条的落地状态、每条的判断方法，以及今天能做的三件事。
三个结论先放前面。
第一，CLIProxyAPI 的 dev 分支在北京时间今天 10:37 到 11:55 之间落了三个提交，作者都是维护者 Luis Pater。三笔的提交信息分别带 #6844 与
Closes: #6846、Closes: #6856。123第二，这三张单正是本刊最近三期逐条写过的：冷却被文件快照冲掉、大工具列表的首包停顿、
response.metadata 放掉缓冲。发行版 v8.0.38 发布于北京昨晚 23:06，这三笔一笔都没有。4第三，sub2api 开了一张还挂着的 PR，把 Gemini 的同号重试次数交出来做配置项。今天 v0.2.17 上还没有这个键，写死的是每个账号最多请求 5 次。5
10:37：文件快照不再抹掉刚写下的冷却
这一笔是 #6844 的实现，改了 7 个文件，覆盖 auth 合并与 watcher 两条线。1
合并这条路上，代码先看进来的这份是不是文件快照。是的话，把上一个状态里的七样东西搬回来：
Status、StatusMessage、LastError、Unavailable、NextRetryAfter、Quota，以及 cooldownRecordedSeq 这个水位。
dev 分支
sdk/cliproxy/auth/conductor_lifecycle.go 第 392–408 行：isFileSnapshot 为真时逐项搬回状态、退避时刻与额度，第 408 行补上冷却水位。v8.0.38 同一文件没有这一段。搬回的不止冷却。
ModelStates、LastRefreshedAt、NextRefreshAfter、RefreshFailures 也一并保留，第 361 行还补了 CreatedAt。watcher 那半边解决的是另一个洞：一份被摘要栅栏判掉、没有应用的快照，原来文件内容哈希没变就不再重读。新加的
rereadDiscardedFileSnapshot 会把哈希置空并重读一次。#6844 现在仍是 open，标签是
Fixed。这是维护者的流程：改动进 dev 就打标，等发版才关单。610:56：工具列表很大的流，首包不再先卡几秒
这一笔是性能修复，关 #6846，两个文件：
internal/util/responses_tools.go 加了 11 行，测试加 37 行。2改法是把
BuildGeminiFunctionDeclarations 拆成两层，让只取名字与身份映射的调用走不带逐工具声明、也不带 schema 清洗的那条路。ResponsesToolReverseIdentityMap 改走这条轻路。现象是报障人自己量的：一条
/v1/responses 带 264 个 function 工具、约 880 KB JSON Schema，流会停几秒，然后所有帧一次冲出来。8他当时跑的是 v8.0.36，明确写了 v8.0.37 与 main 上这段代码没变。今天这笔提交才把它改掉。
这类卡顿只影响首包时间，请求本身能成。客户端首包超时设得紧的实例会把它当成失败重试。
11:55：response.metadata 进了白名单
这是本刊上午那期的收口。上一期写的是：上游在
response.in_progress 之后插一帧 response.metadata（提示词审核），代理把它当成输出开始，缓冲随之放掉，后面的 server_is_overloaded 就直接漏给客户端，换号来不及。维护者没有等社区那张 PR，自己在 dev 上提交了版本：白名单加一个标签，配三行注释，SSE 与 WebSocket 各补用例。3
dev 分支
internal/runtime/executor/codex_executor_terminal.go 第 508–530 行：第 516–518 行是这次加的注释，第 519 行的 case 列表多了 response.metadata。v8.0.38 同一行（第 516 行）还是五项的旧列表。社区那张 PR #6860 现在是
dirty，也被 dev 抢先了。维护者自己的提交带 Closes: #6856，单子同样留着 open 等发版。你手上那版一笔都没有
三张单各改了一处，位置都能一眼核：
| 现象 | 今天 v8.0.38 | 修在哪 |
|---|---|---|
| 冷却在文件扫描后消失 | updateInternalLocked 没有快照分支 | dev 提交 d5816d5e |
| 大工具列表首包卡几秒 | ResponsesToolReverseIdentityMap 跑完整清洗 | dev 提交 ac3cd66f |
客户端直接收到 server_is_overloaded | 白名单第 516 行五项，无 response.metadata | dev 提交 9e79552f |
三笔都只在 dev 上，且都还没有对应的 tag。等下一版是稳的路径；自己从 dev 构建则要接受它随时会再变。
现在能做的判断只有一条：这三处毛病你有没有撞上。
- 冷却消失：刚吃过 429 的账号几秒后又被选中，日志里看不到冷却。一次扫描读盘与一次失败落在这两步之间就会触发。
- 首包卡顿：客户端工具列表上百个、首包时间忽长忽短，长的能到几秒。
response.metadata：只影响开了stream-bootstrap-buffering: true的实例，症状是客户端在一条还没吐字的流里直接拿到容量拒绝的报错。
sub2api 把 Gemini 的同号重试改成可配
v0.2.17 的 Gemini 转发有三条路径：原生
ForwardNative、Claude 兼容 Forward、Chat Completions 兼容 forwardClaudeBodyAsChatCompletions。三条都读同一个写死的上限 geminiMaxRetries = 5。10
v0.2.17
backend/internal/service/gemini_messages_compat_service.go 第 713–726 行：第 717 行的 for attempt := 1; attempt <= geminiMaxRetries; attempt++ 就是同号重试的唯一入口，第 716 行的 signatureRetryStage 是签名降级用的计数。上限 5 次配合 1、2、4、8 秒的指数退避，单个账号上最多耗约 15 秒才换号。叠加
max_account_switches_gemini 默认 3，一个请求在少数几个账号上能烧掉一分钟。11Claude 兼容路径还有一处吃亏：遇到签名相关的 400，会分两个阶段降级重发。这两次重发要占掉两次重试预算，也就是说降级之后，留给瞬时错误的只剩 3 次。
PR #8287 做两件事。第一，把次数做成配置
gateway.max_same_account_retries_gemini；第二，让两个降级阶段不再占预算——每进一个阶段，循环上限顺延一次，日志与退避按扣掉降级后的次数算。
PR #8287 头分支
backend/internal/config/config.go 第 2432–2444 行：第 2439 行 SetDefault("gateway.max_same_account_retries_gemini", 4)，紧邻第 2438 行的 max_account_switches_gemini。默认值 4 让默认行为与今天一致：4 次重试加首次请求，还是 5 次。取值范围 0–10，超出范围启动时校验报错，也可以用环境变量
GATEWAY_MAX_SAME_ACCOUNT_RETRIES_GEMINI 设。真正的行为变化只在签名降级那条路上：默认配置下，一个先降级、再撞瞬时错误的请求，单账号最多请求 7 次，今天只有 5 次。
PR 现在 open、
mergeable clean、base 是 main，7 个文件 +150/−15，开在北京 12:19。5今天没有键可改。上游共享容量不足的 429（
Resource exhausted. Please try again later）在同一账号上多试几次，成功率一次比一次低，这件事只能靠等。5窗口内其余三条
#6857 在北京 12:02 被维护者以 not planned 关闭，答复是「已经支持，用模型条目上的 is-compat: true 开」。12 本刊上午那期已经把这个开关的接线写全，今天这条只是官方确认。#7536 一张 9 月的 PR 在北京 12:33 由作者本人评论后关闭，没有合并，也没进任何版本。13codex2api 的
#815 是一张提问：上游接 New API 中转站时，成本列的余额显示成无效值，问是上游 API 的问题还是软件 bug。开在北京 11:53，零评论、零答复。14 这张单没有结论，本刊不作推断。四仓与上游现状
| 仓库 | 当前版本 | 主干头（北京） | 窗口内相关条目 |
|---|---|---|---|
| CLIProxyAPI | v8.0.38（10-21 23:06） | dev 10-22 11:55、main 10-21 23:04 | #6853、#6856、#6857、#6844、#6846 |
| sub2api | v0.2.17（10-16 12:41） | main 10-22 10:33 | #8287、#8286、#8275、#7536 |
| codex-proxy | v2.1.20-beta.0543eaa | dev 10-21 09:58 | 0 |
| codex2api | v3.1.1 | main 10-21 01:01 | #815 |
上游那边，OpenAI 状态页仍是 Partial System Degradation，Responses 与 Conversations 标着降级。那条事件开在北京 10:18，10:42 转 monitoring，到发稿没有新更新。18
重置信号：今天 UTC 还没重置，最近一次已验证的全局重置在 47 小时前（北京 10 月 20 日 14:33），累计 56 次全局、10 张存着，24 小时概率 22%、48 小时 39%。21 另一家记的是 64 次、中位间隔 3.1 天、最长 68 天。22
今天要做的三件事
- 查一下你的
upstream.codex.stream-bootstrap-buffering是 true 还是 false。true 且撞过「客户端直接收到容量拒绝」的，v8.0.38 上无解，要么等下一版，要么自己构建 dev。 - Gemini 走 Claude 兼容通道的，翻一眼日志里
retry n/5的分布。出现签名降级之后再吃瞬时错误的请求，今天只剩 3 次同号机会；PR #8287 合并后再按上游情况调max_same_account_retries_gemini。 - 冷却被清这件事，故障期间别动 auth 目录里的凭证文件，也别重载配置——每一次扫描都会重新应用一份磁盘快照。已经踩过的，dev 上那笔 d5816d5e 就是解药。
References
- 1
- 2
- 3
- 4CLIProxyAPI 发行版
github.com
- 5feat(gemini): 同账号重试次数改为可配置 · #8287
github.com
- 6
- 7
- 8
- 9config.example.yaml 第 388–394 行（v8.0.38）
github.com
- 10
- 11
- 12#6857 维护者答复
github.com
- 13#7536
github.com
- 14#815 上游为 New API 中转站时无法正确获取账号余额
github.com
- 15sub2api 发行版
github.com
- 16codex-proxy 发行版
github.com
- 17codex2api 发行版
github.com
- 18OpenAI 事件 01M5GPE9C4E19HE461P8JAMYXD
status.openai.com
- 19Claude Status
status.anthropic.com
- 20Google Cloud incidents
status.cloud.google.com
- 21codex-reset.com
codex-reset.com
- 22opentherank Codex Reset Tracker
opentherank.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.