10/18 下午速报：排除名单筛不到插件声明的静态模型；冷却上限一张补丁要五分钟、一张要六小时 (2026)

10 月 18 日北京 13:01 到 14:35 这一个半小时，四个仓库都没有新版本：CLIProxyAPI 还是 v8.0.32，sub2api 还是 v0.2.17，codex-proxy 还是 v2.1.18，codex2api 还是 v3.1.11 2 3 4。主干也没动，CLIProxyAPI 的 dev 头停在今天 12:16。这一轮没有要升的版本，能动手的是前两件；第三条只是把一处客户端边界说清楚。

这两小时能动手的两件事，都落在本地这一侧的记录上：一份模型排除名单，一条凭证冷却时长。

排除名单筛不到插件声明的静态模型

名单有两个来源：全局的 oauth-excluded-models（管理端有同名读写接口）5；以及凭证 JSON 里的 excluded-models。值支持 * 通配6。

v8.0.32 上，自带模型在注册前被 applyExcludedModels 筛一遍。插件按凭证返回的模型也筛：service_executors.go 第 621 行先取名单再过滤7。

插件注册模型有两种做法：按凭证现算，或者给某个 provider 声明一份固定清单。后者就是这里说的静态模型。

漏掉的就是静态那一种：它们等自带模型筛完，才在第 321 行被追加进来8。

追加函数自己不看名单。appendPluginModels 只做去重和拼接，签名里连名单参数都没有9。

appendPluginModels：入参只有 providerKey 与 models，函数体只做去重与拼接 — *`CLIProxyAPI` v8.0.32 的 `sdk/cliproxy/service_executors.go` 第 503–535 行：追加插件静态模型的函数里没有任何名单判断9。*

对比一下按凭证注册的那条路：同一个文件第 609–621 行先算出 activeExcluded，再拿它过滤插件返回的模型。

按凭证注册的插件模型先取名单，第 621 行 applyExcludedModels 过滤后才注册 — *`CLIProxyAPI` v8.0.32 的 `sdk/cliproxy/service_executors.go` 第 606–622 行：同一份名单，这条路是生效的7。*

Antigravity 的提示路径同一个顺序：第 660 行先筛自带模型，第 662 行再把没筛过的插件静态模型追加上去10。

后果落到选号那一步。发请求时，管理器会问注册表这张凭证支不支持这个模型，不支持就跳过11。

插件静态模型没被筛掉，这一步给出的答案是支持。你排掉的那个模型，只要插件还提供着，就仍然挂在这张凭证上：客户端照单可选，选号也照单会选。

今天 13:03 开出的 #6737 补的就是这条：先按原始 ID 把插件静态模型筛一遍，再追加12。

按原始 ID 是有讲究的。OAuth 别名在过滤之后才套上去，拿合并后的列表按别名再筛，会把名字撞上的自带模型一起误杀。作者的测试里专门留了这一条。

#6737 现在的状态：open、mergeable clean、1 笔提交、4 文件 +150/−9。自动评审 13:04 跑完，结论是还有未解决的意见，dev 分支上没有这笔。

今晚能做的：

名单对自带模型照常有效，这部分不用改。
插件静态模型这条今天没有配置层的解法。要立刻挡住，只有把那个插件停掉。
插件必须留着，就只能等这笔合并。

同一条冷却上限，两张补丁在抢：一张五分钟，一张六小时

Codex 判额度用完时，429 响应体里带 usage_limit_reached 和 resets_at 或 resets_in_seconds。v8.0.32 把这两个值直接换算成冷却时长，换算完就返回13。

这个错误随后被标成凭证级14，selector.go 第 836 行按它把整张凭证跳过15。同一张凭证下的其它模型一起停。

本地另有一道上限：配额退避从 1 秒起、封顶 30 分钟16。它只在没有重置提示时走；上游给了时间点，走的就是上游那个17。

常量块：quotaBackoffMax 30 分钟、minQuotaCooldownFloor 10 秒 — *`CLIProxyAPI` v8.0.32 的 `sdk/cliproxy/auth/conductor_refresh.go` 第 32–40 行：本地这层退避上限是三十分钟，管不到上游给的时间点16。*

今天 14:07，#5764 被重基到 dev 头 69d0ff8e。这张单 9 月 12 日就开了，2 文件 +12/−2，做两件事：把 usage_limit_reached 这条冷却封顶到 6 小时，并在换算前挡住 resets_in_seconds 的整数溢出18。

