Codex CLI 配置第三方 API 的注意事项

一个关键区别：接口形态

Codex CLI 依赖 OpenAI 的 Responses API（/v1/responses），而不是更常见的 Chat Completions（/v1/chat/completions）。

这个区别很重要，因为：

绝大多数中转站只实现了 Chat Completions。 它是最通用的标准，几乎人人都有。但 Responses API 较新，实现它的站少得多。

结果就是：一个站可能「网页版能用、Chat API 能用」，但 Codex CLI 配上去就 404。

先做这一步验证

curl -s -o /dev/null -w "%{http_code}\n" -X POST https://站点域名/v1/responses \
  -H "Authorization: Bearer 你的key" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o","input":"hi"}'

• 200 / 400 → 端点存在
• 404 / 405 → 该站不支持，Codex CLI 无法使用

配置要点

一、base_url 的写法

不同工具的 base_url 习惯不同，有的要带 /v1，有的不带。配错了表现为 404。

不确定时两种都试一次，哪种返回 200 用哪种。这是最快的判断方式。

二、认证头

Codex CLI 用 Authorization: Bearer，不是 Anthropic 那套 x-api-key。不要混用。

三、模型名

Codex CLI 默认请求的模型名可能与站点提供的别名不一致。如果报「模型不存在」，去查该站 /v1/models 的实际 id。

「能用但不完全能用」的三种情况

这是最需要留意的：基础的 chat 请求正常，但特定功能失败。原因是站点只做了「最小可用」的协议实现。

情况一：不支持工具调用

Codex CLI 会大量使用函数调用（读取文件、执行命令）。如果站点没有正确透传 tool 相关字段，工具调用会失败或返回空。

表现：模型能聊天，但无法操作文件。

情况二：不支持流式

Codex CLI 期待流式返回。如果站点缓冲了整个响应再返回：

• 功能上「能用」（最终结果一样）
• 体感上很差（长时间无输出，然后一次性全出来）
• 某些情况下会因超时被判失败

情况三：不支持推理参数

如果你用的是推理模型，站点可能丢掉 reasoning 相关参数，导致：

• 思考预算设置不生效
• 返回结构里缺字段，客户端解析失败

怎么判断站点是「完整实现」还是「最小实现」

一个实用的方法：用你真实的工作流跑一遍，而不是只测「你好」。

具体来说：

• 让它读一个文件（测工具调用）
• 让它改一个文件（测写入）
• 让它跑一条命令（测执行）
• 观察输出是逐步出现还是一次性出现（测流式）

四项都正常，才算真的可用。

如果找不到支持 Responses 的站

有三个选择：

1. 换工具 —— 用只依赖 Chat Completions 的同类工具，兼容性会好很多
2. 走官方 —— 官方 API 自然支持，代价是支付与网络门槛
3. 自建网关 —— 用一个支持协议转换的网关（如 LiteLLM 这类）把 Responses 转成 Chat Completions

第 3 条对技术要求高一些，但能同时解决「协议兼容」和「不想依赖单一中转站」两个问题。

相关阅读

• Claude Code 接入中转站完整配置教程（含排错）
• OpenAI 协议兼容性：chat/completions 和 responses 的区别
• Cursor 与 Cline 使用中转站的配置要点