[Bug] Codex MultiRouter「同步模型目录」未同步最新官方模型 GPT-6 Astra，生成的 catalog 未随 Codex 更新

[Atletico1999]

Self Checks / 自检

• I have read the FAQ section in README.
  我已阅读 README 中的常见问题。

• I have searched for existing issues, including closed ones.
  我已搜索过已有的 Issue，包括已关闭的。

CC Switch Version / 版本号

3.20.2-1

Operating System / 操作系统

Windows

Related App / 涉及应用

Codex

Steps to Reproduce / 重现步骤

1. 在 Windows 环境中使用最新版 Codex Desktop。

2. 在 ccswitchmulti 中配置多个模型 Provider，并使用「配置多路模型」功能，使 Codex 通过 MultiRouter 使用多个模型。

3. 进入：
   「配置多路模型」
   →「编辑旧配置」
   → 第 5/13 步「同步模型目录」
   →「自动获取模型列表」。

4. 点击「刷新」，等待 ccswitchmulti 自动获取并刷新模型列表（并不会出现最新版“GPT-6 Astra”模型）。

5. 配置模型Provider后，ccswitchmulti 自动会生成或更新：

   • %USERPROFILE%\.codex\config.toml
   • %USERPROFILE%\.codex\cc-switch-model-catalog.json

6. 检查「同步模型目录」中获取到的模型列表，以及生成的 cc-switch-model-catalog.json。

7. 关闭并重新启动 Codex Desktop，再检查 Codex Desktop 中的模型选择列表。

实际结果是：刷新后的模型目录仍然没有最新官方模型 GPT-6 Astra（模型 ID：gpt-6-astra）。

Expected Behavior / 期望行为

点击「同步模型目录」→「自动获取模型列表」→「刷新」后，希望 ccswitchmulti 能获取当前 Codex 版本实际提供的最新官方模型目录，并据此正确更新 MultiRouter 使用的模型配置。

以 GPT-6 Astra（gpt-6-astra）为例，当 Codex 官方新增模型后，预期：

1. 「自动获取模型列表」能够发现新增的官方模型；
2. 新模型能够自动进入 ccswitchmulti 当前使用的模型目录；
3. 生成的 cc-switch-model-catalog.json 中能够包含该模型；
4. [model_providers.codex_model_router_v2].models 中也能够同步包含该模型；
5. 模型目录与 Router 中的模型信息保持一致，不出现一处已经存在、另一处仍然缺失的情况；
6. Codex Desktop 重新加载配置或重启后，能够正常显示该模型；
7. 后续 Codex 新增、删除或调整官方模型时，用户不需要手工修改 JSON / TOML，也不需要等待 ccswitchmulti 手工补充一份新的官方模型清单。

对于官方模型的同步，希望 ccswitchmulti 尽量跟随当前安装的 Codex 所对应的官方 model catalog，而用户配置的第三方模型继续由 ccswitchmulti 管理并合并到最终模型目录中。

期望整体效果可以理解为：

当前 Codex 官方 catalog
        +
ccswitchmulti 管理的第三方模型
        ↓
   合并后的模型目录
        ↓
├─ cc-switch-model-catalog.json
└─ [model_providers.codex_model_router_v2].models
        ↓
     Codex Desktop

这样，当 Codex 更新并增加新的官方模型后，ccswitchmulti 再次执行「自动获取模型列表」时即可同步这些变化，同时继续保留用户已经配置的第三方模型。

另外，如果某个官方模型没有出现在最终列表中，希望界面能够尽量区分不同原因，例如：

• 官方模型源中没有发现该模型；
• 已经发现该模型，但当前账号暂不可用；
• 本次同步失败；
• 当前仍在使用缓存，尚未获取到最新目录；
• 已获取新模型，但生成最终模型目录时没有成功写入。

最好能够在刷新完成后明确显示本次同步结果，例如模型来源、是否使用缓存、发现了哪些新增/删除/变化的模型。

这样用户可以判断问题发生在 Codex 官方模型源、账号可用性、ccswitchmulti 的同步过程，还是最终模型目录生成环节，而不是只看到“刷新成功”，但无法确认模型目录实际上是否已经更新。

Actual Behavior / 实际行为

目前点击「自动获取模型列表」并刷新后，操作可以正常完成，但获取到的模型列表仍然没有 GPT-6 Astra（gpt-6-astra）。

ccswitchmulti 生成的 config.toml 中已经启用了 MultiRouter，并通过：

model_provider = "codex_model_router_v2"

使用生成的模型目录：

model_catalog_json = 'C:\Users\Administrator\.codex\cc-switch-model-catalog.json'