作者贴的生产证据值得看一眼。一次 429 带的 resets_in_seconds 是 244741，约 68 小时；4 小时 52 分后重启进程清掉内存里的冷却，下一个请求直接成功。真被锁 68 小时，这一步还会再吃一个 429。

另一张是昨天午后的 #6735，思路相反：把 Codex 的额度到期时间压到 5 分钟以内，五分钟后就拿这张凭证探一次19。它仍是 open、clean。

六小时那张的代价，作者自己列了三条20：

六小时到点没有单飞探针，并发请求会一起打到上游。
max-retry-interval 默认 30 秒，请求不会在线上等满六小时；调到六小时以上就会。
save-cooldown-status 开着时，升级前落盘的冷却不会被缩短。

两张都还开着，差别在代价落在哪儿。五分钟那张把长冷却换成高频探询：真没额度，每五分钟再吃一次 429。六小时那张贴着约五小时的主窗口，保留一次长冷却，只把多天那种截掉。

要等的话，先看自己撞的是哪种。resets_in_seconds 动辄十万的，等六小时那张；被反复探测打得上游报警的，五分钟那张更合。

有个地方容易误读：#5764 每天上午自动重基一次，今天 14:07 就是这轮自动化。它开了五周，维护者没有表态，别把「今天有更新」当成接近合并。

今天仍然靠管理端解冻：POST /v8/management/routing/cooldown/reset，请求体 {"auth_index":"..."}，空值回 400，找不到回 40421。

Codex 桌面端的补全预测，在 cpa-gui 名下不会出现

13:37 开出的 #6739 问的是 Composer Predictions 为什么不出现22。环境写得齐全：Codex 桌面 26.1013.4894.0、app-server 0.163.0-alpha.10.2、EasyCLIProxyAPI 0.3.43、CLIProxyAPI v8.0.32，模型 gpt-6.1-sol，provider 是 cpa-gui。

他在桌面端打包代码里找到一处早退：函数先判 modelProvider === "openai"，其它 provider 被记成 unsupported_provider 后返回 null，预测请求根本不发出去。

EasyCLIProxyAPI 这边把 provider 固定成自己的名字，MANAGED_AGENT_PROVIDER_ID 就是 cpa-gui23，OAuth 分支写 model_provider 用的也是它24。

报障人自己划了边界：手里只有静态代码，没有运行日志，这个报告不构成 CLIProxyAPI 的转发缺陷。他把问题留给维护者：要不要做一个保留 openai 身份的接入方式。

对读者的用处很直接。开了预测却一直没反应，先看会话里的 model_provider；名字是 cpa-gui 这类自定义值时，这是客户端自己的判断，改 base_url 修不出来。

上游与额度

OpenAI 状态页全绿，活动事件 025。最近一条是 10 月 14 日 17:00 开的合规 API 成本数据延迟，10 月 16 日 10:44 结束，影响级别 minor26。

Anthropic 全绿，10 月 18 日无事件27。GCP 的 incidents.json 仍是 7 条，最近一条是 10 月 8 日到 9 日的 Cloud Storage28。

Codex 侧今天 UTC 还没重置。codex-reset.com 的监控行写最近一次在 10 小时前（20:41 UTC，北京今天 04:41），累计 54 次全局、10 次 banked，节奏约每 4 天29。首屏那句「3 天前，10 月 15 日 06:13 UTC」与监控行仍对不上，前几期写过同一条。

Gemini 侧，r/GeminiAI 窗口里三条仍是额度体感：13:31 一条问 3.1 Pro 与 3.8 Flash 的额度是不是太小30，13:54 一条是自制额度条，14:22 一条「please someone fix this」。官方没有新说法，按背景记。

官方社区 Codex 分区窗口内 0 条新话题，最新一条停在 10 月 17 日 23:57 UTC31。

其余几件记一笔。CLIProxyAPI #6738 是一张 40 文件 +2451/−210 的大改，做 Meta Muse 与带路由后缀的推理签名，跨 Responses、Claude、Gemini 与 Interactions，状态 unstable，离合并还远32。

sub2api 窗口内有两张单动过。#8193 把 VERSION、COMMIT、DATE 三个构建参数挪到 go build 之前，作者实测两次构建从 119 秒降到 6 秒，open、1 文件 +8/−433；#2752 是 5 月的老单，今天在扫描里跳了一下，时间线上最后一次事件是 8 月 17 日作者自己关单，窗口里没有新评论34。

