连接第三方 API

最后核对日期

2026-05-30。第三方 API、模型名称、Base URL、计费方式和兼容性变化很快，请以各工具实际文档和后台显示为准。

Codex 默认最稳的方式，是使用官方账号和官方支持的模型。第三方 API 是进阶玩法，适合已经理解 API Key、Base URL、模型名、代理网关、config.toml 和本地启动方式的人。它解决的是“模型请求走哪里、用哪个 provider、由谁计费”的问题，不等于自动获得官方插件、自动化或完整 App 能力。

这篇解决什么问题

本章讲四件事：第三方 API 到底改了什么；手动配置、Codex++、CCX + CCSwitch 这几条路线怎么选；OpenRouter、DeepSeek、Minimax、Gemini、CliproxyAPI、0011.ai 和 API 中转站分别适合什么场景；什么时候该用官方 API，什么时候该用中转，什么时候该用聚合工具。

Redman 的实测补充可以看这篇博客：Codex Speedy / 第三方 API 加速与低成本使用思路。

第三方 API 接入入口示例

手动配置通常围绕 config.toml、环境变量和 provider 信息展开。改之前一定先备份，尤其是已经配置过 MCP、Skills 或插件的人。

第三方 API 配置示例

第一次配置时只接一个 provider，跑通后再加更多模型。不要一口气把十几个模型、多个中转和多个本地网关都混在一起。

模型与接口测试示例

配置完成后先用只读任务验证，不要直接交给真实项目。验证时重点看模型是否生效、日志是否清楚、权限提示是否正常。

适合谁

已经跑通过 Codex 基础任务，想降低模型成本的人。
有 DeepSeek、Minimax、Gemini、OpenRouter 或其他 API Key 的用户。
想研究 CCX、CCSwitch、Codex++、CliproxyAPI 等社区工具的人。
能接受第三方链路带来的稳定性和安全风险的人。

前置条件

已安装 Codex 桌面 App。
知道配置文件、环境变量和 API Key 的基本用法。
准备一个测试目录和一个低风险测试任务。
不把密钥写进公开仓库、截图、教程或聊天记录。

操作步骤

先决定路线：官方 API、中转站、模型聚合工具，还是本地网关。
准备 API Key、Base URL、模型名称和必要的代理设置。
备份本机 Codex 配置文件和认证文件。
只新增一个 provider，先不要一次性混入很多模型。
完全退出并重新打开 Codex。
发送只读验证任务，确认模型、权限、日志都正常。
再逐步接入 DeepSeek、Minimax、Gemini 或其他模型。

三种路线怎么选

路线	适合谁	优点	注意事项
手动配置	想理解底层配置、能自己排障的人	透明、可控、容易知道改了什么	字段写错就不生效；不适合纯小白
Codex++	主要用桌面 App，希望图形化管理中转配置的人	配置和切换更直观，适合多模型尝试	第三方 launcher / 增强工具，Codex 更新后可能要等适配
CCX + CCSwitch	有多个供应商、需要协议转换和统一切换的人	适合多 Key、多供应商、多协议路由	组件多，排障链路更长，需要理解本地服务和端口

如果你只是刚开始学 Codex，先跳过本章也没关系。先用官方账号跑通第一个任务，再回来研究第三方 API，会少很多“到底是 Codex 问题还是中转问题”的困惑。

路线一：手动配置

手动配置的核心通常是修改本机的 ~/.codex/config.toml，并通过环境变量或认证文件提供 API Key。改之前先备份：

cp ~/.codex/config.toml ~/.codex/config.toml.backup
cp ~/.codex/auth.json ~/.codex/auth.json.backup

Windows 用户可以把思路对应到自己的用户目录下 .codex 配置目录，具体路径以你本机实际安装和配置为准。

一个最小化 provider 配置可以理解成下面几部分：

model = "your-model-name"
model_provider = "my-provider"

[model_providers.my-provider]
name = "My Provider"
base_url = "https://example.com/v1"
wire_api = "responses"
env_key = "OPENAI_API_KEY"
requires_openai_auth = false

这里最容易写错的是：

model_provider 要和 [model_providers.xxx] 里的 xxx 对上。
base_url 通常写到 /v1，不要把完整接口路径重复拼进去。
wire_api = "responses" 表示按 Responses API 形态访问。
env_key 指向环境变量名，不要把真实 Key 直接写进公开文档。

然后在启动 Codex 前设置环境变量：

export OPENAI_API_KEY="sk-your-key"

macOS 上如果你从终端启动 App，环境变量更容易被当前进程继承；如果双击图标启动读不到 Key，就要回到环境变量继承方式排查。启动前先彻底退出 Codex，再重新打开。

