10/17 凌晨速报：Gemini 流式断开不计费、分组生图开关从未生效、Vertex 账号不累计费用——三张修复同一分钟开出，都还没合并；另有一个今晚就能起来的用量伴随工具
10 月 17 日北京 00:31 到 01:37 这 66 分钟里四个仓库都没发新版本：sub2api 在 01:12 到 01:14 之间开出三张修复，补的分别是 Gemini 流式断开不计费、分组生图开关对 Gemini 入口失效、Vertex 账号不累计费用这三处会让你看错账的口径漏洞，都还没合并；CLIProxyAPI 多了一个今晚就能拉起来的用量伴随工具，Antigravity 客户端版本缓存那条刚过审。
北京 00:31（上一期刊出时刻）到 01:37 这 66 分钟里，四个仓库都没有发出新版本。
四个仓库的主干在本窗口也没有新提交。窗口里出现的六条东西全部还停在仓库内部，没有一条进发行版。
今晚要当场拿定主意的是三件事。sub2api 在 01:12 到 01:14 这三分钟里开出三张修复，补的是三处会让你看错账的口径漏洞，都还没合并。
CLIProxyAPI 多了一个只在终端里跑的伴随工具，今晚就能拉起来看每次请求落到哪个账号、那张凭证还剩多少额度。
还有一条 Antigravity 客户端版本的缓存修复刚过审，正在等合并。
一、Gemini 系流式请求中途断开时，这段用量一直不计费
它是 1 个提交、4 个文件 +359/−29，base 是 main，head 是
feeeei:fix/gemini-stream-client-disconnect-billing5。它要补的口子是这样的。Gemini 原生
/v1beta、/v1/messages 兼容、/v1/chat/completions 兼容这三条流式路径，遇到客户端中途断开时会直接按错误返回，已经解析到的那份 usageMetadata 被丢掉，这次请求就此不计费5。客户端收到
finishReason 之后立刻关连接，结果一样5。本刊在读者手上这一版核到了同一处死值。v0.2.17 的
backend/internal/service/gemini_chat_completions_compat_service.go 第 304 行写的是 ClientDisconnect: false，这条路径从来不把自己标记成断连6。它要求三件事同时成立。第一件是这次读取确实报错了，错误还得是文件没读完的那种（排除
io.EOF）。第二件是断开来自客户端：错误本身是 context.Canceled，或者请求自带的 context 已经取消7。第三件是断开之前已经观测到可计费的输出，也就是
usage.hasObservedTokens() 为真，或者已经回吐过图片7。
backend/internal/service/gemini_stream_client_abort.go 第 11–25 行：第 16 行先排除空错误与 io.EOF，第 19–20 行判是不是客户端走了，第 24 行要求已观测到 token 用量或图片才放行计费7三个条件都满足时，调用方按已收集的结果正常收尾并计费，
ForwardResult.ClientDisconnect 置为 true。断开前一点用量都没有的，仍然不计费5。token 按断开前收到的最后一份
usageMetadata 计，所以读到结束分片之后才断开，拿到的是完整用量7。中途断开时，中间那些分片可能只带输入计数、甚至不带用量，那就按已有的计数计，一条都没有就不计7。
收到
finishReason 之后断开，与正常完成同口径5。原生路径读取出错时还多做了一件事：丢掉末尾那行不完整的数据，防止一段被截断的
usageMetadata 覆盖掉前面已经收好的用量5。作者特意写清了他没做的一件事：不把上游请求与客户端 context 解绑。理由是 Gemini 兼容链路没有流空闲超时，一旦解绑，上游真的挂起时读取会一直阻塞下去5。
今晚没有版本可升，也就动不了手。可以现在就记住现象的形状：如果你在 Gemini 系通道上看到用量统计偏低、或者按请求数对不上账，那可能是本地少记，而不是上游少发。处置账号之前先把这一条列进候选原因。
二、Gemini 系分组的「允许生图」开关，对 Gemini 入口从来没生效
sub2api PR #8167 在北京 01:13 开出，open、非 draft、
merged=false、mergeable_state 为 clean，1 个提交、13 个文件 +585/−48。分组的「允许当前分组生图」这个开关，此前只在 OpenAI 图片接口、Responses 的生图工具、以及 Grok 媒体接口上生效8。
Gemini 系分组的后台一样显示这个开关，但
/v1beta/models、/v1/messages、/v1/chat/completions、/v1/responses 都不查它。关掉之后照样能生图8。本刊在 v0.2.17 上核了一遍调用点，作者的说法站得住。这门禁的函数叫
GroupAllowsImageGeneration，定义在 backend/internal/service/image_generation_intent.go 第 34–37 行：无分组时放行，有分组时看 group.AllowImageGeneration9。它的非测试调用点全部落在 OpenAI 那一侧：
openai_gateway_forward.go 第 343–345 行、openai_ws_forwarder_ingress.go、openai_gateway_passthrough.go、openai_gateway_handler.go、openai_images.go、image_task_handler.go、grok_media.go10。Gemini 的 handler 与 service 里一处都没有。后台那个开关对 Gemini 系分组只是摆在那儿。
修复的边界写得很清楚。门禁只作用于 gemini、antigravity、composite 这三类分组，没有分组的 Key 和其他平台的分组不受影响11。
backend/internal/service/gemini_image_generation_gate.go 第 14–37 行：第 19 行先看分组开关，第 22–26 行用 switch 把门禁限定在三类分组上，第 27 行才进入生图判定11检查发生两次。handler 在选号之前，按客户端请求的模型名和渠道映射名先查一次8。
Gemini 兼容与 Antigravity 的转发层，在账号自己的模型映射做完之后，再按上游模型名查一次8。
作者专门写了为什么用 400 而不用 403：下游 sub2api 把本实例当上游时，收到 403 会把这张账号停用8。
这是本期唯一一条今晚就该去改配置的事。如果你一直靠这个开关拦 Gemini 系分组的生图，它没生效过。
现在能立刻补上的是分组级模型白名单：把名字里带
image 或 banana 的模型从白名单里摘掉，GroupModelAllowlist 中间件会在合成路由改写与调度之前按客户端写的公开模型名拦下，回 40412。它有一个走不到的入口：Responses WebSocket 不走这条中间件，首帧与后续每一轮由 WebSocket 层逐帧校验12。
三、Vertex（service_account）账号此前不累计费用，也设不了配额上限
sub2api PR #8166 在北京 01:12 开出，open、非 draft、
merged=false、mergeable_state 为 clean，1 个提交、18 个文件 +521/−2613。本刊在 v0.2.17 上核到了原因。
backend/internal/service/account.go 第 1381–1384 行的 IsAPIKeyOrBedrock() 只认 apikey 与 bedrock 两种类型14。第 209 行的可调度判定写的是
a.IsAPIKeyOrBedrock() && a.IsQuotaExceeded()，gateway_usage_billing.go 第 140 行与第 544 行同样只认这两种类型。整包搜 SupportsAccountQuota 没有任何结果，这个方法正是这张 PR 新加的。改法是把配额判定从类型判断里拆出来。新增
SupportsAccountQuota()，认 apikey、bedrock 与 service_account 三种13。配额相关的判定——累加、超限后停止调度、额度通知、接口输出——统统改用它。池模式等其他特性仍然只看
IsAPIKeyOrBedrock()，语义不动13。第二个新方法是
AlwaysAccumulatesQuotaUsed()，只有 service_account 为真。这类账号即使一个上限都不设，也会累加 quota_used，账号接口始终返回这个字段；日用量与周用量仍然要设了对应上限才统计13。设了上限之后行为与 apikey 一致：显示进度条、发额度通知、用满之后停止调度13。
前端两处也跟着放开：Vertex 账号的用量列常驻显示累计费用，创建与编辑弹窗里开放配额设置13。
作者单独标出一句要紧的话：存量账号的
quota_used 从升级之后开始累加，升级之前的历史费用不会被补进来13。所以你升级当天打开面板看到的，是一个从零开始攒的数字，它只反映升级之后新产生的费用。
今晚同样动不了手。如果你现在靠 Vertex 账号跑量、想用额度上限止损，这个上限今天在面板上设不了，只能先用别的口径盯着这批账号的消耗。
四、CLIProxyAPI 多了一个今晚就能拉起来的用量伴随工具
它是 1 个提交、3 个新文件 +210/−0，base 是 dev，head 是
kakcil:feature/usage-watch-account-quota15。工具本体是
examples/usage-watch/watch.py。每完成一条代理请求，它打印一行：provider、请求的模型、被选中的账号、token 用量，以及那张凭证最近一次观测到的额度百分比15。同一个 provider 上连续两次请求换了账号时，它另外打一行提示。作者自述这条工具不改路由、不改响应、不改客户端行为，用的全是 v8 已经有的管理端接口15。
跑起来分两步。先打开配置里的
observability.usage.usage-statistics-enabled，v8.0.31 的示例配置里这个键在第 1160 行，默认是 false16。然后在单独的终端里执行
python3 examples/usage-watch/watch.py --key-file <管理密钥文件>。基址默认 http://127.0.0.1:8317，可用 --base-url 改；--provider claude 或 --provider codex 只输出一侧；--once 读一次当前队列就退出。密钥也可以走环境变量 CLIPROXY_MANAGEMENT_KEY17。它调的两个接口在本刊核的这一版里都在。队列是
GET /v8/management/observability/usage/queue，凭证列表是 GET /v8/management/credentials，两条都挂在 v8 的管理端路由上18。额度百分比那几个数字从哪来，作者写在代码里。codex 的凭证读
X-Codex-Primary-Used-Percent 与 X-Codex-Secondary-Used-Percent，claude 的凭证读 Anthropic-Ratelimit-Unified-5h-Utilization 与 Anthropic-Ratelimit-Unified-7d-Utilization19。它用 100 减掉使用率得到剩余百分比，并附一句这个读数是多少秒之前观测到的；读不到就打印
quota unavailable19。
examples/usage-watch/watch.py 第 33–70 行：第 42–44 行取不到任何信号就返回 quota unavailable，第 46–56 行按 provider 分别指定要读哪几个响应头，第 68–71 行把观测时间换算成「多少秒之前」19三个限制必须一起看，它们决定了这个工具的读数能用到什么程度15。
第一，管理端的 usage 队列是破坏性消费，这个 watcher 就是它的消费者，不能再有另一个消费者同时读同一个队列。
第二，一条事件对应一次 API 请求，一个完整的 Claude Code 或 Codex 回合会产生多条记录。
第三，额度值取自 provider 的响应头，可能缺失，也可能过期。它只反映当时那个响应头给出的数字，把它当成还剩多少次提问会看错。
今晚能不能动手：能。它是一个独立的 Python 脚本，用不着等合并，直接从该 PR 的分支取
examples/usage-watch/watch.py 就能跑。跑之前先确认自己那版 CLIProxyAPI 有上面那两个 v8 管理端接口，并且注意它的基分支是 dev。作者自述的验证是三条单测通过、本地 Codex 与 Claude 请求各跑通一次、
CGO_ENABLED=0 编译通过。他没有说自己做过别的东西。这一期前面三条讲的全是本地口径上的漏洞，这个工具正好是把口径看清的那把尺子：你能看到每一次请求究竟落到哪张凭证，以及那张凭证当时的额度读数是什么。
五、Antigravity 客户端版本缓存的修复刚过审，还没合并
CLIProxyAPI PR #6616 创建于 10 月 14 日 18:12（北京），open、非 draft、
merged=false、mergeable_state 为 clean，base 是 dev，2 个文件 +53/−6，到截稿只有 1 个提交20。本窗口里它的变化是拿到一次 APPROVED 评审，时间是北京 01:33，也就是通过了审核、正在等合并。此前 10 月 14 日那次只是自动审查机器人的一行记录，没有人的意见20。
它修的是
internal/misc/antigravity_version.go 里两处独立的缺陷。第一处，
AntigravityLatestVersion() 用 time.Now().Before(antigravityVersionExpiry) 按挂钟时间判断缓存还新不新，而负责刷新的 runAntigravityVersionUpdater 用的是 time.NewTicker——单调时钟在系统休眠时会暂停20。第二处，
refreshAntigravityVersion() 在 TTL 过期之后撞上一次瞬时抓取失败——作者举的例子是刚唤醒、网卡还在重连——会把有效的缓存覆盖成 fallback，于是那句「keeping cached value」在 TTL 一过期就永远走不到20。本刊在 v8.0.31 上把两处旧写法都定位到了。第 88–99 行是刷新函数里那段「缓存为空或已过期就写 fallback」，第 103–113 行是取值函数里那段按挂钟判断的分支21。
同一份文件里还有三个常量值得记住：fallback 版本是
2.23.0（第 23 行），缓存 TTL 是 6 小时（第 25 行），刷新间隔是 TTL 的一半、也就是 3 小时（第 59 行）22。这个缓存值最终拼进 User-Agent，格式是
antigravity/hub/<版本> darwin/arm6423。具体差多少，本刊直接取了那个上游清单：当前版本是 2.24.024。出了故障的长跑实例会把 User-Agent 从 2.24.0 报成 2.23.0。
这跟 Gemini 4 Argon 的关系是直接的。作者在正文里点明，Google Cloud Code 会给新模型抬高最低客户端版本门槛，他举的例子正是
gemini-4-argon-high 要求不低于 2.23.020。掉回 fallback 的长跑实例会一直拿不到新模型，直到下一次 3 小时的能力缓存刷新20。
按本刊量到的两个版本号看，2.23.0 眼下仍压在那道门槛之上，所以今天还不至于立刻失效。风险在于门槛再抬一次：睡过一觉的实例会静默掉队，而面板上不会有任何提示。
今晚动不了手，这条还没合并。能当场判断的是：如果你跑 Antigravity 通道的机器会休眠——笔记本、被挂起的开发机——就把「某个模型忽然不可用」这条也列进候选原因，排查时一并看。
这条本刊此前登记过。10 月 14 日晚间那期已经报过同一张 PR，当时只有一句「Antigravity 客户端版本缓存 TTL 过期掉回内置版本」。本期补上的是两个成因各自的代码位次、当前实际的版本差，以及它刚刚通过审核这个状态。
六、同一窗口里的短条目
sub2api issue #8154 在 01:10 等到了维护者的答复。这单是 10 月 16 日下午开的，主题是「模型厂商越来越多，是不是将模型厂商插件化更合理」25。
维护者
feeeee 的原话是：现在的插件化还比较弱，暂时只支持 OpenAI 的 OAuth 出站部分，用于防止 Codex 账户降智；提问者设想的那种设计，要大改 sub2api 整体架构、改成插桩式才做得到25。另一条评论在 16:13 就写下了「new-api 有这个做法」。
这条单子给你的是一个口径，不是一条路线图：如果你在等多厂商插件化来解决某个具体问题，官方现在的答复是暂时没有，而且要动的是整体架构。
sub2api PR #8141 在北京 00:33 由草稿转成待审。它要修的是 Antigravity OAuth 通道上用
gemini-3.8-flash-high 做多轮工具会话时，上游回一个合法的 functionCall 但整条回答里没有正文26。兼容桥原样转发之后，客户端只看到工具在跑，看不到任何进度说明。作者说加强提示词能改善短会话，但八条工具结果的历史仍然不返回正文，所以他提了一个范围很窄的兼容改法26。
这条目前的动静只是从草稿转成待审，还没有评审意见。
codex-proxy 与 codex2api 在窗口内都是 0 条条目更新，codex-proxy 的预发布版仍然没有占上
latest4。七、上游与额度侧
OpenAI 状态页本轮全绿：All Systems Operational，活动事件 0 条，没有降级的组件27。
最近一条有记录的仍是 10 月 14 日那条 Compliance API 成本数据延迟，它已经在 10 月 16 日 18:44（北京）转正27。
Anthropic 状态页也是 All Systems Operational，10 月 16 日那一栏写着 No incidents reported today28。
Google Cloud 的事件列表仍是 7 条，最近一条仍是 10 月 8 日到 9 日的 Cloud Storage 上传与写入延迟29。
Codex 重置追踪站上，今天（UTC）没有重置。最近一次已验证的全局重置在 35 小时前，即 10 月 15 日 06:13 UTC、北京 14:1330。
累计是 54 次全局、10 次 banked，节奏约每 4 天。它同时给出两套概率：模型口径是 24 小时 18%、48 小时 33%；把它计为「提示」的那一套口径是 24 小时 50%、48 小时 75%30。
被计为提示的是 10 月 16 日中午那条回帖，提示在帖出 60 小时后失效。页面上那个「Announced target time」的倒计时仍挂着，公告区同时写着现在没有官方的重置窗口30。
另一个追踪站记最近一次为 10 月 15 日 04:55 UTC；自 2025 年 9 月以来 62 次，中位间隔 3.1 天，最长等了 68 天31。
官方开发者社区 Codex 分区本轮取到 25 条，最新的一条仍是 10 月 16 日 23:09（北京）那条「Sudden extreme reduction in remaining usage」，窗口内没有新帖32。
Reddit 三个板块窗口内没有额度或风控条目。窗口里沾边的只有三条，都按收录口径不收。
r/GeminiAI 在 00:52 发了一条讲怎么减少 Argon 的 token 消耗，做法落在 IDE 侧33。
八、未闭合项（下期继续跟，不作结论）
- CLIProxyAPI：本窗口登记 #6693，#6616 拿到一次通过评审；继续跟 #6693 会不会被采纳、#6616 通过审核之后会不会并进 dev，以及 #6691、#6690、#6688、#6686、#6682、#6687、#6681、#6683、#6679、#6680、#6676、#6677、#6515、#6675、#6605、#6669、#6670、#6661、#6667、#6659、#6671、#6673、#6625、#6603、#6500、#6169
- sub2api：本窗口登记 #8168、#8167、#8166，#8154 与 #8141 更新；继续跟这三张修复会不会合并，以及 #8165、#8164、#8163、#8161、#8160、#8157、#8158、#8159、#8155、#8151、#8139、#8135、#8136、#8142、#8143、#8146、#8147、#8127、#8125、#8123、#7962、#7398
- codex-proxy：本窗口 0 条；继续跟 v2.1.18 正式版会不会打上
latest - codex2api：本窗口 0 条；继续跟 #793
下期优先回看三条：这三张 Gemini 与 Vertex 的修复会不会合并；#6616 通过评审之后会不会进 dev；#6693 会不会被采纳进 dev。
References
- 1sub2api Releases
github.com
- 2CLIProxyAPI Releases
github.com
- 3codex2api Releases
github.com
- 4codex-proxy Releases
github.com
- 5sub2api #8168
github.com
- 6
- 7
- 8sub2api #8167
github.com
- 9
- 10
- 11
- 12
- 13sub2api #8166
github.com
- 14account.go（v0.2.17）第 1381–1384 行
github.com
- 15CLIProxyAPI #6693
github.com
- 16
- 17watch.py（该 PR 头分支）第 172–205 行
github.com
- 18
- 19watch.py（该 PR 头分支）第 33–70 行
github.com
- 20CLIProxyAPI #6616
github.com
- 21
- 22antigravity_version.go（v8.0.31）第 20–32 行
github.com
- 23
- 24Antigravity Hub 更新清单
antigravity-hub-auto-updater-974169037036.us-central1.run.app
- 25sub2api #8154
github.com
- 26sub2api #8141
github.com
- 27OpenAI Status
status.openai.com
- 28Claude Status
status.anthropic.com
- 29Google Cloud Status
status.cloud.google.com
- 30codex-reset.com
codex-reset.com
- 31opentherank
opentherank.com
- 32社区帖 1406982
community.openai.com
- 33r/GeminiAI 1x7lhnm
reddit.com
- 34r/OpenAI 1x7lpem
reddit.com
- 35r/GeminiAI 1x7lxj2
reddit.com
- 36CLIProxyAPI #6690
github.com
- 37sub2api #8164
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.