sub2api v0.2.19 发出：默认 Gemini 模型表里一个 2.x 名字都没剩下
sub2api v0.2.19 今晚发出：内置 Gemini 默认表里一个 2.x 名字都没剩下，两张迁移启动自动执行，新加的同账号重试只作用于 Gemini 兼容入口；另附智谱限流不换号的两条来路与 CLIProxyAPI 两张新单。
sub2api 今天北京 18:16 发出 v0.2.19，从
main 切出，距 v0.2.18 五天，两版之间并进 71 笔提交。发行说明列了五条新功能、六条优化、十二条修复。对已经在跑站点的人来说，先要处理的是发行说明末尾的两句：Gemini 默认模型表被换过一次，两张迁移会在启动时自己执行。12要用的 Gemini 模型先写进白名单
v0.2.18 的内置 Gemini 默认表是 11 个名字，v0.2.19 是 17 个。34 少掉的五个是
gemini-2.0-flash、gemini-2.5-flash、gemini-2.5-flash-image、gemini-2.5-pro 和 gemini-3-pro-preview。补进来 11 个：3.1 与 3-pro 的图像档四个，3-flash 与 3.1 到 3.8 的文本档七个。表里现在连一个 2.x 的名字都没有。
gemini-3.1-flash-image 排到 gemini-4-argon；旧版的 2.0 / 2.5 与 gemini-3-pro-preview 已整体移除。3这张表在两个地方是活的判据。Vertex API Key 账号请求
/v1beta/models 时，返回的就是这份内置表。5 Gemini CLI 路径遇到上游 404 时，只有名字还在这张表里才做降级重试。6站点上还在用
gemini-2.5-pro 的话，升级后这两条路会一起变窄：列表里看不到这个名字，404 也不再触发回落。客户端表现是「模型不见了」和「偶发 404 直接返回」。两种情况都发生在启动之后，日志里没有对应告警。
有一个现成的绕法。分组内每个可调度的 Gemini 账号都配上
model_mapping 时，/v1beta/models 改按声明的模型应答，内置表退到后面。7 要保留 2.5 系，就在账号的模型映射里把名字写回去。两张迁移：启动自己跑
| 文件 | 改了什么 | 影响 |
|---|---|---|
247_scoped_admin_api_keys.sql | 新建 scoped_admin_api_keys 表，存密钥摘要、策略 JSONB、IP 白名单、撤销时间 | 空表，运行期才有数据 |
248_group_image_count_billing.sql | groups 加 image_count_billing 列 | 默认 false，即沿用旧计费 |
两步都是
IF NOT EXISTS 的新增，没有删改。回退到 v0.2.18 时，多出来的一表一列旧代码用不上，也不会因此报错。要留意的是升级后第一次启动的日志：迁移在同一批里顺序执行，任一失败会挡住后面的启动步骤。
按张计费那个开关默认关着，升级本身不会改账单。要开，去 OpenAI 与 Composite 分组上打开，并且只对专用图片端点生效。
新的同账号重试：名字比作用范围大
它只管 Gemini 兼容入口这一条线。整包里读它的调用点三处：
/v1/messages 相容路径两处，/v1/chat/completions 相容路径一处。1213 OpenAI 原生 Responses 与 Antigravity 执行器走各自的重试逻辑，改这个键对它们没有影响。这三条 Gemini 改动都在 18:02 到 18:03 这一分钟内并入
main：同账号重试次数可配置、绑定显式缓存的请求按配置同号重试、模型列表刷新在并发冷启动时复查缓存。2实际尝试次数是配置值加一。默认 4 就是单账号最多发 5 次，设 0 就只发一次。可重试的状态码是 429、500、502、503、504、529；403 只对 code_assist 类型的 OAuth 账号重试。
maxAttempts 这一处换算成尝试次数，下面那个 switch 决定哪些状态码算可重试。12拿默认值算一下最坏情况：换号次数
max_account_switches_gemini 默认 3，14 4 个账号各 5 次，一个客户端请求最多打到上游 20 次。上游在抖动的时候，这个数字会真实发生，按自己的并发和限额决定要不要调低。签名降级重发不占这 5 次：循环上限会随降级阶段顺延，只顺延不算尝试。12
国产 Coding Plan 的频率 429 改成秒级
这是本版里对运维日常影响最大的一条。国产供应商的 429 现在按三档分派：余额不足、请求频率、窗口耗尽。15
命中「速率限制」「请求频率」这类文案、又不含任何额度词时，账号归到频率档，交回默认 429 处理，冷却按秒算。旧做法会把一次并发突发停调到 5h 窗口结束，代码注释里记的实测是 1.5 到 4.8 小时。
#8399：限流不换号，先分清池模式与窗口冷却
今天北京 18:43 有一张新单：Composite 分组里用智谱模型，账号限流后请求不自动换号，要手动停号才切走。18 单子只有这一句，没有版本、日志和配置，也没有评论。
按 v0.2.19 的代码，这类症状有两条完全不同的来路，值得先分开。
第一条是池模式。API-key 账号在凭证里勾了
pool_mode 时，19 上游错误在没开自定义错误码的情况下会整段早退，账号状态一个字都不写，只留一条 pool_mode_error_skipped 日志。20一次请求内部仍会按
pool_mode_retry_status_codes（默认 401/403/429）在同号重试再换号。换号结果不记账，下一个新请求照样选中这个正在限流的账号。第二条是窗口冷却。三档分派里只有频率档会变短；命中护栏、或额度词与频控词同时出现时，账号仍会停到窗口重置点。
停调期间它会退出调度，请求换到别的账号，前提是分组里另有一个可调度的同模型账号。
状态写入本身是完整的。限流落库之后同一函数里会推一次调度 outbox、并刷新本机快照，调度侧能看到这次停调。21
SetRateLimited 写完 rate_limited_at 与 rate_limit_reset_at 之后，同一函数里推 outbox、同步快照，两步都在返回前完成。21自查按日志走，比翻代码快：搜
pool_mode_error_skipped 能确认是不是池模式那条路；搜 cn_coding_plan_frequency_429 说明这次按秒级处理了，搜到 cn_coding_plan_rate_limited 则是按窗口冷却。要立刻恢复一个账号，POST /api/v1/admin/accounts/:id/clear-error 会把错误态、全局限流、模型级限流和临时不可调度一起清掉，clear-rate-limit 只清限流相关的时间戳。22CLIProxyAPI #7072：想要一种开销更小的正文改法
上期那条 #7071 还开着，0 评论。今天 17:55 又开了一张同源的：请求拦截器插件想改 Codex 请求里的
<timezone> 与 <current_date>，代价是每次都要整包读正文、克隆、编解码。2324它引的两件事都在。
#6998（请求拦截器不必要的全文编码与复制）已以 completed 关闭，v8.0.44 起协议里多了 RequestInterceptorOmitBodyBefore 与 RequestInterceptorOmitBodyAfter 两个开关，可以在指定阶段不收正文。2526提需求的人自己也承认，时区改写必须读正文，省略正文解不了这件事，所以给了两个方案：官方原生支持时区改写，或者让插件只回传局部字节区间、由宿主拼接。第二方案想复用现有 C ABI，只加可选能力。
这张单现状是 open、0 评论、没有对应 PR。今天要压这部分开销，能做的仍是在插件侧：给只读 header 的能力加 omit-body 开关，把正文改写限定在真的需要它的模型或路径上。
CLIProxyAPI #7073：配额页把周日画了两遍
同一小时还有一张展示层缺陷单：Quota Management 的图表把周日重复成两个首日，实际数据是对的，只有图错位。27 报障人写的是 v8.0.40，当前发行版是 v8.0.45，没有复现说明；单子 open、0 评论、没有修复。
影响面只在面板读数。调度、冷却、计费都按数据库里的时间走，图表错位不会改任何判定，所以它排在本期最后，值得排期但今天不动手。
上游与社区
OpenAI 状态页现在 All Systems Operational，没有降级组件；最近一条事件是 10-27 夜里 6.1 Sol 模型性能下降，已恢复。28 Anthropic 同样全绿，最近一条仍是今天 13:48 恢复的 Gmail 连接器。29 Google Cloud 的事故表八条，最新一条是 10-20 起的那次多产品中断，最后更新在今早 08:38。30
Codex 那边的额度：追踪站记今天 14:35 有一次已验证的全局重置，距今 4 小时，累计 61 次，暂时没有新的官方信号。31 两家官方开发者论坛本窗口没有新话题：Google 那边最新一条停在 16:42，OpenAI 社区停在 14:51。3233
今晚能做的
- 先看白名单：站点上还在用
gemini-2.5-pro、gemini-2.5-flash或gemini-3-pro-preview的，把名字补进账号模型映射，再升级。 - 升级后查一次启动日志里的迁移执行，确认 247 与 248 都过了。
- 如果最近有站点报「智谱限流后不换号」，按日志里的
pool_mode_error_skipped判断是不是池模式那条路，再决定是关池模式还是加临时不可调度规则。
References
- 1Sub2API 0.2.19
github.com
- 2compare v0.2.18...v0.2.19
github.com
- 3
- 4同文件 at v0.2.18
github.com
- 5gemini_models_endpoints.go 第 160–175 行
github.com
- 6gemini_v1beta_handler.go 第 1040–1048 行
github.com
- 7gemini_models_endpoints.go 第 27–58 行
github.com
- 8antigravity/claude_types.go 第 189–222 行
github.com
- 9config.go 第 1108–1117 行
github.com
- 10config.go 第 2436–2440 行
github.com
- 11config.go 第 3374–3380 行
github.com
- 12
- 13
- 14config.go 第 2435–2436 行
github.com
- 15ratelimit_cn_providers.go 第 372–396 行
github.com
- 16ratelimit_cn_providers.go 第 124–128 行
github.com
- 17ratelimit_cn_providers.go 第 185–207 行
github.com
- 18sub2api #8399
github.com
- 19account.go 第 1230–1240 行
github.com
- 20ratelimit_service.go 第 333–350 行
github.com
- 21account_repo.go 第 2323–2338 行
github.com
- 22routes/admin.go 第 403–410 行
github.com
- 23CLIProxyAPI #7072
github.com
- 24CLIProxyAPI #7071
github.com
- 25CLIProxyAPI #6998
github.com
- 26sdk/pluginapi/types.go 第 113–123 行
github.com
- 27CLIProxyAPI #7073
github.com
- 28status.openai.com summary
status.openai.com
- 29status.anthropic.com summary
status.anthropic.com
- 30status.cloud.google.com incidents
status.cloud.google.com
- 31codex-reset.com
codex-reset.com
- 32discuss.ai.google.dev gemini-api
discuss.ai.google.dev
- 33community.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.