dev 比 v8.0.53 多出 11 笔：模型发现刚搬进 sdk/auth，17 分钟后补了两处保护
这一小时四仓零发版，但 dev 上动了两处：CLIProxyAPI 把 Antigravity 模型发现搬进 sdk/auth，合并 17 分钟后补上克隆与 nil 守卫；sub2api 开出一张把异常流收尾改成 502 的补丁。两条都还没进发行版。
过去 55 分钟里，四个中转实现一个新版本都没发。CLIProxyAPI 把 Antigravity 的模型发现整块搬进
sdk/auth，合并 17 分钟后又在 dev 上补了两处保护。sub2api 开出一张还没合的单，专门修「上游流异常收尾却被写成正常结束」。这个窗口的时间线
| 北京时间 | 动作 | 现在的位置 |
|---|---|---|
| 10:46 | CLIProxyAPI PR #7238 开出，把 Antigravity 模型发现下沉到 sdk/auth | 2 提交、3 文件 +586/−1881 |
| 11:01 | #7238 合并进 dev（cbf0188） | 未随任何发行版发出1 |
| 11:03 | sub2api PR #8510 开出，修异常流被写成正常结束 | open、基于 main、6 文件 +465/−9、零评论2 |
| 11:18 | dev 打补丁 0e02765：克隆模型 ID、保留 nil 未知目录 | 2 文件 +27/−13 |
搬了什么
「模型发现」指的是拿账号的 access token 去问
daily-cloudcode-pa.googleapis.com 的 /v1internal:fetchAvailableModels，这个号到底能用哪些模型。这段逻辑原先住在 sdk/cliproxy/antigravity_models.go，v8.0.53 里那个文件 891 行。单看文件挪位置像是整理代码。真正的变化在下面两节的语义上。
探测三态与「nil 不等于空」
sdk/auth/antigravity_models.go 第 30–50 行：探测状态只有成功、鉴权错误、瞬时错误三态；第 42 行那句注释把「未知」与「确认没有」在类型层面分开。4AntigravityProbeStatus 只有三态：成功、鉴权错误、瞬时错误。探测不再靠「有没有拿到模型」这种布尔判断。更要紧的是
ModelIDs 上那行注释：Nil means unknown; an empty non-nil set is an authoritative empty catalog. 未知目录是 nil，真的一个模型都没有是空集。一个 nil 的 map 和一个空 map 在 Go 里都能被
range，都能返回长度为 0。这行注释是要求所有调用方把它们当两种结果处理。探测失败时保留上次成功的表
sdk/cliproxy/antigravity_models.go 第 329–345 行：只有「成功且 ModelIDs 非 nil」才覆盖缓存；其余保留上次成功并拉长抖动退避。5覆盖缓存的条件是两个一起成立：
status == antigravityProbeStatusSuccess && hints.ModelIDs != nil。少一个都不写。不满足就走下面那条：注释写「Missing models … are not a successful catalog. Preserve last success and increase the jittered backoff.」，保留上次成功的表，只把重试间隔按抖动拉长。
按这段写法，一次探测抖动只会让这个号晚点再探，面板上的模型表不会被清空。旧位置那版是怎么处理的，这轮没有逐行核对。
17 分钟后补的两处
11:18 那笔
0e02765 的标题是 fix(auth): clone parsed model IDs and preserve nil unknown catalogs，2 文件 +27/−1，真正的代码只动 6 行3。第一处是
NormalizeAntigravityModelID 的返回值改成 strings.Clone(trimmed)。第二处是 BuildPersistedAntigravityCapabilityHints 开头多了 if hints.ModelIDs == nil { return nil }。
sdk/auth/antigravity_models.go 第 214–228 行：第 215 行注释写明「未知目录永远不会被当作权威空集落盘」，第 217–219 行就是那道 nil 守卫。6为什么需要 Clone？这版把 JSON 操作换成了零拷贝的
ojson（同 PR 的第二笔提交）7。零拷贝拿到的模型名字符串是指向响应缓冲的切片。缓存 map 一直留着这些字符串，也就一直留着整块缓冲，上限在同文件里写着
8 << 20。这条因果是从两笔提交一起看出来的，提交说明里没写。写在这里的价值是：如果你在 dev 上跑过一版，内存曲线会告诉你这个推断对不对。
对在跑版本的影响
所以升级到最新发行版拿不到 #7238。v8.0.53 用的是标准
encoding/json，每条模型名都是新分配的字符串，上面那条驻留问题在它身上不成立。顺带一提 #7233：还开着、带 Fixed 标签，修复提交
606e667a 停在 dev，不在 v8.0.53 里。11:31 有人在该单下面问「什么时候能升到含这个修复的版本」，暂时没人回9。sub2api #8510：异常收尾不能写成正常结束
#8510 表头写
Fixes #8505，基于 main，6 文件 +465/−9，一个提交，零评论、未合并2。它改的是 Antigravity 兼容流的收尾判定。原代码遇到
MALFORMED_FUNCTION_CALL 只打一行日志，然后照常调 emitFinish，而 emitFinish 的 stopReason 默认是 end_turn。结果是客户端看到一条「正常说完」的响应，账单照记，真实原因只留在服务端日志里。
三类判据
Finish() 里对异常收尾与截断的两处提前返回，第 189–191 行才是正常补终局事件。10MALFORMED_FUNCTION_CALL、UNEXPECTED_TOOL_CALL、TOO_MANY_TOOL_CALLS 三个值归为异常收尾。STOP 但只有思考内容、没有可见输出，标成 thinking_only_response。流结束时
finishReason 为空且没有任何可见输出，标成 upstream_stream_truncated。前两类在 Finish() 里直接返回，不再补终局事件。三种出口
malformed_function_call 额外标成请求级瞬时故障，并把下一账号动作设成 stop。11客户端已断开：只把 usage 交回去，不写任何事件。
还没往客户端写过一个字节：抛异常失败错误，502、
RetryableOnSameAccount: true，同号重试或换号都行。已经写出去过：发一帧 SSE error，标记响应已提交，然后继续把上游收干净。
malformed_function_call 这一种额外标 RequestScopedTransient 并把下一账号动作设成 stop。作者的理由是这类坏请求不该拿去污染下一个号。保留的行为
这次不动默认
max_tokens，也没把 #7899 的空流与请求历史改动一起带进来。作者说四组回归在原 base
4a4a83ee5 上都失败、打上补丁后通过。v0.2.19 仍在犯这个问题
MALFORMED_FUNCTION_CALL 那一支只到日志为止。Finish() 在拿不到 finishReason 时也会走一次 emitFinish("")。所以这个窗口里，跑 v0.2.19 的中转站遇到上游畸形工具调用，客户端收到的仍是正常结束。
队列上还压着的几条
#8509（手动与自动刷新时强制拉上游额度）25 文件 +1903/−242，状态是不能自动合并，替代作者误关的 #850713。
#8508 开在北京时间 10:01，零评论、维护者没回14。报障人的说法是 Claude 取消 Ultra 的 5 小时限额之后，setup-token 授权的账号取不到真实的 7d 额度。这是报障人单方面的描述。
#8505 那条原始缺陷还开着，没有标签15。
版本位与上游
| 仓库 | 当前发行版 | 发行时间（北京） | 主干位置 |
|---|---|---|---|
| CLIProxyAPI | v8.0.53 | 11-03 20:27 | main 与 tag 同为 01b24f1f，dev 到 0e02765c16 |
| sub2api | v0.2.19 | 10-28 18:16 | main 为 4a4a83ee17 |
| codex-proxy | v2.1.23 | 11-03 19:35 | dev 有未发布提交18 |
| codex2api | v3.1.3 | 11-04 10:22 | main 为 20e4b399，上一期已覆盖19 |
上游三处都在正常水位。OpenAI 状态页全绿，最近一次事故是 11-03 的文件上传报错，北京 08:46 到 13:39 之间，已恢复20。
Codex 额度重置这边没有新承诺。追踪站首页写着今天 UTC 还没重置，最近一次已验证的全局重置在 7 天前，即 10-28 14:35 北京23。
今晚可以做的三件事
- 别为了 #7238 升级。它还没进任何发行版，v8.0.53 上模型发现仍走旧路径。
- 跑 v0.2.19 的，先量一下手上的量。判据很简单：客户端收到
end_turn的会话里，服务端日志有没有同时出现[Antigravity] MALFORMED_FUNCTION_CALL。两者同现就是 #8510 描述的那条。 - 想要 #7233 那个修复只能在 dev 上跑。等版本时盯发行页就够。
References
- 1CLIProxyAPI PR #7238
github.com
- 2sub2api PR #8510
github.com
- 3CLIProxyAPI 提交 0e02765
github.com
- 4CLIProxyAPI dev 分支 antigravity_models.go
github.com
- 5
- 6CLIProxyAPI dev 分支 antigravity_models.go
github.com
- 7CLIProxyAPI 提交 f49bd5d
github.com
- 8CLIProxyAPI v8.0.53...dev 对比
github.com
- 9CLIProxyAPI issue #7233
github.com
- 10
- 11
- 12sub2api v0.2.19 stream_transformer.go
github.com
- 13sub2api PR #8509
github.com
- 14sub2api issue #8508
github.com
- 15sub2api issue #8505
github.com
- 16CLIProxyAPI v8.0.53
github.com
- 17sub2api v0.2.19
github.com
- 18codex-proxy 发行页
github.com
- 19codex2api v3.1.3 发行页
github.com
- 20OpenAI 状态页
status.openai.com
- 21Anthropic 状态页
status.anthropic.com
- 22Google Cloud 状态页
status.cloud.google.com
- 23codex-reset 现状
codex-reset.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.