OpenCode 对比 Codex CLI:终端 AI 编程智能体全面对比(2026)

太长不看: OpenCode 和 Codex CLI 都是终端优先的编程智能体,它们在一个决定下游一切的问题上意见相左:你被允许运行哪些模型。OpenCode 是一个模型无关的框架(75+ 供应商任选,会话中途也能切换),采用 MIT 许可,还额外附带一个桌面应用。Codex CLI 是 OpenAI 自家的智能体,用 Rust 编写,默认锁定 OpenAI 的端点,拥有本类别中最强的沙箱,配置文件也给其他供应商开了一扇门,只不过这扇门比几个版本之前要窄。如果你的技术栈是多模型的,或者你不信任供应商锁定,那就选 OpenCode。如果你身处 OpenAI 之中、想要最严密的安全保障,那就选 Codex。本文剩下的篇幅讲的是这个选择真正咬人的那些边角,包括我们用同一个网关分别跑两者时发现的一处。

太长不看:你该选哪个?

如果你已经清楚自己的约束条件,可以跳过这篇长文。下面是按场景给出的决策。

两者都免费且开源。两者都在你的终端里运行。分歧在于理念,而非价格。

五分钟对比

下面是那些会改变两者日常使用手感的规格,均于 2026-07-29 对照各项目的仓库和文档核实过。

那张表里有两行承担了大部分分量。“默认模型:无”就是 OpenCode 的整个立论。“默认模型:GPT-5-Codex”就是 Codex 的整个立论。其余一切都从这两个事实衍生而来。

OpenCode:模型无关的框架

OpenCode 把模型当成一个运行时参数,而不是一个产品决策。它出厂时不带任何默认供应商。首次运行时你连接一个,之后模型就是一样你按会话、甚至按消息从 75+ 供应商列表里挑选的东西,这些供应商通过 models.dev 接入。Claude、GPT、Gemini、GLM、本地的 Ollama 构建,它们全都只是 /models 里的条目而已。

这种设计有几个实实在在的后果。

你不被任何人的路线图绑住。 当一个新模型发布并出现在 models.dev 注册表里时,它无需客户端更新就会出现在 OpenCode 里。框架并不在乎模型是谁造的,这正是重点所在。

它是一个完整的智能体,而不是薄壳封装。 OpenCode 运行一个 plan 智能体和一个 build 智能体,一个按键就能切换。plan 模式是只读的,会提出方案却不碰文件;build 模式则执行。它集成了 Language Server Protocol 服务器,所以对于 TypeScript、Python、Rust、Go 以及一长串其他语言,模型看到的是真实的类型信息和编译器诊断,而不是从原始文本里瞎猜。它支持 MCP,支持自定义工具,并能在同一个项目上并行运行多个会话。

它不只是一个终端工具。 除了 TUI,还有一个桌面应用和一个 IDE 扩展。如果你想要智能体循环但不想要终端,OpenCode 给你留了入口。Codex 则更偏重终端和 exec 流水线。

它咬人的地方:模型无关意味着模型决策由你负责,连同它的失败模式一起。把 OpenCode 指向一个弱的或配置错误的供应商,你就得到弱的或配置错误的输出,而框架不会替你从糟糕的路由选择里救场。供应商注册表里还有一个已知的粗糙之处。在全新安装上,一个刚添加的供应商可能在第一次调用时压根不出现,因为注册表缓存还没写入。运行一次 models 命令给它预热,问题就解决了。在你写脚本做自动化配置并假定第一次调用就是权威结果之前,这一点值得知道。

OpenCode 把模型当成一个运行时参数,而不是一个产品决策。正是这一个选择,让它在多模型场景中胜出,却在”开箱即用”这件事上败下阵来。

Codex CLI:OpenAI 的第一方智能体

Codex CLI 出自 OpenAI,而它的每一个设计决策都透着这一点。它用 Rust 编写,所以是一个快速的单一二进制文件,而不是一个 Node 进程。它出厂就指向 OpenAI 自家的端点和经 Codex 调校的 GPT-5 模型,对默认用户而言这意味着零配置:安装、用你的 ChatGPT 账户或一把 API key 认证,然后开始写代码。

它的强项集中在信任与安全上。

