OpenAI Codex 测评：价格、能力与六项限制（2026 年 8 月核实）

Codex 每月 $20 的订阅只有在你把它当成一套编码系统、而不是自动补全时才值得：本地仓库作业、隔离的 worktree、云端委派和代码评审都收在同一个账号下。如果你主要想要编辑器里的行内补全，GitHub Copilot Pro 每月 $10；如果你只想要一个以终端为中心的智能体、不需要 ChatGPT 的整套工作流，Claude Code Pro 每月 $20。

OpenAI Codex 是什么

Codex 是 OpenAI 的软件开发智能体：你给它一个仓库的访问权限和一个目标，它就能检视文件、修改代码、执行命令、测试自己的成果，并把一份 diff 交回给你评审。这个产品远比一个模型或一个聊天窗口宽。同一个账号可以触达终端客户端、IDE 扩展、ChatGPT 桌面应用里的本地项目、隔离的 Git worktree、托管的云端环境、GitHub 上的拉取请求评审，以及从另一台设备发起的远程操控。这份宽度就是它存在的理由。如果你需要的只是敲代码时的补全，Codex 的大部分能力都用不上。

Codex 与 Claude Code、Cursor、GitHub Copilot 速览对比

当本地执行、异步云端作业和评审必须共用同一套运作模型时，这四者里最合适的就是 Codex。如果你的工作流只有一个主导面，专精工具反而更划算。

价格这一行并不能替你做决定。Codex Go 比三个专精工具的付费档都便宜，但 OpenAI 自己把它描述为轻量访问。对预期会经常使用智能体的开发者来说，实际的基准线是 Plus。终端就是产品时，Claude Code 站得住；编辑器就是产品时，Cursor 站得住；当补全、GitHub 策略和 $10 的入门价比一套从本地贯通到云端的统一智能体更重要时，Copilot 站得住。

如果你要做的是二选一的深入判断，本站的 Codex 与 Claude Code 对比把终端行为、自主性和成本拆得更细。

谁该买 Codex，谁该跳过

Codex 面向的是这样一类开发者和技术负责人：他们想要一个智能体，能在亲手做的本地作业和委派出去的作业之间来回切换，而不必每次都重搭工作流。

手里有两条在跑产品线的融资创始人收益最清楚。紧急的支付 bug 留在 IDE 里本地处理，依赖升级交给一个 worktree，测试套件清理送去云端，然后在同一个桌面工作区里评审每一份结果。优势不在于 Codex 能改文件——任何像样的编码智能体都能改。优势在于这些活儿可以跑在不同的执行环境里，并以可评审的 diff 形式回来。

拉取请求队列越排越长的中型企业 CTO，在评审经验被锁在少数几位资深工程师身上时应当考虑 Codex。GitHub Code Review 能从 AGENTS.md 应用仓库专属规则，把评论集中在 P0 和 P1 问题上，并从拉取请求的评论直接发起一次云端修复任务。对组织数据来说，合理的下限是 Business 档，因为 OpenAI 默认不会用 Business 的输入和输出训练模型，而且这个档位还带来工作区管理能力。年付的最低配置是两个席位，也就是每年 $480。

跨多台设备统筹工程的资深管理者，只有在环境里本来就有一台常醒的开发主机时，Remote 才有价值。手机可以启动或引导那台主机上的作业，但手机替代不了主机。它适合查看一次通宵的迁移，或者在离开工位时响应一次告警。它不是无服务器云端的替代品。

主要活在终端里的独立开发者应该先去比 Claude Code。Claude Pro 每月 $20，而 Claude Code 在连接 IDE 和命令行工具的同时，刻意把重心放在终端。Codex 也能在那里干活，但如果你打算用的只有本地终端会话，为它更宽的产品面付钱就是浪费。

主要想要行内补全的开发者应该把 Codex 排除在主力采购之外。GitHub Copilot Pro 每月 $10，把交互留在你已有的编辑器和 GitHub 里。Cursor Pro 每月 $20，适合聊天、行内编辑和智能体作业都该待在一个 AI 原生编辑器内部的情况。

