我现在怎么用 CC Switch 管中转站，顺手拿 Codex 举个例子

HOPE705
0 阅读8分钟

这篇我主要参考了这几个地方：OpenAI Codex CLI 文档OpenAI Models 文档CC Switch GitHub 仓库

图片

中转站 + CC Switch 封面图

我前面一段时间折腾中转站，最烦的一件事就是来回改配置文件。刚开始只有一套配置的时候还好，后面中转站一多、Key 一多、模型一多，就很容易改乱。

后来我就改成用 CC Switch 统一管这些配置，省事很多。

这篇就聊聊我现在是怎么配的。正文里我会拿 Codex 举例，但这个思路其实不只适用于 Codex。

如果你现在也是每次切线路都得手改配置文件，几个中转站放着放着自己都记不清，或者工具到底读的是哪套配置已经有点搞不清了，那这篇应该能帮你省一点时间。

我一开始也是手改配置文件。这样不是不能用，但只要你开始频繁换中转、换模型、换 Key，这个办法很快就会变得很乱。

CC Switch 挺适合拿来收这个烂摊子。它本质上就是一个给 Claude Code、Codex、Gemini CLI 这类工具管配置的桌面工具。你把它理解成一个切换面板就行：

  • • 统一管理不同中转站

  • • 一键切换不同模型和 Key

  • • 少碰配置文件

  • • 出问题时更容易排查

我现在基本就是把中转站都扔到 CC Switch 里统一管，真要换就点一下。下面我拿 Codex CLI 走一遍，因为这个例子比较好讲。

先说一下大概是怎么回事=

图片

Codex + CC Switch 工作链路

我自己理解，这套东西跑起来大概就是这条线：

Codex CLI -> CC Switch -> 中转站/API聚合层 -> 模型服务

拆开来说：

  • • Codex CLI 负责在终端里读代码、改代码、跑命令

  • • CC Switch 负责帮你维护 Codex 的配置和密钥

  • • 中转站 负责把你的请求转发到对应模型

  • • 最终返回结果给 Codex

所以我这里不是想单独讲某个工具怎么安装，主要还是想把“工具怎么稳定走中转”这件事说清楚。这里先拿 Codex 说。

开始之前先备点东西

开始之前，手里先准备这几样东西：

这里我先多说一句。

从 OpenAI 当前文档和本机 Codex 实际配置结构来看，Codex 这一条链路更偏向 Responses API 兼容模式，而不只是传统的 chat/completions。

如果一个中转站只支持“OpenAI 格式聊天接口”，但不支持 Responses，那你就很可能出现下面这些问题：

  • • 能连上，但一运行任务就报错

  • • 普通对话能用，Agent 能力不稳定

  • • 工具调用、长任务、代码操作不太正常

所以我自己的做法一直很简单，就是优先选那些明确写了支持 Codex、支持 Responses API，或者明确支持 CC Switch / Codex CLI 的中转。

Codex CLI 直接用 npm 装就行，不折腾：

插一嘴，这里在vscode中安装codex插件也是一样的。

npm i -g @openai/codex
codex --version

装完以后，我一般不会急着手动登录。因为如果你准备走 CC Switch + 中转站 这套，后面更适合让它统一接管配置。

第一次打开 codex 的时候，会提示你用下面两种方式之一认证：

  • • ChatGPT account

  • • API key

如果你打算走官方，直接用 ChatGPT 登录就行。

如果你打算走中转站，我会直接用第二种，也就是 API Key。

当然也可以先不管，我自己是把 CC Switch 配好以后，直接跳过了认证界面。

CC Switch 现在支持的工具，官方仓库里写得很清楚：

图片

  • • Claude Code

  • • Codex

  • • Gemini CLI

  • • OpenCode

  • • OpenClaw

它不是拿来替代 Codex 的，而是帮你管理这些工具的供应商配置。这里只是刚好拿 Codex 举例。

你可以直接理解成：

  • • Codex 负责干活

  • • CC Switch 负责切线路和管配置

接下来在 CC Switch 里加一个 Codex 配置

我自己的做法是在 CC Switch 里给不同工具分别建供应商。这里如果你要配 Codex，目标应用就选 Codex，然后看下面几项。

图片

名字

名字随便起，但我一般会起得很直白：

  • • 官方

  • • 中转A

  • • 包月-Codex

  • • 按量-GPT54

后面切换的时候，能少看错。

Base URL 怎么填

这里填你中转站提供的根地址，通常就长这样：

https://your-relay.example.com/v1

这里注意两点：

  • • 一般填到 /v1 就够了

  • • 不要自作主张改成奇怪路径，除非中转站文档明确要求

API Key 填什么

这里就填你的中转站 Key，不一定非得是官方 OpenAI Key。

大多数时候，Codex 这里只认一个名字：

OPENAI_API_KEY

也就是说，就算你接的是中转站，最后写到本地时，通常也还是 OPENAI_API_KEY 这个名字。

模型这项别乱填

这一项别图省事乱填。