沙箱是本次对比中最好的。 Codex 用操作系统级原语隔离命令执行,macOS 上是 seatbelt,Linux 上是 Landlock 和 seccomp,并在其上叠加审批模式。你来决定给智能体多长的绳子:仅建议、在工作区内自动编辑,或在沙箱内完全自动。智能体运行的 rm 是被构造性地限制住的,而不是靠模型选择规矩行事。如果你自动批准任务,或者运行任何不是你自己写的东西,那份隔离就是你真正花钱买的功能。

它是 OpenAI 技术栈里的第一方公民。 /review 命令在不碰你工作树的情况下做内联代码审查。子智能体让工作并行化。Codex Remote 让你从 ChatGPT 手机应用驱动一台已连接的 Mac 或 Windows 主机。/import 命令把 Cursor 和 Claude Code 的设置、MCP 服务器、插件和命令拉进 Codex,让迁移从一个周末变成一条命令。

尽管默认值如此,它并没有锁定在 OpenAI 上。 在 ~/.codex/config.toml 里加一个指向兼容网关的 [model_providers.<id>] 块,Codex 就会调用那个网关所提供的任何东西。门是有的。你只是得亲手把它打开,这就是它与 OpenCode 之间诚实的区别,后者的门默认就是开着的。

问题在于哪种协议算兼容,而这个答案变了。Codex 过去接受 wire_api = "chat",意味着任何 Chat Completions 端点。那个值没了。在 0.146.0 的源码里 WireApi 枚举只剩下一个变体 Responses,而传入 chat 不是被忽略,而是一个硬性的启动错误:

wire_api = "chat" is no longer supported. How to fix: set wire_api = "responses" in your provider config.

那条消息链接到 discussion #7782,标题是 “Deprecating chat/completions support in Codex”,作为一次弃用来说已经算相当明确了。Chat Completions 是几乎通用的方言。Responses API 则不是。那次变更之前写的每一篇教程现在都会产出一个加载不了的配置,而每一个只代理 Chat Completions 的网关如今都触达不到了。

它咬人的地方:OpenAI 优先的默认值在你想离开之前都是一种安慰。在 Codex 里,模型自由是一项配置任务,而不是一份菜单,而且协议边界是真实存在的,还朝着对 OpenAI 有利的方向移动了。你不能把 base_url 指向 Anthropic 的原生 API 还指望它能用,因为那不是 Responses API。你要么把非 OpenAI 模型路由到一个支持 Responses 的网关,要么就根本别路由它们,而且正如下一节所示,“支持 Responses”结果是一个逐模型的属性,而不是逐网关的。

正面交锋:那些改变你日常的差异

六个维度,以及每个维度的胜者。这里的”胜者”指的是”对大多数为该轴做优化的人而言更好”,而不是一个放之四海皆准的定论。

扫一眼那一列,规律很清楚。OpenCode 在自由度和独立性上胜出。Codex 在安全性以及在单一供应商内的即开即用上胜出。没有哪个维度上其中一个在所有方面都绝对领先,这正是为什么推荐是有条件的,而不是一个单一的名字。

实测的设置与日常工作流

忘掉那些编造出来的质量评分吧。诚实、可核查的差异在于每个工具完成同一件事需要多少步骤,以及摩擦落在哪里。

用一个非默认模型拿到第一个回复。 在 OpenCode 里,你导出供应商的 key,打开 TUI,运行 /models,然后挑一个。没有文件要编辑。在 Codex 里,非 OpenAI 模型意味着先在 config.toml 里写一个 model_providers 块,然后核查你想要的模型是否真的通过 Responses API 提供,再选中它。对于多模型场景,OpenCode 在设计上步骤更少;而如果你想要的模型是 OpenAI 自己的,Codex 步骤更少,因为那时候是零步骤。

任务进行中切换模型。 OpenCode 在一个运行中的会话里通过 /models 实时切换。Codex 用每次调用的 --model 来切换模型,或者加载一个命名 profile,那更像是选车道而不是轻推方向盘。如果你的工作流是”用贵模型思考,然后让便宜模型去磨改动”,OpenCode 让这变成一个两秒钟的开关。

运行一条 shell 命令。 OpenCode 请求权限。Codex 在你设定的审批模式下于沙箱内运行它,所以即便你说了”是”,隔离依然成立。表面上是同一个提示,底层的爆炸半径却天差地别。