尚未批准云端仓库访问的受监管团队不该硬推。Codex 可以用 API 密钥在本地运行，但 API 密钥模式不包含 Codex cloud、GitHub Code Review 和 Slack。在安全团队评估连通式工作流期间，先用本地 CLI 或 IDE 自动化，或者选择与你的数据政策相匹配的 Business、Enterprise 管控。

能力 1：本地 CLI 与 IDE 编码循环

Codex 在本地最强的时候，是任务有一个界定清楚的结果和一项可执行的检查。“把结账流程做好一点”太模糊。“追踪支付 webhook 的重复投递，加一个幂等保护，跑支付测试，然后给我最小的 diff”，则同时给了它目标、边界和证据。

Codex CLI 直接作用于你机器上已有的仓库。它能读文件、改文件，并执行你自己在用的那套测试、lint、类型检查和 Git 命令。哪些改动和命令可以不经批准就执行，由权限和沙箱设置决定。这套本地模型对敏感仓库很关键：作业发生在你掌控的环境里，而不是一个新配出来的托管容器里。

下面这套流程，能把一个本地智能体从聊天框变成真正好用的工程循环。

1. 1

   只给它一个窄的故障

   打开仓库，启动 codex，只描述一个可观测的问题。点名失败的测试、路由、报错或改变了的行为。原因不明时，要求它先检视再动手改。

2. 2

   把安全边界说清楚

   告诉 Codex 什么必须保持不变、哪些迁移或公开接口不可触碰、哪些命令算作验证。长期有效的仓库规则写进 AGENTS.md；任务专属的约束写进提示词。

3. 3

   要求可执行的证据

   索取相关的测试、类型检查或 lint 命令。没有通过检查的 diff 只是一个提议；diff 加上那条确切的检查，才是另一位工程师能够评估的结果。

4. 4

   评审 diff，再评审这份评审

   查看被改动的文件，并对未提交的改动运行 /review。专用的评审器只报告问题、不动工作树，因此第二轮编辑值不值得，由你来判断。

Codex 的 IDE 扩展更适合相关上下文已经打开的小改动。附上一段选中内容或一个文件，提出改动要求，然后在代码旁边查看结果。当任务从一个组件膨胀成跨仓库迁移时，把它委派出去，而不是让编辑器里的聊天变成一场没有边界的会话。

真正的墙是上下文纪律。大仓库会诱使智能体读得比任务需要的更多，这会抬高用量，还会混进不相干的指令。把 AGENTS.md 就近嵌套在它所管辖的代码旁边，点名目标文件或服务，并在大范围改动前索要一份简短计划。上下文并不是越多越好。

能力 2：worktree 与云端委派

当彼此独立的任务拿到彼此独立的环境时，Codex 就从助手变成了作业协调者。Git worktree 是同一个仓库的另一份检出，让一个任务能改动某个分支，而不与你主目录里的分支相撞。Codex 在本地可以用 worktree，在云端可以用隔离容器。

设想一次分三部分的发版：升级支付 SDK、修一个不稳定的浏览器测试、加上审计日志。支付改动触及公开契约，需要盯得紧，所以留在本地。不稳定的测试给一个隔离的 worktree。审计日志送去 Codex cloud，那里的环境会检出指定的分支或提交，运行安装脚本，执行任务，并返回摘要和 diff。合并之前三份都要评审。

只有当安装过程写得明确时，云端环境才是可复现的。锁定运行时版本，把依赖装在安装脚本里，并把仓库的验证命令写进长期有效的指令。Codex 会把配置好的容器缓存最多 12 小时，这能缩短后续的安装时间，但改动安装、维护、变量或密钥都会让这份缓存失效。

托管环境的墙立在网络与密钥的边界上。安装脚本有互联网访问权限，而智能体本身的互联网访问默认关闭，除非你启用受限或不受限访问。密钥对安装脚本可见，随后会在智能体阶段之前被移除。这个设计比把所有凭据都放在触手可及的地方安全，但也意味着：需要在执行过程中调用受保护服务的任务，得换一种架构。环境变量会持续可用，但会加大暴露面；否则这个任务就需要一个经过批准的工具或服务边界。

能力 3：本地与 GitHub 代码评审

