CCSwitchMulti: Codex MultiRouter、多模型路由与子 agent 低成本适配的上游化讨论

[BigStrongSun]

你好，我是 BigStrongSun/ccswitchmulti 的维护者。我们基于 cc-switch 做了一条主要面向 Codex 重度用户的增强分支，核心不是单纯改名或 provider preset，而是围绕 Codex MultiRouter / 多路路由 做了一整套可验证的工作流。

项目地址：

• Fork: https://github.com/BigStrongSun/ccswitchmulti
• 已提交到上游的相关 PR：fix(codex): repair history visibility for active sqlite DB #4292、feat(codex): integrate history repair into session manager #4294、fix(codex): preserve live settings on backup restore #4381

核心：Codex MultiRouter / 多路路由

CCSwitchMulti 的核心能力是让 Codex 在一个本地 provider 后面同时接入多路模型来源：

• 官方 OpenAI / ChatGPT 订阅模型继续作为主力旗舰模型；
• DeepSeek、Qwen、本地 vLLM、远端 OpenAI-compatible API 作为可路由的国产/第三方模型源；
• Codex 侧仍然按模型名选择模型，MultiRouter 根据 model 字段做精确匹配或前缀匹配，把请求分发到对应上游；
• 模型列表、上下文窗口、模型能力和路由状态会回填到 Codex 可见的 catalog，避免只显示 custom 或模型不可见。

这个设计解决的是 Codex 用户的一个真实痛点：官方 Codex/ChatGPT 路径能力强，但额度贵；国产和本地模型便宜，但直接切 provider 又会破坏历史、模型显示、OAuth 状态和体验。MultiRouter 让用户可以在同一个 Codex 工作流里混用它们，而不是每次手动切换整个 provider。

Codex 子 agent 的专门适配

我们还针对 Codex 的 subagent / spawn agent 使用方式做了专门适配：

• 主 agent 可以继续使用订阅里的旗舰模型，例如 GPT 系列，负责规划、审查和关键决策；
• 子 agent 自动生成/迁移 ~/.codex/agents/*.toml role 配置，并绑定到 codex_model_router_v2；
• 前 5 个 MultiRouter 模型可以自动投影成 Codex 子 agent role；
• 子 agent 可以配置 DeepSeek、Qwen、本地 vLLM 等国产/低成本模型，承担阅读、整理、测试、子任务执行；
• 这样能在保持主流程能力上限的同时，尽量降低 Codex 官方订阅额度消耗。

这也是我们认为 MultiRouter 比单纯 provider 切换更有价值的地方：它不是只把 Codex 请求转到另一个 endpoint，而是把“主 agent 用旗舰模型、子 agent 用低成本模型”的协作模式产品化。

社区反馈

这套能力已经在中文社区拿到了一些真实反馈。小红书相关分享目前约 2.5 万阅读、2k 点赞收藏。反馈最集中的问题包括：

• Codex 无法方便混用官方模型和国产/本地模型；
• 切换 provider 或使用 MultiRouter 后历史记录像丢失一样；
• Codex 模型列表不显示、只显示自定义模型，或者上下文窗口不正确；
• 切回官方 provider 后 OAuth 登录态丢失；
• 第三方 bearer API 被错误标记为需要 ChatGPT OAuth；
• MultiRouter 模型刷新、路由选择和子 agent role 配置需要自动化。

已修复/实现的主要方向

历史 release 线里比较关键的点：

• v3.16.2-19 起产品化 Codex 历史修复和 fork updater；
• v3.16.2-22 把历史修复集成到 Session Manager；
• v3.16.3-1 合并官方 v3.16.3 并引入 MultiRouter；
• v3.16.3-5 修复 takeover restore 覆盖 live Codex settings；
• v3.16.3-7 做 MultiRouter 工作台和上下文窗口透传；
• v3.16.3-10/11 修复路由状态、OAuth/auth.json 保留和页签回跳；
• v3.16.3-14 让历史修复自动合并所有未知 provider 桶，并修复第三方 bearer API OAuth 污染；
• v3.16.3-19/20 修复 vLLM/Qwen 上下文窗口与模型刷新卡住；
• v3.16.3-23 做 subagent role 投影、精确路由优先和 route picker 去重。

历史记录修复说明

这里我想特别说明一下：我们说的历史修复不是“恢复云端历史”，而是本地历史仍在，但 Codex Desktop 的可见性条件不一致。

实际影响因素包括：

• active SQLite，例如新版 Codex 常用 ~/.codex/sqlite/state_5.sqlite；
• threads.model_provider；
• rollout 首行 session_meta.model_provider；
• session_index.jsonl；
• workspace hints；
• has_user_event；
• Codex Desktop 的 recent window 限制。

所以只改一个旧路径 ~/.codex/state_5.sqlite 或只同步 provider metadata，经常不够。CCSwitchMulti 的修复策略是先 dry-run、自动备份，再把所有非目标 provider 桶归并到当前目标 provider，并同步 rollout/index/workspace 线索。后续我们希望这部分能和上游已有的统一历史能力结合，而不是作为下游长期 fork 差异存在。

希望上游化的方式

我不建议一次性提交一个巨大的 MultiRouter PR。更合理的方式可能是分批上游：

1. 先合历史修复核心和 UI：fix(codex): repair history visibility for active sqlite DB #4292、feat(codex): integrate history repair into session manager #4294；
2. 再合 takeover / OAuth / live config 保留类修复：fix(codex): preserve live settings on backup restore #4381；
3. 再讨论 MultiRouter 的最小上游边界：模型 catalog、上下文窗口、路由状态、第三方 bearer API 安全；
4. 最后再讨论 Codex subagent role 投影和多模型协作体验。

想听听 maintainer 更倾向哪种拆分方式：是先继续 review 现有 PR，还是我重新整理一个更小的 MultiRouter RFC/PR stack？

[kingka]

用了你这个fork, 会把ccswitch 的历史会话消失， 是因为 codex_model_router_v2 这个provide 的原因吗？