如果这项工作必须在本地仓库里边看边改，先选 Claude Code：它更像一个开发者身边的本地搭档，适合在 terminal、IDE、desktop app 或 browser 会话里读大代码库、追依赖关系、改计划，并用 skills、subagents 和模型控制处理复杂重构。
如果这项工作可以交出去等结果，先选 OpenAI Codex：它更像一个可委派的工程执行层，适合 app、IDE、CLI、云端、GitHub、CI、浏览器/computer-use、连接工作区上下文，以及由宿主机器承载的远程跟进。
这比“谁的单次跑分更高”更重要。到 2026 年，Codex 已经不只是一个编程模型或 CLI：OpenAI 的 remote connections 现在让 ChatGPT 移动端可以跟连接在 Mac 上的 Codex 协作，也可以从另一台 Codex App 设备继续工作；但项目文件、命令、凭据、工具、浏览器设置和 approvals 仍由宿主机器承担。Claude Code 的优势也没有消失：它不再只是终端工具，但最强默认场景仍然是本地监督式开发、项目 Skills、subagents、hooks、memory、条件成立时的长上下文路径和代码库推理。
最稳的答案通常不是二选一，而是分工：让 Claude Code 在本地探索、规划和发现风险，让 Codex 去实现边界清楚的任务、做 PR review、补 CI 或跑浏览器检查。价格、用量、模型名、上下文窗口和基准分数都变化很快，除非当天从官方页面重新确认，否则不要把旧表格当购买依据。
先看结论
Claude Code 和 Codex 都能写代码，但它们现在代表的是两种工作方式。Claude Code 的核心价值是“开发者仍在现场”：你看着它读文件、执行命令、解释推理、调整方案，并且可以随时打断。Codex 的核心价值是“任务可以被派出去”：你把一个边界清楚的工程请求交给它，让它在 app、IDE、CLI、云端、GitHub 或 CI 里完成，再回来审查结果。
优先用 Claude Code 的场景很明确：
- 大型重构、迁移计划、架构梳理，需要反复理解多文件关系；
- bug 复现依赖本地状态、私有脚本或复杂开发环境；
- 团队已经有项目级 Skills、subagents、hooks 或终端工作规范；
- 你希望人一直盯着改动，而不是等一个云端结果。
优先用 Codex 的场景也很明确：
- 任务可以拆成独立分支、独立 PR 或独立检查；
- 你希望它处理 GitHub 评论、代码审查、CI/CD、依赖更新或发布前检查；
- 工作需要浏览器/computer-use、连接器、文档、工单或其他工作区上下文；
- 多个小任务并行推进比一个深度本地会话更重要。
如果风险分成两层，两个工具一起用最合理。Claude Code 负责“要改什么、为什么这样改、哪里有耦合风险”，Codex 负责“这个边界清楚的任务能不能被执行、检查、复审或自动化”。这不是重复提问，而是把不同风险交给不同执行面。
Codex 最大的变化是什么
很多旧对比把 Codex 当成 CLI 或某个 OpenAI 编程模型来比较，这个框架已经过窄。OpenAI 的 Codex quickstart 把 Codex 描述为桌面 app、IDE 扩展、CLI 和云端入口的组合；IDE extension 可以在项目目录里读文件、运行命令、写入变更，云端 Codex 则可以连接 GitHub、在配置好的环境中运行任务、展示日志、让你 review 变更并创建 Pull Request。
更新的变化是远程连接。OpenAI 的 remote connections docs 在 2026 年 5 月 25 日显示，ChatGPT 移动端可以跟连接在 Mac 上的 Codex 协作，也可以从另一台 Codex App 设备继续工作，或者让 Codex App 连接 SSH host 上的项目。手机负责发送 prompts、approvals 和 follow-up messages，但连接的宿主仍提供仓库文件、命令、MCP servers、skills、浏览器访问、Computer Use、sandbox、凭据、权限和 approvals。当前同一文档还说明，移动端设置需要 macOS 版 Codex App；Windows 版 Codex App 暂不支持 mobile setup。
这让 Codex 的对比点从“云端写代码”变成“委派任务能否在受控宿主上继续推进”。开发者不一定要坐在主力机器前才能批准动作、重定向任务或检查失败结果。但这也不意味着 Codex 可以无人审查地自动合并。远程跟进降低的是等待和切换成本，不是代码正确性风险。
所以 Codex 的变化不是“换了一个更强模型”这么简单，而是从模型比较变成执行面比较。Codex GitHub Action 说明它可以在 CI/CD 中运行、应用补丁、发布代码审查意见；Codex configuration reference 则展示了模型选择、review model、approval policy、sandbox mode、项目说明、Skills、apps/connectors、memories、hooks、MCP、多智能体、web search、文件系统和网络权限等配置面。
入口差异也会改变结论。OpenAI 的 Codex pricing page 在 2026 年 5 月 25 日说明，API Key 路线可以用于 CLI、SDK 或 IDE extension，但不包含 GitHub code review 或 Slack 这类 cloud-based features。企业文档也把运行在开发者电脑 sandbox 里的 local Codex，和运行在托管容器中的 cloud Codex 区分开来。这个边界不只是计费细节，而是工作流边界。
这也是为什么单纯问“Codex 和 Claude Code 哪个更聪明”会误导。真正的问题是：这项工作是不是适合被派到一个受控环境里，产出一个可 review 的结果？如果是，Codex 的价值会明显上升；如果不是，本地监督仍然重要。
Claude Code 仍然强在哪里
Claude Code 的强项是本地、交互式、代码库内的深度工作。Anthropic 的 Claude Code overview 已经不再只把它写成终端工具，而是覆盖 terminal、IDE、desktop app 和 browser。它可以读代码库、编辑文件、运行命令、集成开发工具，并被定位为跨多个文件和工具构建功能、修复 bug、自动化开发任务的 agentic coding tool。这个定位和“云端委派一个任务”不同。
它的优势不只是“Claude 会解释”或“上下文更长”。更关键的是工作会话的形状：开发者可以让它先读项目规范，要求它只做计划，不满意就改方向；也可以让它追一个函数调用链、看本地失败日志、理解 monorepo 里的共享包，再决定是否动手。对于私有工具链、复杂本地环境、严格代码风格或高风险迁移，这种现场控制比速度更重要。
Anthropic 的 model configuration docs 也提醒我们不要把上下文窗口写成无条件卖点。按 2026 年 5 月 25 日的官方文档，Claude Code 支持 best、sonnet、opus、haiku、sonnet[1m]、opus[1m]、opusplan 等别名，同时说明这些别名会随时间更新，并且在 Anthropic API、Bedrock、Vertex、Foundry 等提供方上可能解析不同。当前在 Anthropic API 和 Claude Platform on AWS 上，opus 映射到 Opus 4.7，sonnet 映射到 Sonnet 4.6；Opus 4.7 需要 Claude Code v2.1.111 或更高版本。
同一页现在还写明，Opus 4.7、Opus 4.6 和 Sonnet 4.6 都支持面向大代码库长会话的 1M token context，但可用性取决于模型、计划、提供方和版本。Max、Team、Enterprise 计划中的 Opus 会自动升级到 1M context；Sonnet 的 1M context 在所有订阅计划中都需要 usage credits。也就是说，中文读者如果要为长上下文买单，应该核对当天官方条件，而不是看旧文章里的绝对化说法。
Claude Code 的项目级能力也成熟。Anthropic 的 subagents docs 把 subagents 描述为有独立 context window、prompt、tool access 和 independent permissions 的专业助手；skills docs 则把 skills 描述为基于 SKILL.md 的指令包，支持 invocation control、subagent execution 和 dynamic context injection。对于有固定工程流程的团队，这类本地可组合能力往往比一次云端输出更有价值，因为它可以把团队约束、工具权限和复用方式放进日常开发循环。
按任务选择，而不是按信仰选择
| 任务 | 先用 Claude Code | 先用 Codex | 两者配合 |
|---|---|---|---|
| 大型重构 | 适合，尤其是跨文件关系复杂时。 | 只有在任务已拆成独立分支时适合。 | Claude Code 本地规划，Codex 执行拆好的子任务。 |
| Bug 调查 | 适合，特别是依赖本地状态和复现细节时。 | 适合可在沙箱或 CI 里稳定复现的问题。 | Claude Code 缩小原因，Codex 准备补丁和 review。 |
| PR review | 适合做深度本地审查。 | 很适合委派 GitHub review。 | Codex 做常规审查，Claude Code 看架构和耦合。 |
| CI/发布检查 | 本地环境是事实来源时更合适。 | 很适合通过 Action 和自动化执行。 | Claude Code 诊断，Codex 固化为检查。 |
| 浏览器/UI 验证 | 适合开发者现场控制的测试。 | 浏览器/computer-use 可委派时更合适。 | Claude Code 设计验证路径，Codex 执行或更新检查。 |
| 远程跟进 | 不是主要优势。 | 适合通过连接的宿主或另一台 Codex App 设备继续审批、重定向或查看 active work。 | Codex 保持委派任务推进，Claude Code 之后做本地整合。 |
| 文档、工单和连接器上下文 | 上下文在本地文件时更合适。 | 需要连接器和工作区上下文时更合适。 | Codex 收集上下文，Claude Code 转成代码库内变更。 |
| 敏感代码 | 本地监督通常更容易控制。 | 取决于云端环境、权限和企业策略。 | 只把经过批准的边界任务交给 Codex。 |
这张表的核心规则很简单：看工作应该在哪里运行。应该在开发者本地 loop 中运行，就从 Claude Code 开始；应该作为可审查的委派任务运行，就从 Codex 开始。
价格、限制、模型和跑分要怎么读
旧版文章常把精确价格、消息次数、上下文窗口、SWE-bench 分数、Terminal-Bench 分数和模型名放在第一屏。现在这正是最危险的写法，因为这些数字变化很快，而且不同入口可能不是同一个产品合同。
对 Codex 来说，价格、模型和功能入口尤其容易被写错。OpenAI 的 Codex pricing page 在 2026 年 5 月 25 日列出 Free、Go、Plus、Pro 和 API Key 路线，并把 web、CLI、IDE extension、iOS、cloud-based integrations、GitHub code review、Slack integration、模型访问和使用区间拆开说明。API Key 路线可以用于 CLI、SDK 或 IDE extension，但不包含 GitHub code review 或 Slack 这类 cloud-based features。Pro 从 $100/month 起，OpenAI 还说明 $100/month Pro tier 到 2026 年 5 月 31 日有 double normal Codex usage。这些都应该被当作有日期的购买信息，而不是长期能力承诺。
对 Claude Code 来说，上下文和用量限制也要同样谨慎。Anthropic 支持页面在 2026 年 5 月 25 日的说法是，Pro 和 Max 的使用量在 Claude 与 Claude Code 之间共享，用量受计划、模型、功能、对话长度、文件和项目复杂度影响；如果设置了 ANTHROPIC_API_KEY，Claude Code 可能改走 API 计费。中文读者如果关心限额，可以继续看 Claude Code usage limit issues，但真正采购前仍要看当天官方页面。
跑分仍然有参考价值，但应该放在工作流判断之后。SWE-bench 类结果可以帮助理解复杂修复能力，Terminal-Bench 类结果可以帮助理解 shell/自动化任务表现；它们不能直接回答团队是否需要本地监督、GitHub 委派、浏览器自动化或连接器上下文。
一个更现实的混合工作流
不要把同一个问题同时丢给两个工具，然后比较谁的回答更顺眼。那样最容易得到互相冲突的 patch。更好的方式是在任何 agent 动代码前先分清所有权：
- 先让 Claude Code 读取本地仓库、项目规则、失败日志和风险点，输出迁移或实现计划。
- 把计划拆成边界清楚的任务，明确文件所有权和验收条件。
- 把可独立完成的部分交给 Codex，例如分支实现、PR review、CI 配置、浏览器检查、远程跟进、依赖更新或重复审查。
- 像审查外部贡献一样审查 Codex 输出，不把“agent 完成”当作“生产可用”。
- 如果补丁触及架构、隐式依赖或跨包行为，再让 Claude Code 回到本地做最终整合。
这种用法让 Claude Code 保持本地推理伙伴的角色，让 Codex 变成委派执行和复查层。团队最好把边界写清楚：Claude Code 可以读哪些范围，Codex 可以改哪些文件，要跑哪些检查，结果进入哪个 branch 或 PR，最后由谁批准合并。人仍然负责边界：哪些任务可以被派出去，哪些必须在本地监督下完成。
最终建议
如果你想要的是一次谨慎的本地结对编程会话，先用 Claude Code。它更适合大代码库理解、人类实时监督的重构、项目级 Skills、subagents、hooks 和需要反复追问的调试。
如果你想要的是把任务交出去，先用 Codex。它更适合 app、IDE、CLI、云端任务、GitHub/PR 工作流、CI/CD review、浏览器/computer-use 检查、由宿主机器承载的远程跟进、连接器上下文和可重复自动化。
如果你的团队已经进入 AI 编程的日常阶段，通常要两者都用，但不要让它们抢同一块代码。Claude Code 负责判断“为什么改、怎么拆、哪里危险”；Codex 负责执行“这个边界明确的任务能不能实现、检查、复审或自动化”。这才是 2026 年真正有价值的 Claude Code vs Codex 对比。
常见问题
现在 Codex 比 Claude Code 更好吗？
Codex 在可委派的多入口工作上更强：云端任务、GitHub、PR review、CI 自动化、浏览器/computer-use 和连接器上下文。Claude Code 仍然更适合有人监督的本地编程、深度代码库理解、项目 Skills、subagents 和谨慎重构。
Codex 最近真正变化在哪里？
关键变化不是单个模型名，而是操作面扩展。Codex 现在覆盖 app、IDE、CLI、云端、GitHub、CI、浏览器/computer-use、连接器、hooks、memory、MCP、Skills、automations 和 remote connections。当前 OpenAI 文档把移动端跟进定义成宿主承载：手机可以发送 prompts 和 approvals，但连接的宿主提供仓库、工具、凭据、浏览器设置和权限。
Claude Code 更适合大型代码库吗？
通常是，前提是任务依赖本地项目上下文、跨文件推理和人类监督。官方文档确实描述了 1M context 路径，但当前可用性取决于模型、计划、提供方和版本，不是所有账号都自动拥有的能力。
Codex 能替代 Claude Code 吗？
在部分委派实现、PR review、CI、浏览器和 GitHub 任务上可以。但它不应该自动替代本地监督式流程，尤其是架构敏感重构、私有工具链调试、需要开发者随时打断推理路径的变更。
同一个仓库可以同时用 Claude Code 和 Codex 吗？
可以，但要分清所有权。不要让两个工具同时改同一批文件。更稳的做法是 Claude Code 先本地探索和规划，再把边界清楚的实现、审查或自动化交给 Codex。
哪个更便宜？
不要根据旧对比表做决定。订阅计划、用量上限、模型路由和 token 经济性变化很快。只要成本会影响采购，就在当天查看 OpenAI 和 Anthropic 官方页面。
哪个更适合私有代码？
Claude Code 的本地工作姿态更容易被人监督，但安全性仍取决于计划、企业控制、数据政策和具体任务。Codex 的云端和 GitHub 工作流也可以安全使用，前提是环境、权限和审查边界配置清楚。
我已经在用 Claude Code，还需要 Codex 吗？
如果你的痛点是 PR review、CI 检查、浏览器任务、远程跟进、依赖更新或边界清楚的实现工作，Codex 值得加入。继续让 Claude Code 处理本地代码库推理和高风险重构，把 Codex 放在委派执行层。