Codex Code Review 最有用的定位是一位聚焦的第二评审人，而不是 CI 或代码归属的替代品。本地 /review 和 GitHub 评审解决的是相关但不同的问题。

本地代码评审可以检视相对基线分支的 diff、全部未提交改动、某个特定提交，或者自定义标准。它不会改动工作树。这让它在提交前那一刻特别有用：问它正确性、数据丢失风险和缺失的测试，然后自己挑出哪些问题值得改。

GitHub 代码评审需要为该仓库配置好 Codex cloud。在拉取请求里提及 @codex review，或者开启自动评审。GitHub 这条流程刻意只发布 P0 和 P1 的问题，把评论集中在严重风险上，而不是格式偏好上。

有价值的部分是仓库专属的判断力。在对应的 AGENTS.md 里放一节 ## Code Review Rules，根目录的规则写得宽一些，服务级规则放进嵌套文件。支付服务可以规定 webhook 处理必须保持幂等，并点名安全的重试路径。公开 API 服务可以禁止在兼容窗口关闭之前删除某个响应字段。这些正是资深评审人反复强调的检查，因为通用静态分析器推断不出这些来龙去脉。

OpenAI 报告称，在其主要评估中，带规则引导的变体找回了所需自定义问题的 98%，而基线对照组是 58.3%。这是厂商自己跑出来的结果，不是独立基准测试，但它支撑一个很窄的结论：简洁的仓库规则确实能显著改善一次针对已知不变量的评审。OpenAI 同时也说明，测试、分支保护和必需审批才是真正的强制手段。

从评审到修复的完整闭环是这样的。

1. 1

   把两三条有后果的规则写下来

   挑那些资深评审人反复解释的不变量。格式和确定性检查留给 CI。

2. 2

   发起评审

   在一个有代表性的拉取请求上使用 @codex review；等规则确实产出有用信号之后，再打开自动评审。

3. 3

   质疑证据

   读它引用的文件和行号，复现这个风险，把经不起检视的问题驳回。严重度标签并不能让一个论断变正确。

4. 4

   窄范围修复

   问题成立时，@codex fix the P1 issue 可以用这个拉取请求作为上下文发起一次云端任务。评审它的 diff，并在合并前重跑那套同样的强制检查。

能力 4：跨设备远程操控

当开发机器不在身边时，Codex Remote 才有价值，但真正干活的电脑始终是那台主机。Remote 可以把一台醒着的 Mac 或 Windows 主机，接到 iOS、Android 或另一台受支持桌面上的 ChatGPT。仓库、shell、凭据、工具、沙箱设置和审批策略都由主机提供。

设想一位不在电脑旁的值班工程师，此时一个后台任务开始失败。他可以从手机上打开常开主机里的项目，让 Codex 检视日志、追踪失败路径，然后等一份诊断。一条安全的提示词会停在证据和一份补丁提议上。工程师可以换到更大的屏幕上评审 diff，必要时把这段对话交接给另一台主机，再走常规的部署管控。

Remote 也支持 SSH 主机上的项目，并能在已连接的主机之间交接对话和 Git 状态，在目标端使用一个 worktree。当依赖装在一台专用开发机上时，这很好用；而当笔记本休眠、网络中断或桌面应用被关掉时，它就很脆弱。需要无人值守的持续作业时，请用一台常开主机或 Codex cloud，别把个人笔记本当成基础设施。

本站的 Codex Remote 分析更详细地讨论了主机与控制平面之间的取舍。

Codex 价格：现行全部档位

Codex 的价格用美元看很简单，用用量看很复杂。现行的 Codex 官方定价页列出了八条购买路径，而订阅里究竟包含多少实际工作量，会随模型选择、上下文、推理、工具、检索和缓存而变化。

各档位的细节和额度机制，请看本站专门的 Codex 价格指南。2026 年 8 月 2 日，OpenAI 各个线上页面在价格上是一致的；在包含的消息数区间上则不一致。

