Codex 接入 ROIBest AI：OpenAI 兼容协议怎么配

Codex 走 OpenAI 协议，和 Claude Code 不是同一条路。密钥、端点、配置方式三样都不一样，照搬 Claude Code 的做法会一路撞墙。

先把协议分组选对

ROIBest AI 按协议分组签发密钥：

Codex 需要 OpenAI 兼容分组的密钥。用错分组会返回 401，而错误信息不会提示你分组选错了——这是接入阶段最常见、也最难自己看出来的一个坑。

到控制台 → API Keys 新建密钥，选 OpenAI 兼容分组。

配置 Codex

Codex 支持自定义 model provider，配置写在 ~/.codex/config.toml：

model = "gpt-5"
model_provider = "roibest"

[model_providers.roibest]
name = "ROIBest AI"
base_url = "https://ai.roibest.com/v1"
env_key = "ROIBEST_API_KEY"
wire_api = "responses"

几个字段值得单独说：

• base_url 要带 /v1，和 Claude Code 的 ANTHROPIC_BASE_URL 正相反。Codex 会在这个地址后面直接拼 /responses，少了 /v1 就会 404。
• wire_api = "responses" 指定走 Responses API（/v1/responses）。网关同时支持 /v1/chat/completions，如果你的 Codex 版本或场景需要 Chat Completions，把这里改成 "chat"。
• env_key 是环境变量名，不是密钥本身。Codex 会去读这个变量：

export ROIBEST_API_KEY="你的密钥"

把它写进 ~/.zshrc 或 ~/.bashrc 才能长期生效。

配置项的确切写法以 Codex 官方文档为准——不同版本字段名有过调整。上面这套对应当前的 model_providers 配置形态。

先验证端点，再启动客户端

把网关问题和客户端配置问题分开排查，能省掉大量时间：

curl https://ai.roibest.com/v1/responses \
  -H "Authorization: Bearer $ROIBEST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5",
    "input": "ping"
  }'

拿到正常响应，说明密钥、分组、端点都对。这时再启动 Codex：

codex

确认用量记下来了

回控制台看用量明细。每条请求会记录模型、协议分组、输入输出 Token、缓存 Token、计费方式、费用和延迟。

这一步的意义和 Claude Code 那篇一样：它是确认请求真的走了网关的唯一方式。配置没生效时 Codex 会用原来的凭据继续工作，表面上一切正常。

常见问题

401，密钥没问题 先查分组是不是 OpenAI 兼容。再确认 ROIBEST_API_KEY 在当前 shell 里有值：echo $ROIBEST_API_KEY。

404 base_url 少了 /v1，或者多了一层（写成了 .../v1/responses）。它应该正好是 https://ai.roibest.com/v1。

模型名不被接受 可用模型取决于账户和分组，去控制台的模型广场查当前可用的名字，直接复制。

想同时留着官方配置 config.toml 里可以并存多个 provider，切换只需要改顶部的 model_provider。两套配置互不影响。

小结

Codex 和 Claude Code 的区别集中在三点：要 OpenAI 兼容分组的密钥、base_url 要带 /v1、配置在 config.toml 而不是环境变量。先 curl 一次 /v1/responses，能把绝大多数问题挡在启动客户端之前。