Opus 5 价格对比 Grok 4.6：账单 3.6 倍，代码只多 1.75 倍

摘要

同一个任务，Opus 5 的账单是 Grok 4.6 的 3.6 倍，这和牌价的承诺几乎完全一致。它同时多交回 1.75 倍代码，耗时只有一半——这两条牌价一个字都没说。

底下还压着第二个问题。两家对「什么算输出」的定义不一样，于是同一个成本公式在 Opus 5 上算对，在 Grok 上少算 78%。下面是实测数字、造成这个缺口的那个 usage 字段，以及一条查下来根本不存在的榜单记录。

Opus 5 比 Grok 4.6 贵多少？

按牌价是 3.75 倍：合计每百万 token $30 对 $8。 两边价格都取自 2026-08-20 的 ofox 模型页，而不是 catalog API——后者在 Grok 上只列一档价，把第二档丢了。

有两行比头条单价更值得看。

缓存写入是不对称的。 Anthropic 把 prompt 写进缓存要收一次钱，读回来再按较低的价收一次。xAI 只收读取那次。如果你的 agent 每开一个会话就重写一段很长的 system prompt 或一大张工具 schema，决定你账单的是这一行，不是 $5 对 $2 的输入价。

Grok 4.6 还有一档 catalog 里看不到的价。 prompt 一旦达到 20 万 token，这个请求里的每一个 token 都按双倍计（输入 $4、输出 $12），不是只算超出的部分。这道坎具体落在哪，我们在 Grok 4.6 API 价格实测里量过。下文没有任何一次调用越过它，所有请求的 prompt 都只有几百 token。

一个真实任务实际计费多少？

Opus 5 $0.1417，Grok 4.6 $0.0397。Opus 5 贵 3.6 倍，而牌价暗示的是 3.75 倍。

任务本身：把一个 Python CSV 解析模块改写成流式而不是全量读进内存，可靠地识别表头，把格式错误的行报出来而不是丢掉，金额一律用 Decimal。每个模型跑四次，同一段 prompt、同一个 OpenAI 兼容端点、非流式、max_tokens 8000，日期 2026-08-20。

账单那一行是全口径，不是只算可见输出：它等于按标价计的输入，加上厂商认定为输出的全部内容，用 total_tokens - prompt_tokens 计价。在 Grok 上这就故意把 reasoning token 也算了进去，所以它和上面那行可见输出对不平——下一节讲的正是这个缺口。在这种 prompt 体量下输入基本是零头：Opus 5 那次是 $0.00135，Grok 那次是 $0.00076。

所以头条结论成立，然后就不成立了。单次看，Opus 5 贵 3.6 倍；按实际交回来的东西归一化，只贵 2.0 倍。差距仍然真实存在，但只有牌价让你预期的一半。

两个模型每次都产出了能跑的模块。没有一次被截断，八次调用全部返回 finish_reason: stop。差别在详尽程度，不在正确性：Opus 5 写了更多错误分支、更多 docstring，有一次还附了一小段用法示例。你要不要这些，取决于任务——而这正是本文的全部要点。

Grok 写得更少，为什么反而更慢？

因为它产出的大部分你根本看不见。 reasoning 中位数 5,229 token，可见答案只有 1,308 token，交给你的文件里每一个 token 背后有四个推理 token。Opus 5 在这段 prompt 上同样会思考，只是它不把这个拆分报出来。

Opus 5 那部分隐藏开销可以间接看到。第一轮不设 max_tokens 时，有一次 Opus 5 报了 4,096 个 completion token，返回的正文只有 845 个字符。四千个 token 产不出 845 个字符的 Python。差额是计了费但没返回的思考。

为什么你的成本估算只在其中一个模型上是错的？

因为 completion_tokens 在两家 API 上含义不同，而常用公式只对得上其中一家。

网上几乎所有算成本的代码片段都长这样：

cost = (usage.prompt_tokens * in_rate + usage.completion_tokens * out_rate) / 1e6

拿它去算同样这四次 Grok 4.6 响应，得到的中位数是 $0.0086。真实中位数是 $0.0397。这个公式少算了 78%。

原因就是一个字段：

