Codex CLI 与 Claude Code 2026 年对比：架构、定价与中国访问

Codex CLI 与 Claude Code 都以终端原生的智能体工具形式发布，但它们通过根本不同的机制来保障安全：一个采用内核级沙箱，另一个采用应用层钩子。这一设计决策会层层传导到每个工具在配置、权限、多智能体工作流与团队治理方面的处理方式。下文的对比通过具体的决策标准梳理这些差异，延续我在本站持续构建的AI 工程领域内容。

我将 Claude Code 作为主力工具使用。这一偏好我在此开门见山地说明。文中的观察来自日常在生产任务中对两个工具的使用、盲测评估以及双工具协同的工作流。

一句话结论： Codex 在操作系统内核层（Seatbelt、Landlock、seccomp）强制执行安全策略¹，采用粗粒度控制。Claude Code 通过 26 个可编程钩子事件在应用层强制执行安全策略²，采用细粒度控制。两个工具现在都支持大上下文：Claude Code 基于 Opus 4.7，以标准定价提供 100 万 token 上下文⁵；Codex CLI 基于 GPT-5.4（OpenAI 当前的前沿模型，2026 年 3 月 5 日发布，整合了 GPT-5.3-Codex 的编码能力），上下文最高 105 万、最大输出 128K，但默认上下文为 272K，除非您显式启用长上下文模式⁴。云端沙箱化的任务委派和内核级隔离请使用 Codex。可编程治理、长周期重构和安全导向的代码审查请使用 Claude Code。同时使用两者效果最佳。

核心要点

• 独立开发者： 选择与您的主力语言生态最匹配的工具即可。两个工具可以在同一仓库中共存，互不冲突（CLAUDE.md 与 AGENTS.md 彼此独立）。
• 团队负责人： Codex 的 profile 提供显式、可审计的配置切换。Claude Code 的分层体系会自动应用上下文相关的规则。根据团队偏好显式控制还是自动适配来选择。
• 安全工程师： Codex 的内核沙箱可在操作系统层面阻止智能体绕过限制。Claude Code 的钩子与智能体共享进程边界，但允许任意验证逻辑。请根据威胁模型匹配工具。

您应当选择哪个工具？（角色决策路径）

对比的答案取决于您是谁。下面针对本页面最常见的四类读者各给出一条路径。

个人项目或小团队项目的独立开发者

默认选择：Claude Code。 在标准定价下 Opus 4.7 提供 100 万 token 上下文、26 个钩子组成的治理系统，以及插件市场，覆盖了独立开发者日常遇到的场景（大型代码库重构、会话连贯性、保存时自动格式化）。Pro 每月 20 美元、Max 每月 100-200 美元，定价可预测且相当慷慨。

何时引入 Codex CLI： 需要内核级沙箱进行一次性的不可信代码审查时；或 ChatGPT Pro/Plus 已覆盖您的主要 AI 开支，再加 Claude 有些冗余时。两个工具可以干净地共存；CLAUDE.md 与 AGENTS.md 并排放置即可。

10-50 人工程团队的技术负责人

默认选择：Claude Code。 可编程钩子（lint 门禁、安全扫描、禁止命令拦截）以确定性方式编码团队标准，而不是寄希望于模型遵循 prompt 指令。托管设置让负责人可以设定组织级策略，个人开发者无法覆盖。claude agents CLI 和 Agent Teams 原语契合团队在审查流程中实际采用的模式。

何时引入 Codex CLI： 安全敏感的审查需要内核级硬隔离时（例如审查外部承包商代码、来自陌生作者的开源 PR）；或团队已通过 Azure OpenAI / Microsoft Foundry 全面投入 OpenAI 工具链时。将其作为聚焦的审查工具使用，而非日常主力。

安全导向的评审者或红队研究员

默认选择：Codex CLI（用于对抗性输入）+ Claude Code（用于受治理的执行）。 Codex 在 macOS Seatbelt / Linux Landlock+seccomp 上的内核沙箱会在应用层之下拒绝系统调用，因此恶意智能体实际上无法触碰您未授权的文件系统区域。Claude Code 的钩子系统虽然强大，但与智能体共享进程边界。请根据威胁匹配工具。

何时引入 Claude Code： 需要可编程的审查后动作时（分诊钩子、审计日志、自动化报告生成）。典型工作流：Codex 在沙箱约束下检查，Claude Code 处理分诊和策略执行层。