References

1
CLIProxyAPI Releases
github.com
2
sub2api Releases
github.com
3
codex-proxy Releases
github.com
4
codex2api Releases
github.com
5
server_management.go 第 165–166 行
github.com
6
service_models.go 第 646 行起
github.com
7
service_executors.go 第 609–621 行
github.com
8
service_models.go 第 316–322 行
github.com
9
service_executors.go 第 503–535 行
github.com
10
antigravity_models.go 第 654–662 行
github.com
11
conductor_selection.go 第 1024–1036 行
github.com
12
PR #6737 apply excluded models to plugin models
github.com
13
codex_executor_terminal.go 第 424–443 行
github.com
14
同文件第 317–331 行
github.com
15
selector.go 第 836 行
github.com
16
conductor_refresh.go 第 37–40 行
github.com
17
conductor_cooldown.go 第 2770–2785 行
github.com
18
PR #5764 cap usage_limit_reached cooldown
github.com
19
PR #6735 clamp quota cooldown
github.com
20
config.example.yaml 第 205–218 行
github.com
21
quota.go 第 27–54 行
github.com
22
CLIProxyAPI issue #6739
github.com
23
EasyCLIProxyAPI main.rs 第 172 行
github.com
24
configuration.rs 第 2905–2959 行
github.com
25
status.openai.com summary
status.openai.com
26
status.openai.com incidents
status.openai.com
27
Anthropic Status
status.anthropic.com
28
Google Cloud Status incidents
status.cloud.google.com
29
codex-reset.com
codex-reset.com
30
Is it just me, or are the quotas for Gemni 3.1 Pro and 3.8 Flash ridiculously small?
reddit.com
31
OpenAI Developer Community · Codex
community.openai.com
32
PR #6738
github.com
33
PR #8193 docker build args
github.com
34
PR #2752
github.com

这两小时能动手的两件事，都落在本地这一侧的记录上：一份模型排除名单，一条凭证冷却时长。

排除名单筛不到插件声明的静态模型

名单有两个来源：全局的 oauth-excluded-models（管理端有同名读写接口）5；以及凭证 JSON 里的 excluded-models。值支持 * 通配6。

v8.0.32 上，自带模型在注册前被 applyExcludedModels 筛一遍。插件按凭证返回的模型也筛：service_executors.go 第 621 行先取名单再过滤7。

插件注册模型有两种做法：按凭证现算，或者给某个 provider 声明一份固定清单。后者就是这里说的静态模型。

漏掉的就是静态那一种：它们等自带模型筛完，才在第 321 行被追加进来8。

追加函数自己不看名单。appendPluginModels 只做去重和拼接，签名里连名单参数都没有9。

对比一下按凭证注册的那条路：同一个文件第 609–621 行先算出 activeExcluded，再拿它过滤插件返回的模型。

Antigravity 的提示路径同一个顺序：第 660 行先筛自带模型，第 662 行再把没筛过的插件静态模型追加上去10。

后果落到选号那一步。发请求时，管理器会问注册表这张凭证支不支持这个模型，不支持就跳过11。

今天 13:03 开出的 #6737 补的就是这条：先按原始 ID 把插件静态模型筛一遍，再追加12。

#6737 现在的状态：open、mergeable clean、1 笔提交、4 文件 +150/−9。自动评审 13:04 跑完，结论是还有未解决的意见，dev 分支上没有这笔。

今晚能做的：

名单对自带模型照常有效，这部分不用改。
插件静态模型这条今天没有配置层的解法。要立刻挡住，只有把那个插件停掉。
插件必须留着，就只能等这笔合并。

同一条冷却上限，两张补丁在抢：一张五分钟，一张六小时

Codex 判额度用完时，429 响应体里带 usage_limit_reached 和 resets_at 或 resets_in_seconds。v8.0.32 把这两个值直接换算成冷却时长，换算完就返回13。

这个错误随后被标成凭证级14，selector.go 第 836 行按它把整张凭证跳过15。同一张凭证下的其它模型一起停。

本地另有一道上限：配额退避从 1 秒起、封顶 30 分钟16。它只在没有重置提示时走；上游给了时间点，走的就是上游那个17。

另一张是昨天午后的 #6735，思路相反：把 Codex 的额度到期时间压到 5 分钟以内，五分钟后就拿这张凭证探一次19。它仍是 open、clean。

