夯爆了！Codex 接入 DeepSeekV4、GLM5.1、K2.6

3. 接入原理：Codex 到底在接什么

前面两条路线看着不一样，但真正卡住的地方其实是同一个：Codex 发出去的模型请求，第三方服务到底能不能接住。

以 API Key 模式为例，Codex 大概是这么跑的：

用户输入
  -> Codex Agent 编排任务
  -> 读取 ~/.codex/config.toml
  -> 根据 model_provider 找到对应 provider
  -> 取出 base_url、API Key、wire_api 等配置
  -> 向模型服务发请求
  -> 模型返回结果
  -> Codex 解析响应
  -> 继续工具调用、文件编辑、命令执行等动作

这里最关键的是几个配置项：

• model_provider：当前用哪个模型供应商。
• base_url：请求发到哪里。可以是 OpenAI，也可以是第三方中转、本地代理，或者公司内部模型网关。
• env_key：API Key 从哪个环境变量里读，避免直接把 Key 写死在配置文件里。
• wire_api：Codex 用哪种协议跟模型服务通信，比如 responses 或 chat。

最后这个 wire_api 很关键。

普通聊天接口能返回一句话，不代表它就能支撑 Codex 的 Agent 流程。Codex 不只是把问题发给模型再展示答案，它还要解析流式响应、tool call、reasoning、状态字段，然后继续读文件、改代码、跑命令。

所以，第三方模型能不能接进来，不能只看“是不是 OpenAI-compatible”，还要看它兼容的是 Chat Completions，还是能完整接住 Codex 当前使用的 Responses 链路。

3.1 为什么不能只改 Base URL

Codex 当前更偏向使用 OpenAI Responses API，而很多第三方模型给的是 Chat Completions API。两者不是同一个东西。

Responses API 更适合 Agent 场景，它会涉及更多状态和事件结构；Chat Completions API 更像传统对话接口，核心是 messages 列表和模型回复。普通聊天工具只要能发 messages 就够了，但 Codex 还要处理工具调用、流式事件、上下文、reasoning、任务状态等内容。

所以，第三方模型接入 Codex 时，真正麻烦的地方不是“请求发不出去”，而是“请求和响应能不能被双方正确理解”。

3.2 CC-Switch 的原理：在代理层做转换

CC-Switch 的本地代理干的就是协议转换：

• 把 Codex 发来的 Responses 请求转成 Chat Completions，再转给上游。
• 把上游返回的 SSE 流式响应重新包装成 Responses，再推回 Codex。
• 处理 reasoning 内容、tool calls、previous_response_id 这类状态字段。

也正因为中间有转换层，第三方模型能不能稳定跑，不只取决于模型本身，还取决于 provider 的兼容性和代理实现。

如果上游本身支持 Responses API，代理可以少做一层 Chat Completions 转换，主要承担认证注入、用量追踪和健康检查等工作。

3.3 Codex++ 的原理：在桌面端做增强

Codex++ 更偏 Codex App 桌面端增强 + provider 配置写入/同步。它不是像 CC-Switch 那样把所有请求统一收进本地代理层再做协议转换，而是通过 launcher 启动 Codex，再用 CDP 注入增强脚本，让 Codex App 具备额外的菜单、配置入口、插件入口和供应商切换能力。

简单来说就是：CC-Switch 主要解决“请求怎么路由、协议怎么转”；Codex++ 主要解决“Codex 桌面端怎么增强，以及第三方 provider 怎么更方便地写入和切换”。

4. 怎么选：CC-Switch 还是 Codex++

先说结论：绝大部分人选 CC-Switch 就可以，这也是我更推荐的默认路线。

4.1 按需求选择

• 主要用 Codex CLI，还同时跑 Claude Code / Gemini CLI：选 CC-Switch。
• 只用 Codex 桌面版，并且想要插件入口和 UI 增强：选 Codex++。
• 不想动 Codex 任何安装文件：优先选 CC-Switch。
• 希望协议转换和本地路由开箱即用：优先选 CC-Switch。
• 想折腾桌面端增强、插件入口、脚本注入：再看 Codex++。

4.2 功能兼容性

接入第三方模型后，不要默认所有 Codex 能力都能完整替代。比较现实的情况是：

完全不可用或很难等价替代：

• Image Gen：依赖 OpenAI 对应的图像生成能力，第三方文本模型无法直接替代。
• Computer Use：依赖 Responses API 内置的 computer action 类型、本地运行时和截图反馈循环。Chat Completions 协议及普通第三方模型通常无法提供对等能力，协议转换层也很难补齐。

降级可用：

• 普通 Skills / 插件：配合 Codex++ 页面增强后，部分场景可用，稳定性视版本而定。
• 工具调用：基础代码编辑、文件读写、命令执行通常可以跑，但遇到复杂 tool calls 或长任务时，仍可能出现格式和兼容性问题。

基本正常：

• 代码编写
• 调试和重构
• 文件读写
• 项目管理
• 多轮对话
• 任务规划

4.3 更合理的使用方式

• 轻量代码问答、文字任务、简单脚本：DeepSeek 等成本较低的模型有明显价格优势。
• 复杂工程项目：先用更强的 GPT 跑通规划，再用第三方模型处理简单子任务。
• 如果你的 GPT Plus / Pro 额度够用：原生体验仍然最稳定，不一定需要额外折腾。