这里填的一定得是你中转站真的支持、而且适合给 Codex 用的模型名。常见写法可能是：

  • • gpt-5.4

  • • gpt-5

  • • gpt-5-mini

  • • gpt-5.3-codex

  • • codex-mini-latest

但到底能不能用，要看你的中转站有没有映射这个模型。

我一般就是这么看：

  • • 先看中转站文档

  • • 再看它是否明确支持 Codex

  • • 最后再决定模型名

剩下那些配置怎么办

如果 CC Switch 里还有别的配置项，先用默认值也行。想稳一点的话，可以把推理强度设成：

high

做代码修改、重构、排查问题这类事时，high 一般会更稳一点。

说到底，它改的是哪些文件

图片

按我这台机器现在的情况，Codex 的核心配置主要落在下面两个文件：

  • • ~/.codex/config.toml

  • • ~/.codex/auth.json

如果你不用 CC Switch，那平时其实就是你自己手动维护这两个文件。

CC Switch 做的事，说白了就是把图形界面里填的内容，替你同步到这两个地方。

比如一个很常见的 Codex 自定义 provider 配置，大概就长这样：

model_provider = "custom"
model = "gpt-5.4"
model_reasoning_effort = "high"
disable_response_storage = true

[model_providers.custom]
name = "custom"
wire_api = "responses"
requires_openai_auth = true
base_url = "https://your-relay.example.com/v1"

对应的认证文件通常像这样：

{
  "OPENAI_API_KEY": "sk-your-relay-key"
}

这里可以留意两行：

wire_api = "responses"
requires_openai_auth = true

这说明 Codex 这条链路，不是随便找一个 OpenAI 兼容聊天接口就一定能跑通。

所以还是那句话，优先选明确兼容 Codex / Responses API 的中转站。

配完以后怎么试

当你在 CC Switch 里把新的 Codex 供应商设成当前使用后，我一般是这么做：

cd /path/to/your/project
codex

如果你只是想先试一下，也可以先跑一个非交互命令：

codex exec --skip-git-repo-check "用一句话介绍当前目录的内容"

我为什么会重开终端，其实也很简单。

CC Switch 的说明里提到过，对大多数工具来说，切换供应商后最好重启终端或者重启对应 CLI，配置才会完全生效。Claude Code 例外一点，但 Codex 这边我一般还是直接重开。

后面有空的话，再折腾本地代理

如果你只是单一中转、单一 Key，前面的做法其实就够用了。

但如果你有下面这些需求，那就可以再看看 CC Switch 的本地代理能力：

  • • 想在多个中转之间快速切换

  • • 想做自动故障切换

  • • 想统一走本地一个固定入口

  • • 想保留用量日志或排查请求

在这种模式下，CC Switch 会在本地起一个代理端口，例如：

http://127.0.0.1:15721

然后再由它把请求转发到你选中的中转站。

这样做有几个明显的好处：

  • • Codex 侧配置更稳定

  • • 中转切换集中在 CC Switch

  • • 出问题时更好排查

不过对大多数人来说，这属于后面的事。如果你现在只是想先跑通，那先用前面的“直接切供应商”方案就够了。

几个我自己觉得特别容易踩的坑

能启动，但一跑任务就报接口错误

我一般先怀疑下面两件事：

  • • 你的中转站不支持 Responses API

  • • 你填的模型名根本不在这个中转站的可用列表里

在 CC Switch 里明明切成功了，但 Codex 还是旧配置

先做这几步：

如果还不行，再检查：

  • • ~/.codex/config.toml 有没有被更新

  • • ~/.codex/auth.json 里的 Key 有没有被更新

之前用的是官方登录，现在切中转以后有点乱

这种情况挺常见的，一般是旧认证状态还留着。

可以先执行：

codex logout

然后回到 CC Switch 重新切一次供应商，再重新打开 codex。

Base URL 看着没错，但还是不工作

很多人会忽略下面这几个小问题：

  • • 地址最后是否需要 /v1

  • • 是否误填成了某个文档页地址

  • • Key 是否属于另一个平台

  • • 该模型是否需要白名单或单独开通

如果你不想看太多原理，直接照这个顺序来就行：

这套流程跑通以后，后面你再换中转站，基本就不用自己手改 ~/.codex/ 这两个文件了。

我自己现在用下来，如果你本来就经常换中转、换模型、换 Key，但又不想天天改配置文件，那这套方式确实挺省心。

它的好处不在于让 Codex 变强，说到底还是下面这几件事：

  • • 让你的中转切换更省事

  • • 让配置管理更可视化

  • • 出问题时更容易排查

你记住一句话就差不多了：

Codex 负责干活，CC Switch 负责切线路，而你选的中转站得真的兼容 Codex 这条链路。

后面如果你还想看，我也可以继续补这两个方向：

  • • CC Switch 里给 Codex 配 MCP 的方法

  • • Codex + 中转站 + 本地代理接管的完整进阶玩法

avatar
文章
阅读
粉丝