claude-opus-5-5-medium 报 unknown provider：v8.0.44 三处标识对不上，429 修复已落 dev (2026)

这一小时里 CLIProxyAPI 新开了三张单。三条都指向同一件事：同一个标识在两侧写法不一致。

目录名单里的 ID、模型名里的前缀、错误体里的 code，各错开一处。请求就落到 400、404 或 502。四个仓库在这一窗口没有新版本，下文代码位置按 v8.0.44 核对1。

先把边界说清。三张单都不动 -high 档，也不影响没开 Antigravity 或 Vertex 前缀的站。三处今天都能绕过去，但每条只有一条绕法。

另有一条跟进：修 429 冷却的那笔提交，北京 07:16 落进了 dev。

一｜Antigravity 只露出 -high，low 与 medium 被交集筛掉

北京 07:17 开的这张单写得很具体。claude-opus-5-5-medium 请求回 unknown provider for model claude-opus-5-5-medium2。

同一个账号用仓库自带的 fetch_antigravity_models 能取到 20 个上游模型。/v1/models 里却只剩 -high 那几个。这是报障人的复现，不是这里的实测。

原因是一段十行的交集判断。filterAntigravityModels 只保留 ID 同时出现在静态名单里的模型，交集之外直接丢掉3。

代码截图：一段交集筛选函数 — v8.0.44 的 `sdk/cliproxy/antigravity_models.go` 第 645–655 行。第 649 行是唯一判定：ID 不在 `hints.ModelIDs` 里的模型连 `filtered` 都进不去3。

而这份静态名单的 antigravity 段只有 11 个 ID。Claude 与 Gemini 只列了 -high，没有任何 low 或 medium4。

报障人贴的缺失清单是 9 个 ID。

Opus 5.5 与 Sonnet 5.5 各 low/medium，Argon 与 3.8 Flash 各 low/medium，外加一个 gemini-3.8-flash-tiered。

远端镜像也没补上。主干那份 models.json 的 antigravity 段同样只有这 11 个 ID5。

目录每 3 小时刷一次6。等它自己长出来是白等。

第二层影响在路由。名字解不出 provider，就回 400 model_not_found7。

不是 404，也不是「没有可用凭证」。provider 索引同样由这份目录喂进去，被筛掉的 ID 连注册都没有。

影响面窄但很硬。开了 Antigravity 的站，客户端按上游档位去点 low 或 medium，一律 400。

-high、gemini-3-flash、gpt-oss-120b-medium 这些在名单里的照常。

今天的绕法只有一条：自己托管目录。把官方 models.json 拉下来，在 antigravity 段补齐缺的 ID，再挂到 models.catalog8。

两个前提先说清。自定义源不会回退官方地址，写错了就没有备份。Home 模式根本不加载总目录，这条路对它是关着的9。

二｜Vertex 配了 prefix，列表和详情都不认它

北京 07:39 开的第二张单，三条症状并列。/v1beta/models 返回的名字不带前缀、用带前缀的名字查详情 404、带前缀直接调用却 20010。

三条能同时成立，是因为前缀只写进了 ID。

applyModelPrefixes 把 clone.ID 改成 gcp/gemini-4-argon，Name 却原样留在 gemini-4-argon11。

代码截图：前缀注册只改 ID — 同一段第 729–752 行。第 741 行只写 `clone.ID`，第 742–744 行只补 `MetadataModelID`，`Name` 与 `DisplayName` 全程未被触碰11。

Gemini 目录优先用 Name，只有 Name 为空才回落 ID12。详情查询又拿 name 去比对13。

于是列表给出的是裸名。裸名查得到，带前缀的反查不到。

这不是 Vertex 专属。任何经前缀注册、且 Name 非空的模型都会掉进同一个坑。

修法就在同一个文件里。rewriteModelInfoName 早已写好，OAuth alias 那条路已经在用14。

补一句 clone.Name 的同步改写即可。路由与能力元数据都不用动。

今天的选择是二选一。要么先别用 prefix，要么把带前缀的名字写进客户端配置，别指望自动发现。