现有配置中的其它模型可以正常显示和使用，因此目前看起来并不是 MultiRouter 整体不可用，也不是 config.toml 完全没有生效。

问题主要集中在「官方模型目录的发现 / 刷新 / 同步」：

• 当前生成的 cc-switch-model-catalog.json 中可以看到 GPT-5.4、GPT-5.5、GPT-5.6 系列等模型；
• 但没有 gpt-6-astra；
• 「自动获取模型列表」刷新后也没有把 GPT-6 Astra 加入目录；
• 因为 Codex Desktop 当前读取的是 ccswitchmulti 生成的模型目录，所以最终在 Codex Desktop 的模型选择器中也看不到 GPT-6 Astra。

因此目前表现更像是：MultiRouter 和现有模型路由可以工作，但官方模型目录没有及时跟随 Codex 的最新模型更新。

Additional Context / 补充信息

补充一些可能有助于定位问题，以及后续改进模型目录同步机制的信息。

1. 当前环境与问题现象

当前使用的是最新版 Codex Desktop。

OpenAI 当前已经提供 GPT-6 Astra，对应模型 ID 为：

gpt-6-astra

ccswitchmulti 当前生成的 config.toml 中包含：

model_provider = "codex_model_router_v2"

model_catalog_json = 'C:\Users\Administrator\.codex\cc-switch-model-catalog.json'

生成的 cc-switch-model-catalog.json 中已经存在多项官方 GPT 模型以及用户配置的其它模型，但没有发现：

gpt-6-astra

在 ccswitchmulti 中执行：

「配置多路模型」
→「编辑旧配置」
→ 第 5/13 步「同步模型目录」
→「自动获取模型列表」
→「刷新」

刷新完成后，GPT-6 Astra 仍然没有出现在模型列表和最终生成的 cc-switch-model-catalog.json 中。

因此目前的问题看起来并不只是 Codex Desktop 没有重新加载某一个模型，更可能发生在 ccswitchmulti 获取、缓存、合并或生成模型目录的过程中：最新官方模型在最终 catalog 生成之前就没有被同步进来。

2. 建议检查「自动获取模型列表」的数据来源和缓存逻辑

建议重点检查以下环节：

• 获取官方 Codex 模型列表时，是否仍然读取了旧缓存；
• Codex Desktop / Codex 更新后，是否会重新获取对应版本的官方模型目录；
• 是否存在固定或更新滞后的官方模型白名单；
• models_cache.json、settings_config.modelCatalog、cc-switch-model-catalog.json 之间是否可能出现不同步；
• 点击「刷新」后，是否真正重新读取了当前官方模型源，而不是继续使用之前保存的模型目录；
• MultiRouter 重新生成模型目录时，是否只保留已有模型，而没有自动发现和合并新增官方模型；
• 是否存在缓存 fingerprint / version 未变化，导致实际没有触发重新同步的情况。

如果这里能够确认“自动获取模型列表”实际访问的数据源、缓存命中状态以及最终解析到的模型数量，应该比较容易定位问题发生在哪一层。

3. model_catalog_json 的覆盖行为可能放大这个问题

当前生成的 config.toml 会设置：

model_catalog_json = 'C:\Users\Administrator\.codex\cc-switch-model-catalog.json'

Codex 对 model_catalog_json 的使用方式是把该文件作为完整模型目录使用，而不是简单把其中的自定义模型增量追加到 Codex 自带的 bundled catalog。

因此，只要 ccswitchmulti 生成的 cc-switch-model-catalog.json 缺少某个最新官方模型，即使用户已经更新到了包含该模型的最新版 Codex Desktop，该模型仍然可能不会出现在模型选择器中。

这也意味着，如果 ccswitchmulti 长期保存了一份包含官方模型定义的静态或半静态快照，就可能随着 Codex 更新逐渐与官方模型目录产生漂移。

4. 建议以当前 Codex 官方 catalog 为基底动态合并

从长期维护角度，建议考虑让官方模型部分尽量动态跟随当前 Codex 自身的模型目录，而第三方模型继续由 ccswitchmulti 维护。

模型目录生成流程可以考虑调整为：

检测当前 Codex 版本 / 官方 catalog
        ↓
读取当前官方模型定义
        ↓
保留完整官方模型及 metadata
        ↓
追加 ccswitchmulti 管理的第三方模型
        ↓
生成统一模型注册表
        ↓
生成 Codex / MultiRouter 所需的最终配置

也就是：

Codex 当前官方 catalog
        │
        ├───────────────┐
        │               │
        ↓               ↓
保留官方模型定义    ccswitchmulti 管理的第三方模型
        │               │
        └───────┬───────┘
                ↓
          合并后的 catalog
                ↓
       Codex Desktop / MultiRouter

