Pro 号 Argon 用满，Flash 也被跳过：sub2api 多写了一把家族冷却键
sub2api 在写模型级冷却时会同时写一把整族 Gemini 的键，Pro 号的 Argon 用满后，同一张凭证上的 Gemini 3.8 Flash 也跟着被跳过；本期把两把键、调度判定、今晚可用的两条处置路径和修复进展逐条落到行号。
10 月 28 日 15:15（北京），有人在 sub2api 提了一张单（#8393）：Pro 账号的 Gemini 4 Argon 额度用满之后，同一个账号上的 Gemini 3.8 Flash 请求也开始被跳过1。
10 月 29 日 03:47（北京），另一位用户沿着当前主干把调度路径核了一遍，给出候选根因：写冷却的时候，代码同时写了两个键——精确模型名，和整族 Gemini 共用的一把
antigravity:gemini2。这一期的重点，就是那第二把键。
本期覆盖北京时间 10 月 29 日 03:30 到 06:25。四个仓库在这段时间都没有新版本：CLIProxyAPI v8.0.46（10 月 28 日 19:01 发布）3、sub2api v0.2.19（10 月 28 日 18:16）4、codex-proxy v2.1.21（10 月 28 日 04:33）5、codex2api v3.1.2（10 月 28 日 04:39）6。
先认现象：一张凭证上，两个模型一起停
报障人把两种套餐的额度关系写得很具体：Pro 账户的 Gemini 4 Argon 额度是独立的，Ultra 账户的 Gemini 4 Argon 和 Gemini 3.8 Flash 共用一个池子。
他遇到的情况是：当这张 Pro 号的优先级高于站内 Ultra 号时，Argon 一用完，后续所有 Gemini 3.8 Flash 请求都会跳过这张 Pro 号。
这两个模型在同一个套餐层级里的额度关系不同，代码却按同一套冷却处理，问题就出在这里。
回复这条单的人做了三件事：核到写键的条件、核到查键的条件、核到订阅档位没有进入调度快照。他自己注明，只做了代码结构分析，没有在本地跑出复现，也没有提交修复。
冷却键是在哪一行多写出来的
modelRateLimitKeysForRequest 返回的是「这次请求要查哪些键」的列表。函数先按账号的模型映射拿到 modelKey，Antigravity 账号再经 resolveFinalAntigravityModelKey 落到最终模型名，然后以这一把键起一个切片7。接着是一个 switch。Antigravity 分支第 83 行到第 84 行写着：模型是 Gemini、且不是 Gemini 图片模型、且本身不等于家族键时，往切片里再追加一把
antigravity:gemini。
backend/internal/service/model_rate_limit.go 第 66–92 行。第 80 行是只有精确模型名的那个切片，第 83–84 行的三条件里，!isAntigravityGeminiImageModel 是唯一的例外口子，所以图片模型不继承家族冷却，文本模型继承。7同一个 switch 里还有两段形状一样的：OpenAI 平台的
openai:image-generation、Anthropic 平台的 Fable 家族键。三处写法一致，说明家族键是这套冷静机制的统一设计，落到哪一类模型就继承哪一类。写库那一侧用的是同一个条件。
antigravityModelRateLimitKeys 第 162 到 173 行，同样是「先放精确名，再在三个条件都满足时追加家族键」8。setAntigravityModelRateLimits 拿到这两把键之后，用 for _, key := range keys 逐个写库，每个键各调一次 setModelRateLimitByModelName，再刷一次账号的限流缓存9。
backend/internal/service/antigravity_gateway_retry.go 第 881–898 行。第 885 行一次取回全部键，第 891 行的循环让每个键各写一条限流记录，第 893 行同步刷缓存；写两条和写一条走的是同一段代码，没有「只写精确名」的分支。9什么情况会走到这里：上游回了可解析的重试信息，并且
retryDelay 大于等于 7 秒（antigravityRateLimitThreshold），代码就直接限流这个模型、不再重试；上游没给 retryDelay 时按 30 秒算10。判定函数在 antigravity_gateway_retry.go 第 1053 到 1082 行11。调度那一步只问一句：有没有命中任一键
选号时看的是
IsSchedulableForModelWithContext。前两句依次拦：账号整体不可调度就返回 false；本次请求的键命中任一条限流记录也返回 false12。命中之后只剩一个例外：Antigravity 账号、开了超量请求、并且积分还没耗尽，才放行。
查键的那一侧是
isModelRateLimitedWithContext，它遍历请求对应的每一把键，命中任意一把就判为限流13。
backend/internal/service/antigravity_quota_scope.go 第 37–52 行。第 44 行这一句是分水岭：家族键一旦写进 model_rate_limits，任何非图片 Gemini 请求都会在这里被判 false；第 46 行是全函数唯一的放行例外，条件同时要求 Antigravity 平台、开了 overages、积分未耗尽。12把这两段接起来，Argon 那次 429 的后果就清楚了：它写下的家族键，会让接下来所有非图片 Gemini 请求在这一句上返回 false，而不是只挡住 Argon。
Pro 与 Ultra 的差别，进不了选号阶段
新版本其实拿到了套餐档位。额度探测走
LoadCodeAssist，会把 tier 归一成 ULTRA、PRO、FREE、UNKNOWN 之一，再连同逐模型的 antigravity_quota 一起写进用量信息1415。问题在下一站：调度快照在投射账号时只搬一张白名单里的键，逐模型的额度表和订阅档位都不在这张表里16。
backend/internal/repository/scheduler_cache.go 第 1245–1262 行。第 1251 行与第 1255 行是全部被搬进调度快照的键，plan_type 在列，antigravity_quota 与 subscription_tier 不在列。选号侧想按 tier 区分 Pro 与 Ultra，先得让这两个字段到达这一层。16这条家族规则是有测试的。仓库里有一条用例专门断言「图片模型不继承家族限流」：三个 Gemini 图片模型期望未被限流，
gemini-3-flash 期望被限流17。
backend/internal/service/model_rate_limit_test.go 第 258–281 行。第 271–273 行三个图片模型断言未被限流，第 274 行断言 gemini-3-flash 被限流；用例名字就写着 ImageDoesNotInheritGeminiFamilyLimit，说明「文本模型继承、图片模型不继承」是被写进预期的行为。17所以家族键本身有它的道理：两个模型真共池的时候，其中一个见底，另一个也确实还能打，先挡住更省事。
按报障人给出的额度关系推下去，Pro 的 Argon 独立，家族键就变成了跨界扣分——Argon 的冷却被算到了 Flash 头上。这一步是推断，也是 r266-tech 不肯直接删掉家族键的原因：删了会破坏 Ultra 那种真实共池的语义。
今晚能把号放回来的两条路
第一条是清状态。
POST /api/v1/admin/accounts/:id/clear-rate-limit 这一组里，清限流那条走 ClearRateLimit：先清账号的限流时刻，再清 Antigravity 的额度作用域，然后清整张 model_rate_limits，最后连临时不可调度一起清掉1819。代价要提前知道：Argon 自己那条合法的冷却也一起没了。如果上游那边确实还没恢复，下一个 Argon 请求会重新把两把键写回来。
清错误状态那条接口做的是同一套清理（还多清一次错误信息），面板上的批量入口是
batch-clear-error21。这条路适合「今晚就要把 Flash 跑起来、且这个号还有积分」的情况。
不要做的三件：重新登录、换 API key、删凭证重建。
model_rate_limits 存在账号 extra 里，能删掉它的只有上面那两个清理函数；重登只换令牌，那张表原样留着。修复进展：只有代码结构分析，没有补丁
#8393 目前仍是打开状态，没有标签，只有那一条回复。回复人明确写了两件事：他没有提交修复；他在等维护者确认边界，即「Pro 的 Argon 冷却不影响 Flash，Ultra 的共享池仍共同冷却」，以及是否接受把订阅档位纳入调度快照。
这条回复是北京时间 03:47 发的，到现在两个多小时，维护者那边还没有表态。
想让这个行为变，改的落点在调度快照的投射和额度写入两侧，属于改代码，改配置绕不过去。
同一窗口的另外两件事
CLIProxyAPI 的 #7088 在 03:58（北京）开出来，诉求是给
websockets: true 的 Codex 凭证加一个开关，让它们也能用 websocket 执行器去服务 HTTP 下游请求；作者自测固定开销 websocket 1.2 秒、HTTP 2.1 秒24。这件事在 v8.0.46 里由执行器的入口决定：
DownstreamWebsocket(ctx) && codexWebsocketsEnabled(auth) 两个条件都成立才走 wsExec，否则落到 httpExec25。
internal/runtime/executor/codex_websockets_executor.go 第 74–98 行。Execute 与 ExecuteStream 两个入口的写法一致：第 78 行与第 91 行都要求下游本身是 websocket，第 84 行与第 97 行才回落到 HTTP 执行器。凭证上的 websockets: true 只决定第二个条件，决定不了第一个。25这条单目前零评论、没有标签。上一期写过的同一诉求范围更宽，这次收窄到了 opt-in 一个开关。
PR #6715 在 03:50（北京）有一次更新，内容是把这个分支的 dev 合了进来，没有新实现；它仍是打开状态，73 个文件、+6116 −38926。
v8.0.46 的管理端 oauth/auth-url 里，
codex 走的仍是浏览器回调那条路，flow=device 只对 xai 等少数 provider 开放27。要等设备码登录，还是得等这张单。上游与社区
Anthropic 那条 Google Calendar 连接器报错的事件在 20:05（UTC）结案，影响等级 minor。结案说明里的真实影响窗是从 10 月 26 日 11:07（UTC）到 10 月 28 日 18:52（UTC），换成北京时间是 10 月 26 日 19:07 到 10 月 29 日 02:52，比事件开单时间早了两个多小时28。
重置侧没有新信号。追踪站今天没有已验证的全局重置，最近一条信号已经过期，几条官方预告都还停在未验证状态31。
社区这一轮扫得比较全，没有额度或封号类的新帖。Antigravity 官方论坛窗口内三条：一条 v2.6.0 评审流程回归（04:46）32、一条卡在 working（05:26）33、一条上游回的 400 INVALID_MEDIA（06:10）34。
三条都属于客户端与请求内容，跟额度无关。INVALID_MEDIA 那条可以顺手记一下：它带
error.details[].reason 和 error_number 2011，是内容参数被拒，处理方式是换图换格式，清限流没有用。再往前两个小时还有一条值得留意的：一位用 Jio 促销档拿到 Google AI Pro 的用户在论坛问，为什么 Antigravity 里看不到 Gemini 4 Argon 的下拉项，清缓存、重置引导、重新登录都试过（北京时间 10 月 29 日 01:43，在本次窗口之前）35。
这条讲的是授权档位，跟这一期的冷却键是两件事，放在一起看能说明 Pro 这一档在 Argon 上的边界确实比较杂。
OpenAI 官方开发者社区的 Codex 分区窗口内没有额度类新帖，最新一条是旧会话如何分辨 Codex 与 Chat（06:16）36。Reddit 三个板块（ClaudeAI、OpenAI、GeminiAI）窗口内十来条，全是 Gemini 4 Carbon 的讨论、客户端改版吐槽和梗图。
今晚三步
先查这张号的
extra.model_rate_limits。里面同时出现精确模型名与 antigravity:gemini 两把键，就对上这一期说的病；只有一把，问题在别处。要马上放回来，就调
clear-rate-limit（整张限流表一起清，Argon 的冷却也没了），或者给这张号开 allow_overages（走积分，积分耗尽会写 5 小时标记）。剩下的等 #8393。维护者确认边界之后才有针对性补丁，在那之前每次 Argon 见底都会重演一遍。
References
- 1
- 2issuecomment-6478949603
github.com
- 3CLIProxyAPI Releases
github.com
- 4sub2api Releases
github.com
- 5codex-proxy Releases
github.com
- 6codex2api Releases
github.com
- 7model_rate_limit.go 第 66 行起
github.com
- 8model_rate_limit.go 第 162 行起
github.com
- 9antigravity_gateway_retry.go 第 881 行起
github.com
- 10antigravity_gateway_service.go 第 32 行起
github.com
- 11antigravity_gateway_retry.go 第 1053 行起
github.com
- 12antigravity_quota_scope.go 第 37 行起
github.com
- 13model_rate_limit.go 第 41 行起
github.com
- 14antigravity_quota_fetcher.go 第 113 行起
github.com
- 15account_usage_service.go 第 198 行
github.com
- 16scheduler_cache.go 第 1245 行起
github.com
- 17model_rate_limit_test.go 第 258 行起
github.com
- 18routes/admin.go 第 403 行起
github.com
- 19ratelimit_service.go 第 2183 行起
github.com
- 20account_repo.go 第 2665 行起
github.com
- 21admin_account.go 第 1318 行起
github.com
- 22account.go 第 2168 行起
github.com
- 23antigravity_credits_overages.go 第 16 行起
github.com
- 24
- 25codex_websockets_executor.go 第 74 行起
github.com
- 26
- 27auth_files_v8.go 第 119 行起
github.com
- 28Elevated errors affecting the Google Calendar connector
status.claude.com
- 29OpenAI Status summary
status.openai.com
- 30Google Cloud incidents
status.cloud.google.com
- 31codex-reset
codex-reset.com
- 32Regressed Review Workflow in v2.6.0
discuss.ai.google.dev
- 33Antigravity is stuck on working
discuss.ai.google.dev
- 34INVALID_MEDIA error
discuss.ai.google.dev
- 35Model Entitlement Issue Gemini 4 Argon missing
discuss.ai.google.dev
- 36community.openai.com Codex
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.