位于中国大陆的开发者

两个工具都能使用，但连通性与成本对选择的影响超过功能本身。在做决定前请先跳到从中国访问 Codex 与 Claude Code。

核心架构的分野

Codex 与 Claude Code 之间最深层的差异在于治理发生的位置。Codex 通过 macOS 上的 Seatbelt、Linux 上的 Landlock 与 seccomp 在内核层强制安全策略¹。操作系统会在这些操作抵达应用层之前限制文件系统访问、网络调用和进程派生。模型无法绕过这些限制，因为操作系统在系统调用执行前就已拒绝它。

Claude Code 通过钩子在应用层强制安全策略——钩子是在 26 个生命周期节点拦截操作的程序²。作用于 Bash 的 PreToolUse 钩子可以检视每条命令、按任意逻辑校验，并以退出码 2 阻止其执行。钩子系统提供可编程治理：编码业务规则、运行 linter、扫描凭证。代价是应用层强制执行与智能体共享进程边界；而内核级强制执行不会。

每种安全架构都在表达力与边界强度之间权衡。这两个工具分处这一光谱的两端，而且这种定位是刻意为之。当威胁模型包含潜在对抗性智能体（审查恶意代码、运行不可信脚本）时，内核沙箱更合理。当威胁模型是一个过度自信但用意良好的智能体（您自己的代码、自己的团队、自己的规范）时，应用层钩子更合理。大多数开发者在不同时刻都需要这两种威胁模型。

配置哲学

Codex 使用 TOML 作为配置格式。Claude Code 使用 JSON。格式差异只是表面。哲学差异则不然。

Codex 围绕profile 组织配置——即您通过 --profile 显式切换的命名预设。careful profile 设置 approval_policy = "untrusted" 并采用激进沙箱⁹。deep-review profile 则切换到更强的模型。您始终知道当前生效的是哪份配置，因为是您按名字选的。指令层使用 AGENTS.md，这是 Linux 基金会旗下 Agentic AI Foundation 的开放标准³，可被 Codex、Cursor、Copilot、Amp、Windsurf 和 Gemini CLI 读取。

Claude Code 围绕分层层级组织配置——五层从托管设置（最高优先级）依次到命令行、本地项目、共享项目和用户默认值层层叠加。CLAUDE.md 文件在用户、项目和本地三个层级生效。Skills、hooks 和 rules 目录再增加几层。上下文相关的配置会自动应用，但从任何单一文件都看不出当前生效的配置。您需要逐层阅读才能复原。

profile 倾向显式性与可审计性。”当前生效的是哪份配置？”可以通过检查传入的 --profile 标志得到答案。分层层级倾向自动化与上下文敏感性。合适的上下文会自动应用，但回答”当前生效的是哪份配置？”需要读完最多五层并理解它们的合并顺序。这一权衡是真实的：我偶尔会被与项目级指令冲突的用户级 CLAUDE.md 覆盖所意外——使用显式 profile 就不会发生。

安全模型对比

规律是：Codex 提供更强的边界但控制粒度更粗。Claude Code 提供较弱的边界但控制粒度更细¹¹。正确选择取决于您的威胁模型。审查不可信的外部代码？内核沙箱。在可信代码上强制组织级编码标准？可编程钩子。

上下文与模型

截至 2026 年 4 月，Codex CLI 默认使用 GPT-5.4（2026 年 3 月 5 日发布，快照版本 gpt-5.4-2026-03-05）⁴。GPT-5.4 是 OpenAI 当前的前沿通用模型，据 OpenAI 的发布博文介绍，它整合了 GPT-5.3-Codex 的编码能力，同时新增原生 Computer Use 和更广泛的智能体工作流支持。默认上下文为 272K，同时提供 105 万 token 的实验性长上下文模式，可通过 model_context_window / model_auto_compact_token_limit 配置启用。输出上限为 128K。⁴超过 272K 输入 token 的长上下文 prompt 在该会话中按输入 2×、输出 1.5× 计费。⁴GPT-5.3-Codex 未被弃用，仍可供偏好编码优化的成本/速度配置的团队使用。

Claude Code 的默认模型依据 Anthropic 模型配置文档按套餐分层确定⁵：Max 与 Team Premium 默认 Opus 4.7（2026 年 4 月 16 日发布）；Pro、Team Standard、Enterprise 以及按 token 付费的 Anthropic API 默认 Sonnet 4.6，其中 Enterprise 与 API 将于 2026 年 4 月 23 日迁移到 Opus 4.7。Opus 4.7 在使用时以标准定价提供 100 万 token 上下文窗口（无长上下文溢价）。两家厂商的默认模型与上下文上限都会在版本间变化；当前值请查阅各厂商页面。