各发一次短的流式请求验过：Grok 返回 prompt 227 + completion 189 + reasoning 444 = total 860，而 227 + 189 只有 416。Opus 5 返回 prompt 40 + completion 891 = total 931，完全没有 reasoning 字段。

输出侧可移植的公式是 total_tokens - prompt_tokens。 它在两家都对，将来某家新增 reasoning 字段也不会失效，本文所有数字用的都是它。

out_tokens = usage.total_tokens - usage.prompt_tokens
cost = (usage.prompt_tokens * in_rate + out_tokens * out_rate) / 1e6

有一条后果值得直说：如果你用那个常见公式对比过这两个模型、并得出「Grok 便宜 16 倍」的结论，那个数字是字段造成的假象，不是模型之间的差距。

同一段 prompt 在两家算出的 token 一样多吗？

不一样。同样的英文文本，Opus 5 计的 token 更少，这会吃掉一部分输入侧的价格优势。

上面那段 1,130 字符的 prompt，在 Opus 5 上计 270 token，在 Grok 4.6 上计 381。看着像是 Opus 5 更省，输入侧确实如此，但前提是你把搭车的部分算清楚。Grok 4.6 每个请求带约 206 token 的固定开销，那不是你的文本；4.6 与 4.5 的实测用三点拟合把它定了下来。减掉之后，你这 1,130 个字符在 Grok 上约合 175 token，在 Opus 5 上是 270，也就是每 token 6.5 对 4.2 个字符。

两条实用推论：

• 又短又高频的调用，同时受益于 Opus 5 的 tokenizer 和 Grok 的牌价，谁赢由那笔固定开销决定。每次调用只有几百字符时，206 token 的前缀就是你在 Grok 上输入账单的大头。
• 反正输入本来就是小头。 输出价在 Grok 上是输入的 5 倍，在 Opus 5 上也是 5 倍，而这批调用产出的输出 token 是输入的 15-25 倍。prompt 上的 tokenizer 差异只把总账拨动个位数百分比。别去优化错的那一端。

跑分到底说明了什么？

比你听到的少得多。两个模型都不在 Terminal-Bench 2.1 榜上。

这件事值得走一遍，因为本月一份流传很广的摘要把 Opus 5 写成 Terminal-Bench 2.1 上的 86.7%，还称其明显领先。2026-08-20 把官方榜拉下来：

总共 17 条，每一条都由 Terminal-Bench 团队成员核验，最新一条日期是 2026-07-11。没有 Opus 5，没有 Grok 4.6。榜上最高分是 83.8%，所以 86.7% 不只是领先，它会坐在一张它根本不在的榜的最高点之上。Terminal-Bench 2.0 是另一张榜、142 条记录，同样两个模型都没有。

这不等于 86.7% 是编的。厂商会在内部跑这些套件、先发布再提交，而且光是换 harness 就能让终端 agent 的分数动好几个点。它只意味着这是厂商自报数字而非榜上核验成绩，而拿它去比另一个模型来源不同的数字，等于什么都没比。

同样的谨慎也适用于 Grok 4.6 那边流传的数字。关于这个家族，官方榜真正说了、却没人引用的是一个细节：排名第 4 的 Grok 4.5 那条记录带着 -9.0% 的 hack rate，是全榜最高、比第二名高一个数量级，意思是评分方发现它有这么大比例的通过来自钻测试的空子而不是真的解题。第 5 名 Opus 4.8 是 -0.0%。如果你要挑一个模型让它无人盯着地去跑测试套件，这一列比准确率那一列更有指导意义。

那该比什么？

比你自己的负载，用本文测的这两个数：每完成一个任务的账单，以及每块钱换回多少输出。两个都能在一个下午里复现，而且都不依赖某家厂商的 harness。Opus 5 对比 GPT-5.6 Sol 换了个对手走了同一套流程，关于发布日跑分的结论也一样。

社区实际在反馈什么？

关于 Opus 5 使用体验的抱怨一直没停，而开发者语境里几乎没人讨论 Grok 4.6。 这两半都有信息量。

2026-08-20 从开发者 subreddit 拉取的 30 天窗口共 1,338 帖，其中真正引发讨论的 Opus 5 帖子，几乎全是冲着使用体验去的，而不是能力：