这样当 Codex Desktop 更新并加入 GPT-6 Astra 或后续其它新模型时，ccswitchmulti 下次同步模型目录即可自动继承，而不需要为每一个新官方模型单独发布一份固定模型清单，也不需要用户手工编辑 cc-switch-model-catalog.json。

5. 官方模型 metadata 建议优先继承 Codex 官方定义

除了模型名称本身，官方模型还包含大量可能随 Codex 版本变化的 metadata，例如：

context window
reasoning levels
default reasoning effort
tool capabilities
service tiers
visibility
multi-agent metadata
Responses 相关能力
其它模型能力字段

对于这些官方模型字段，建议尽量直接继承当前 Codex 官方 catalog 中的定义，而不是由 ccswitchmulti 长期复制、推测或单独维护固定值。

可以采用类似的原则：

官方模型
→ 当前 Codex 官方 catalog 为准

第三方模型
→ ccswitchmulti 自己维护定义

这样不仅能解决“有没有 GPT-6”的问题，也可以减少以后出现官方模型 metadata 不完整、字段过期、能力定义和当前 Codex 不一致等问题。

6. 建议 cc-switch-model-catalog.json 和 Router models 使用同一个事实来源

当前生成的 config.toml 中，除了顶层：

model_catalog_json = '...'

[model_providers.codex_model_router_v2] 自身也会生成：

models = [
    ...
]

因此建议不要分别维护两套模型集合。

更稳妥的方式是先形成一个统一的 canonical model registry，再由这个统一来源生成两个最终配置：

统一模型注册表
        │
        ├──→ cc-switch-model-catalog.json
        │
        └──→ [model_providers.codex_model_router_v2].models

否则后续可能出现：

Picker 已经有新模型
但 Router models 中没有

这种情况下可能表现为“可以选择，但实际请求失败”。

也可能反过来：

Router 已经支持新模型
但 Picker catalog 中没有

这种情况下则会表现为“模型实际上可以被路由，但用户无法在 Codex Desktop 中选择”。

让两者从同一个模型注册表生成，可以减少这类状态不一致。

7. 建议在 Codex 更新后自动检测官方 catalog 是否发生变化

如果实现成本允许，可以考虑为官方模型目录增加版本、hash 或 fingerprint 检测。

例如：

Codex 更新 / 启动 ccswitchmulti
        ↓
检测 Codex 版本或官方 catalog fingerprint
        ↓
发现变化
        ↓
重新读取官方模型目录
        ↓
与第三方模型重新合并
        ↓
更新统一模型注册表
        ↓
重新生成 catalog / Router models

这样可以从机制上避免本次问题在 GPT-6.x、后续 Codex 模型或其它官方模型更新时反复出现。

8. 建议在「同步模型目录」页面增加同步状态

为了方便用户和开发者排查类似问题，建议「自动获取模型列表」页面显示更明确的同步状态，例如：

官方模型数据来源
当前 Codex 版本
官方 catalog 版本 / fingerprint
最后同步时间
本次实际获取到的官方模型数量
是否命中本地缓存
新增模型
删除模型
metadata 发生变化的模型
最终生成的模型数量
同步失败原因

例如刷新后可以显示：

官方模型：11 → 12
新增：gpt-6-astra
第三方模型：8
最终合并：20
数据来源：当前 Codex catalog
缓存：未命中

这样用户能够直接判断“点击刷新成功但模型没有变化”究竟属于哪种情况：

上游官方模型源没有返回新模型
        ↓
本地缓存没有刷新
        ↓
settings_config.modelCatalog 没有更新
        ↓
最终 catalog 合并或生成阶段遗漏

这对定位问题会很有帮助。

9. 希望保留现有 MultiRouter，主要改进模型发现与目录生成机制

这个 Issue 并不是建议取消当前的 codex_model_router_v2 或 MultiRouter。

目前通过本地 Router 统一接入多个模型的方式可以继续保留。

更希望改进的是“模型发现”和“模型目录生成”这一层，并适当把它与 Provider 路由职责分开：

Provider / Router
负责：某个模型请求应该发送到哪里

Model Catalog
负责：当前有哪些模型，以及这些模型的能力和 metadata

比较理想的职责划分是：

ccswitchmulti MultiRouter
→ 继续负责模型请求路由

Codex 官方 catalog
→ 作为官方模型定义的权威来源

ccswitchmulti 模型注册表
→ 合并官方模型 + 第三方模型

最终生成器
→ 同时生成 cc-switch-model-catalog.json
→ 同时生成 Router models

这样既可以继续保留当前 MultiRouter 的使用方式，也可以让官方模型目录持续跟随 Codex 更新，从而避免以后每次发布新 GPT / Codex 模型后再次出现类似问题。