路线二：Codex++

Codex++ 更偏桌面 App 增强和图形化管理。根据项目说明，它不是直接修改 Codex App 原始安装文件，而是通过外部 launcher 启动 Codex，并注入增强能力。它适合这些情况：

你主要使用 Codex 桌面 App，不想长期手写 config.toml。
你希望在一个界面里维护 Base URL、Key、模型列表和切换状态。
你希望保留更接近桌面 App 的工作流，而不是只做命令行 provider 替换。
你能接受第三方增强工具带来的兼容性、更新和安全评估成本。

Codex++ 项目与管理工具示例

Codex++ 操作流程

打开 Codex++ Releases，下载与你系统匹配的安装包。

Codex++ Releases 下载页

通常会看到「Codex++ 管理工具」和「Codex++ App」两个安装包。

Codex++ 安装包示例

安装后先打开 Codex++ 管理工具。macOS 首次打开如果提示无法验证开发者，先确认来源，再到系统设置里放行。

Codex++ 首次打开安全提示

macOS 隐私与安全性放行示例

进入管理界面后，确认 Codex++ 能检测到本机环境和 ChatGPT 登录状态。

Codex++ 管理界面

Codex++ 环境检测示例

添加供应商配置，填写你的 Base URL、Key、模型名和接入方式。第一次建议只配一个供应商，接入方式按你的上游能力选择。

Codex++ 添加供应商配置

如果上游能返回模型列表，可以先拉取模型列表，再选择要给 Codex 使用的模型。

Codex++ 模型列表示例

保存前确认这几项：Base URL 没多写路径、Key 没贴错、模型名和上游一致、没有覆盖你原来的 MCP 和 Skills 配置。

Codex++ 写入配置示例

测试连通，确认没问题后选择使用该配置。

Codex++ 测试连通并启用

从 Codex++ 入口启动 Codex，而不是从原版 Codex 入口启动。

从 Codex++ 入口启动

重新启动后，你应该能在 Codex 里看到自定义供应商和更多模型。

Codex++ 启动后的模型选择示例

如果你的目标是插件能力，也要单独验证插件库、MCP 和移动端控制是否正常，不要只看模型能不能回复。

Codex++ 插件能力示例

Codex++ 验证和回滚

验证时先用只读任务确认 Codex 能正常响应。
如果 Codex++ 菜单或增强功能没有出现，确认你是从 Codex++ 入口启动，而不是原版 Codex。
如果要回到官方登录态，在管理工具里清除 API 模式或切回官方配置。
Codex App 更新后，如果页面结构变化，注入脚本可能需要等待 Codex++ 适配。

Codex++ 可能写入类似这样的 provider：

model_provider = "CodexPlusPlus"

[model_providers.CodexPlusPlus]
name = "CodexPlusPlus"
wire_api = "responses"
requires_openai_auth = true
base_url = "https://example.com/v1"
experimental_bearer_token = "sk-..."

路线三：CCX + CCSwitch

这条路线把“网关”和“切换工具”拆开理解：

CCX 更像本地或远程 API 网关，负责渠道管理、模型路由、协议转换和故障转移。
CCSwitch 更像配置切换器，负责把某个供应商配置切到 Codex、Claude Code、Gemini CLI 等工具里。

它适合你同时有多个国产模型、中转站、OpenRouter、Gemini 或内部服务，并且需要把不同协议统一成 Codex 能使用的入口。代价是链路更长，出错时要分别排查 Codex、CCSwitch、CCX、上游模型和网络代理。

CCX 配置示例

CCX 渠道或模型配置示例

第 1 步：部署 CCX

如果使用 Docker，可以参考 CCX README 中带访问密钥的方式：

docker run -d \
  --name ccx \
  -p 3000:3000 \
  -e PROXY_ACCESS_KEY=your-proxy-access-key \
  -e APP_UI_LANGUAGE=zh-CN \
  -v $(pwd)/.config:/app/.config \
  crpi-i19l8zl0ugidq97v.cn-hangzhou.personal.cr.aliyuncs.com/bene/ccx:latest

启动后打开本地管理页：

http://localhost:3000

第 2 步：在 CCX 添加渠道

在 CCX Web 管理界面里添加你的上游渠道：

选择上游服务类型。
填写 DeepSeek、Minimax、OpenRouter、Gemini 或中转站的 API Key。
填写 Base URL。
配置模型映射、可用模型或路由规则。
先用 CCX 自带测试功能确认渠道可用。