两个工具现在都能很好地处理大上下文。Claude Code 基于 Opus 4.7 达到 100 万，按标准定价，无溢价。Codex CLI 基于 GPT-5.4 在启用长上下文模式时达到 105 万，超过 272K 输入时按 2×/1.5× 倍率计费。就 monorepo 摄取而言，实际差距已经收窄；对大多数项目来说，检索质量（每个工具找到相关代码的能力）比原始窗口大小更重要。

在 2026 年 4 月的公开基准上，Opus 4.7 在 SWE-bench Verified（87.6% vs GPT-5-Codex 的 74.9% 基线）、SWE-bench Pro（64.3% vs GPT-5.4 官方 57.7% 和 GPT-5.3-Codex 56.8%）以及 CursorBench（70% vs Opus 4.6 的 58%）上领先¹²。在 Terminal-Bench 2.0 上，Opus 4.7 为 69.4%；GPT-5.4 以 75.1%、GPT-5.3-Codex 以 77.3% 在该项领先¹²。截至撰稿时，GPT-5.4 的 SWE-bench Verified 分数并未在官方模型页或发布页公布；第三方报道的数字约为 80%，但未公布的厂商数据宜谨慎对待。基准领先在版本间反复摇摆；决定前请查看厂商页面。在我使用早期 Opus 版本做的盲测中，即使在较小上下文下，它在审查与安全任务上也表现更佳，100 万 token 下同样的规律依旧成立。

两个工具都支持模型路由。Codex 按 profile 选择模型⁹。Claude Code 的默认值如上按套餐分层（Max 与 Team Premium 的 Opus 4.7，Pro、Team Standard、Enterprise 和 API 的 Sonnet 4.6，其中 Enterprise 与 API 将于 2026 年 4 月 23 日迁移到 Opus 4.7），每次调用都可通过 --model 或设置级配置覆盖。

定价深入分析

定价分为三种模式：按 token 的 API 计费、含智能体 CLI 用量的订阅，以及通过 AWS / GCP / Azure 的云厂商计费。最划算的路径取决于每日 token 用量，而不是标价。

Claude Code 定价（2026 年 4 月）

按 token 计费（Anthropic API）：¹³

无长上下文溢价：Opus 4.7 的 100 万 token 窗口按标准价格计费。批量 API 可在输入和输出上享受 50% 折扣。¹³

包含 Claude Code 的订阅方案：⁸

云厂商定价依据 AWS Bedrock / Google Vertex AI / Microsoft Foundry 的官方价目，这些价目紧贴 Anthropic 的直连 API，但在区域可用性与数据驻留方面有差异。

Codex CLI 定价（2026 年 4 月）

按 token 计费（OpenAI API）：¹⁴

OpenAI 会随模型变体轮换调整定价；以下为 2026 年 4 月 19 日核实的价格。

GPT-5.4 上超过 272K 输入 token 的长上下文 prompt 在该会话中按输入 2×、输出 1.5× 计费，适用于 standard、batch 和 flex 等档位。⁴

包含 Codex 的订阅方案：

ChatGPT Plus（$20/月）、Pro（5× 为 $100/月，20× 为 $200/月）以及 Business（按量付费的仅 Codex 席位，或带 Codex 用量上限的标准 ChatGPT Business 席位）都包含 Codex 系列用量，并具有各自套餐限额。Pro 5× 的用量临时提升到 Plus 的 10 倍，有效期至 2026 年 5 月 31 日；同一促销期内 Pro 20× 的 5 小时 Codex 限额按 Plus 的 25 倍计。GPT-5.4、GPT-5.3-Codex 和 GPT-5.2-Codex 都可通过 OpenAI API 使用，受支持的 API 档位具有公开的按 token 价格和速率限制（免费档不支持）。¹⁴仅使用 API 的团队可以完全跳过订阅；当捆绑的 Codex 用量加上更广的聊天端点对团队更具价值时，再考虑 ChatGPT 订阅。

Opus 4.7 的 100 万上下文实际成本

实际问题是：”如果我给 Opus 4.7 喂入一个 100 万 token 的代码库，账单是多少？”