六小时那张的代价，作者自己列了三条20：

六小时到点没有单飞探针，并发请求会一起打到上游。
max-retry-interval 默认 30 秒，请求不会在线上等满六小时；调到六小时以上就会。
save-cooldown-status 开着时，升级前落盘的冷却不会被缩短。

要等的话，先看自己撞的是哪种。resets_in_seconds 动辄十万的，等六小时那张；被反复探测打得上游报警的，五分钟那张更合。

有个地方容易误读：#5764 每天上午自动重基一次，今天 14:07 就是这轮自动化。它开了五周，维护者没有表态，别把「今天有更新」当成接近合并。

今天仍然靠管理端解冻：POST /v8/management/routing/cooldown/reset，请求体 {"auth_index":"..."}，空值回 400，找不到回 40421。

Codex 桌面端的补全预测，在 cpa-gui 名下不会出现

他在桌面端打包代码里找到一处早退：函数先判 modelProvider === "openai"，其它 provider 被记成 unsupported_provider 后返回 null，预测请求根本不发出去。

EasyCLIProxyAPI 这边把 provider 固定成自己的名字，MANAGED_AGENT_PROVIDER_ID 就是 cpa-gui23，OAuth 分支写 model_provider 用的也是它24。

上游与额度

OpenAI 状态页全绿，活动事件 025。最近一条是 10 月 14 日 17:00 开的合规 API 成本数据延迟，10 月 16 日 10:44 结束，影响级别 minor26。

Anthropic 全绿，10 月 18 日无事件27。GCP 的 incidents.json 仍是 7 条，最近一条是 10 月 8 日到 9 日的 Cloud Storage28。

官方社区 Codex 分区窗口内 0 条新话题，最新一条停在 10 月 17 日 23:57 UTC31。

References

1
CLIProxyAPI Releases
github.com
2
sub2api Releases
github.com
3
codex-proxy Releases
github.com
4
codex2api Releases
github.com
5
server_management.go 第 165–166 行
github.com
6
service_models.go 第 646 行起
github.com
7
service_executors.go 第 609–621 行
github.com
8
service_models.go 第 316–322 行
github.com
9
service_executors.go 第 503–535 行
github.com
10
antigravity_models.go 第 654–662 行
github.com
11
conductor_selection.go 第 1024–1036 行
github.com
12
PR #6737 apply excluded models to plugin models
github.com
13
codex_executor_terminal.go 第 424–443 行
github.com
14
同文件第 317–331 行
github.com
15
selector.go 第 836 行
github.com
16
conductor_refresh.go 第 37–40 行
github.com
17
conductor_cooldown.go 第 2770–2785 行
github.com
18
PR #5764 cap usage_limit_reached cooldown
github.com
19
PR #6735 clamp quota cooldown
github.com
20
config.example.yaml 第 205–218 行
github.com
21
quota.go 第 27–54 行
github.com
22
CLIProxyAPI issue #6739
github.com
23
EasyCLIProxyAPI main.rs 第 172 行
github.com
24
configuration.rs 第 2905–2959 行
github.com
25
status.openai.com summary
status.openai.com
26
status.openai.com incidents
status.openai.com
27
Anthropic Status
status.anthropic.com
28
Google Cloud Status incidents
status.cloud.google.com
29
codex-reset.com
codex-reset.com
30
Is it just me, or are the quotas for Gemni 3.1 Pro and 3.8 Flash ridiculously small?
reddit.com
31
OpenAI Developer Community · Codex
community.openai.com
32
PR #6738
github.com
33
PR #8193 docker build args
github.com
34
PR #2752
github.com

10/18 下午速报：排除名单筛不到插件声明的静态模型；冷却上限一张补丁要五分钟、一张要六小时

排除名单筛不到插件声明的静态模型

同一条冷却上限，两张补丁在抢：一张五分钟，一张六小时

Codex 桌面端的补全预测，在 cpa-gui 名下不会出现

上游与额度

References

Related content

10/18 下午速报：排除名单筛不到插件声明的静态模型；冷却上限一张补丁要五分钟、一张要六小时

排除名单筛不到插件声明的静态模型

同一条冷却上限，两张补丁在抢：一张五分钟，一张六小时

Codex 桌面端的补全预测，在 cpa-gui 名下不会出现

上游与额度

References

Related content