命令行 Agent

用 Responses API 把 Codex 接入国产模型

当前 Codex 只支持 Responses 协议。本文给出可复制的配置、环境变量与接口探测命令,并说明遇到只支持 Chat Completions 的网关时应该如何处理。

核查日期 2026-10-26适用于
Codex CLI 0.154.0

先说结论

当前 Codex 的 wire_api 只支持 "responses"。 "chat" 已被移除,填写它会导致启动配置报错。KimiSeek 提供 /v1/responses,可以使用下文的配置直接接入。

30 秒决策表

网关能力处理方式
提供 /v1/responses使用 "responses"
只有 /v1/chat/completions换用支持 Responses 的网关,或配置提供 Responses 接口的转换层
不确定先用下方命令探测路径和返回体

为什么 Codex 默认走 responses

Codex 向 /responses 发送请求,并处理 Responses 的工具调用和流式事件。Chat Completions 的请求与事件结构不同;只改 wire_api 不能让当前 Codex 调用 Chat Completions。模型能力还取决于上游模型与网关实现,接口返回成功并不等于每项工具能力都已验证。

前置条件

  • Node.js 20 或以上
  • Codex CLI:npm install -g @openai/codex
  • 一个 KimiSeek API Key(ks- 开头),在控制台创建

Step 1 · 写配置文件

配置文件在 ~/.codex/config.toml,没有就新建:

TOML · ~/.codex/config.toml
model = "deepseek-v4-pro-0813"
model_provider = "kimiseek"

[model_providers.kimiseek]
name = "KimiSeek"
base_url = "https://api.kimiseek.app/v1"
env_key = "KIMISEEK_API_KEY"
wire_api = "responses"

三个容易踩的点:

  1. base_url 必须带 /v1。Codex 会在 base_url 后面直接拼 /responses,少写 /v1 就会打到 https://api.kimiseek.app/responses,得到 404。
  2. env_key 是环境变量名,不是 key 本身。这里写的是变量名 KIMISEEK_API_KEY,真正的值放环境变量里。
  3. model 必须用 catalog 里真实存在的 id。写错会拿到 model not found,已下线的模型同样会报这个错。

Step 2 · 设置环境变量并启动

Shell
export KIMISEEK_API_KEY="ks-your-key"

codex

想临时换模型,直接改 config.toml 里的 model,或者用 codex --model <id> 覆盖。

Step 3 · 确认 key 有效

Shell
curl https://api.kimiseek.app/v1/models \
  -H "Authorization: Bearer ${KIMISEEK_API_KEY:?Set KIMISEEK_API_KEY before running this command}"

返回里能看到模型列表,说明 key 与网络都没问题。这一步的意义是把「鉴权问题」和「协议问题」分开——否则 404 时你分不清是 key 错了还是路径错了。

Step 4 · 30 秒探测 responses

Shell · OpenAI Responses
curl https://api.kimiseek.app/v1/responses \
  -H "Authorization: Bearer ${KIMISEEK_API_KEY:?Set KIMISEEK_API_KEY before running this command}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-pro-0813",
    "input": "Explain what a base URL is in one sentence.",
    "max_output_tokens": 256,
    "stream": false
  }'
  • 返回 200,JSON 中包含 output 数组 → Responses 路由可用,接着验证实际任务和工具调用。
  • 返回 404 → 检查 base_url 是否包含 /v1,再检查返回体是路由不存在还是模型不存在;不能仅凭状态码判定协议支持。
  • 返回 401 → 回到 Step 3,检查凭证。

如果网关只有 Chat Completions

保持 wire_api = "responses"。需要换到提供 /v1/responses 的网关,或在中间配置兼容 Responses 的转换层。不要改成已移除的 "chat"。

常见报错

报错成因修法
unexpected status 401 Unauthorized: Missing bearerenv_key 指向的环境变量没设置,或变量名拼错确认 KIMISEEK_API_KEY 在当前 shell 里可见
unexpected status 404 Not Foundbase_url 少写 /v1,或网关没有 /v1/responses补 /v1 并检查错误正文;若确实缺少 Responses 路由,换用兼容网关或转换层
stream disconnected before completion流式响应被中途截断:本地代理、公司网关或超时检查 HTTP 代理设置,换网络重试
model not foundmodel 写成了别名之外的错名,或用了已下线 id用 catalog 里的完整 id,例如 deepseek-v4-pro-0813

更多协议层报错见 报错对照表。

成本

Codex 的用量特点是输入远大于输出:每次执行都要把上下文重新发一遍。DeepSeek V4 Pro 定价按峰谷两档、人民币每百万 tokens 计:

时段输入缓存输入输出
谷时¥4.5¥0.45¥13.5
峰时¥9¥0.9¥27

峰谷差正好一倍。跑批量的重构任务,排在谷时能省一半。具体模型与实时价格以 价格页 为准,那里直接读的是模型目录的配置。

适用版本与核查

配置已在 Codex CLI 0.154.0 验证;核查日期:2026-10-26。协议支持以官方配置说明为准。

常见问题

用了中转,还需要 Codex-Bridge 这类桥接工具吗?

不需要。桥接工具存在的意义,是把 Responses 请求在本地翻译成 Chat Completions 再发出去,用来对付「只实现了 chat completions」的网关。KimiSeek 自己实现了 /v1/responses,桥接层反而多一跳、多一处出错点。

为什么 base_url 一定要带 /v1?

因为 Codex 拿 base_url 直接拼路由:base_url + "/responses"。写 https://api.kimiseek.app 会打到 https://api.kimiseek.app/responses,那是站点页面不是 API。

当前 Codex 还能设置 wire_api = "chat" 吗?

不能。当前版本会拒绝该值并停止启动。请使用 responses;只有 Chat Completions 的上游需要兼容网关或转换层。

同一个 key 能同时配 Claude Code 和 Codex 吗?

可以。key 是账号级的,两个客户端只是用不同的协议路径调用同一个 key。配置方式见 Claude Code 教程。