sub2api 面板从 v0.2.16 起就写 model_catalog_url，今天补清的是它什么时候不写
sub2api 维护者今天把模型目录那两行的边界写清了：面板从 v0.2.16 起就在写 model_catalog_url 与 [features] 下的 api_key_model_discovery，超过 1 MiB 才换成本地目录；给账号配了映射的分组仍然看不到上游新模型。
这个窗口从北京时间 8 点 55 分算起，四个仓库都没有发新版本。
今天上午 9 点 22 分，sub2api 的维护者在那张 9 月 27 日开的模型目录旧单里补了一段答复1。
答复把上一期留下的问题结掉一半。顺着它核对代码，上一期标题里那句「少配一行」也要收窄：这两行从 v0.2.16 起就写进生成的配置里了。
一、维护者划清的两条边界
他说的是：面板生成 Codex 配置时默认选远程目录，并同时写两处1。
换成
model_catalog_json 的情形有两种：主动选本地目录模式，或者 manifest 超过 1 MiB 被自动切过去1。他把这件事拆成两件。生成入口已经有了，就是上面那两行。
服务端运行时同步官方目录是另一件：同步来源、缓存、分组策略仍要设计确认1。
第二句对运维更要紧。这张单最初想要的东西还没人做，排期里先按「自己加映射」安排。
他末尾自注了一句：以上是公开源码与版本标签核对，没有复现那台部署或客户端，AI 辅助分析1。
二、三个稳定版都在写这两行
他提到这个行为由 #7736 合入、v0.2.18 也包含。前半句对，只是范围比他说的更宽。
#7736 在 9 月 30 日合进主干，6 个文件 +176/−432。
v0.2.16 是 10 月 13 日发的5。
所以从那一版起，面板生成的 Codex 配置就带着这两行。为了这一处把部署升到 v0.2.18，换不来任何变化。
第 1041 行开的是
[model_providers.OpenAI] 表，第 1044 行在 remote 模式下往这张表里写 model_catalog_url；第 1047 行另起 [features] 表，第 1048 行才写 api_key_model_discovery = true。两行分属两个表，这一条决定了它们常常只被抄进一半。
弹窗里四段生成模板都带这两行：OpenAI 直连、OpenAI WebSocket、Grok 等平台路由、通用路由3。
三、会缺这两行的三种情况
第一种是手写或自建模板，只抄了 provider 那一段，
[features] 那行被漏掉。第二种是面板版本早于 v0.2.16，或者从别处复制来的老片段。
第三种是文件模式，这里有一条硬边界。
面板会先拿这张 key 真拉一次目录，再按拿回来的字节数判定6。
原始响应按 UTF-8 字节数计，超过 1024×1024 就判超限6。
第 20 行拼入
client_version 参数，第 24 行把基址补成 /v1 再拼 /models；第 60 行的 responseBytes 统计原始响应文本的 UTF-8 字节数。
第 677 行拿到目录，第 681 行把字节数写进状态，第 682 行一句就把模式切成
file，第 683 行起才算 ready。代价要提前算：远程模式下新模型上架，下一次请求就能拿到；文件模式得人工重下一份。
还有一处容易误判。拉目录失败时面板只把状态标成 error，模式留在远程，生成照常8。
四、有一类部署带着这两行也看不到新模型
issue 7626 里列过一张表，讲清目录从哪来1。
/responses 原样转发，固定 manifest 的分组直接代理上游，没有映射的分组走上游清单，这三条都跟得上。例外只有一种：分组给账号配了
model_mapping 时，目录由服务端用内置名单加硬编码规则拼出来1。这类部署即使打开了远端 URL，目录里也只有内置名单上的模型，新上架的一个都进不来。
处理只有两条：在账号映射或分组白名单里自己加一条，或者等下一版。
五、窗口内其他读数
| 仓库 | 当前版本 | 发布时间（北京） | 本窗口发版 |
|---|---|---|---|
| CLIProxyAPI | v8.0.45 | 10-27 23:27 | 无 9 |
| 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 |
CLIProxyAPI 的 dev 头停在北京 8 点 24 的 58874f3b，上一期报的那笔注册写锁修复还在 dev13。
上游状态页今天都正常。OpenAI 的 25 个组件全在运行14。
Claude 侧同样全绿，昨夜那条 Sonnet 5.5 事件在 23:50 恢复15。
GCP 那条多产品事件的记录在北京 8 点 38 又被改过一次，正文没动，最新一版仍是昨夜 23:13 的事故报告16。
额度方面，今天 UTC 内还没有重置。最近一次已验证的全局重置停在 10-26 14:08（北京），到现在约 44 小时17。
累计 60 次全局重置、10 次预留，节奏约每两天一次，目前没有官方重置信号17。
Antigravity 那边，Hub 更新清单已经到 2.27.018。
今早 10 点 02 分，论坛上一位付费 Pro 用户自述：IDE 更新后被登出，重新登录时登录与账号入口已经不见了19。
一条用户自述，官方没有回复，先当信号看。跑 Antigravity 账号的，重登前先对一下客户端版本。
CLIProxyAPI 这一侧的兜底客户端版本仍是 2.24.0，清单每 6 小时刷新一次，它报给上游的版本会跟着 2.27.0 走20。
社区有一份额度提案。今天 9 点 54 分，Codex 分区有人贴出完整价目设想：$20 给 1 倍周额度、$100 给 10 倍、$200 给 20 倍、$500 给 50 倍21。
五小时限制只留在最低档。
配套的要求是固定重置日、可买容量卡、免费全局重置只当故障补偿。1 帖 6 次浏览，官方没有回应。
六、今天按这个顺序处理
- 打开面板生成的
config.toml，确认[model_providers.*]下的model_catalog_url与[features]下的api_key_model_discovery都在。 - 只抄了 provider 段的手写片段，把
[features]那一行补回去。 - 目录超过 1 MiB 的走本地文件，记住新模型上架后要自己重下一份。
- 分组给账号配了映射的，直接把新模型加进映射或白名单。
References
- 1sub2api issue 7626：运行时同步官方 OpenAI 模型目录
github.com
- 2
- 3v0.2.18 UseKeyModal.vue 第 1041–1048 行
github.com
- 4v0.2.16 同一文件同一行段
github.com
- 5sub2api v0.2.16 发行页
github.com
- 6v0.2.18 api/codex.ts 第 16–62 行
github.com
- 7v0.2.18 UseKeyModal.vue 第 324–333 行
github.com
- 8v0.2.18 UseKeyModal.vue 第 676–686 行
github.com
- 9CLIProxyAPI v8.0.45
github.com
- 10sub2api v0.2.18
github.com
- 11codex-proxy v2.1.21
github.com
- 12codex2api v3.1.2
github.com
- 13CLIProxyAPI dev 分支提交
github.com
- 14OpenAI 状态页
status.openai.com
- 15Anthropic 状态页
status.anthropic.com
- 16GCP 事件 Xs2XTHzAVC9YnafnPyzj
status.cloud.google.com
- 17codex-reset 首页
codex-reset.com
- 18Antigravity Hub 最新清单
antigravity-hub-auto-updater-974169037036.us-central1.run.app
- 19Antigravity 分区：升级后登录入口消失
discuss.ai.google.dev
- 20
- 21Codex 分区：额度提案
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.