我曾完全信赖Claude:但这次测试让我改变了看法

nn文章通过对比测试发现，Grok 4.5在编程任务中能以Claude Opus约四分之一的Token消耗和成本，交付同等质量的代码，尽管Opus在文档完善度上略胜一筹。这对追求高性价比的开发者而言具有重要参考价值。

Grok 4.5 真的能在只消耗四分之一 Token 的情况下与 Opus 一较高下吗？

xAI 于 7 月 8 日发布了 Grok 4.5。该模型在训练中加入了 Cursor 会话数据。xAI 声称，该模型在编程能力上基本与 Claude Opus 4.8 持平，但仅使用了约 4.2 倍更少的输出 Token 来实现这一目标。xAI 的策略显然直指那些关注 Token 成本的开发者。

Grok 的开箱即用成本也更低。每百万输入 Token 的费用为 2 美元，输出为 6 美元。而 Opus 分别为 5 美元和 25 美元。这不到对方价格的一半。

基准测试基本支持 xAI 的市场宣传。Terminal-Bench 2.1 用于衡量模型在命令行处理实际工作的能力。在该测试中，xAI 将 Grok 4.5 的得分定为 83.3%，略高于 Opus 4.8 的 78.9%。SWE-Bench Pro 的难度更大，它评估模型修复开源项目中实际 Bug 的能力。在该测试中，Opus 依然胜出。因此，营销宣称的并不是“更好”，而是“一样好，但便宜得多”。

仅从这些基准测试和定价来看，xAI 似乎想要蚕食 Anthropic 的市场份额。Anthropic 目前在 AI 公司中颇受欢迎，因此若要实现这一目标，其营销说辞必须经得起推敲。

为了找到答案，我让 Grok 4.5 和 Claude Opus 4.8 在同一个代码库中针对三个任务进行了正面交锋，并追踪了每一个 Token。

测试过程

我使用了 fd，这是 sharkdp 开发的一款流行的 Rust 文件搜索工具。fd 是 Unix find 命令的一个快速且更友好的替代品，我选择它是因为它是真正的生产级 Rust 代码，拥有深入且记录在案的 Bug 历史可供调用。

Grok 和 Opus 都在 Cursor 的 Agent 模式下运行。工具和提示词保持完全一致，因此模型是唯一的变量。我为每个模型在每次测试中都建立了一个新文件夹（总共六个），以确保每次测试都是独立的。

以下是我运行的三个测试（按此顺序）：

• Bug 修复
• 多文件重构
• 功能开发

对于每一次测试，我都记录了时间（使用秒表）、Token 消耗量以及来自 Cursor 使用仪表板的成本数据。

测试 1：Bug 修复

提示词：

这个代码库（fd 命令行工具）中有一个 Bug。当你传递 –no-ignore-vcs 标志时，fd 也会停止遵循父目录中的忽略文件。它不应该这样做。找到根本原因并修复它，使 –no-ignore-vcs 不再禁用父目录的忽略文件。不要更改任何其他行为。

对于 Bug 修复，我调取了 fd 在 2021 年真实修复（issue #907）之前的那个提交，当时 –no-ignore-vcs 标志错误地同时关闭了父目录中的忽略文件。我首先重置了 git 历史记录，这样模型就无法查找维护者的答案。重构和功能测试是在当前的 fd 版本上进行的。

两个模型都在同一个地方找到了 Bug 并写出了相同的修复方案。每个模型都从 src/main.rs 中删除了整整一行代码，差异完全相同，且都确保了所有 70 个测试用例通过。我重新编译了每个版本，确认 Bug 已消失，并检查了相邻标志的行为是否正常。我甚至将它们的修复代码与维护者 2021 年的真实修复进行了对比。官方修复删除了三行，而模型删除了其中一行，但当我测试所有相关标志时，行为是一样的。多出的删除只是清理工作。

