Codex CLI 多线路接入实战

当 ChatGPT Plus 账户在 Codex 中的可用额度用完后，Codex CLI 还能不能继续工作？已经通过 ChatGPT 账号登录 Codex CLI，如何切换到 9router 进行代理？如果没有通过 ChatGPT 账号登录，又能不能直接使用 DeepSeek 或其他 API？今天记录一下自己的这个小问题进行分享。自己是 Windows + PowerShell 实操，从 Profile 设计、API Key 配置，到 Responses API 兼容性、401/403/404 排障，整理出一套可复用的多线路方案。

Codex CLI 多线路接入

让人困惑的，不是模型，而是“线路”

这次折腾 Codex CLI，起点很普通：我的 ChatGPT Plus 账户在 Codex 中的本周可用额度用完了，但手上还有 9router 的 OpenGo 套餐，想让 Codex 继续工作。

最初我以为，只要把模型名从一个名字改成另一个名字就可以。很快我就发现，事情没有这么简单：

ChatGPT Plus 登录，和 API Key 认证不是一回事；
模型名，和模型实际走的 provider 不是一回事；
/v1/models 能访问，也不代表 Codex 一定能调用；
模型回答“我是谁”，也不一定可信；
一个 API 平台支持 Chat Completions，不代表它支持 Codex 当前需要的 Responses API。

稳定的做法，不是反复改主配置，而是把不同线路拆成不同 Profile。这样，ChatGPT Plus、9router 和其他中转站各走各的，切换时只换一个参数。

三条起点问题 - 一个解法

一、先建立一个正确的模型：账号、线路、模型是三层东西

很多教程把“登录”“中转”“选模型”混在一起讲，导致配置时很容易走错。实际应该拆成三层：

层级	解决的问题	典型内容
认证方式	你凭什么访问服务	ChatGPT 登录、API Key
provider 线路	请求发到哪里	OpenAI、9router、其他中转站
模型	具体使用哪个模型	`ocg/minimax-m3`、`deepSeek-v4-flash`

可以把它想成手机拨号：账号是身份，provider 是运营商，模型是你拨打的号码。只改模型名，不一定会换运营商；只改 Key，也不一定能访问正确的接口。

排障流程 - 认证到模型的检查链

二、配置最终应该长什么样？

我的用户级配置最终分成三个文件：

C:\Users\我的用户名\.codex\config.toml
C:\Users\我的用户名\.codex\9router.config.toml
C:\Users\我的用户名\.codex\proxy.config.toml

它们不是三个完全独立的 Codex 安装，而是“基础配置 + 覆盖层”的关系：

config.toml
    ├── + 9router.config.toml  → 9router Profile
    └── + proxy.config.toml    → 其他中转站 Profile

config.toml 继续保存审批策略、沙箱、MCP、skills、plugins、通知等全局设置。Profile 只需要写 provider、模型、地址和认证。

9router Profile

文件：

C:\Users\我的用户名\.codex\9router.config.toml

典型结构：

model_provider = "9router"
model = "ocg/minimax-m3"
model_reasoning_effort = "medium"

[model_providers.9router]
name = "9Router OpenGo"
base_url = "http://127.0.0.1:20128/v1"
experimental_bearer_token = "我的 9router API Key"
wire_api = "responses"

启动：

codex --profile 9router --dangerously-bypass-approvals-and-sandbox resume --last

切换模型：

codex --profile 9router --dangerously-bypass-approvals-and-sandbox resume --last -m "ocg/deepseek-v4-flash"

codex --profile 9router --dangerously-bypass-approvals-and-sandbox resume --last -m "ocg/gpt-5.6-luna"

codex --profile 9router --dangerously-bypass-approvals-and-sandbox resume --last -m "ocg/minimax-m3"

通用 Proxy Profile

文件：

C:\Users\我的用户名\.codex\proxy.config.toml

结构：

model_provider = "proxy"
model = "MODEL_ID"
model_reasoning_effort = "medium"

[model_providers.proxy]
name = "Provider Display Name"
base_url = "https://provider.example/v1"
experimental_bearer_token = "API_KEY"
wire_api = "responses"

以后接入其他中转站时，通常修改四项：

model = "模型 ID"
name = "平台显示名称"
base_url = "中转站 API 根地址/v1"
experimental_bearer_token = "API Key"

启动：

codex --profile proxy --dangerously-bypass-approvals-and-sandbox resume --last

账号 · 线路 · 模型三层结构

三、已经通过 ChatGPT 账号登录 Codex CLI，应该怎么切换？

继续使用 ChatGPT Plus 登录线路

不带 Profile：

codex --dangerously-bypass-approvals-and-sandbox resume --last