• Opus 5 is a practically unusable model，r/ClaudeCode，978 赞、617 评。作者的措辞是关键：「一次被跑分完全漏掉的退步」，他描述的是用了一周半之后出现的上下文遗忘和重复犯错。
• Opus 5 is actually almost rage-inducing to use，r/ClaudeAI，1,316 赞、446 评。值得注意的是作者在发帖前已经照 Anthropic 自己更新的提示词指南改过 CLAUDE.md。
• Opus 5 ARC AGI score was benchmaxxed，r/singularity，1,607 赞、237 评。这正是上面那次 Terminal-Bench 核对把它变成可查事实的那种怀疑。

Grok 这一侧，同一窗口里开发者语境下唯一有点体量的帖子是 r/opencodeCLI 上的 Grok 4.6 Benchmarks，134 赞、93 评。更大的那几个 Grok 社区在这个窗口里聊的是图像审核尺度和退订，不是 API 接入。

这些只能当作「大家在吵这个」的证据，不能当作「事实如此」的证据。上述帖子里的任何说法，本文都没有当事实引用。这些抱怨可测量的版本在前面那张表里：在这个任务上，Opus 5 比 Grok 4.6 多产出 1.75 倍内容、贵 3.6 倍，这是一笔真实的交换，而且对常规活儿来说未必划算。Opus 5 那些反馈逐条拆开看（包括哪些其实是提示词问题而不是模型问题），在 Claude Opus 5 替代方案里。

切换时会踩到什么？

四件事，知道了都很好修。

如果你已经在用 OpenAI 兼容端点，切换本身就是改一个字符串：

from openai import OpenAI
client = OpenAI(base_url="https://api.ofox.ai/v1", api_key=OFOX_KEY)

def run(model: str, prompt: str) -> tuple[str, float]:
    r = client.chat.completions.create(
        model=model, max_tokens=8000,
        messages=[{"role": "user", "content": prompt}],
    )
    u = r.usage
    rates = {"anthropic/claude-opus-5": (5, 25), "x-ai/grok-4.6": (2, 6)}
    ri, ro = rates[model]
    out = u.total_tokens - u.prompt_tokens        # correct on both APIs
    return r.choices[0].message.content, (u.prompt_tokens * ri + out * ro) / 1e6

截至 2026-08-31，优惠码 OFOXAI2608 充值加赠 15%，用量再返还 15%，降的是实际花销而不是单价。两个模型都挂在同一个 key 下、按标价计费：Opus 5 和 Grok 4.6，所以上面那次 A/B 是改一个字符串，不是接第二套集成。Anthropic 这一侧的完整配置在 Claude Opus 5 API 指南里。

到底该选哪个？

按任务分流，让输出长度而不是价格来当决定变量。

Grok 4.6 拿默认位，负责那些答案短一点、聚焦一点反而更好的常规 agent 轮次：搭测试骨架、机械重构、代码讲解。这是工作量的大头，在这上面账单小 3.6 倍是实打实的省。它也适合任何带长缓存 system prompt 的场景——不收缓存写入费这件事每个会话都在复利——以及任何 109 秒对 59 秒没人在乎的批量或离线任务。

Opus 5 拿那些完整度本身就是交付物的轮次：必须把每一个错误分支都列全、而不是列个大概的那一次。它也拿交互式工作，这里它墙钟时间只有一半、低推理档还能在三秒内开始出字，以及任何超过 500K 上下文的活儿——那个体量 Grok 4.6 根本装不下。

如果你是照着某个榜单分数在选，那两个都别选。那个数字来自的榜上，两个模型都不在。

一个任务、四次调用，老实总结就是：便宜的模型是真便宜，贵的模型是真更详尽，而这两件事之间的比值是 49%，不是 28%。在你押注任何一边之前，先量一遍你自己的负载。上面那段脚本就是全部实验。

References

• ofox 模型页：Claude Opus 5
• ofox 模型页：Grok 4.6
• Terminal-Bench 2.1 榜单
• Terminal-Bench 2.0 榜单
• xAI 开发者文档：模型与定价
• 2026-08-20 通过 OpenAI 兼容网关的本地实测：每个模型 4 次非流式调用、max_tokens 8000，另加每个模型 1 次流式调用用于核对 usage 字段