一个模型的 429，把整族 Gemini 锁到今晚 19:54
一次 gemini-2.5-pro 的 429 被 local 放大成整族冷却，Antigravity 号锁到今晚 19:54、客户端只看到没有可用账号；这篇给锁的形成、时长的四种来源，以及今晚三条解除路径的代价。
北京时间今天 16:14，sub2api 上开了一张新单：一次 429，把整族 Gemini 从调度里摘了出去1。
单子里贴了两条记录。14:56:16 请求 gemini-2.5-pro，Google 回 429 QUOTA_EXHAUSTED，带一个重置时刻 19:54:30（北京）。两分钟后请求 gemini-4-argon，拿到的是
No available accounts1。本期覆盖北京 15:48 到 17:15。这段时间四个仓库没有新版本：CLIProxyAPI v8.0.47（10 月 29 日 08:27 发布）、sub2api v0.2.19（10 月 28 日 18:16）、codex-proxy v2.1.21（10 月 28 日 04:33）、codex2api v3.1.2（10 月 28 日 04:39）2345。sub2api 主干停在 02:44:47（UTC）。
两把键是同一个函数写出来的
backend/internal/service/model_rate_limit.go 第 162–172 行。第 168 行是那三个条件，-image 是唯一的例外口；第 169 行把家族键追加进同一个切片，写库时两个键会拿到同一个截止时刻。6所以「一个模型被限」和「整族被限」在这套代码里是同一件事。图片模型（名字里带
-image）不继承这把键，这是唯一的例外。锁多久，看上游那句话
截止时刻不是拍脑袋算的。写键时用的是
time.Now().Add(rateLimitDuration)，而这个时长直接来自上游响应里的重试延迟；只有拿不到延迟时才退回 30 秒的默认值7。
backend/internal/service/antigravity_gateway_retry.go 第 142–152 行。第 142 行取上游给的时长，第 149 行把它加到当前时间上，第 150 行带着这个时刻去写键——一次请求的等待时间，变成了整族模型的冷却截止。7时长有两个来源，差别很大。模型限流那条读
RetryInfo.retryDelay，没有上限，上游给多久就是多久。429 的兜底那条按顺序试四种：quotaResetDelay、RetryInfo.retryDelay（这一支被压到 15 分钟）、正文里的 Please retry in Xs、以及「每日配额」字样（按洛杉矶时间算到次日零点）；四种都拿不到，才用默认值10111213。
backend/internal/service/gemini_messages_compat_service.go 第 3293–3314 行。第 3293 行读 quotaResetDelay，第 3306–3308 行把 RetryInfo 里的延迟压到 15 分钟，其它分支不压。同一个 429 走不同的路，锁的长度能差两个数量级。11这次锁到 19:54:30，从 14:56:16 算起差 4 小时 58 分。它不是整点也不是洛杉矶零点，所以走的不是每日配额那一支，是上游给的一个很长重试延迟。
单子里没写是哪条路写的键。两条路都会把同一个截止时刻写进两把键，这点没有区别。
客户端看到的是「没有可用账号」
调度那一步只问一句：这次请求对应的键里，有没有任意一把还在生效14。
命中就不可调度，全函数只有一个例外：Antigravity 账号、开了超量请求、积分还没耗尽。三条件缺一不可14。
当池子里只剩这一张号时，候选集被清空，客户端拿到的是 503 与
No available accounts，不是 42915。报障人另有一句值得记下：Antigravity 客户端里看到额度还很多。他给的解释是客户端显示的是官方 baseline，而这次 429 是运行时的逐模型窗口，两者不是同一套口径。
今晚三条路，按代价排
第一条，等。 19:54:30 到点自动过期。重启、重登、换 API key 都不清，因为这些键存在账号的
extra.model_rate_limits 里，清它的是清理函数而不是令牌刷新6。第二条，开
allow_overages。 429、分类为配额耗尽、账号开了这个开关、积分又没耗尽，四条同时成立时，请求会先在原地换成积分重试一次；成功就把积分耗尽的标记清掉，不会走到写家族键那一步1617。
backend/internal/service/antigravity_gateway_retry.go 第 118–131 行。第 120–123 行是那四个条件，第 124 行发起积分重试。这条分支排在写冷却键之前，所以在它成功时，家族键根本不会出现。16代价是这场对话走 AI Credits；真把积分用光，代码会在同一张表里写一个
AICredits 键，冷却 5 小时18。第三条，清表。
POST /api/v1/admin/accounts/{id}/clear-rate-limit 会按顺序清账号限流、Antigravity 的配额作用域、整张 model_rate_limits，最后连临时不可调度一起清1920。起作用的是那句
extra - 'model_rate_limits'——整张表一起删，精确键和家族键都不剩21。代价要提前知道：这张号本来合法的模型冷却也一起没了；上游真没恢复，下一个请求会把两把键重新写回来。
面板里没有「只删一把键」的入口。要单独删，只能手工改
extra，风险自负。修复状态：主干一字未动
仓库里还有两条单测明确断言这个行为：一条断言 Gemini 文本模型会写家族键，一条断言图片模型不写。换句话说，这不是漏改，是写进预期的设计24。
想让它变，得改代码。报障人给的方向是：对 QUOTA_EXHAUSTED 只冷却上游点名的那一个模型，或者等官方配额接口确认整族都耗尽时才写家族键——这一句是他的主张，不是仓库里的结论。
同窗口：上游把 capacity 拒在账号上
今天 16:43，openai/codex 上开了一张单：所有 Codex 模型都报
Selected model is at capacity，同一台机器、同一个客户端版本，换成另一个 Pro 100 美元的号就正常25。
对中转的好处是它给出了一条便宜的判据：看到
at capacity，先换一张号试一次。换号就好，说明容量拒在账号上，别急着去冷却某个模型；换号一样报，才轮到模型容量。这一条与上面那张 sub2api 的单正好相反：一个把单模型的拒绝放大成整族，另一个本来就是账号级、只是长得像模型级。
同窗口：连接复用的两张单
CLIProxyAPI 上今天出现两张想复用上游连接的 PR，一张还开着，一张开了 25 秒就没了。
开着的是 #7101：10 月 29 日 15:40（北京）开，30 个文件 +2136，状态 clean，做法是给 api-keys 的每个凭据配一个可选连接池，键名
connection-pool，默认不写就是不启用28。没了的是 #7116：今天 16:20:49 开，16:21:14 由作者本人关闭，5 个文件 +1250，改的是 uTLS 那一层29。
关单之后 8 分钟，自动评审跑完了，留了一条 P2：被缓存的连接池没有把
CloseIdleConnections 转发下去，调用方清理空闲连接时它收不到，只能等缓存淘汰29。今晚没有可做的事：v8.0.47 里没有
connection-pool 这个键。以后真开了，记得把空闲超时设得比上游的静默断连短。边栏：codex-proxy 的合并策略
codex-proxy 今天 16:55 开了一张文档单，17:08:59 合进 dev：往
dev 或 main 的 PR 一律用 squash 合并，禁止普通 merge 与 rebase merge，1 个文件 +530。只对维护自己 fork、又想把补丁提回去的人有意义：历史会被压成一个提交，分笔提交的痕迹留不住。
上游与社区
OpenAI 状态页全绿，没有活动事件，最近一条是 10 月 27 日的 6.1 Sol 降速31。Anthropic 最近一条是 10 月 28 日的 Google Calendar 连接器报错，已恢复32。Google Cloud 事故表八条，最新一条的更新时间停在 10 月 28 日33。
重置侧今天没有新动作。codex-reset 首页写着今日 UTC 未重置，最近一次已验证的全局重置在 10 月 28 日 14:35（北京），累计 61 次、10 次未用34。opentherank 的口径是 69 次、中位间隔 2.9 天，最新记录落在 10 月 28 日 14:2935。两家数字不一致是常态，引用时各按各家的标签写。
社区窗口内只有一条弱信号：r/GeminiAI 有人自述买了 Ultra x20，单条消息还是被 Gemini 判到上限、对话直接截断，没有对照实验36。Google 官方论坛窗口内没有额度类新帖，最近两条是运营商拦截短信验证与 Antigravity 认不到积分，都在本期窗口之前。
今晚三步
第一步，查这张号的
extra.model_rate_limits。里面同时有精确模型名和 antigravity:gemini、截止时刻一样，就是这一期说的病；只有一把键，问题在别处。第二步，按代价选一条：能等到截止时刻就等；这张号还有积分、又急着用，就开
allow_overages；要立刻放回来，就调 clear-rate-limit，但要接受合法冷却一起消失。第三步，把单子 #8439 记下来。它现在零标签、一条关联回复，主干也还没动，下次同一个模型见底，这一幕还会重演。
References
- 1Gemini 单次429把整个帐号给冷却
github.com
- 2CLIProxyAPI Releases
github.com
- 3sub2api Releases
github.com
- 4codex-proxy Releases
github.com
- 5codex2api Releases
github.com
- 6model_rate_limit.go 第 162 行起
github.com
- 7antigravity_gateway_retry.go 第 142 行起
github.com
- 8antigravity_gateway_service.go 第 28 行起
github.com
- 9antigravity_gateway_retry.go 第 1049 行起
github.com
- 10ParseGeminiRateLimitResetTime 第 3277 行起
github.com
- 11parseGeminiRetryDelayResetTime 第 3287 行起
github.com
- 12geminiRetryInfoMaxDelay 第 48 行
github.com
- 13geminiQuotaLocation 第 429 行起
github.com
- 14antigravity_quota_scope.go 第 37 行起
github.com
- 15gateway_handler.go 第 423 行
github.com
- 16antigravity_gateway_retry.go 第 118 行起
github.com
- 17IsOveragesEnabled 第 2168 行起
github.com
- 18antigravity_credits_overages.go 第 14 行起
github.com
- 19routes/admin.go 第 403 行起
github.com
- 20ClearRateLimit 第 2183 行起
github.com
- 21ClearModelRateLimits 第 2672 行
github.com
- 22model_rate_limit.go 主干同名文件
github.com
- 23sub2api 开放 PR 列表
github.com
- 24model_rate_limit_test.go 第 258 行起
github.com
- 25
- 26同症状旧单 57447
github.com
- 27
- 28
- 29
- 30
- 31OpenAI Status
status.openai.com
- 32Claude Status
status.claude.com
- 33Google Cloud incidents
status.cloud.google.com
- 34codex-reset
codex-reset.com
- 35opentherank codex reset
opentherank.com
- 36Gemini stops working
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.