项目指令。 两者都读取 AGENTS.md,这也是 Cursor 等工具采用的同一约定,所以一个已经带有它的仓库在任一智能体里都能不加改动地工作。这是过去一年里悄然而至的胜利:你项目的智能体指令如今可以在工具之间移植了。

首次运行,并排对比

感受这个差异最快的方式,是把两个都装上并拿到第一个回复。OpenCode,配上一个你自备的模型:

npm i -g opencode-ai
export OFOX_API_KEY=sk-your-key      # any OpenAI-compatible provider works
cd your-project
opencode                              # /models to pick, Tab to toggle plan/build

Codex,在 OpenAI 的默认值上,这正是它优化的场景:

npm i -g @openai/codex
cd your-project
codex                                 # authenticates with ChatGPT or OPENAI_API_KEY

注意每条命令的前提假设。OpenCode 的顺畅路径期望你指定一个供应商,并回报你一份菜单。Codex 的顺畅路径期望你是个 OpenAI 用户,并回报你零设置。两者都没错。它们是在为不同的首次用户做优化,而安装体验告诉你各自团队心里想的是哪种用户。

可扩展性:MCP、Skills 与子智能体

绕过模型问题,两个智能体在形态上有着相似的可扩展性,只是在各个角落成熟度不同。这正是”第一方”开始以打磨程度而非理念显现出来的地方。

两者都支持 MCP,所以同样的上下文服务器和工具集成能插进任一个里。Codex 偏向一个结构化的扩展模型,Skills、带命名空间的 MCP 以及斜杠命令,都透着一种被一支在做产品的团队所治理的感觉。OpenCode 偏向多种入口,在终端、桌面窗口和你的编辑器里给你同一个智能体,外加一个 /share 流程用于把会话交给队友。只读方面的表现恰好映照了它们各自的理念:OpenCode 给你一个可以翻进去的专用 plan 智能体,而 Codex 给你一个 /review 命令,能在不碰你工作树的情况下做批评。目标相同,两种表达。

关于速度有一条实用的说明。Codex 是一个 Rust 二进制文件,所以启动快、常驻轻。OpenCode 跑在 Node 上,在模型思考时你不会以任何方式察觉到它慢,但它在空闲时是一个更重的进程。对大多数人来说模型的延迟远大于工具的延迟,这一点从来不重要。如果你要给一队无头智能体写脚本,那它可能就重要了。

一把 Key,两份截然不同的模型菜单

这就是两种理念不再抽象的部分,也是我们不再猜测、真刀真枪跑起来的部分。两个智能体都接受一个网关 base URL,所以一把 key 就能覆盖 Claude、GPT、Gemini 和开放权重模型的计费。但一把 key 不能保证两个智能体都能触达它们全部。我们在 2026-07-29 把两者都对着 ofox.ai 搭好,结果并不对称。

OpenCode:一个环境变量,零配置文件。 因为 ofox 是 models.dev 注册表里的一个内置供应商,只要 key 在场,OpenCode 就会立刻发现它。

export OFOX_API_KEY=sk-your-key
opencode            # /models now lists ofox/... entries, pick one

这就是全部设置。没有文件,没有供应商块,而且因为 OpenCode 使用 Chat Completions,网关提供的一切都在菜单上。

Codex CLI:一个配置块,以及一份比你预期更短的菜单。 Codex 需要在 ~/.codex/config.toml 里把网关声明一次。

model = "openai/gpt-5.5"
model_provider = "ofox"

[model_providers.ofox]
name = "ofox.ai"
base_url = "https://api.ofox.ai/v1"
env_key = "OFOX_API_KEY"
wire_api = "responses"
requires_openai_auth = false

wire_api = "responses" 不是一种偏好,它是当前 Codex 版本唯一接受的值,所以你的网关必须暴露一个兼容 Responses 的端点,而不只是 Chat Completions。requires_openai_auth = false 是默认值,能阻止 Codex 展示 ChatGPT 登录流程,让它转而从 env_key 读取 key。完整的键列表在 Codex config reference。

实际跑起来的结果

我们把 Codex 0.146.0 指向那份配置,用 codex exec --sandbox read-only 让每个模型用一个词回复。这是我们下场前没料到的结果。