ChatGPT Work 和 Codex 共享用量。本地消息和云端对话也共享同一个五小时窗口，而且 OpenAI 表示可能还有额外的每周限额。Plus 和 Pro 用户在用完包含额度后可以购买额度包。采用弹性定价的 Business、Edu 和 Enterprise 工作区可以购买工作区额度。因此这份订阅是一个容量上限会浮动的组合包，而不是一个固定数量的已完成工程任务。

单个限定任务的 API 成本

API 定价按 token 计费，因此更容易建模，但 API 密钥模式会失去那些让 Codex 与众不同的云端集成。这个对比只适用于本地或脚本化的作业。

假设一个限定任务在短上下文下消耗 100,000 个未缓存输入 token 和 20,000 个输出 token。按标准费率：

• GPT-5.6 Luna 花费 $0.044：输入 0.1 x $0.20 加上输出 0.02 x $1.20。
• GPT-5.6 Terra 花费 $0.44：输入 0.1 x $2 加上输出 0.02 x $12。
• GPT-5.6 Sol 花费 $1.10：输入 0.1 x $5 加上输出 0.02 x $30。

按这些假设，$20 大约能买到 455 个 Luna 任务、46 个 Terra 任务或 19 个 Sol 任务（向上取整到刚好达到门槛的那个任务）。和订阅的比较并不对等：Plus 包含那些互相连通的 Codex 产品面，而 API 密钥模式不含云端任务、GitHub 评审和 Slack。这笔账适合用来算一个 CI 作业或 SDK 流程，不适合用来给整个产品估值。

决定是否购买的那些限制

Codex 有六项实质限制，对不合适的买家来说，任何一项都足以推翻这笔采购。

1. 可用容量不够可预测

美元价格是固定的，能干多少活却不是。上下文长度、模型、推理、检索、工具和缓存都会改变用量。OpenAI 目前有两个官方页面公布着互相矛盾的 Plus 区间。额度包能缓和这个上限，但它并不能让一个 $20 的档位对一个想给一个月智能体作业做预算的开发者变得可预测。

对决策的影响： 不要因为“可以用更多”这句承诺就买 Pro。留在 Plus，完整观察一个工作周期里登录后的用量面板，只有当中断的代价超过差价时才升级。

2. API 密钥是一个本地产品，不是订阅的替代品

API 密钥支持 CLI、SDK 和 IDE 扩展，模型用量按 API 费率计费。它不含 Codex cloud、GitHub Code Review 和 Slack。一家公司没法绕开工作区档位、只付 token 钱，却还指望拿到整套连通的产品。

对决策的影响： 在 CI 和受控的本地自动化上，API 密钥胜出。当委派和连通式评审是结果的一部分时，ChatGPT 订阅胜出。

3. 云端密钥在智能体开工之前就消失了

云端密钥对安装脚本可见，并在智能体阶段之前被移除。这是一条刻意划下的安全边界，但它推翻了一个常见假设：把生产凭据存成密钥，并不意味着智能体在解决任务时能调用那个受保护的服务。环境变量会保留，但会让会话暴露得更多。

对决策的影响： 通过经过批准的工具边界使用短期凭据，或者把任务设计成让安装阶段取回执行阶段所需的东西，而不在触手可及处留下一个可复用的密钥。如果这套架构不可接受，就把任务留在本地。

4. 个人版的数据控制需要检查两处

OpenAI 表示，个人 ChatGPT 和 Codex 账号的内容可能被用于训练模型，除非用户主动选择退出。Codex 另有一项关于“在完整环境上训练”的独立开关，而且改动 ChatGPT 的通用设置或隐私门户里的设置，并不会改变那个完整环境的开关。Business、Enterprise 和 API 的输入与输出默认不用于训练，除非组织主动选择加入。

对决策的影响： 处理专有代码的个人用户，应当同时确认通用数据控制和 Codex 的完整环境设置。需要一个组织级默认值的公司，应当使用 Business、Enterprise 或 API，而不是指望每位员工都把个人账号配置正确。

5. 评审仍是建议，不是强制

GitHub Code Review 聚焦在 P0 和 P1 问题上。自定义的仓库规则能改善它去看什么，但模型仍可能漏掉缺陷，或者把某个问题说重了。OpenAI 那个 98% 的结果，是厂商针对一套既定自定义规则做的评估，不是对陌生仓库的保证。

