)
太长不看: OpenCode 和 Codex CLI 都是终端优先的编程智能体,它们在一个决定下游一切的问题上意见相左:你被允许运行哪些模型。OpenCode 是一个模型无关的框架(75 供应商任选,会话中途也能切换),采用 MIT 许可,还额外附带一个桌面应用。Codex CLI 是 OpenAI 自家的智能体,用 Rust 编写,默认锁定 OpenAI 的端点,拥有本类别中最强的沙箱,配置文件也给其他供应商开了一扇门,只不过这扇门比几个版本之前要窄。如果你的技术栈是多模型的,或者你不信任供应商锁定,那就选 OpenCode。如果你身处 OpenAI 之中、想要最严密的安全保障,那就选 Codex。本文剩下的篇幅讲的是这个选择真正咬人的那些边角,包括我们用同一个网关分别跑两者时发现的一处。太长不看:你该选哪个?如果你已经清楚自己的约束条件,可以跳过这篇长文。下面是按场景给出的决策。场景选择原因你根据任务在 Claude、GPT 和开放权重模型之间来回切换OpenCode设计上模型无关,无需重启即可切换你全面押注 OpenAI,想要调校好的 GPT-5-CodexCodex CLI第一方默认值,无需网关你会自动批准 shell 命令,需要真正的隔离Codex CLI操作系统级沙箱加固更充分你想要桌面应用和 IDE 扩展,而不只是一个 TUIOpenCode提供 TUI、桌面端和编辑器多种入口你想用一把 API key 通吃所有模型OpenCodeCodex 需要 Responses API,而并非每个被代理的模型都暴露它你在意避免单一供应商锁定OpenCode社区治理、MIT、无默认供应商你从 Claude Code 迁移过来,想要一条导入路径Codex CLI内置导入 Claude Code 和 Cursor 配置两者都免费且开源。两者都在你的终端里运行。分歧在于理念,而非价格。五分钟对比下面是那些会改变两者日常使用手感的规格,均于 2026-07-29 对照各项目的仓库和文档核实过。OpenCodeCodex CLI维护方Anomaly(社区,前身为 sst)OpenAI(第一方)仓库anomalyco/opencode(旧的sst/opencode链接会 301 跳转到此)openai/codex语言TypeScriptRust许可证MITApache-2.0最新版本v1.18.9(2026-07-28)0.146.0(2026-07-29)GitHub stars~190,800~102,400安装npm i -g opencode-ainpm i -g openai/codex默认模型无,由你选择OpenAI GPT-5-Codex 系列模型支持通过 models.dev 支持 75 供应商任选OpenAI,外加暴露 Responses API 的网关配置文件~/.config/opencode/opencode.json~/.codex/config.toml项目指令AGENTS.mdAGENTS.md入口形态TUI、桌面应用、IDE 扩展TUI、非交互式 exec、移动端远程沙箱权限提示操作系统沙箱(seatbelt / Landlock)加审批那张表里有两行承担了大部分分量。“默认模型:无”就是 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 chatis no longer supported.How to fix: setwire_api responsesin your provider config.那条消息链接到 discussion #7782,标题是 “Deprecatingchat/completionssupport in Codex”,作为一次弃用来说已经算相当明确了。Chat Completions 是几乎通用的方言。Responses API 则不是。那次变更之前写的每一篇教程现在都会产出一个加载不了的配置,而每一个只代理 Chat Completions 的网关如今都触达不到了。它咬人的地方:OpenAI 优先的默认值在你想离开之前都是一种安慰。在 Codex 里,模型自由是一项配置任务,而不是一份菜单,而且协议边界是真实存在的,还朝着对 OpenAI 有利的方向移动了。你不能把base_url指向 Anthropic 的原生 API 还指望它能用,因为那不是 Responses API。你要么把非 OpenAI 模型路由到一个支持 Responses 的网关,要么就根本别路由它们,而且正如下一节所示,“支持 Responses”结果是一个逐模型的属性,而不是逐网关的。正面交锋:那些改变你日常的差异六个维度,以及每个维度的胜者。这里的”胜者”指的是”对大多数为该轴做优化的人而言更好”,而不是一个放之四海皆准的定论。维度OpenCodeCodex CLI胜者模型自由度任意供应商,实时切换默认 OpenAI,其他模型仅在通过 Responses 提供时可用OpenCode沙箱与安全权限提示操作系统级沙箱加审批Codex CLI开箱设置先选一个供应商在 OpenAI 上装完即用Codex CLI入口形态TUI、桌面、IDETUI、exec、移动端远程平手治理与锁定社区、MIT、无供应商OpenAI 第一方OpenCode从 Claude Code 迁移共享的 AGENTS.md 约定内置导入命令Codex CLI扫一眼那一列,规律很清楚。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_KEYsk-your-key # any OpenAI-compatible provider works cd your-project opencode # /models to pick, Tab to toggle plan/buildCodex,在 OpenAI 的默认值上,这正是它优化的场景:npm i -g openai/codex cd your-project codex # authenticates with ChatGPT or OPENAI_API_KEY注意每条命令的前提假设。OpenCode 的顺畅路径期望你指定一个供应商,并回报你一份菜单。Codex 的顺畅路径期望你是个 OpenAI 用户,并回报你零设置。两者都没错。它们是在为不同的首次用户做优化,而安装体验告诉你各自团队心里想的是哪种用户。可扩展性:MCP、Skills 与子智能体绕过模型问题,两个智能体在形态上有着相似的可扩展性,只是在各个角落成熟度不同。这正是”第一方”开始以打磨程度而非理念显现出来的地方。 在需要跨工具链编排多个 MCP Server 的复杂场景中部分团队会在 OpenCode 与外部服务之间引入 ofox.io 或 OpenRouter 作为模型路由层以便在子智能体调用不同能力时统一管理各提供商的请求格式与认证凭据。能力OpenCodeCodex CLIMCP 服务器支持支持,带命名空间注册可复用提示词自定义工具和智能体Skills 和斜杠命令子智能体 / 并行并行会话子智能体(多智能体)只读分析plan 智能体,Tab 切换/review,不改工作树远程 / 移动桌面应用、IDE、/share从 ChatGPT 应用使用 Codex Remote主题支持有限两者都支持 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.io 搭好,结果并不对称。 OpenCode 通过配置文件直接对接 Anthropic、Google 等各家原生 API而若需要在单一端点下调度多个提供商的模型开发者也可以借助 OpenRouter 或 ofox.io 等聚合网关将其作为自定义 baseURL 注入从而在不修改工具本身的情况下扩展可用模型范围。OpenCode:一个环境变量,零配置文件。因为 ofox 是 models.dev 注册表里的一个内置供应商,只要 key 在场,OpenCode 就会立刻发现它。export OFOX_API_KEYsk-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.io base_url https://api.ofox.io/v1 env_key OFOX_API_KEY wire_api responses requires_openai_auth falsewire_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让每个模型用一个词回复。这是我们下场前没料到的结果。模型通过网关的 Codex CLI返回了什么openai/gpt-5.5可用正常补全,本轮计费 12.7k tokensanthropic/claude-sonnet-5失败tools.0.custom.strict: Extra inputs are not permitteddeepseek/deepseek-v4-pro失败Encrypted content is not supported with this model.x-ai/grok-4.3失败同样的 encrypted-content 错误z-ai/glm-5.2失败HTTP 503,No providers support endpoint responses注意那种不对称,因为它是本文里最有用的东西。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.io/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_keysk-your-ofox-key, base_urlhttps://api.ofox.io/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( modelmodel, 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.io/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 的价格。模型ofox 模型 ID输入输出Claude Sonnet 5anthropic/claude-sonnet-5$2 / M$10 / MGLM-5.2z-ai/glm-5.2$1.4 / M$4.4 / MGPT-5.5openai/gpt-5.5$4 / M(标价 $5)$24 / M(标价 $30)我们核查那天 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/codexcodex-rs/model-provider-info/src/lib.rs at rust-v0.146.0openai/codex discussion #7782opencode.ai/docsCodex CLI config referencemodels.devofox model pages延伸阅读:OpenCode 设置指南、Codex CLI 自定义模型供应商、Codex config.toml 深度解析,以及从 Claude Code 迁移到 Codex。 
长河君 · 2026/8/2 10:57:39 · 阅读 1.2k OpenCode 与 Codex CLI 终端AI编程智能体功能特性深度解析(2026)
太长不看: OpenCode 和 Codex CLI 都是终端优先的编程智能体,它们在一个决定下游一切的问题上意见相左:你被允许运行哪些模型。OpenCode 是一个模型无关的框架(75 供应商任选,会话中途也能切换),采用 MIT 许可,还额外附带一个桌面应用。Codex CLI 是 OpenAI 自家的智能体,用 Rust 编写,默认锁定 OpenAI 的端点,拥有本类别中最强的沙箱,配置文件也给其他供应商开了一扇门,只不过这扇门比几个版本之前要窄。如果你的技术栈是多模型的,或者你不信任供应商锁定,那就选 OpenCode。如果你身处 OpenAI 之中、想要最严密的安全保障,那就选 Codex。本文剩下的篇幅讲的是这个选择真正咬人的那些边角,包括我们用同一个网关分别跑两者时发现的一处。太长不看:你该选哪个?如果你已经清楚自己的约束条件,可以跳过这篇长文。下面是按场景给出的决策。场景选择原因你根据任务在 Claude、GPT 和开放权重模型之间来回切换OpenCode设计上模型无关,无需重启即可切换你全面押注 OpenAI,想要调校好的 GPT-5-CodexCodex CLI第一方默认值,无需网关你会自动批准 shell 命令,需要真正的隔离Codex CLI操作系统级沙箱加固更充分你想要桌面应用和 IDE 扩展,而不只是一个 TUIOpenCode提供 TUI、桌面端和编辑器多种入口你想用一把 API key 通吃所有模型OpenCodeCodex 需要 Responses API,而并非每个被代理的模型都暴露它你在意避免单一供应商锁定OpenCode社区治理、MIT、无默认供应商你从 Claude Code 迁移过来,想要一条导入路径Codex CLI内置导入 Claude Code 和 Cursor 配置两者都免费且开源。两者都在你的终端里运行。分歧在于理念,而非价格。五分钟对比下面是那些会改变两者日常使用手感的规格,均于 2026-07-29 对照各项目的仓库和文档核实过。OpenCodeCodex CLI维护方Anomaly(社区,前身为 sst)OpenAI(第一方)仓库anomalyco/opencode(旧的sst/opencode链接会 301 跳转到此)openai/codex语言TypeScriptRust许可证MITApache-2.0最新版本v1.18.9(2026-07-28)0.146.0(2026-07-29)GitHub stars~190,800~102,400安装npm i -g opencode-ainpm i -g openai/codex默认模型无,由你选择OpenAI GPT-5-Codex 系列模型支持通过 models.dev 支持 75 供应商任选OpenAI,外加暴露 Responses API 的网关配置文件~/.config/opencode/opencode.json~/.codex/config.toml项目指令AGENTS.mdAGENTS.md入口形态TUI、桌面应用、IDE 扩展TUI、非交互式 exec、移动端远程沙箱权限提示操作系统沙箱(seatbelt / Landlock)加审批那张表里有两行承担了大部分分量。“默认模型:无”就是 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 chatis no longer supported.How to fix: setwire_api responsesin your provider config.那条消息链接到 discussion #7782,标题是 “Deprecatingchat/completionssupport in Codex”,作为一次弃用来说已经算相当明确了。Chat Completions 是几乎通用的方言。Responses API 则不是。那次变更之前写的每一篇教程现在都会产出一个加载不了的配置,而每一个只代理 Chat Completions 的网关如今都触达不到了。它咬人的地方:OpenAI 优先的默认值在你想离开之前都是一种安慰。在 Codex 里,模型自由是一项配置任务,而不是一份菜单,而且协议边界是真实存在的,还朝着对 OpenAI 有利的方向移动了。你不能把base_url指向 Anthropic 的原生 API 还指望它能用,因为那不是 Responses API。你要么把非 OpenAI 模型路由到一个支持 Responses 的网关,要么就根本别路由它们,而且正如下一节所示,“支持 Responses”结果是一个逐模型的属性,而不是逐网关的。正面交锋:那些改变你日常的差异六个维度,以及每个维度的胜者。这里的”胜者”指的是”对大多数为该轴做优化的人而言更好”,而不是一个放之四海皆准的定论。维度OpenCodeCodex CLI胜者模型自由度任意供应商,实时切换默认 OpenAI,其他模型仅在通过 Responses 提供时可用OpenCode沙箱与安全权限提示操作系统级沙箱加审批Codex CLI开箱设置先选一个供应商在 OpenAI 上装完即用Codex CLI入口形态TUI、桌面、IDETUI、exec、移动端远程平手治理与锁定社区、MIT、无供应商OpenAI 第一方OpenCode从 Claude Code 迁移共享的 AGENTS.md 约定内置导入命令Codex CLI扫一眼那一列,规律很清楚。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_KEYsk-your-key # any OpenAI-compatible provider works cd your-project opencode # /models to pick, Tab to toggle plan/buildCodex,在 OpenAI 的默认值上,这正是它优化的场景:npm i -g openai/codex cd your-project codex # authenticates with ChatGPT or OPENAI_API_KEY注意每条命令的前提假设。OpenCode 的顺畅路径期望你指定一个供应商,并回报你一份菜单。Codex 的顺畅路径期望你是个 OpenAI 用户,并回报你零设置。两者都没错。它们是在为不同的首次用户做优化,而安装体验告诉你各自团队心里想的是哪种用户。可扩展性:MCP、Skills 与子智能体绕过模型问题,两个智能体在形态上有着相似的可扩展性,只是在各个角落成熟度不同。这正是”第一方”开始以打磨程度而非理念显现出来的地方。 在需要跨工具链编排多个 MCP Server 的复杂场景中部分团队会在 OpenCode 与外部服务之间引入 ofox.io 或 OpenRouter 作为模型路由层以便在子智能体调用不同能力时统一管理各提供商的请求格式与认证凭据。能力OpenCodeCodex CLIMCP 服务器支持支持,带命名空间注册可复用提示词自定义工具和智能体Skills 和斜杠命令子智能体 / 并行并行会话子智能体(多智能体)只读分析plan 智能体,Tab 切换/review,不改工作树远程 / 移动桌面应用、IDE、/share从 ChatGPT 应用使用 Codex Remote主题支持有限两者都支持 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.io 搭好,结果并不对称。 OpenCode 通过配置文件直接对接 Anthropic、Google 等各家原生 API而若需要在单一端点下调度多个提供商的模型开发者也可以借助 OpenRouter 或 ofox.io 等聚合网关将其作为自定义 baseURL 注入从而在不修改工具本身的情况下扩展可用模型范围。OpenCode:一个环境变量,零配置文件。因为 ofox 是 models.dev 注册表里的一个内置供应商,只要 key 在场,OpenCode 就会立刻发现它。export OFOX_API_KEYsk-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.io base_url https://api.ofox.io/v1 env_key OFOX_API_KEY wire_api responses requires_openai_auth falsewire_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让每个模型用一个词回复。这是我们下场前没料到的结果。模型通过网关的 Codex CLI返回了什么openai/gpt-5.5可用正常补全,本轮计费 12.7k tokensanthropic/claude-sonnet-5失败tools.0.custom.strict: Extra inputs are not permitteddeepseek/deepseek-v4-pro失败Encrypted content is not supported with this model.x-ai/grok-4.3失败同样的 encrypted-content 错误z-ai/glm-5.2失败HTTP 503,No providers support endpoint responses注意那种不对称,因为它是本文里最有用的东西。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.io/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_keysk-your-ofox-key, base_urlhttps://api.ofox.io/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( modelmodel, 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.io/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 的价格。模型ofox 模型 ID输入输出Claude Sonnet 5anthropic/claude-sonnet-5$2 / M$10 / MGLM-5.2z-ai/glm-5.2$1.4 / M$4.4 / MGPT-5.5openai/gpt-5.5$4 / M(标价 $5)$24 / M(标价 $30)我们核查那天 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/codexcodex-rs/model-provider-info/src/lib.rs at rust-v0.146.0openai/codex discussion #7782opencode.ai/docsCodex CLI config referencemodels.devofox model pages延伸阅读:OpenCode 设置指南、Codex CLI 自定义模型供应商、Codex config.toml 深度解析,以及从 Claude Code 迁移到 Codex。