一次完整上下文通过、配一个 10K token 的响应： - 输入：1,000,000 token × $5.00/百万 token = $5.00 - 输出：10,000 token × $25.00/百万 token = $0.25 - 合计（无缓存）：每次通过 $5.25

在 100 万 token 代码库上启用 5 分钟 prompt 缓存（假设单次缓存写入，后续追问重复读取）： - 首次写入：1,000,000 × $6.25/百万 token = $6.25（一次性） - 5 分钟内的每次后续读取：1,000,000 × $0.50/百万 token + 10,000 输出 × $25/百万 token = $0.75 - 一次会话内五次读取：$6.25 + (5 × $0.75) = 五次完整上下文通过共 $10.00

人民币示例按参考汇率 1 美元 ≈ 6.82 元（2026 年 4 月前后央行中间价在 6.82-6.90 区间波动）：100 万 token 代码库的五次完整 Opus 4.7 会话约 ¥68.20。 汇率在变动；在采购中引用前请核对当前汇率。对预算编制而言，重要的是计算逻辑，而非人民币数字的精确值。

在 GPT-5.4 长上下文模式下的等价计算： - 输入：1,000,000 token × ($2.50 基础价 × 2 长上下文倍率) = $5.00 - 输出：10,000 token × ($15.00 基础价 × 1.5 长上下文倍率) = $0.225 - 合计（无缓存）：每次通过 $5.23 ——在完整 100 万上下文下与 Opus 4.7 的无缓存价格相差不到 1%

在 GPT-5.2-Codex（400K 输入上限）上，要摄取同样的 100 万代码库至少需要三次通过，会话级成本结构因此改变。大多数中国开发团队并不需要每日使用完整 100 万上下文，所以现实对比会落在典型会话规模（50K-200K token）上——在那里两个工具每次会话的成本都在 1 美元以下。

订阅何时比按 token 更划算

粗略经验法则（并非官方公布的 token 配额，Anthropic 未发布具体数值）：轻度交互使用 Pro 完全够用；在 Opus 4.7 上高强度的日常智能体工作流会进入 Max 5x 或 Max 20x 范围；持续的完整上下文（每次会话 $5+）工作负载在按 token 付费并配合激进 prompt 缓存下，可能比带上限的订阅更便宜。与其从公式中猜测，不如在 Pro 上跑一个代表性周，查看 Claude 用量仪表盘，再按需升级。团队同样做这套按用户的计算，外加 Enterprise 档位所吸纳的管理、策略与 SSO 开销。

从中国访问 Codex 与 Claude Code

根据各提供商公布的支持国家/地区列表，中国大陆并非 OpenAI 和 Anthropic 第一方 API 的官方支持区域。¹⁸开发者有时通过非大陆网络与账号绕开这一限制，但这样做会带来账号暂停和合规风险，需要与您所主张的生产力收益权衡。CLI 的二进制文件下载后在本地安装和运行；日常的智能体循环行为在哪里都一样。合规路径走在云厂商的路由上。

AWS Bedrock 区域可用性

Anthropic 的 Claude 模型通过 Amazon Bedrock 在特定 AWS 区域提供。截至 2026 年 4 月，Bedrock 公开运行时端点覆盖包括东京、首尔、新加坡、孟买和悉尼在内的亚太区域，但目前中国大陆或香港均无 Bedrock 运行时端点。¹⁵通过 AWS 路由的中国客户通常选择新加坡或东京，并承担相应的延迟成本。

Google Vertex AI 区域可用性

Google Cloud 在亚太区域提供 Vertex AI 生成式 AI 端点。¹⁶具体的 Claude 模型可用性因区域而异，asia-east2（香港）历来为中国南部用户提供较低延迟。在做出承诺前，请验证所选 Vertex 区域中 Claude 模型的可用性；覆盖范围随时间扩展，但在亚太各地并不均匀。

Microsoft Foundry

Claude 通过 Microsoft Foundry 在 Azure 全球标准部署上提供，通常需要符合条件的 Enterprise / MCA-E 订阅。Claude 在 Azure 中国（由世纪互联运营） 上未被公开记录为可用——该环境是独立的主权云，拥有不同的服务目录。使用 Foundry 的中国客户走的是全球 Azure 版图，而非 Azure 中国。¹⁷

从中国访问 OpenAI Codex