三｜Daybreak 的硬件密钥重认证，代理侧没有恢复入口

北京 07:11 开的第三张单。Daybreak 账号经 Codex OAuth 凭证请求，上游回 400，正文要求用已授权的硬件密钥重新认证15。

关键不在那句文案，而在它的分类。cyber_policy 被列进请求过错码表，按客户端过错处理——不冷却，也不换号16。

这正是问题所在。客户端自己的「重新登录」刷的是它自己的登录态，动不了代理手里那张 OAuth 凭证。

于是凭证账面一直健康，每个请求都打回同一张、报同一句错。

代码截图：错误码到状态码的映射 — v8.0.44 `internal/runtime/executor/codex_executor_terminal.go` 第 182–196 行。第 188 行专门给 `cyber_policy` 留了 400 分支，与后面几个分支并列，说明这是有意判成请求过错17。

还有一层拼写坑值得单独记。发行版比对的是 snake_case。

第 186 行先把 error.code 转小写，第 188 行再与 cyber_policy 精确比较。

报障贴出的 body 里写的是 cyberPolicy。这样一段 body 走不到那一行，会落到 default 回 50218，并按瞬时错误记一分钟冷却19。

两种表现都不通，但对号方式不同。日志里 400 加 cyber_policy，说明它被判成请求过错、不会换号。502 加 cyberPolicy，说明它只是被当成上游抽风。

今天能做的只有人工。用管理端 OAuth 流程或设备码登录，把那张凭证重新认证一遍，再让客户端重建会话20。

别想着换号蒙过去。按设计这一类不换号，池里其他号也过不了同一道硬件密钥检查。

四｜修 429 的提交已落 dev，v8.0.44 还按配额冷却

上一期讲的那张 429 单没有停。北京 07:16，一笔提交以 Closes: #7017 落进 dev21。

提交正文三句话就是改法。把每轮限流与模型容量这类 429 归成「瞬时的、模型级的」限流，按上游给的等待提示决定等多久。

只冷却报错的那个模型。不再打配额标签，也不做指数退避。

判据写得很克制。只认 turn_rate_limit_exceeded 与两个容量码。

泛泛的 rate_limit_exceeded 不被降级，仍走原来的通用 429 处理22。

代码截图：dev 上新增的瞬时限流判定 — 提交 `9a35fa12b2` 内 `internal/runtime/executor/codex_executor_terminal.go` 第 394–420 行。注释第 395 行直接点名 issue 7017，第 416 行是那句精确匹配，第 419–420 行的兜底决定「有别的错误码就不认」22。

发行版里还没有这套。isCodexUsageLimitError 只认 usage_limit_reached，重置时刻也只从这一类型的 body 里读23。

所以 v8.0.44 上遇到这类 429，仍然按配额冷却走指数退避。报障人上一轮实测的「每 11 秒一轮、客户端 23 秒后拿到 429」，这一版不会变。

单子本身还是 open。今天仍建议用 request-scoped-errors 把这类拒绝按停止处理，别把重试交给冷却逻辑24。

下一个版本再看 dev 这套有没有被带出来。

版本面与上游

四个仓库都没有新发行版。CLIProxyAPI 停在 v8.0.44，10 月 26 日 23:49 发布25。

其余三家也都在窗口前。sub2api 还是 0.2.18，codex-proxy 停在预发布 v2.1.21-beta.852249c，codex2api 是 v3.1.126。

dev 在同秒落了两笔。除了那笔修 429 的，还有一笔给 Codex 客户端目录加了 workspace 与 cloud agent orchestrator 两条限制字段27。

那是 2 文件 +721/−147。两笔都还没进任何发行版。

其余三个仓库这一窗口的新开与更新条目都是 0。sub2api 只翻出一条 4 月的交流帖被顶起，不构成动态。

上游在这一窗口是干净的。OpenAI 全绿，最近一条事件是 02:19 到 02:30 的广告接口报错，早于窗口28。

Claude 也全绿29。Google Cloud 最新仍停在 10 月 23 日凌晨的 europe-west230。

