Claude Code 与 Codex CLI——实际差异是什么，以及如何选择

Claude Code 和 Codex CLI 在同一位置解决同一个问题：终端中的代理读取代码库、提出编辑建议、运行命令并迭代结果。它们的区别在于背后的模型系列、扩展能力以及配置方式，而不在于工作的基本形态。

本页面比较两者实际存在的差异，提供决策规则而非简单结论，并说明如何使用同一个密钥运行两者，以便你根据自己的代码自行评估。

并排比较

两者都在积极开发，迭代速度也都很快，因此应将任何功能列表（包括本列表）视为一个快照。结构性差异（模型系列、API 能力、配置格式）相对稳定；具体功能则不是。

如何选择

不存在一个普遍适用的答案来判断哪个能生成更好的代码——这取决于语言、代码库和任务，而已发布的正面对比基准通常很少能反映你的代码库。你可以预先决定的是哪个工具更符合你的工作方式：

坦诚的建议是：两者都可以免费安装，因此请将自己代码库中的同一个真实任务分别交给两者，然后比较差异。花一个下午这样做，比任何比较文章（包括本文）都更有参考价值。

运行成本

成本取决于模型和代理步骤数量，而不是 CLI 本身。两个工具都会在每一步重新发送系统提示、任务历史和最新文件上下文，因此每个令牌的费率会以相同方式累积。请比较你实际会运行的模型——下表中的 Claude 栏对应Anthropic 的官方 API 定价，其中列出了每个模型的每令牌费率以及典型代理步骤的计算成本：

一个典型的代理步骤大约包含 25,000 个输入令牌和 1,200 个输出令牌，因此按这些费率计算，一个 20 步任务约为 $1.30，运行于 claude-sonnet-4-6。不要只相信单个示例，请将自己的数字代入成本计算器——以输出为主的工作会改变排名，因为这些模型之间的输出费率差异大于输入费率差异。

自定义端点：一个实际存在的不对称性

两个工具都支持第三方端点，但支持程度并不相同，这也是目前两者之间最实际的差异。

Claude Code 会读取 ANTHROPIC_BASE_URL 并使用 Anthropic Messages API，而许多供应商都提供该 API。将它指向其他位置只需设置三个环境变量，无需额外软件（设置指南）。

Codex CLI 更为严格。其 model_providers 区块包含一个 wire_api 键，而当前配置参考将 responses 列为唯一支持的值——这意味着自定义供应商必须在 /v1/responses 提供 OpenAI 的 Responses API，而不是更常见的 /v1/chat/completions：

# ~/.codex/config.toml — wire_api accepts only "responses"
model          = "gpt-5-6-sol"
model_provider = "kunavo"

[model_providers.kunavo]
name     = "kunavo"
base_url = "https://api.kunavo.com/v1"
env_key  = "KUNAVO_API_KEY"
wire_api = "responses"        # requires POST /v1/responses upstream

# A provider that serves only /v1/chat/completions still cannot be
# configured here, whatever base_url you give it.

这仍然排除了大多数 OpenAI 兼容网关，因为它们只提供 /v1/chat/completions。这就是为什么这么多声称“适用于任何 OpenAI 兼容端点”的供应商会在 Codex CLI 中悄然失败：基础 URL 可以接受，但每个请求都会返回 404。

Kunavo 同时提供两种能力——OpenAI 兼容聊天端点，以及位于 /v1/responses 的 Responses API——因此上述配置可以原样使用；gpt-5-6-sol（每 1M 个令牌 $2.00 / $12.00）也可以从 Codex CLI 运行，以及从 Cursor、Kilo Code 和 Cline 运行。完整演示（包括 Codex 读取密钥所用的环境变量）位于 Codex CLI API 密钥指南。

有一点值得了解：由于 Codex 绑定的是协议而不是模型系列，因此该端点背后的任何聊天模型都可以响应，包括 Claude。将 Codex CLI 指向 claude-opus-5 后，可以完整运行端到端流程，并保留工具调用；网关会在 Responses API 和 Messages API 之间进行转换。代价是 Codex 的不透明 reasoning 项目在非 GPT 上游中没有对应项，会被丢弃，因此模型在不同轮次之间会失去其私有草稿区；可见的对话记录不受影响。

因此，这种不对称性比看起来更窄，但并未消失：Claude Code 几乎可以与任何 Messages-API 供应商协作，而 Codex CLI 只能与少数实现了 Responses API 的供应商协作。如果使用自己的端点（出于成本、路由或治理原因）是你在两者之间选择的重要原因，这一点仍然值得权衡。如果成本是决定因素，Anthropic 官方 API 价格表列出了每个 Claude 层级相对于 Anthropic 自行公布费率的每 1M 个令牌成本，而这个数字才真正会影响代理式编码账单。

相邻比较

本页面不回答另外两个相邻问题。Codex 与 ChatGPT 的比较关注的是应开启哪个 OpenAI 能力界面，而不是应安装哪个 CLI——答案取决于共享套餐额度以及代理消耗额度的速度。Cline 与 Claude Code 的比较则是将终端换成编辑器侧边栏，此时决定性差异是计费方式，而不是协议。

两者能否驱动对方的模型？

一个方向可以。Codex CLI 可以运行 Claude 模型，前提是通过提供 Responses API 的网关——它绑定的是网络协议而不是模型系列，因此在上面的供应商区块中设置 model = "claude-opus-5" 后即可端到端运行，包括工具调用。代价是 Codex 的不透明 reasoning 项目在发送到非 GPT 上游的过程中会被丢弃，模型因此失去不同轮次之间的私有草稿区。

反方向更困难：Claude Code 期待 Messages API 上的 Claude 系列标识，因此要从它访问 GPT，需要本地路由器——这会增加一个环节，并造成部分功能损失，因为只有在原生路由上 cache_control 才会未经翻译地传递。Claude Code 路由器指南介绍了何时值得进行这项设置，以及何时只需更换基础 URL 即可。

让每个工具运行在其设计所针对的模型系列上，仍然是更简单的默认选择。但如果你希望在 Claude 后面使用 Codex CLI 的沙箱功能，这种组合目前可用——请参阅 Codex CLI API 密钥指南。

常见问题