由于代码相同，胜负取决于数据。Opus 在一次请求中以 174.1K Token 在 30.43 秒内完成。Grok 分两次请求，耗时 46.25 秒，消耗 210.2K Token。

在三个测试中最小的这个任务里，Opus 是明显的赢家。xAI 的营销宣传在这里站不住脚。

测试 2：重构

提示词：

在 src/main.rs 中，construct_config 函数很大，而且大部分工作是内联完成的。对其进行重构：将其连同所需的任何辅助逻辑移动到一个专门的新模块中，并将工作分解为更小、更专注的函数。不要更改任何行为。必须通过所有现有测试。

代码质量方面与测试 1 相同。两个模型都产生了完全相同的结果。它们将 construct_config 移至新的 config_builder.rs，拆分为专注的辅助函数，并保持所有 264 个测试绿色通过。两个 diff 的大小相差不到六行。

数据则呈现了不同的结果。Grok 用了 1 分 23 秒，消耗 197.1K Token。Opus 大约用了 5.5 分钟，消耗 953.7K Token。这意味着相同的产出，Opus 的 Token 消耗是 Grok 的 4.8 倍。成本也反映了这一点：Grok 的运行费用为 0.27 美元，Opus 为 1.67 美元。由于 Opus 在第一个测试中更快、更便宜，这些结果让我感到惊讶。

测试 3：功能开发

提示词：

为 fd 添加一个新的 –count 标志。当传递 –count 时，fd 不应打印匹配路径。相反，它打印一行：匹配条目的总数，同时遵循所有常规过滤器。将该标志添加到 CLI，连通逻辑，并确保所有现有行为和测试仍然通过。

这是代码细节出现分歧的地方。两者都正确实现了 –count。Grok 修改了 6 个文件，添加了一个测试，并更新了变更日志。Opus 修改了 7 个文件，增加了更多的测试覆盖率，并且更进一步，编写了 man 页面条目。Opus 的版本是两者中更详尽的一个。我运行了两个二进制文件，确认 –count 返回了正确的数字，并且在有无过滤器的情况下都与 fd | wc -l 匹配。

尽管代码质量有细微差别，但数据差异更大。Grok 在 1 分 37 秒内完成了功能开发，消耗 602.6K Token，成本 0.54 美元。Opus 大约用了 5 分半钟，消耗 320 万 Token，成本 3.25 美元。在最大的任务中，Opus 为了提供一个稍微详尽一点点但功能类似的结果，消耗了超过 5 倍的 Token。

测试结果

以下是每个模型在各项测试中的快速统计数据

在三项任务中，Opus 使用的 Token 数量是 Grok 的 4.3 倍。这几乎完全符合，甚至略高于 xAI 宣传的 4.2 倍差距。不得不说，这个结果非常令人惊讶。我一直将 Claude 作为我的首选 AI 模型，虽然我对它也有不满，但我总是默认它就是最好的。我不知道这种想法是从哪来的，但这确实是我大脑的第一反应。

对于一些测试说明，我认为有必要提一下。这些是 Cursor 的混合 Token 计数，而不是原始 API 数字，因此它们包含了 Agent 每次轮询时重新发送的上下文。Grok 在 Cursor 的“快速”层上运行，而 Opus 在“思考”层上运行，因此 Opus 的部分 Token 堆积是由于扩展推理而非浪费。Grok 的金额数字还包含 50% 的促销优惠。即使加倍到全额费率，它的三个任务成本约为 2 美元，而 Opus 为 5.14 美元。而且这只是在一个代码库中的三个任务，而不是三百个。

考虑到所有这些因素，主要评分标准中的模式保持不变。在代码方面，这两个模型是可以互换的：相同的 Bug 修复，相同的重构，相同的功能，Opus 在文档方面稍微详尽一点。

这让我得出结论，Grok 以大约四分之一（23%）的 Token、三分之一的时间和零头的价格完成了同样的工作。

如果你是一位不再热衷于“Token 最大化”的开发者，Grok 可能适合你。