额度侧按 UTC 算今天（10 月 26 日）有过一次已验证的全局重置。它落在北京 14:08，仍在本窗口之前31。

累计 60 次全局重置、10 次 banked，节奏约每两天一次。

三行自查

症状	看哪里	今天做什么
`unknown provider for model …-medium`	目录 `antigravity` 段有没有这个 ID	自托管 `models.catalog` 补 ID；Home 模式无解，等发版
列表名不带前缀、带前缀查详情 404	auth 文件里的 `prefix`	先不用前缀，或客户端手写带前缀名
Daybreak 的 400 或 502 反复出现且从不换号	错误体里 `error.code` 的拼法	管理端重认证该凭证，再重建客户端会话

References

1
CLIProxyAPI v8.0.44 发行页
github.com
2
CLIProxyAPI issue 7037
github.com
3
v8.0.44 antigravity_models.go 第 645 行
github.com
4
v8.0.44 内置 models.json
github.com
5
router-for-me models 主干 models.json
raw.githubusercontent.com
6
model_updater.go 第 17 行
github.com
7
handlers_routing.go 第 220 行
github.com
8
config.example.yaml 第 18 行
github.com
9
catalog_sources.go 第 246 行
github.com
10
CLIProxyAPI issue 7038
github.com
11
service_models.go 第 741 行
github.com
12
model_registry.go 第 1793 行
github.com
13
gemini_handlers.go 第 105 行
github.com
14
service_models.go 第 1157 行
github.com
15
CLIProxyAPI issue 7036
github.com
16
client_error.go 第 18 行
github.com
17
同一段源码
github.com
18
同文件第 200 行
github.com
19
conductor_cooldown.go 第 1220 行
github.com
20
CLIProxyAPI 管理端 v8 文档
github.com
21
提交 9a35fa12b2
github.com
22
提交内 codex_executor_terminal.go 第 394 行
github.com
23
v8.0.44 codex_executor_terminal.go 第 408 行
github.com
24
CLIProxyAPI issue 7017
github.com
25
CLIProxyAPI 发行页
github.com
26
codex-proxy 发行列表
github.com
27
提交 19398539ff
github.com
28
OpenAI 状态页
status.openai.com
29
Claude 状态页
status.claude.com
30
Google Cloud 事件页
status.cloud.google.com
31
codex-reset 首页
codex-reset.com

这一小时里 CLIProxyAPI 新开了三张单。三条都指向同一件事：同一个标识在两侧写法不一致。

先把边界说清。三张单都不动 -high 档，也不影响没开 Antigravity 或 Vertex 前缀的站。三处今天都能绕过去，但每条只有一条绕法。

另有一条跟进：修 429 冷却的那笔提交，北京 07:16 落进了 dev。

一｜Antigravity 只露出 -high，low 与 medium 被交集筛掉

北京 07:17 开的这张单写得很具体。claude-opus-5-5-medium 请求回 unknown provider for model claude-opus-5-5-medium2。

同一个账号用仓库自带的 fetch_antigravity_models 能取到 20 个上游模型。/v1/models 里却只剩 -high 那几个。这是报障人的复现，不是这里的实测。

原因是一段十行的交集判断。filterAntigravityModels 只保留 ID 同时出现在静态名单里的模型，交集之外直接丢掉3。

而这份静态名单的 antigravity 段只有 11 个 ID。Claude 与 Gemini 只列了 -high，没有任何 low 或 medium4。

报障人贴的缺失清单是 9 个 ID。

Opus 5.5 与 Sonnet 5.5 各 low/medium，Argon 与 3.8 Flash 各 low/medium，外加一个 gemini-3.8-flash-tiered。

远端镜像也没补上。主干那份 models.json 的 antigravity 段同样只有这 11 个 ID5。

目录每 3 小时刷一次6。等它自己长出来是白等。

第二层影响在路由。名字解不出 provider，就回 400 model_not_found7。

不是 404，也不是「没有可用凭证」。provider 索引同样由这份目录喂进去，被筛掉的 ID 连注册都没有。

影响面窄但很硬。开了 Antigravity 的站，客户端按上游档位去点 low 或 medium，一律 400。

