OpenAI Codex 还是 Anthropic Claude?按你要做的事选
一句话:上个月跟一个朋友吃饭,他在做技术选型——团队 5 个人,三人坚信 Claude,两人吹 Codex,谁也说服不了谁,迭代节奏被卡了两周。我说"你们不用选 A 或 B,应该按任务选"。他愣了一下:可以这样吗? 这是 2026 年 AI 编程工具典型的坑——以为 "Codex vs Claude" 是站队问题。其实不是。两边在不同场景上有清晰可量化的差异:上下文窗口、价格、API 协议、生态。本文给一份按任务的决策树,配 7 个真实场景判定 + 双 Key 并行的实操配置。一篇看完,下次组里再吵就有数据可以拍板了。
2026-05 模型阵容快照(写在前面)
OpenAI 2026-04-23 出 GPT-5.5(gpt-5.5)—— $5/$30 per 1M tokens、1M context、coding 项目刷到 SOTA。
但 Codex CLI 默认仍调 gpt-5.3-codex ($1.75/$14, 400K context)——OpenAI 专为 codex agent 调优的版本,便宜 3 倍,本文场景推荐里如无特殊标注 Codex CLI 都指它。
需要更深推理或更长 context(>400K tokens)时,可手动切到 gpt-5.5(贵 3 倍但更擅长复杂推理)。
Anthropic 这边模型阵容没变:Sonnet 4.6 / Haiku 4.5 / Opus 4.7。
目录
基础参数对比:四个维度搞清楚定位
先把"两边到底差什么"摆清楚。下面四个维度——价格、上下文、协议、生态——决定了 90% 的选型场景。
价格(截至 2026-05,per 1M tokens)
模型 | 输入 | 输出 | Cache read | 定位 |
|---|---|---|---|---|
| $1.75 | $14 | $0.175 | OpenAI 主力编码模型 |
| $5 | $30 | $0.50 | OpenAI 顶配通用,coding SOTA |
| $3 | $15 | $0.30 | Anthropic 平衡主力 |
| $1 | $5 | $0.10 | Anthropic 速度型 |
| $5 | $25 | $0.50 | Anthropic 强项推理 |
速读:GPT-5.3 Codex 输入比 Sonnet 4.6 便宜约 40%,输出价格几乎一样。Haiku 4.5 是同量级性价比高。Opus 4.7 价格较高,适合扛复杂架构推理。
上下文窗口
模型 | 上下文 | 适合场景 |
|---|---|---|
GPT-5.3 Codex | 272K(超出走 2x 倍率) | 中型代码库 / 单文件深度理解 |
GPT-5.5 | 1M | 顶配推理 / 比 5.3-Codex 更长 context |
Claude Sonnet 4.6 | 1M | 整库分析 / 长 PRD / 跨服务追踪 |
Claude Opus 4.7 | 200K | 单点深度推理 |
Claude Haiku 4.5 | 200K | 高频小任务 |
速读:要塞整个代码库进去做全局推理 → Claude Sonnet 4.6 一骑绝尘(实测对比详见后面场景 #2)。
API 协议
工具 | 协议 | Endpoint |
|---|---|---|
Codex CLI | OpenAI Responses API |
|
Claude Code | Anthropic Messages API |
|
CodeGateway 网关同时兼容两套,一个 sk-cg- 开头的 Key 都能用。区别在客户端 SDK / CLI 怎么调用——Codex CLI 写死调 Responses API,Claude Code 写死调 Messages API,两边切环境变量就分别接入。
生态与功能
维度 | Codex CLI | Claude Code |
|---|---|---|
Skills 系统 | 基础( | 成熟(`.claude/skills/` 目录系统、可继承、可分享) |
Hooks 系统 | 有限 | PreToolUse / PostToolUse / Stop 三层 |
MCP(外部工具协议) | 部分支持 | 原生 + 一等公民 |
Sub-agents |
|
|
IDE 集成 | OpenAI 系列 IDE 插件 | VS Code 官方扩展、Cursor 集成 |
模型选择粒度 | 单 model 参数 | 按角色 + skill 自动路由 |
工程化深度 | 中(够用) | 高(适合多人团队) |
速读:纯个人开发 + 不在意 skill 系统 → Codex 够用且便宜;多人团队 + 工程化习惯 + 想做 skill 复用 → Claude Code 更顺。
7 个真实场景,按任务选模型
场景 1:重构 30K LOC 中型 Python 项目
- 任务:删死代码、重命名、拆函数、补类型注解、跑测试。
- 选 Codex CLI + GPT-5.3 Codex:价格便宜(input $1.75 vs $3),机械任务多,重构密集型不需要顶级推理。子代理拆 9 件事并行跑,整晚 $1-3。详见 Codex 给祖传代码大扫除。
- 反例:如果项目接近 100K LOC 且需要"读完全库再决策" → 切 Sonnet 4.6(1M 上下文,单次能塞进去)。
场景 2:长上下文文档分析(500 页 PDF / 整套 PRD)
- 任务:读完所有相关材料,提取要素、风险、时间线。
- 选 Claude Sonnet 4.6:1M tokens 上下文吊打——单次塞下整套文档无需切片。Codex 同样任务要分 5-8 次 chunk,token 总消耗可能反超 Claude 1M 单次。
- prompt cache 命中后输入降到 ~10%,长文档反复问答非常划算。
场景 3:写测试(已有 spec)
- 任务:按 spec 给中型模块补 80% 覆盖。
- 选 Codex CLI + GPT-5.3 Codex:写测试是中等推理 + 大量输出,按价格 Codex 输出 $14 < Sonnet $15。一晚跑 12K 测试 LOC 估算 $1-2。
- 反例:如果 spec 不清晰需要 AI 帮忙补 spec → Sonnet 4.6 的长上下文 + 推理深度更稳。
场景 4:UI / React 组件代码生成
- 任务:从 Figma 描述或 PRD 生成 React 组件。
- 可选 Codex CLI + GPT-5.3 Codex 或 Claude Code + Sonnet 4.6——基本平手。两边都能写组件、组件库样式都熟。
- 如果有团队设计系统(自家 tokens、特定 Skills)→ Claude Code,因为
frontend-design之类的 Skill 能 commit 进 repo 团队复用。 - 纯个人项目 → 哪个便宜哪个用 → Codex CLI。
场景 5:跨文件 / 跨服务字段重命名
- 任务:把
userId改成accountId,影响 6 个仓库 30+ 文件。 - 选 Claude Code 多代理:sub-agent 拆任务(grep / 改后端 / 改前端 / 跑测试 / 收集失败)成熟得多。Hook 系统能加"防火墙"自动阻止动 test 配置之类。
- Codex 也能干,但子代理调度成熟度差一截。
场景 6:架构决策(多服务设计 / 数据库迁移规划)
- 任务:给一个跨 5 个服务的数据库迁移方案,含回滚预案。
- 选 Claude Opus 4.7:架构推理这事 Opus 单次能想透。一次 Opus 调用 $5/$25 看着贵,但能省后面 3 轮 Sonnet 反复+返工的代价。决策类任务 70% 是"想",30% 是"写"——这种比例下 Opus 性价比更高。
- 反例:日常代码任务千万别用 Opus,账单会爆。
场景 7:高并发批量任务(CI 跑 lint / 全量测试归因)
- 任务:CI 触发,扫 50 个 PR 的 diff 给评论。
- 选 Claude Haiku 4.5 或 GPT-5.4-mini:单价 $1/$5 vs $0.40/$1.60。机械任务密集型,模型推理深度不重要。
- 关键:为 CI 单独申请 Key(命名
ci-<repo>),设 RPM 上限 + 月度预算上限,避免单次失控。
场景速查表
任务类型 | 推荐 | 备选 | 估算成本 |
|---|---|---|---|
中型项目重构 | Codex CLI + gpt-5.3-codex | Claude Code + Sonnet 4.6 | $1-3 / 晚 |
长上下文文档分析 | Claude Sonnet 4.6 (1M) | — | $0.5-2 / 次 |
写测试(有 spec) | Codex CLI + gpt-5.3-codex | Sonnet 4.6 | $1-2 / 模块 |
UI 组件生成 | 任一 | — | 看用量 |
跨服务重命名 | Claude Code 多代理 | Codex 子代理 | $2-5 / 仓库 |
架构决策 | Claude Opus 4.7 | — | $1-3 / 次 |
CI 批量任务 | Haiku 4.5 / gpt-4.1-mini | — | $0.1-0.5 / 跑 |
决策树(直接抄)
按"任务核心特征"自顶向下走:
你的任务核心特征是?
├─ 输入超过 200K tokens?
│ └─ Claude Sonnet 4.6(1M 上下文专属优势)
│
├─ 是 100% 机械重复任务(lint / format / 简单生成)?
│ └─ Haiku 4.5 或 gpt-4.1-mini(单价至少)
│
├─ 是高深度架构推理(多服务设计 / 复杂调试)?
│ └─ Claude Opus 4.7(一次性投入省后续返工)
│
├─ 是跨 N 个文件的重构 / 重命名 / 跨服务改动?
│ └─ Claude Code 多代理系统(sub-agent + hook + skill 成熟度高)
│
├─ 是中型项目大扫除 / 写测试 / UI 组件生成?
│ ├─ 看价格预算 → Codex CLI + gpt-5.3-codex(input $1.75 较 Sonnet $3 便宜约 40%)
│ └─ 看团队工程化 → Claude Code + Sonnet 4.6(skill 系统 commit 进 repo)
│
└─ 完全不确定?
└─ Sonnet 4.6 当默认(综合能力稳),子代理切 Haiku 4.5 省钱双 Key 并行的实操配置
高效的做法不是"选 A 或 B"——是两边都用,按任务切。CodeGateway 一个账号下一把 Key 同时支持 Anthropic + OpenAI,所以并行配置无需第二个账号。
Step 1:申请两把 Key(区分用途)
Dashboard → API Keys → Create Key 两次:
claude-laptop(给 Claude Code 用)codex-laptop(给 Codex CLI 用)
技术上一把 Key 两边都能调,但分开命名好处是 Logs 页能按 Key 分流量、出问题能单独旋转。
Step 2:环境变量按"激活哪个工具"切换
# 文件 1:~/.claude-env
export ANTHROPIC_BASE_URL="https://api.codegateway.dev"
export ANTHROPIC_API_KEY="sk-cg-claude-key-xxx"
export ANTHROPIC_MODEL="claude-sonnet-4-6"
# 文件 2:~/.codex-env
export OPENAI_BASE_URL="https://api.codegateway.dev/v1"
export OPENAI_API_KEY="sk-cg-codex-key-xxx"平时跑 Claude Code → source ~/.claude-env;切 Codex → source ~/.codex-env。
Step 3:项目级别覆盖(推荐)
不同项目可能想固定不同工具。.envrc(配合 direnv)+ git-ignored:
# legacy-cleanup-project/.envrc
source ~/.codex-env
echo "✓ Codex environment loaded for legacy cleanup"
# new-saas-project/.envrc
source ~/.claude-env
echo "✓ Claude environment loaded for SaaS work"cd 进项目目录自动加载对应环境,少切环境变量,少踩"上次环境忘清"的坑。
Step 4:账单一目了然
CodeGateway Dashboard → Logs → 按 Key 过滤。能看到:
claude-laptop30 天用了多少 tokencodex-laptop30 天用了多少 token- 哪个 Key 在哪个模型上花的多
3 个不要陷入的误区
误区 1:「Claude 比 GPT 聪明 / GPT 比 Claude 快」
错。两者综合能力差异 < 10%(公开 benchmark 数据),但单点场景差异显著(如长上下文)。比拼综合的是市场叙事,对你具体项目无意义。
正确思路:你这周要做的具体任务,哪个模型在它的强项区?
误区 2:「便宜的就是好的」
错。单看 token 单价,gpt-5.3-codex 比 Sonnet 4.6 便宜 40%。但如果用 Codex 跑 3 轮才得到 Claude 一次就能给的方案,总成本反超 1.5x。
正确思路:算"完成单位任务"的端到端成本,不是 token 单价。
误区 3:「我团队全部统一用 X」
错。统一带来的运维收益远小于"任务-工具不匹配"的隐性成本。开发者本身就是异质的——后端工程师用 Sonnet 跑 SQL 优化 vs 前端用 Codex 跑组件生成,没必要让他们用一样的。
正确思路:基础设施统一(一把 CodeGateway Key、一份计费、一份监控),工具与模型选择留给个人 / 项目。
FAQ
Q:Codex CLI 和 Claude Code 真的能用同一个 Key 吗?
A:能。CodeGateway Key 在网关层根据请求 endpoint 自动路由——/v1/responses 走 OpenAI 路径,/v1/messages 走 Anthropic 路径。同一把 Key 双向都能调。
Q:那为什么还要分两把 Key 命名?
A:不是技术必要,是运维必要。Logs 按 Key 分组、突发用量按 Key 报警、Key 泄露按 Key 旋转——分开命名后这些维度都能用。一把 Key 走两边的话,所有数据混在一起难定位。
Q:CodeGateway 的阶梯倍率怎么算 Codex + Claude 混用?
A:累计。所有 token 用量(不管哪个上游模型)累计到你的 90 天滚动消耗。新账号 1.5x,累计满 $10 降到 1.4x,依此类推到至少 1.2x。混用其实有利于更快下倍率档——比单边消费更快达到阶梯。详见 阶梯倍率详解。
Q:可以同时跑 Codex 和 Claude Code 吗?
A:能。两个 shell 各自加载不同 env 文件即可。RPM 限额按 Key 算(不按账户),分两把 Key 时双倍 RPM 头。
Q:Cursor 怎么办?它跟 Claude / OpenAI 都对接。
A:A:Cursor 是 IDE,跟 Codex CLI / Claude Code 是不同形态。Cursor 强在 IDE 内的交互式编辑、行内补全、UI 反馈;Codex CLI / Claude Code 强在长链路自动化任务。同时用三个工具完全合理——Cursor 写小段、CLI 跑大块。CodeGateway Key 在 Cursor 里也能用(设置里改 base URL + API key)。
Q:选了之后还能换吗?
A:能,且很便宜。CodeGateway 一把 Key 双协议兼容,切工具不用换 API key、不用迁数据。这是用 CodeGateway 的核心优势——避免被单边生态绑死。
Q:长上下文 Claude 1M 真的有用吗?
A:看任务。日常 5K-30K token 任务用不到。但当任务必须塞进整个 codebase / 整套 PRD / 完整 incident 日志一次性推理时,1M 是 GPT-5.3 Codex 272K 的 3.7 倍——直接决定能不能做。具体阈值:单次输入 > 200K token 强烈建议切 Sonnet 4.6。
Q:架构决策真的值得用 Opus 吗?$5/$25 看着贵。
A:A:单次贵,总账可能省。如果一个数据库迁移决策用 Sonnet 走 3 轮(每轮 $1-2)+ 一次返工($3-5),总成本 $7-12;用 Opus 一次给完 $3-5。Opus 不适合日常代码,但对复杂决策类任务的 ROI 很高。
相关资料
- Codex CLI 给祖传代码大扫除 —— Codex 实战篇,配合本文场景 1
- Claude Code 完整配置指南 —— Claude 工程化篇
- Claude Code 进阶技巧与佳实践 —— 多代理、MCP、成本优化
- Claude Code 连接超时排查 —— 长任务断流,思路通用
- 博客内容工厂 1 小时 16 张配图账本 —— 同样金矿+铲子的 dogfood 复盘
- 充值费用指南
- 阶梯倍率详解 —— 90 天滚动累计、至少 1.2x
- Anthropic 官方文档:Claude Pricing
- OpenAI 官方文档:Pricing
选型不是站队。两个工具都好,关键是把场景说清楚——任务的核心特征(上下文长度 / 推理深度 / 重复性 / 团队工程化),决定哪个工具的强项跟你对齐。下次组里再吵,先把任务摆桌上,再翻这篇决策树。
新增章节:Gemini CLI vs Claude Code:第三个选项
插入位置:在"总结"章节之前
目标关键词:gemini cli vs claude code、claude code vs gemini
字数:约 720 字
Gemini CLI vs Claude Code:第三个选项
如果你觉得 "Codex 还是 Claude" 这个问题已经够难选了,2026 年又多了一个选手——Gemini CLI。
背景:Google DeepMind 于 2025 年 6 月开源了 Gemini CLI,这是一款跑在终端里的 AI agent,背后跑 Gemini 2.5 Pro。它不是 VS Code 插件,也不是网页版聊天框,是正儿八经的 CLI agent 形态,打法和 Claude Code、Codex CLI 直接重叠。
Gemini CLI 的核心优势
1. 免费用量门槛极低
用个人 Google 账号登录就能用,Gemini API free tier 每分钟 15 次请求,对轻量任务、个人项目、探索评估来说成本为零。这是 Codex CLI 和 Claude Code 都给不了的入场门槛。
2. 原生 Google Search 集成
Gemini CLI 内建调用 Google Search 的能力。这意味着跑 agent 任务时可以实时搜索技术文档、检索最新 API 变动——对需要频繁查外部资料的任务有天然优势。Claude Code 和 Codex CLI 都需要靠 MCP 或外部 hook 才能做到。
3. 1M token 超长上下文
Gemini 2.5 Pro 原生支持 1M token 上下文窗口,与 Claude Sonnet 4.6 并列,远超 GPT-5.3 Codex 的 272K。整个代码库塞进去做全局推理,三者里 Gemini 2.5 Pro 和 Sonnet 4.6 都能胜任。
4. 多模态输入
原生处理文本、图片、截图、视频帧——对前端任务有一定加分,比如把 Figma 截图或原型图直接丢进去分析。
Gemini CLI 的局限
1. 工程化深度偏弱
Claude Code 有成熟的 skills 系统、三层 hooks(PreToolUse / PostToolUse / Stop)、原生一等公民 MCP。Codex CLI 次之。Gemini CLI 在复杂工作流编排、多 agent 调度、团队复用这些维度上明显落后——目前更像"个人玩具级"而非"团队工程工具"。
2. 代码理解深度弱于 Claude
同等复杂度的跨文件重构、多服务追踪,Claude Sonnet 4.6 的代码理解稳定性更高,改错更少,生成质量更可控。Gemini 2.5 Pro 有时会在不该动的地方做修改,工程团队反馈噪音更多。
3. 复杂推理不如 Claude Opus
对于架构决策、多服务数据库迁移规划这类 70% 是"想"的任务,Claude Opus 4.7 仍然是单点天花板。Gemini 2.5 Pro 的推理能力在 benchmark 上接近,但工程师实测里在"一次想透"的稳定性上稍逊。
三工具对比速查表
| 维度 | Claude Code | Codex CLI | Gemini CLI |
什么时候选 Gemini CLI?
选它的两种典型场景:
你在个人项目上试水新 AI 工具,免费额度足够,不想立刻付费 → Gemini CLI free tier
任务需要实时联网查文档或搜索最新 API 变化,且不在乎工程化深度 → Gemini 的 Search 集成有优势
继续选 Claude Code 的场景:
多人团队 + 复用 skills + hook 精细控制 → Claude Code 碾压
复杂架构决策 + 推理稳定性 → Claude Opus 4.7
继续选 Codex CLI 的场景:
单纯追求 input token 最低价格 + 中型机械重构 → gpt-5.3-codex $1.75 仍是较便宜选项之一
CodeGateway 的角色
你可能注意到,这三个工具走的是三套 API:Anthropic Messages API、OpenAI Responses API、Google Gemini API。CodeGateway 目前一把 Key 同时覆盖 Claude 全系 + OpenAI 全系,Gemini 系列也在接入计划中。
换句话说,不用挑边站——未来的目标是你只要一个 CodeGateway Key,不管底层模型怎么更迭,账单在一个地方,日志在一个地方,切模型不用换 Key,也不用管哪家 API 今天又把价格改了。
_字数统计:约 720 字(不含表格行)_