这里要确认一件事：Codex 需要的是 Responses API 入口。如果上游只有 Chat Completions，CCX 需要负责协议转换；否则你只改 base_url 通常不够。

第 3 步：安装和初始化 CCSwitch

CCSwitch 可以用桌面安装包，也可以按你的习惯用命令行安装。命令行方式通常类似：

npm install -g cc-switch
cc-switch init

初始化时把 CCX 地址作为中转入口，例如：

http://localhost:3000

第 4 步：切换配置并启动 Codex

切换到你刚配置好的供应商：

cc-switch use <配置名>

然后完全退出并重新启动 Codex，让新的 provider 配置生效。如果 CCSwitch 写入的是 ~/.codex/config.toml，切换后建议打开文件核对一次：

当前 model_provider 是否是你刚选择的配置。
base_url 是否指向 CCX。
API Key 是否没有被写进公开仓库。
原有 MCP、Skills、profile 等配置是否还在。

CCX + CCSwitch 验证

第一次使用时建议只接一个上游渠道，先用 CCX 自带测试确认可用，再让 CCSwitch 写入 Codex 配置，最后重启 Codex 验证。验证 prompt 可以保持只读：

请只读说明当前工作区路径、你准备使用的模型和 provider。
不要修改文件，不要安装依赖，不要联网访问除模型请求以外的服务。

配置后怎么验证

用这个只读提示词做第一轮验证：

请只读说明当前工作区路径、你准备使用的模型和验证方式。

限制：不要修改任何文件，不要安装依赖，不要联网访问除模型请求以外的服务。
如果你无法确认模型或 provider，请说明你能看到的信息和下一步排查建议。

如果失败，按这个顺序排查：

Codex 是否完全退出并重新启动。
model_provider 名称是否一致。
base_url 是否只写到预期层级。
环境变量是否被启动 Codex 的进程继承。
API Key 是否有效、是否有额度、是否被上游限制。
上游是否支持 Responses API；不支持时是否需要 CCX 这类网关转换。

什么时候用官方 API

如果你要稳定、合规、少排障，优先官方 API 或官方 ChatGPT / Codex 路线。尤其是客户项目、生产代码、公司数据、敏感文档，不建议从一开始就放到不明中转里跑。

什么时候用中转站

中转站适合你已经理解风险，但需要统一付款、统一 Base URL、或者临时访问多个模型。常见例子包括 API 中转站、0011.ai 这类服务。使用前要重点看日志留存、计费规则、退款规则和数据安全说明。

什么时候用聚合工具

OpenRouter、CliproxyAPI、CCX、CCSwitch 更偏“多模型、多额度、多供应商管理”。如果你经常在 DeepSeek、Minimax、Gemini、ChatGPT 免费额度之间切换，聚合工具会方便；但链路越长，排障越难。

OpenRouter / API 聚合站模型示例

OpenRouter / API 聚合站模型示例 2

CliproxyAPI 更偏免费额度和多账号额度聚合，适合先做测试和低风险任务，不适合把客户项目、密钥或生产数据长期压在免费额度链路上。

CliproxyAPI 配置示例

CliproxyAPI 与 CCSwitch 联动示例

第三方 API 和插件不是一回事

很多新手会把“模型能响应”理解成“Codex 功能都完整了”，这不准确。

第三方 API 主要影响模型请求：谁来回答、走哪个 Base URL、由哪个 Key 计费。插件、Skills、MCP、浏览器、自动化这些能力，还取决于客户端、工作区、插件安装方式和权限配置。也就是说，DeepSeek 或 Minimax 能接通，不代表所有官方插件和自动化入口都会自动可用。

如果你的目标是插件和完整桌面工作流，除了模型连通，还要单独验证：

Skills 是否能被识别和触发。
插件或 MCP 是否能加载。
外部工具权限是否正常。
自动化入口是否可用。
失败时日志能否定位到具体层级。

常见坑

base_url 写错，把 /v1 和具体接口路径混在一起。
模型名和上游后台显示不一致。
API Key 贴到 Markdown、截图或公开仓库里。
上游只支持 Chat Completions，却期望它直接兼容 Responses API。
把第三方模型接入误认为插件能力也完整。
没备份配置，切换工具覆盖了原来的 MCP、Skills 或认证信息。
只看模型回复成功，没有检查任务日志、权限弹窗和文件写入结果。

Redman 实测建议

新手顺序建议：先用官方或 Plus 跑通 Codex，再试 DeepSeek / Minimax 这类低成本模型，最后再研究 CCX、CCSwitch、Codex++、CliproxyAPI。不要一口气接十个服务，出了问题会很难判断是哪一层。