OpenAI 的支持国家/地区列表不包括中国大陆；OpenAI 警告称来自不受支持区域的访问可能导致账号封禁或暂停。¹⁸Azure OpenAI 在特定的全球区域（不含 Azure 中国）提供，追求合规访问的中国企业通常通过被允许区域中的 Azure OpenAI，配合恰当的合同条款走通路径，而非尝试直接使用 OpenAI API。

来自中国厂商的模型替代方案

DeepSeek、通义千问（阿里巴巴）和 Kimi（月之暗面）都是中国团队出于成本与延迟考虑而评估的模型级替代方案。它们是模型，而非智能体 CLI。将它们与 Claude Code 配合使用需要一个兼容 Anthropic-API 的适配器或网关（Claude Code 期望 Anthropic 的请求/响应结构；ANTHROPIC_BASE_URL 指向的是 Anthropic-兼容端点，而非 OpenAI-兼容端点）。Codex 支持 profile 级的模型路由，但同样期望 OpenAI-兼容响应。两个工具都不原生支持 DeepSeek/千问/Kimi；路径在于一个在提供商 API 结构与 CLI 期望之间翻译的适配器层。这些模型擅长回答采购、延迟和数据驻留问题；而智能体循环正确性与工具调用成熟度问题，仍然最适合由这些 CLI 所调优的前沿 Claude 和 GPT 模型来回答。

多智能体能力

Codex 通过 codex cloud exec 提供云端任务委派⁶。您描述一项任务，Codex 启动云环境、让智能体运行于您的代码库之上，并返回一份 diff。您不会实时监督智能体的推理过程；您前置定义任务，稍后收取结果。云委派自然映射到 CI/CD 流水线和批量处理。在内部，Codex 支持并发智能体线程以并行执行子任务⁷（当前版本最多 6 条，但此上限可能变化）。

Claude Code 通过 Task 工具提供显式的子智能体派生¹⁰。父智能体派生具有特定任务和隔离上下文的子智能体，协调结果并综合输出。子智能体派生支持交互式编排：您能看到推理过程并可介入。再结合让多个智能体相互批评输出的协商模式，交互式编排能捕捉到”发出即忘”模式错过的问题。

云任务适合那些您前置定义任务、想要稍后取结果的工作流。子智能体协调适合那些任务通过推理逐步演进、需要实时综合的工作流。

信任谱系

在查看决策矩阵之前，请考虑您的任务落在信任谱系的哪个位置。每项智能体编码任务都涉及一项隐含的信任决策：您在多大程度上信任智能体对此任务的判断？

低信任（使用 Codex）： 您在审查并非自己写的代码、运行来自外部来源的脚本，或委派给无法实时监督的云环境。智能体可能遭遇对抗性输入。您希望无论模型如何决策，都由操作系统强制边界。

中等信任（两者皆可）： 您在自己的代码库上工作，模式已知。智能体可能犯错，但那是过度自信的错，而非恶意。您希望在变更落地前审查，但不需要内核级隔离。

高信任（使用 Claude Code）： 您已通过钩子、CLAUDE.md 指令和白名单权限建立了防护栏。智能体在您设计的受治理环境中运作。您对治理层的信任足以选择性地批准动作，而非全面限制。

大多数开发者在大多数时间都处于中等信任——这就是双工具工作流行之有效的原因：Codex 处理沙箱优势显现的低信任任务，Claude Code 处理可编程钩子比内核限制更有价值的中高信任任务。

决策框架

基于具体需求的一份具体决策矩阵：

没有单一工具在此矩阵中全面占优。背后的规律比这十行更简单：Codex 在您需要硬边界时更出色，Claude Code 在您需要可编程逻辑时更出色。 如果您在运行不可信代码、审查外部贡献或委派到无法监督的云环境，硬边界更重要。如果您在强制团队规范、编排多步工作流或构建编码业务规则的防护栏，可编程逻辑更重要。如果您的需求中有三项以上指向同一工具，从那里开始。如果分歧均衡，考虑双工具工作流。

我的建议

两个都用。我在 12 个任务类别上通过两个工具跑了相同的代码审查任务（记录见我的盲测系列），发现没有任何一个工具能单独捕捉所有问题。一个具体例子：在一次 FastAPI 身份认证审查中，Opus 标记了密码比较函数中的计时侧信道。该比较使用了 Python 的 == 运算符而非 hmac.compare_digest()，从而产生了计时预言¹¹。Codex 完全漏掉了这个问题。在同一代码库上，Codex 的沙箱捕捉到了一个 URL 获取端点中的 SSRF 攻击向量，用户提交的 URL 可达内部服务。Opus 放行了该端点，因为在应用层面看输入校验是正确的，但内核沙箱标记了对内部 IP 段的出站网络请求。基于不同数据训练的不同模型会捕捉到不同类别的漏洞。同时运行两者的成本大约翻倍，但在安全敏感代码上能捕捉到有意义的更多问题。

