先别急着看官方宣传，我们直接用实测结果说话。Grok 4.5 最近在开发者圈引发了不少讨论，核心卖点非常明确：编程能力接近 Claude Opus 4.8，但 Token 消耗大约只有对方的四分之一。如果这一点成立，那么它在 AI 编程模型里的性价比确实相当突出。

通过对比测试可以看到，Grok 4.5 在编程任务中，能够以约为 Claude Opus 四分之一的 Token 消耗与更低成本，交付接近同等质量的代码，尽管 Opus 在文档完整度和细节补充方面略有优势。对于重视成本控制和开发效率的程序员、团队和企业来说，这一结果很有参考意义。

那么，Grok 4.5 真的能在只消耗四分之一 Token 的前提下，与 Claude Opus 正面对比而不落下风吗？

xAI 于 7 月 8 日发布了 Grok 4.5。该模型在训练过程中引入了 Cursor 会话数据。xAI 对外表示，Grok 4.5 的编程能力基本可与 Claude Opus 4.8 持平，但实现这一效果所需的输出 Token 约少 4.2 倍。很明显，xAI 的产品策略正是瞄准那些高度关注 Token 成本和 API 使用费用的开发者。

Grok 的基础使用成本也更低。每百万输入 Token 收费 2 美元，输出 Token 收费 6 美元；而 Opus 对应价格分别是 5 美元和 25 美元。单从定价来看，Grok 甚至不到对方的一半，这对长期高频调用大模型写代码的用户来说吸引力很强。

从基准测试数据来看，xAI 的宣传并非空穴来风。Terminal-Bench 2.1 主要衡量模型在命令行环境中处理真实任务的能力。在这项测试中，xAI 给出的 Grok 4.5 得分为 83.3%，略高于 Opus 4.8 的 78.9%。而难度更高的 SWE-Bench Pro，则侧重评估模型修复开源项目真实 Bug 的能力，在这项测试里 Opus 依然更强。因此，更准确的说法并不是“Grok 更好”，而是“效果接近，但价格明显更低”。

仅从这些基准分数和模型定价来看，xAI 显然希望切入并争夺 Anthropic 的开发者市场。Anthropic 目前在 AI 编程助手和开发场景中拥有很高的人气，因此如果想真正撼动它，相关营销表述就必须经得起实际测试验证。

为了得到更可靠的答案，让 Grok 4.5 和 Claude Opus 4.8 在同一套代码库中，围绕三个任务展开正面对比，并完整记录每一个 Token 的消耗情况。

测试过程

测试对象使用的是 fd，这是 sharkdp 开发的一款知名 Rust 文件搜索工具。fd 可以看作是 Unix find 命令更快、更易用的替代方案。之所以选择它，是因为它属于真实的生产级 Rust 项目，同时拥有较完整、可追溯的历史 Bug 记录，非常适合做 AI 编程能力评测。

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 中删除了整整一行代码，生成的 diff 完全一致，同时也都保证了 70 个测试用例全部通过。两个版本都重新完成了编译，用于确认 Bug 已经消失，并额外检查了相邻标志位的行为是否仍然正常。之后还把模型生成的修复，与维护者在 2021 年提交的真实修复进行了对比。官方修复删除了三行，而两个模型只删除了其中一行，但在测试所有相关标志时，实际行为完全一致，多删除的部分更像是代码清理而非必要修补。

由于修复代码完全一样，最终比较主要看数据表现。Opus 通过一次请求，在 30.43 秒内完成，总共使用 174.1K Token。Grok 则分成两次请求完成，耗时 46.25 秒，消耗 210.2K Token。

在三个测试里，这个最小规模的任务中，Opus 显然更有优势。因此，xAI 关于“更省 Token”的营销卖点，在这个单一的小任务上并没有得到体现。

测试 2：重构

提示词：

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

在代码质量上，这一轮与测试 1 基本相同。两个模型再次给出了几乎一致的结果。它们都把 construct_config 移动到了新的 config_builder.rs 文件中，并拆分出更小、更聚焦的辅助函数，同时保持 264 个测试全部通过。两个 diff 的差距甚至不到六行。

不过在数据维度上，结果开始明显拉开。Grok 总耗时 1 分 23 秒，Token 消耗为 197.1K；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 每次轮询时重复发送上下文所带来的额外 Token。与此同时，Grok 跑在 Cursor 的“快速”层，Opus 跑在“思考”层，所以 Opus 的部分 Token 增长来自更长的推理链，而不一定全都是浪费。另一个变量是，Grok 的金额数据还包含了 50% 的促销折扣。即便按全价翻倍计算，它完成这三个任务的总成本也大约在 2 美元，而 Opus 仍然是 5.14 美元。更重要的是，这里测试的还只是一个代码库中的三个任务，而不是大规模团队开发中的三百个任务。

即便把这些影响因素全部考虑进去，核心结论依然没有变化。在实际代码结果上，这两个大模型基本可以互相替代：相同的 Bug 修复、接近相同的重构结果、功能一致的新增能力，而 Opus 主要是在文档说明和细节补充上更全面一点。

这也就意味着，Grok 以大约四分之一（23%）的 Token、约三分之一的时间，以及更低的价格，完成了几乎同样的开发工作。

如果你是一位更关注 AI 编程效率、Token 成本和大模型性价比，而不再追求“Token 用得越多越好”的开发者，那么 Grok 很可能值得你认真尝试。