Grok Build 价格账：最便宜的模型，为何要先交 $300/月？

xAI 到底发布了什么

2026 年 5 月 14 日，xAI 发布了 Grok Build。这是一款面向“专业软件工程与复杂编程工作”的智能体式编程 CLI，目前处于早期 beta。只有 SuperGrok Heavy 订阅用户（约 $299/月）可以使用；符合条件的账户只需运行一条命令：

curl -fsSL https://x.ai/cli | bash

它提供的是 2026 年编程智能体的标准配置：交互式 TUI、供脚本和 CI 使用的无头模式，以及可将智能体循环嵌入自有工具的 Agent API。真正值得注意的是并行能力——每次会话最多可启动 8 个子智能体，各自在独立的 git worktree 分支中运行。

这还不是 GA。xAI 明确表示 Grok Build 仍处于早期 beta，并正在收集反馈。官方发布帖将其定位为开发者预览，而非正式产品发布。评估时也应按预览版看待。

Grok Build 价格的矛盾：模型最便宜，入口最贵

底层模型确实便宜。grok-code-fast-1 API 定价为输入 $0.20/1M、输出 $1.50/1M、缓存输入 $0.02/1M。其输入价格是目前已上线的严肃编程模型中最低的；对于代码库级工作流，激进的缓存命中价格足以实质改变成本账。

基准成绩也站得住：采用 xAI 内部评测框架时，SWE-Bench Verified 得分为 70.8%。它能与当前主流模型竞争，但并非同类第一；对生产工作来说，它已经跨过了“真实可用”这道门槛。

问题出在产品包装上。模型按 API 用量计费，智能体却不是。早期 beta 阶段，Grok Build 只能通过固定 $300/月的 SuperGrok Heavy 订阅使用。你不能按 token 购买智能体循环，只能购买席位。

低价模型藏在昂贵的固定入口后面，只有当用量超过多数独立开发者永远达不到的门槛时才划算。定价问题的核心就是这一点。

独立开发者怎么算：订阅制还是 API 按量计费

我在 Claude Max 上运行着 6 条生产级发布流程，也已经算过两次 Codex 迁移账。Grok Build 不是又一个新玩具，而是要写进损益表的第 3 项支出；那张表上已经有 2 个编程智能体。

对于按量计费的技术栈——Max 上的 Claude Code、Codex——边际成本随 token 用量变化。你可以降低某条流程的频率、限制单次会话，或直接终止失控的循环，成本结构清晰可控。

固定 $300/月的入口，在每月编程智能体的 token 成本本来就会超过 $300 之前，只会是一笔闲置负担。这个门槛比多数独立开发者想象的更高。我的 Claude Max 席位已经覆盖这些流程；Codex 在损益表上也只是差一点——近到值得认真核算，却还没有近到让我迁移。第 3 份固定订阅不能直接叠加在前两份之上，它必须替换其中一个。

决策标准可以说得很直接：只有在 (a) xAI 推出按 API 用量计费的 Grok Build，或 (b) Arena Mode 正式上线，并在有代表性的评测中显著超过我当前的通过率时，我才会采用它。在此之前不会。

这不是怀疑模型能力，而是在计算入口成本。

把 token 成本算明白

把它当成一道盈亏平衡题：输入 $0.20/1M、输出 $1.50/1M 时，每月究竟要让 Grok Build 处理多少 token，固定 $300/月的订阅才会比 API 按量付费更便宜？

按独立开发者每天高强度使用的粗略估算，仅靠输入用量几乎达不到盈亏平衡点。大量输出的重构会话会让数字有所变化，但仍赢不了一个已经成为沉没成本的 Max 席位。要让固定档位值得占一个位置，要么有多名开发者持续使用，要么工作流会充分调用 8 个子智能体并行展开。

这里有两个限制条件：

$0.02/1M 的缓存输入价格异常激进。如果工作流的缓存局部性很高——同一个代码库、同一批文件、反复调用相同工具——实际输入成本会下降一个数量级，固定档位就很难击败按量计费的 API。

但 8 个子智能体并行会把成本推向另一个方向。在原本规模不大的工作流中，子智能体会成倍消耗 token，最坏可达 8×。面对这种并行扩散，固定档位看起来很慷慨，因为成本有上限；同一套工作流若通过 API 自行按量计费，则没有封顶。这正是 xAI 设置订阅门槛的一个现实原因：全并行展开时，最坏情况下的 API 账单确实可能高得吓人，而订阅定价吸收了这种波动。

这两个因素都说明，应该等按量计费版本推出后再做一次真实评测，而不是现在就先订阅，再假设最终总能算得过来。

本周应该怎么做

先不要取消任何服务。已经在运行的按量计费技术栈没有问题。

如果团队恰好有闲置的 SuperGrok Heavy 席位——确实有些团队会有——可以选一条非关键流程，用 grok-code-fast-1 与当前模型做一次 A/B 测试。不增加支出，却能获得真实信号。

通过 API 调用模型，在自己的真实代码库中只跑一项评测任务。输入 $0.20/1M，做一次有意义的评测只需几美分。先在自己的代码库里验证那项 70.8%，再决定该如何看待发布帖。基准只是起点，不是决策。

本周需要做的就这些。真正的问题是要不要增加第 3 项订阅支出，而诚实的答案是：除非入口发生变化，或者模型证明它配得上这个席位，否则不要。

接下来 30 天看什么

我会跟踪 3 个信号。

按 API 用量计费的 Grok Build。 一旦智能体本身也能按 token 购买，而不只是底层模型支持按量计费，低用量开发者的成本账就会反转。这是让它进入多数技术栈的唯一关键变化。

Arena Mode 正式上线。 xAI 已经预告过这项功能：多个智能体竞争解决同一个任务，并在结果交给开发者之前进行排名。如果通过率确有提升，能力上的优势就能脱离价格单独成立，整套计算也会随之改变。

xAI 会继续保留 SuperGrok Heavy 门槛，还是推出开发者档位。 这个入口是它无法进入多数开发者技术栈的唯一障碍。如果出现 $20–50/月的开发者档位，本文的结论就得重写。

在这 3 件事至少落地一件之前，Grok Build 仍是一个入口设计不合适、但实力可信的新选手。模型便宜，智能体不便宜。结论就这么简单。