查看登录状态：

codex login status

需要重新登录时：

codex login

临时切换到 9router 线路

codex --profile 9router --dangerously-bypass-approvals-and-sandbox resume --last

这不会注销 ChatGPT 账号，也不会删除 Codex CLI 的 Plus 登录状态。Profile 只是让这一次运行改走另一条 provider 线路。

切回 ChatGPT Plus 线路

codex --dangerously-bypass-approvals-and-sandbox resume --last

因此，不需要为了切换线路反复执行 login 和 logout。

四、没有通过 ChatGPT 账号登录，能不能使用 Codex CLI？

可以，但要区分两种做法。

做法 A：使用 API Key 登录

Codex CLI 支持 API Key 登录。实际使用时，应通过安全的输入或标准输入提供 Key，不要把 Key 直接写进项目文件。

这种方式适合直接使用官方 API Key。它不等同于 ChatGPT Plus 登录，也不会自动获得 ChatGPT 网页端权益、云端任务或连接器权限。

做法 B：不登录账号，直接使用自定义 Profile

对于中转站和第三方平台，更适合使用 Profile：

model_provider = "proxy"
model = "MODEL_ID"

[model_providers.proxy]
name = "Other Proxy"
base_url = "https://provider.example/v1"
experimental_bearer_token = "API_KEY"
wire_api = "responses"

启动：

codex --profile proxy --dangerously-bypass-approvals-and-sandbox resume --last

这里的关键是：Codex 不需要先登录 ChatGPT，直接按 Profile 中的 provider 地址和 Key 发请求。

五、第一次踩坑：`env_key` 不是 API Key

最容易写错的是这一行：

env_key = "sk-真实Key"

env_key 表示“环境变量名称”，不是 Key 内容。于是 Codex 会尝试寻找一个名字叫 sk-真实Key 的环境变量，并报：

Missing environment variable: `sk-...`

环境变量模式应该是：

env_key = "OTHER_PROXY_API_KEY"

再在 PowerShell 中设置：

$env:OTHER_PROXY_API_KEY = "真实 API Key"

如果追求方便、接受明文存储，直接写入模式应该是：

experimental_bearer_token = "真实 API Key"

两种模式二选一，不能混写。

直接写 Key 的风险

直接写入 Profile 很方便，但 Key 会以明文存在于文件中。因此：

不要把 Profile 复制到项目目录；
不要提交到 Git；
不要上传到网盘或截图分享；
不要把配置文件全文发给别人；
Key 一旦出现在日志或聊天中，应立即撤销并重新生成。

六、第二次踩坑：`/v1/models` 成功，不代表 Codex 一定能用

验证一个中转站，不能只看模型列表。

我后来把检查分成四层：

1. 配置文件是否存在
2. API Key 是否非空
3. GET /v1/models 是否返回 200
4. POST /v1/responses 是否可用

其中 /v1/models 返回 200，只能说明地址和认证基本可用。Codex 真正发送请求时，还会调用：

POST /v1/responses

如果平台只支持：

POST /v1/chat/completions

那么当前 Codex Profile 不能直接接入。需要通过 9router、LiteLLM 或其他网关做协议转换。

七、为什么 `wire_api` 只能写 `responses`？

我当前使用的 Codex CLI 版本是 0.146.0。在这个版本的自定义 provider 配置中：

wire_api = "responses"

是可用的协议设置。

不能写成：

wire_api = "chat_completions"

也不能在同一个 provider 里同时写两种协议。因为这不是“模型选择”问题，而是请求格式问题：

Responses API       /v1/responses
Chat Completions    /v1/chat/completions

如果一个平台同时支持两者，优先让 Codex 使用 Responses API；如果只支持 Chat Completions，就需要中间网关。

八、第三次踩坑：模型说自己是谁，不一定可信

在测试过程中，我问模型“现在使用的是什么模型”，它曾经回答自己是另一个模型。这个答案不能作为可靠证据。

更可靠的判断顺序是：

Codex 界面顶部和底部显示的模型；
中转站后台的请求日志；
API 响应中的模型字段；
模型自我描述。

例如界面显示：

DeepSeek-V4-Flash medium

说明当前 Codex 选择的是 DeepSeek-V4-Flash。模型回答“我是 GPT-5.6-sol”，可能是代理映射、系统提示词或模型自我识别错误。

九、常见错误速查表