-high、gemini-3-flash、gpt-oss-120b-medium 这些在名单里的照常。

今天的绕法只有一条：自己托管目录。把官方 models.json 拉下来，在 antigravity 段补齐缺的 ID，再挂到 models.catalog8。

两个前提先说清。自定义源不会回退官方地址，写错了就没有备份。Home 模式根本不加载总目录，这条路对它是关着的9。

二｜Vertex 配了 prefix，列表和详情都不认它

北京 07:39 开的第二张单，三条症状并列。/v1beta/models 返回的名字不带前缀、用带前缀的名字查详情 404、带前缀直接调用却 20010。

三条能同时成立，是因为前缀只写进了 ID。

applyModelPrefixes 把 clone.ID 改成 gcp/gemini-4-argon，Name 却原样留在 gemini-4-argon11。

Gemini 目录优先用 Name，只有 Name 为空才回落 ID12。详情查询又拿 name 去比对13。

于是列表给出的是裸名。裸名查得到，带前缀的反查不到。

这不是 Vertex 专属。任何经前缀注册、且 Name 非空的模型都会掉进同一个坑。

修法就在同一个文件里。rewriteModelInfoName 早已写好，OAuth alias 那条路已经在用14。

补一句 clone.Name 的同步改写即可。路由与能力元数据都不用动。

今天的选择是二选一。要么先别用 prefix，要么把带前缀的名字写进客户端配置，别指望自动发现。

三｜Daybreak 的硬件密钥重认证，代理侧没有恢复入口

北京 07:11 开的第三张单。Daybreak 账号经 Codex OAuth 凭证请求，上游回 400，正文要求用已授权的硬件密钥重新认证15。

关键不在那句文案，而在它的分类。cyber_policy 被列进请求过错码表，按客户端过错处理——不冷却，也不换号16。

这正是问题所在。客户端自己的「重新登录」刷的是它自己的登录态，动不了代理手里那张 OAuth 凭证。

于是凭证账面一直健康，每个请求都打回同一张、报同一句错。

还有一层拼写坑值得单独记。发行版比对的是 snake_case。

第 186 行先把 error.code 转小写，第 188 行再与 cyber_policy 精确比较。

报障贴出的 body 里写的是 cyberPolicy。这样一段 body 走不到那一行，会落到 default 回 50218，并按瞬时错误记一分钟冷却19。

两种表现都不通，但对号方式不同。日志里 400 加 cyber_policy，说明它被判成请求过错、不会换号。502 加 cyberPolicy，说明它只是被当成上游抽风。

今天能做的只有人工。用管理端 OAuth 流程或设备码登录，把那张凭证重新认证一遍，再让客户端重建会话20。

别想着换号蒙过去。按设计这一类不换号，池里其他号也过不了同一道硬件密钥检查。

四｜修 429 的提交已落 dev，v8.0.44 还按配额冷却

上一期讲的那张 429 单没有停。北京 07:16，一笔提交以 Closes: #7017 落进 dev21。

提交正文三句话就是改法。把每轮限流与模型容量这类 429 归成「瞬时的、模型级的」限流，按上游给的等待提示决定等多久。

只冷却报错的那个模型。不再打配额标签，也不做指数退避。

判据写得很克制。只认 turn_rate_limit_exceeded 与两个容量码。

泛泛的 rate_limit_exceeded 不被降级，仍走原来的通用 429 处理22。

发行版里还没有这套。isCodexUsageLimitError 只认 usage_limit_reached，重置时刻也只从这一类型的 body 里读23。

所以 v8.0.44 上遇到这类 429，仍然按配额冷却走指数退避。报障人上一轮实测的「每 11 秒一轮、客户端 23 秒后拿到 429」，这一版不会变。

单子本身还是 open。今天仍建议用 request-scoped-errors 把这类拒绝按停止处理，别把重试交给冷却逻辑24。

下一个版本再看 dev 这套有没有被带出来。

版本面与上游

四个仓库都没有新发行版。CLIProxyAPI 停在 v8.0.44，10 月 26 日 23:49 发布25。