注意那种不对称,因为它是本文里最有用的东西。GLM 是这四个里唯一被目录提前标记为不支持的。Claude、DeepSeek 和 Grok 全都列在 /v1/responses 之下,却照样失败。端点列表是一个预筛选,不是一份保证。

三种不同的失败,一个主题。GLM 压根触达不到模型,因为网关没有在 /v1/responses 下代理它。DeepSeek 和 Grok 能触达,但拒绝了 Codex 附在每个请求里的 reasoning.encrypted_content 字段,而那个字段在 client.rs 里是硬编码的,并没有作为设置暴露出来,所以没有配置逃生舱可用。Claude 能触达且接受加密内容,却被 Codex 那个自由格式的 apply_patch 工具的结构给卡住了。

我们随后在同一把 key、同一个网关、同一台机器上,把完全相同的提示词跑过 OpenCode 1.18.9。Codex 触达不到的那四个模型全都正常回复了,SDK 发起的一次朴素的 chat/completions 调用也一样。这就是关键信号:这是 Codex 和网关层之间的一道协议接缝,不是模型问题,也不是网关宕机。

在你上手之前如何核查。 网关的模型列表会报告每个模型是在哪些端点下提供的,所以你可以提前筛查,而不用去调试一个配置:

curl -s https://api.ofox.ai/v1/models \
  -H "Authorization: Bearer $OFOX_API_KEY" \
| jq -r '.data[] | select(.supported_endpoints | index("/v1/responses")) | .id'

在 2026-07-29,那返回了 67 个模型 ID。目录里有 123 个条目,但其中 18 个是图像、视频、嵌入和转录模型,它们两个文本端点都不暴露,所以真正重要的分母是 105 个文本模型:102 个通过 chat completions 提供,67 个通过 Responses 提供。这两个集合几乎完全重叠,但并非嵌套关系。64 个模型两者都提供,而恰好有三个是仅 Responses 的(openai/gpt-5.2-codex、openai/gpt-5.3-codex、openai/gpt-5.4-pro)。

按系列来数,Claude、GPT、DeepSeek、Doubao 和 Grok 的文本模型是全程覆盖的。Qwen(21 个里的 10 个)、MiniMax(9 个里的 7 个)和 Kimi(5 个里的 2 个)是部分覆盖的,所以即便在一个你以为受支持的系列里,逐模型核查依然重要。Gemini 和 GLM 在任何版本上都没有 Responses 条目,Kimi K3 也没有。把那份列表当作 Codex 能触达范围的外边界,然后再去测试具体的模型,因为正如上面那张表所示,被列出是必要条件而非充分条件。

这一切都不影响 OpenCode,如果你的模型策略确实是混合的,这就是选它的实际论据。同样值得直白地说:这是一个 Codex 侧的协议决策,它一次性搞砸了每一个只支持 Chat-Completions 的网关,而随着网关构建出更完整的 Responses 垫片,它大概会逐渐消解。这是关于当下的一个真实情况,不是一个永久的定论。

同一把 key 从代码里也能用,这正是你在不让任何一个智能体介入的情况下,对同一任务 A/B 两个模型的方式。同样的 base URL,换一个字符串,不用操心协议接缝。

Python:在两个模型上跑同一任务

from openai import OpenAI

client = OpenAI(
    api_key="sk-your-ofox-key",
    base_url="https://api.ofox.ai/v1",
)

task = "Refactor this function to remove the nested loop, keep behavior identical."

for model in ["anthropic/claude-sonnet-5", "z-ai/glm-5.2"]:
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": task}],
    )
    print(f"\n=== {model} ===")
    print(resp.choices[0].message.content)

Node:同样的形态

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: "sk-your-ofox-key",
  baseURL: "https://api.ofox.ai/v1",
});

const task = "Write a Postgres migration to add a nullable created_by column.";

for (const model of ["anthropic/claude-sonnet-5", "openai/gpt-5.5"]) {
  const resp = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: task }],
  });
  console.log(`\n=== ${model} ===`);
  console.log(resp.choices[0].message.content);
}

模型 ID 是字面量。它们就是你粘进 OpenCode 里的东西,也是你粘进 Codex 里、给它当前能触达的那一子集用的东西。这就是可移植性说辞的诚实版本:智能体是框架而模型是变量,但如今这两个智能体里只有一个能让你自由地改变那个变量。