错误	优先检查什么	通常意味着什么
`401 Unauthorized`	Key、认证字段、Base URL	认证失败
`Missing environment variable`	`env_key` 是否误填成 Key	环境变量名称配置错误
`403 RegionError`	上游区域、套餐、模型路由	上游拒绝请求
`404 /v1/responses`	地址、协议、是否只支持 Chat Completions	接口不兼容或地址错误
`Model metadata not found`	不一定需要处理	Codex 缺少第三方模型元数据
`MCP startup interrupted`	MCP 服务和启动耗时	MCP 初始化中断，未必是模型问题
SQLite disk I/O error	是否有多个 Codex 进程占用数据库	本地状态库暂时锁定或异常

排障时不要一次改很多地方。先判断错误属于认证、网络、上游策略、协议，还是本地状态库。

十、推理强度 `medium` 要不要保留？

配置中的：

model_reasoning_effort = "medium"

对支持推理控制的模型有意义。一般来说：

low 更快，消耗较少；
medium 适合日常开发；
high 更适合复杂规划，但速度和消耗会增加。

不同第三方模型对这个字段的处理不同：有的平台会忽略，有的平台会转换，有的平台可能报参数错误。通用模板如果追求兼容，可以删掉这一行；已经验证能正常工作的 Profile 可以保留。

十一、为什么不建议把整个 `config.toml` 复制到两个 Profile？

因为主配置中通常还有很多与线路无关的内容：

MCP server；
skills 与 plugins；
hooks；
审批策略；
沙箱；
通知；
日志和本地状态；
其他全局行为。

Profile 只需要覆盖 provider 相关字段。这样做有两个好处：

第一，修改全局审批或 MCP 时只改一处；第二，切换 provider 时不会意外覆盖权限和项目行为。

优先级可以理解为：

命令行参数 > Profile 文件 > config.toml > Codex 默认值

例如命令行加入：

--dangerously-bypass-approvals-and-sandbox

就会覆盖配置文件中原本的审批和沙箱设置。

基础配置 + Profile 覆盖层 !

十二、推荐的日常操作清单

使用 ChatGPT Plus

codex --dangerously-bypass-approvals-and-sandbox resume --last

使用 9router/OpenGo

codex --profile 9router --dangerously-bypass-approvals-and-sandbox resume --last

使用其他中转站

codex --profile proxy --dangerously-bypass-approvals-and-sandbox resume --last

指定模型

codex --profile 9router --dangerously-bypass-approvals-and-sandbox resume --last -m "ocg/minimax-m3"

需要彻底隔离上下文时

切换 provider 后，如果旧会话上下文让结果看起来混乱，可以不使用 resume，直接新开会话：

codex --profile proxy --dangerously-bypass-approvals-and-sandbox

十三、最后的判断框架

以后接入一个新平台，我会按这个顺序做：

第一步：确认认证方式，是 ChatGPT 登录还是 API Key。
第二步：确认 Base URL，不要把 /responses 写进 base_url。
第三步：确认模型 ID，大小写和前缀以 /v1/models 为准。
第四步：确认平台是否支持 /v1/responses。
第五步：配置独立 Profile，不覆盖主 config.toml。
第六步：先验证 /v1/models，再启动 Codex 实际请求。
第七步：用界面显示、日志和响应字段判断真实线路。

这次最值得留下的经验，不是某一条固定命令，而是这套排查顺序：

先分清认证，再确认线路；
先确认协议，再选择模型；
先验证接口，再进入会话。

结语

Codex CLI 的多线路配置并不复杂，复杂的是一开始容易把账号、provider、模型和协议混成一件事。

把它们拆开后，结构就清楚了：ChatGPT Plus 是一条登录线路，9router 是一个自定义 provider，其他中转站则各自拥有独立 Profile。全局权限和 MCP 继续留在主配置里，线路信息放在 Profile 中。

这样以后遇到额度用完、模型切换或平台更换，不需要重新折腾整个 Codex 环境，只需要选择对应 Profile，并确认目标平台支持正确的 API 协议。

如果你也在使用 Codex CLI、第三方 API 或中转站，最值得先检查的不是模型名字，而是这一句：

这个平台到底支持 /v1/responses，还是只支持 /v1/chat/completions？

这个问题，往往比“我该选哪个模型”更早决定配置能不能成功。

参考资料

Codex 自定义模型提供商配置 (https://learn.chatgpt.com/docs/config-file/config-advanced#custom-model-providers)
9router Codex CLI 接入说明 (https://github.com/decolua/9router/blob/master/gitbook/content/en/getting-started/quick-start.md)

如果你觉得这篇内容有价值，欢迎点个赞、点个在看，也欢迎转发给更多朋友。

我是 AI杨侦探，持续记录 AI、技术、产品和产业变化里那些真正值得看、值得想的事。

谢谢你读到这里，我们下次见。

Codex CLI 多线路接入实战：一次讲清