对决策的影响： 保留必需测试、分支保护、code owners 和人工审批。让 Codex 在这些关卡之前添加信号，而绝不取代它们。

6. Remote 的可用性不会超过它的主机

主机一旦休眠、断网或关闭应用，远程操控就停了。个人笔记本用来偶尔操控还算方便，但作为常在线的执行目标很糟糕。

对决策的影响： 远程流程请用一台常开的开发主机，或者把后台作业挪到 Codex cloud。不要围绕一台可能正在休眠的笔记本去搭事故处理流程。

结论：OpenAI Codex 测评总评，什么时候值得买

当你平常的一周里出现了下面这些当中的 至少两项，Codex 就值得付钱：

• 你希望终端和 IDE 里是同一个智能体。
• 你需要在自己继续工作的同时用隔离 worktree 或云端委派。
• 你想要本地评审，外加带仓库规则的 GitHub P0/P1 评审。
• 你需要从另一台设备操控作业，或在主机之间交接。

如果只符合其中一项，就选专精工具。以终端为中心的智能体，Claude Code 是更干净的选择；编辑器是重心时，Cursor 更好；补全和 GitHub 辅助上，GitHub Copilot 最经济。

对多数独立开发者来说，每月 $20 的 Plus 就是正确的 Codex 档位。Free 和 Go 是评估路径。每月 $100 的 Pro 5x，只有在实测到限额压力确实在打断工作之后才说得通。每月 $200 的 Pro 20x 属于持续的多智能体使用，而不是偶尔写写代码。Business 的实际下限是两个席位每年 $480，在管理能力和默认不训练很重要时是合适的起点。API 密钥用于按量计费的本地或程序化作业，代价很明确：云端功能会消失。

最后一条规则很直白：为那套连通的工作流买 Codex，而不是因为一个 OpenAI 模型会写代码。模型会换。你持续在付钱的，是围绕这项工作的那套操作系统。

常见问题

Codex 写代码到底好不好用？

当提示词点明了结果、约束和可执行的检查时，Codex 在范围明确的仓库作业上很好用。它能检视、修改、执行工具并交回一份 diff。但生产环境的改动仍然需要测试和人工评审。

Codex 比 ChatGPT 更好吗？

Codex 并不是简单地跟 ChatGPT 竞争。它是更大的 ChatGPT 产品内部那条面向开发者的工作流，带有仓库访问、diff、终端命令、worktree、云端环境和代码评审。

Codex 的评审能做什么？

本地 /review 会在不改动工作树的前提下，检视相对基线分支的 diff、未提交改动、某个提交或自定义标准。GitHub Code Review 会发布聚焦的 P0 和 P1 问题，并能应用 AGENTS.md 里的仓库规则。

Codex 现在赶上 Claude Code 了吗？

当本地、云端、应用、评审和远程这几个面必须协同工作时，Codex 是更强的那套系统。而对于希望终端始终处在每一次交互中心的开发者，Claude Code 依然是更锋利的候选。

Codex 有哪些缺点？

主要缺点是用量浮动、官方额度区间互相矛盾、云端功能需要 ChatGPT 订阅、云端安装与密钥方面的约束、个人版数据控制另有一套开关，以及 Remote 依赖一台醒着的主机。

Codex 和 Claude 哪个更好？

需要跨多个面连通的工作流时选 Codex；主要需要一个以终端为先的编码智能体时选 Claude Code。按月付费的话，个人认真使用的入口价，Codex Plus 和 Claude Pro 都是 $20。

Codex 的评审命令是什么？

在 Codex CLI 或 IDE 扩展里使用 /review。你可以选择相对基线分支的评审、未提交的改动、在支持的场景下选择某个特定提交，或者自定义指令。评审器只报告问题，不编辑工作树。

Codex 怎么评审 GitHub 上的拉取请求？

把仓库接到 Codex cloud，在设置里启用 Code Review，然后在拉取请求里提及 @codex review。自动评审可以在拉取请求进入评审状态时触发，作用域收窄的 AGENTS.md 规则还能补上仓库专属的检查。

订阅通讯，获取 Claude Code 与 Codex 的配置清单。