这要花多少钱

上面用到的三个模型的网关价格,于 2026-07-29 从 ofox 模型页面读取。以下为每百万 tokens 的价格。

我们核查那天 GPT-5.5 正带着一个 20% 的促销折扣,所以 $4 和 $24 才是你实际会被计费的数字,而划掉的 $5 和 $30 是标价。促销会过期;别在半年后还信这张表,去读模型页面。另外两个没有应用折扣。

这张表的重点不是绝对数字,而是差距。在促销价下,GLM-5.2 的输出成本大约是 GPT-5.5 的五分之一,所以”用强模型思考,用便宜模型磨”这套工作流是一笔真实的账单差异,不是四舍五入的误差。OpenCode 让那个切换成为一个按键。而 Codex 按上面的测试,压根触达不到这三个里的两个,这正是同一个发现以发票上的一行、而非一条错误字符串的形式出现:成本这根杠杆只对那个能拉动它的智能体存在。

如果你想要一张图而不是一段话来表示这个选择,它可以坍缩成两个问题。

何时选 OpenCode

如果下面任何一条描述的是你,那就选 OpenCode。你把工作路由到多个模型供应商之间,并希望那是一份菜单而非一次迁移。你不愿把自己的日常主力工具绑在一家公司的定价和路线图上。你也想在终端之外用这个智能体,在桌面应用或你的编辑器里。你看重这个项目是 MIT 许可、社区治理的,没有默认供应商来收过路费。模型无关的设计是你来这里的理由,而如果你不会用到它,那你是在为自己不需要的灵活性买单。

何时选 Codex CLI

如果你已经身处 OpenAI 的世界之中、想要默认值就直接好用,如果你自动批准或批量运行任务、需要 Codex 那个比本类别中任何人都加固得更充分的操作系统级沙箱,或者如果你正从 Claude Code 迁走、想让导入命令替你干那些枯燥的部分,那就选 Codex CLI。Rust 二进制文件很快,安全故事是这里最强的,而且与 ChatGPT 应用及 Codex Remote 的第一方集成在 OpenCode 这边没有对等物。如果你很少越过 OpenAI 自家的模型,那么解锁其他供应商的配置工作就是你永远不会去做的工作,那也没关系。如果你确实预期会越过它们,那么在你据此制定计划之前,先读一下上面的协议那一节,因为如今那扇门打开后通向的房间,比文档所暗示的要小。

何时两个都不是正确选择(以及该用什么替代)

如果你几乎不离开编辑器,那么一个终端智能体就是对你工作流的一笔税,带内联助手的 Cursor 或 Zed 会更趁手。如果你的活儿是一条固定流水线,生成这个、审查那个、按计划发布,那你压根不想要一个交互式智能体,你想要的是一个直接调用模型 API 的脚本,这也是为什么上面的代码示例在不让任一 CLI 介入的情况下调用网关。而如果你在比较四个智能体而不是两个,我们的四路终端智能体对比在 Codex 之外还涵盖了 Claude Code 和 DeepSeek TUI,并摆出了价格和日常主力工具的角度。

终端智能体是一件为特定口味服务的特定工具:你想要模型在你的 shell 里,盯着你的文件,运行你的命令。如果那不是你的口味,那这两个都不是你的答案,而伸手去拿错误形态的工具,是一个比在两者之间选错的那个更常见的错误。

FAQ

页面元数据里的上面那些问答请参见;同一组内容在这里为读者和搜索引擎再渲染一遍。如果你在这两个智能体之间做选择,能定下大多数决策的两个事实是:OpenCode 是模型无关的而 Codex CLI 是 OpenAI 优先的,以及 Codex 拥有更硬的沙箱而 OpenCode 拥有更宽的模型菜单。

参考资料

• github.com/anomalyco/opencode(旧的 sst/opencode 路径会 301 跳转到此)
• github.com/openai/codex
• codex-rs/model-provider-info/src/lib.rs at rust-v0.146.0
• openai/codex discussion #7782
• opencode.ai/docs
• Codex CLI config reference
• models.dev
• ofox model pages

延伸阅读:OpenCode 设置指南、Codex CLI 自定义模型供应商、Codex config.toml 深度解析,以及从 Claude Code 迁移到 Codex。