CLIProxyAPI 停服 71.7 秒源自注册写锁，修复已进 dev；sub2api 少配一行目录地址就看不到新模型
CLIProxyAPI 的注册写锁把停服拖到 71.7 秒，修复已进 dev 但 v8.0.45 还没有；sub2api 少配一行 model_catalog_url，Codex 客户端就看不到新上架的模型。
这个窗口从 10 月 28 日早上 7 点 21 分算起，四个仓库都没有发新版本。今天值得动手的两件事，一件管重启要等多久，一件管客户能不能看到新模型。
一、注册阶段的全表扫描，把停服时间推进了 90 秒上限
凭证多、又开了 web search 的部署，重启或停服会卡住，systemd 等满 90 秒的停止上限后直接杀掉进程。
报障那台部署接了约 6.7k 个客户端，实测停服 71.7 秒，正常约 1 秒，离 90 秒只差 18 秒1。
在这套实现里，一条凭证注册成一个客户端，客户端数就是你的凭证数2。
瓶颈在登记。每登记一个模型，注册表都要问一次「还有没有别的客户端支持 web search」，旧实现每次都把全部客户端扫一遍3。
这段扫描跑在注册表的写锁里，一个模型扫一遍，模型之间还要排队。客户端越多，等待越长。
截图取自 v8.0.45 的 internal/registry/model_registry.go：第 1173 行开头的
for cID, infos := range r.clientModelInfos 就是全表遍历，第 1180 行才判断这一条是否支持 web search。修前修后的数字在同一张 benchmark 表里，每客户端 20 个模型。
修前 250 个客户端 68.2 ms、500 个 298 ms、1000 个 1492 ms，每翻一倍涨约 4.4 倍。
修后同一组是 6.8、15.6、28.7 ms1。
旧基准没测出这条曲线。它把 web search 记在一个字段上，聚合读的却是另一个字段，等于在一张 web search 全关的注册表上量速度1。
新测试拿全表扫描当标准答案，模型、provider、排除客户端三种组合都比一遍。
修法换成两个增量计数器：一个按模型记客户端数，一个按模型加 provider 记客户端数，查询从遍历变成查表。
这一笔已经合进 dev，合并提交 e30575dc，2 个文件 +412/−174。
v8.0.45 里还没有它：tag、main 与 v8.0.45 都停在 ad8bdd3f，dev 在 58874f3b5。
按最近的节奏推断，今天到明天那一版该带上它：最近四版都在北京时间 22:21 到 23:49 之间发出5。
等不了这一版的部署，可以把 systemd 的停止超时放长，让进程自己走完关停流程，代价是重启窗口跟着变长。
停服为什么卡在这一段，看启动注册的收尾就清楚。任务由协程逐个投递，主协程等在原地，注册没走完，主流程就不会走到处理退出信号那一步。
同一版本的 sdk/cliproxy/service_plugins.go：第 297 行的协程逐个投递注册任务，投完关闭通道，主协程在第 308 行
wg.Wait() 等它们全部返回。二、少一行 model_catalog_url，Codex 就看不到新模型
今天早上 8 点 04 分，有人在 9 月 27 日开的那张单里补了完整复现6。
复现条件是 Codex CLI 0.164.0-alpha.11.1 配一个自定义 provider。
结果分成两半：
GET /v1/models 和带 client_version 的 manifest 里都有 gpt-6.1-terra6。POST /responses 也能跑通。客户端那一半是坏的：模型选择器里没有 gpt-6.1-terra。
补上
model_catalog_url = "<base_url>/v1/models" 就恢复正常，报障人就是这么解决的6。官方文档对这一项只有一句：
model_catalog_url 是 Codex 原生模型目录的完整 URL。省略这一项，就沿用该 provider 默认的模型发现方式7。
sub2api 自己的接入弹窗默认就写这一行。
同一文件第 1044 行按目录模式二选一：remote 写
model_catalog_url，另一条分支只写 wire_api = "responses"。第 1048 行的 api_key_model_discovery 同样只在 remote 时写入。manifest 超过 1 MiB 时，弹窗会强制切到本地文件模式，那条路不写这一项9。
影响落在两类人身上：客户照着手写配置接入，只看到旧模型；中转站发出去的接入片段漏一行，问题当场复现。
那张单还开着。作者想要的是运行时同步官方目录：每小时一次、只增不删、被删的模型留 7 天宽限，目前没有维护者回复6。
三、窗口内其他读数
| 仓库 | 当前版本 | 发布时间（北京） | 本窗口发版 |
|---|---|---|---|
| CLIProxyAPI | v8.0.45 | 10-27 23:27 | 无 5 |
| sub2api | v0.2.18 | 10-23 15:44 | 无 10 |
| codex-proxy | v2.1.21 | 10-28 04:33 | 无 11 |
| codex2api | v3.1.2 | 10-28 04:39 | 无 12 |
GCP 那条多产品事件的记录被改过一次，没有新增更新，最新一版仍是 10-27 23:13（北京）的事故报告15。
额度重置今天 UTC 内还没发生。最近一次已验证的全局重置停在 10-26 14:08（北京），到现在约 43 小时。
累计 60 次全局重置，另有 10 次预留额度16。
按模型口径，24 小时内重置概率 46%、48 小时 71%，置信度低16。
社区这边窗口内没有新的额度或封号信号。
上一期发稿后才扫到两条论坛帖，都只有用户自述、没有官方回复，放在这里补齐。
一条关于订阅归属：用 Jio 渠道的 Google AI Pro 请求 Antigravity，返回 403
SUBSCRIPTION_REQUIRED。错误码 #3501，来自 cloudaicompanion.googleapis.com，发帖人附了 trace21。
另一条关于滥用判定：取消两个卡住的提示词之后，应用被按滥用立即停用，正在申诉22。
四、今天按这个顺序处理
- 凭证上千、又开 web search 的 CLIProxyAPI 部署：等带 e30575dc 的版本，或者先把停止超时放长。
- 给客户发 Codex 接入片段时确认带上
model_catalog_url，sub2api 弹窗生成的配置已经包含这一行。 - 走第三方渠道拿 Google AI Pro 的 Antigravity 账号：先确认订阅归属，403 SUBSCRIPTION_REQUIRED 靠换号绕不过去。
References
- 1PR 6995：index web-search support
github.com
- 2
- 3
- 4合并提交 e30575dc：Merge pull request #6995
github.com
- 5CLIProxyAPI v8.0.45 发行页
github.com
- 6sub2api issue 7626：运行时同步官方 OpenAI 模型目录
github.com
- 7Codex 配置参考：model_catalog_url
learn.chatgpt.com
- 8v0.2.18 UseKeyModal.vue 第 326 行
github.com
- 9v0.2.18 UseKeyModal.vue 第 680–684 行
github.com
- 10sub2api v0.2.18
github.com
- 11codex-proxy v2.1.21
github.com
- 12codex2api v3.1.2
github.com
- 13OpenAI 状态页
status.openai.com
- 14Anthropic 状态页
status.anthropic.com
- 15GCP 事件 Xs2XTHzAVC9YnafnPyzj
status.cloud.google.com
- 16codex-reset 首页
codex-reset.com
- 17r/OpenAI
reddit.com
- 18r/ClaudeAI
reddit.com
- 19Gemini API 分区
discuss.ai.google.dev
- 20Antigravity 分区
discuss.ai.google.dev
- 21Antigravity 与 Jio 渠道的 AI Plus
discuss.ai.google.dev
- 22应用被误判停用的申诉帖
discuss.ai.google.dev
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.