其余三家也都在窗口前。sub2api 还是 0.2.18，codex-proxy 停在预发布 v2.1.21-beta.852249c，codex2api 是 v3.1.126。

dev 在同秒落了两笔。除了那笔修 429 的，还有一笔给 Codex 客户端目录加了 workspace 与 cloud agent orchestrator 两条限制字段27。

那是 2 文件 +721/−147。两笔都还没进任何发行版。

其余三个仓库这一窗口的新开与更新条目都是 0。sub2api 只翻出一条 4 月的交流帖被顶起，不构成动态。

上游在这一窗口是干净的。OpenAI 全绿，最近一条事件是 02:19 到 02:30 的广告接口报错，早于窗口28。

Claude 也全绿29。Google Cloud 最新仍停在 10 月 23 日凌晨的 europe-west230。

额度侧按 UTC 算今天（10 月 26 日）有过一次已验证的全局重置。它落在北京 14:08，仍在本窗口之前31。

累计 60 次全局重置、10 次 banked，节奏约每两天一次。

三行自查

症状	看哪里	今天做什么
`unknown provider for model …-medium`	目录 `antigravity` 段有没有这个 ID	自托管 `models.catalog` 补 ID；Home 模式无解，等发版
列表名不带前缀、带前缀查详情 404	auth 文件里的 `prefix`	先不用前缀，或客户端手写带前缀名
Daybreak 的 400 或 502 反复出现且从不换号	错误体里 `error.code` 的拼法	管理端重认证该凭证，再重建客户端会话

References

1
CLIProxyAPI v8.0.44 发行页
github.com
2
CLIProxyAPI issue 7037
github.com
3
v8.0.44 antigravity_models.go 第 645 行
github.com
4
v8.0.44 内置 models.json
github.com
5
router-for-me models 主干 models.json
raw.githubusercontent.com
6
model_updater.go 第 17 行
github.com
7
handlers_routing.go 第 220 行
github.com
8
config.example.yaml 第 18 行
github.com
9
catalog_sources.go 第 246 行
github.com
10
CLIProxyAPI issue 7038
github.com
11
service_models.go 第 741 行
github.com
12
model_registry.go 第 1793 行
github.com
13
gemini_handlers.go 第 105 行
github.com
14
service_models.go 第 1157 行
github.com
15
CLIProxyAPI issue 7036
github.com
16
client_error.go 第 18 行
github.com
17
同一段源码
github.com
18
同文件第 200 行
github.com
19
conductor_cooldown.go 第 1220 行
github.com
20
CLIProxyAPI 管理端 v8 文档
github.com
21
提交 9a35fa12b2
github.com
22
提交内 codex_executor_terminal.go 第 394 行
github.com
23
v8.0.44 codex_executor_terminal.go 第 408 行
github.com
24
CLIProxyAPI issue 7017
github.com
25
CLIProxyAPI 发行页
github.com
26
codex-proxy 发行列表
github.com
27
提交 19398539ff
github.com
28
OpenAI 状态页
status.openai.com
29
Claude 状态页
status.claude.com
30
Google Cloud 事件页
status.cloud.google.com
31
codex-reset 首页
codex-reset.com

claude-opus-5-5-medium 报 unknown provider：v8.0.44 三处标识对不上，429 修复已落 dev

一｜Antigravity 只露出 -high，low 与 medium 被交集筛掉

二｜Vertex 配了 prefix，列表和详情都不认它

三｜Daybreak 的硬件密钥重认证，代理侧没有恢复入口

四｜修 429 的提交已落 dev，v8.0.44 还按配额冷却

版本面与上游

三行自查

References

Related content

claude-opus-5-5-medium 报 unknown provider：v8.0.44 三处标识对不上，429 修复已落 dev

一｜Antigravity 只露出 -high，low 与 medium 被交集筛掉

二｜Vertex 配了 prefix，列表和详情都不认它

三｜Daybreak 的硬件密钥重认证，代理侧没有恢复入口

四｜修 429 的提交已落 dev，v8.0.44 还按配额冷却

版本面与上游

三行自查

References

Related content