我的日常工作流按任务类型划分：

• Claude Code 处理功能实现、代码审查和多文件重构。钩子强制格式化、阻止危险命令、每次编辑后运行测试。交互式子智能体模型很适合那些通过推理逐步演进的任务。
• Codex 用 --sandbox read-only 处理不可信代码审查（我在内核沙箱中审查外部 PR 和依赖）、通过 codex cloud exec 处理云委派批量任务，以及在需要第二意见时用不同模型视角捕捉盲区。

CLAUDE.md 与 AGENTS.md 在同一仓库中共存，无冲突。由于两份文件大部分内容共享，维护开销保持最低。我维护一段共享的规范章节并复制到两份文件中。

何时两个工具都不该用。 当您需要确定性保证时，Codex 和 Claude Code 都不是正确选择。两个工具都是概率性的：相同的 prompt 在不同运行中会产生不同输出。如果您的工作流需要精确可复现性（例如生成必须逐字节匹配模式的配置文件），请改用模板引擎或代码生成器。智能体工具在任务需要判断时最强，在任务需要不含判断的精确性时最弱。

完整对比、盲测方法论及 12 个任务类别的结果，请参见Claude Code vs Codex：何时用哪一个。个别上手请参见 Claude Code 指南 或 Codex 指南。对于支撑 Claude Code 治理层的钩子系统的实操演练，请参见钩子教程。

参考资料

常见问题

我能在同一项目中同时使用 Codex 与 Claude Code 吗？

可以。CLAUDE.md 与 AGENTS.md 是两个分别由各自工具独立读取的文件。两个工具都不会解析对方的指令文件。配置文件不冲突。我在每个活跃项目中都同时维护两者。唯一需要注意的是保持指令文件之间的共享内容同步——由于格式类似，这只需要几分钟。

日常使用哪个更便宜？

请参见上文完整的定价深入分析。简版：Claude Code 采用按 token 的 Anthropic API 定价加上订阅阶梯（Pro $20、Max 5x $100、Max 20x $200、Team $30/用户、Team Premium $150/用户）。Codex CLI 采用按 token 的 OpenAI API 定价，GPT-5.4 为 $2.50 输入 / $15 输出每百万 token（输入超过 272K 时 2×/1.5× 倍率），外加 GPT-5.3-Codex / GPT-5.2-Codex 系列，以及 ChatGPT Plus/Pro 中的包含。token 效率因任务类型而异；对预算敏感的工作，建议通过两个工具跑一个代表性任务并比较实际费用。不同提供商的按 token 定价不同，原始 token 数并不直接映射为成本。

哪个处理大型代码库更好？

两者都能很好地处理大型仓库。2026 年 4 月 Opus 4.7 发布后，Claude Code 在标准定价下达到 100 万 token。Codex CLI 基于 GPT-5.4 在启用长上下文模式时达到 105 万 token（超过 272K 输入时输入/输出按 2×/1.5× 计费）；默认上下文为 272K，除非您选择加入长上下文档位。两个工具都不会一次性读完您的整个代码库；两者在日常工作中都依赖检索（Claude Code 的代码库搜索、分层 CLAUDE.md 预置上下文；Codex 基于嵌入的文件发现）。原始窗口大小在单轮推理中需要跨越许多文件的关系时最为重要，而在那一点上两个工具现在都能满足。

Codex CLI 本地运行还是云端运行？

两种都有，但不是在同一模式下。Codex CLI 默认本地运行，与任何终端工具相同。¹云委派是独立流程，通过 codex cloud exec 或 Codex Cloud 在 OpenAI 托管基础设施的容器中运行任务，并返回 diff。当人们说”Codex 沙箱”时通常指的是 Codex Cloud；Codex CLI 的本地沙箱则是上文”安全模型”章节描述的内核级 Seatbelt / Landlock 路径。

我能从中国大陆访问 Claude Code 和 Codex 吗？

中国大陆并非 OpenAI 和 Anthropic 第一方 API 的官方支持区域。CLI 的二进制文件可本地安装和运行，但从中国大陆将流量路由到第一方 API 可能引起账号暂停或合规问题。合规路径是：通过 Azure OpenAI（特定非中国区域）、AWS Bedrock（最近的公开亚太区域包括东京、首尔、新加坡、孟买和悉尼；无中国大陆或香港运行时端点）、Google Vertex AI（asia-east2 香港及其他亚太区域，按模型可用性存在差异）以及 Microsoft Foundry 在全球 Azure（非 Azure 中国）上的 Claude。具体请参见上文从中国访问 Codex 与 Claude Code。

中文注释或代码如何影响 token 用量？

中文字符与英文的 tokenize 方式不同。Claude 的分词器将大多数中文字符视为一个 token，这意味着相同行的中文源码通常比等效英文更省 token，但按字符计则效率较低（一个 token 对应一个字符，而非一个 4-6 字符的英文单词）。Codex（GPT 系列）采用类似方法。实际效果：在两种语言下等效的注释/文档串的 token 数大致相当，按 token 的行为由代码结构决定，而非由自然语言比例主导。

我能让 Claude Code 或 Codex CLI 使用 DeepSeek、千问或 Kimi 作为后端模型吗？

只能通过适配器或网关。Claude Code 期望 Anthropic API 的请求/响应结构（ANTHROPIC_BASE_URL 指向 Anthropic-兼容端点）；Codex 期望 OpenAI 的结构。DeepSeek / 千问 / Kimi 都发布各自的 API，需要经过翻译才能让 Claude Code 或 Codex CLI 会话驱动它们。社区适配器项目存在，但并非一等公民，并且每家提供商使用的工具调用与 prompt 缓存方言差异足以让多轮智能体循环常常崩坏。DeepSeek / 千问 / Kimi 作为通过独立 shell 做一次性代码生成以及在其原生价格点上做单文件审查的可行选项是可信的。完整智能体循环正确性与工具调用可靠性仍然来自这些 CLI 所调优的前沿 Claude 和 GPT 模型。

Codex CLI 与 ChatGPT 的 Codex 功能有何区别？

Codex CLI 是终端工具，位于 github.com/openai/codex。ChatGPT 内的”Codex”指的是通过 ChatGPT 网页/桌面/移动应用浮出水面的同一模型家族，具备不同的 UI 功能（云任务委派、异步结果、ChatGPT 历史整合）。CLI 与 ChatGPT 共享底层模型；工作流与上下文管理不同。如果您的问题是”我该在我的笔记本上安装哪个工具？”，答案是 Codex CLI。

使用 Codex CLI 需要 ChatGPT 订阅吗？

不需要，但订阅有助于降本。Codex CLI 可使用独立的 OpenAI API 密钥按 token 付费。ChatGPT Plus 或 Pro 捆绑了一定的 Codex 用量（当前限额请查看 ChatGPT 订阅页面）。¹⁴对中国开发者而言，通过 OpenAI 账户直接 API 计费通常比通过中国大陆支付通道订阅 ChatGPT 更干净。

Claude Code 的实际钩子数量是多少？

截至 v2.1.116（2026 年 4 月）为 26 个生命周期事件。²数量随时间增长，所以 2 月的文章中引用的 17 个已过时。2026 年主要新增：PostToolUseFailure、SubagentStart、TeammateIdle、TaskCompleted、PermissionRequest、PermissionDenied、PreCompact / PostCompact、Elicitation / ElicitationResult、StopFailure、TaskCreated、CwdChanged、FileChanged、InstructionsLoaded、ConfigChange、WorktreeCreate / WorktreeRemove 以及 Setup。

Opus 4.7 何时发布，它如何改变这项对比？

2026 年 4 月 16 日。这是 Anthropic Glasswing 之后首个正式发布的 Opus 版本，并自带显式的网络安全防护。实际对比改变了：Claude Code 现在以标准定价达到 100 万 token（Opus 4.7 已包含，无长上下文溢价）；SWE-bench Verified 的领先转移到 Opus 4.7，以 87.6% 超越 GPT-5-Codex 的 74.9% 基线；Terminal-Bench 2.0 的领先则朝另一方向摆动——GPT-5.4 以 75.1%、GPT-5.3-Codex 以 77.3% 在该项领先，而 Opus 4.7 为 69.4%。基准领先是流动的；请将任何单一结果视为时点测量。完整数字请参见上文”上下文与模型”章节。