Claude API 价格详解：build-eval 评测真的免费吗？

答案是否定的，但要先说清 Claude API 价格是怎么产生的：Claude API 的 build-eval 工作流是公开的，它编排的评测却不会自动免费。如果你想知道“Claude API build eval 是否免费”，就要把免费的操作说明和收费的实际运行分开看：24 个案例 × 3 次重复 × 2 个模型变体，意味着在任何可选的裁判或重试调用之前，应用就要执行 144 次。本次核查没有可用的付费应用试跑，因此 144 是算术结果，不是实测的美元总额。

Claude API 价格：build-eval 评测免费吗？

工作流文件可以免费阅读，但真正执行评测时，可能在三个环节产生付费模型用量。 Claude Code 可能消耗订阅套餐额度，也可能走按量计费账户；被测应用会调用自己的模型提供商；如果启用了模型裁判，还会再产生一组调用。使用本地确定性评分器可以避开第三笔费用，却无法免掉应用本身的调用成本。

这一点很重要，因为 build-eval 并不是一池免费的评测额度，而是一套由 Claude Code 引导的工作流，用来围绕已有应用搭建评测。它会帮助定位入口、整理案例、选择评分器、编写或改造运行器，并生成可供审查的结果。公开实现 已收录在 Anthropic 的 skills 仓库中，但最终运行器发起的调用，仍按所用账户和提供商的计费规则收费。

所以，更稳妥的答案带有前提：设计评测可以免费；只有当没有发生任何计费调用，或全部用量都落在你已经付费的额度内时，执行评测才不会新增费用。 即使如此，这里的“免费”也只表示账单边际成本为零，并不代表容量无限。

9 月 28 日和 29 日，具体发生了什么？

Anthropic 把评测构建和迭代优化明确拆成了两套 Claude Code 工作流。 2026 年 9 月 28 日发布的指南 引入了用于创建评测的 /claude-api build-eval，以及用于针对评测改进应用的 /claude-api hillclimb。这套实现于 9 月 29 日 02:20:03 UTC 在 commit 8a1541c4 中公开落地。

build-eval 从一条应用流程出发。它读取现有入口，询问代表性案例应从哪里获得，提出能够正确衡量输出且成本最低的评分方式，并要求对输入和评分方法分别给出明确批准。最终会在你的仓库中留下代码与证据，包括运行器、results.jsonl、trace 和报告。

hillclimb 则在此之后使用。它把案例拆成训练集和留出测试集，每次只修改一个获准调整的部分，重新运行评测，并撤销造成退步或只改善训练集的改动。它可以优化 prompt、模型选择、effort、工具或应用封装代码，但每尝试一个变体，都意味着更多执行次数。

真正持久的变化并不是“评测现在免费了”，而是 Claude Code 可以在不强制引入独立框架的情况下，搭建一套严谨、可审计的评测流程。工作流底层的计费模式并没有消失。

Claude API 价格拆解：build-eval 有四层成本

做预算时，应把四个成本面分开，因为其中只有一个明确免费。 如果统统归为一笔“Claude 费用”，事后就无法解释钱花在了哪里。

1. 公开工作流。 指南和 skill 文件是公开的。阅读这些资料、审查本地生成的文件，以及运行本地确定性检查，本身都不会产生 Claude API token 费用。
2. Claude Code 编排。 Claude Code 会读取仓库、向你提问、编写运行器，并协助检查结果。订阅用户消耗套餐额度；通过 API 认证的会话则消耗按量计费 token。Anthropic 的 Claude Code 成本文档 说明，API 用户看到的会话成本是估算值，而订阅用户看到的是套餐用量。当前套餐和认证细节可参阅本站的 Claude Code 价格指南。
3. 被测应用。 运行器应调用现有应用入口，而不是重新拼一个简化版模型请求。因此，每张客服工单、每次重试、每轮工具调用和每次重复，都会消耗该应用原本使用的提供商与账户额度。
4. 评分器。 固定标签、schema 检查、单元测试或终态断言都可以在本地运行。开放式答案则可能需要逐项或成对的模型裁判，这会额外增加输入、输出、缓存以及可能的工具用量。

省钱的第一步不是换一个更便宜的裁判，而是在输出具有受约束的正确形式时，优先选择程序化评分器。假设客服路由器必须从固定列表中返回一个队列，代码就能完成检查。为了判断 billing 是否等于 billing 而再请一个模型，等于花钱回答一道确定性问题。

只有当待评属性确实需要判断时，才使用模型裁判，例如检查升级摘要是否保留了客户的紧迫程度，同时没有编造事实。即便如此，也要把应用用量和裁判用量放在不同字段中。便宜的裁判可能掩盖昂贵的应用运行，反过来也一样。

算清执行次数：24 个案例如何变成 144 次应用运行

案例数只是第一个乘数。 Anthropic 的发布指南展示了一个包含 24 条输入的收件箱路由示例。如果比较 2 个模型变体，并让每个案例重复 3 次，应用执行次数就是：

24 个案例 × 3 次重复 × 2 个变体 = 144 次应用执行

这就是该设计的执行下限，还没有计算任何模型评分，也没有计算请求失败后的重试。之所以需要重复，是因为模型面对同一输入也可能给出不同答案；之所以需要变体，是因为对比必须拿到两套配置的输出。

评分器会改变下一个乘数：

• 程序化评分器： 模型裁判调用为 0，整轮仍是 144 次应用执行。
• 成对裁判： 如果每个案例的每次重复只用 1 次调用比较两个变体，就会产生 72 次裁判调用，因为 24 × 3 = 72 组配对。
• 逐项裁判： 如果每个应用输出都单独评分，就会产生 144 次裁判调用。这样总计为 288 次模型调用，即 144 次应用调用加 144 次裁判调用，尚未计入重试或 Claude Code 的编排用量。

Hillclimbing 还会再增加一个维度，因为每轮都要运行一个新候选方案。即使所有失败补丁最终都被撤销，尝试多个补丁的循环也可能花掉数个完整评测轮次。开始优化前，应先设定轮次上限和支出上限。“分数提高就停止”并不算预算，因为有噪声的分数可能让循环继续搜索。

Claude API 评测如何定价：从实测用量开始

单个案例没有固定价格，因此，站得住脚的估算只能从一次付费试跑的实际用量字段开始。 一张工单可能只需一次简短的分类调用，另一张却可能触发长上下文、多个工具、重试和裁判。如果一律按“一个评测案例”计价，就会掩盖真正决定账单的差异。

Anthropic 的直连 API 价目表已于 2026 年 9 月 29 日核验。以下价格均按每百万 token 计算：

来源：Anthropic 实时 Claude API 价格页面。如果使用 Amazon Bedrock 或 Google Cloud，应采用相应提供商自己的价目表，不要照搬这里的直连 API 价格。

针对试跑中的每一行，都按以下项目计算：

应用新输入 + 应用输出 + 应用缓存写入 + 应用缓存读取 + 裁判新输入 + 裁判输出 + 裁判缓存写入 + 裁判缓存读取 + 付费服务端工具

每一类 token 都要乘以生成它的模型费率。不要把缓存 token 合并进新输入。通用的简化算法会说，5 分钟缓存写入按输入价格的 1.25 倍计算，缓存读取按 0.1 倍计算，但当前价目表有两个重要的读取例外：Fable 5.1 是其输入费率的 0.025 倍，Opus 5.5 是 0.05 倍。直接套用 0.1 倍会高估两者。

裁判也要遵守同样的原则。如果应用使用 Sonnet 5.5，裁判使用 Haiku 4.5，就分别按各自的用量和费率计算。如果应用采用云厂商的协议价，就使用该合同价格。如果服务端工具按操作次数收费，则单独加入。客户端工具虽然不直接收费，却仍会扩大模型上下文，从而增加 token 账单。

本文没有给出实测美元金额，因为本次发布流程没有应用入口、提供商账户或获批的付费试跑。凭空编一个 token 数量，只会得到一个看起来整齐、实际无用的预算。费率表已经核验，但整轮运行的总价必须等实测用量出来后才能确定。

Claude Code build-eval：先给 5 个工单的试跑定价

最小且有价值的动作，是先让 5 个工单通过现有客服路由入口，再逐行检查用量。 5 个案例不足以证明系统已经达到生产质量，却足以在把错误放大到完整套件之前，确认运行器、评分器、trace 和成本核算是否接线正确。

使用 5 个覆盖不同路由行为的合成工单，不要复制客户数据：

• 客户无法打开账单门户。
• 一张卡似乎被重复扣款。
• 客户询问年度套餐能否退款。
• 生产环境中断，需要紧急升级处理。
• 企业买家要求修改合同。

这些只是建议的试跑案例，并不是已经完成的测试。它们应进入生产路由器实际使用的同一个函数、端点或脚本，同时隔离外部副作用。如果线上流程可能发邮件、修改数据库或呼叫工程师，只把这项副作用换成测试 fixture。prompt 组装、模型调用、工具、重试和响应解析应与生产环境等效，否则试跑估算的将是错误的系统。

1. 1

   确认入口与计费身份

   记录应用函数或端点、模型、提供商、账户、prompt、工具和输出形式。同时记录 Claude Code 本身如何认证。这样就能在任何一端开始运行前，把套餐额度与应用 API 用量分开。

2. 2

   批准 5 条输入与评分器

   逐条审查合成工单并批准预期路由。如果输出是固定队列标签，就使用程序化评分器。只有代码无法判断某项属性时才增加模型裁判，而且绝不能让被测模型给自己打分。

3. 3

   运行一次获批的付费试跑

   运行 5 个案例 × 1 次重复 × 1 个应用变体，也就是 5 次应用执行。已发布的工作流 要求在第一次付费运行前获得明确同意。如果预算尚未批准，就停在可运行的 dry setup，不要声称已经得到价格。

4. 4

   检查数据行，而不是控制台总数

   打开 results.jsonl 和一份 trace。确认成功数据行包含非空的 model 与 usage，入口会暴露 stop_reason，并且应用和裁判的用量可以区分。缓存写入与缓存读取字段必须保留，不能折叠进输入。一个本不该为 0 的值如果显示为 0，说明运行器有 bug，并不代表调用免费。

5. 5

   给完整规模定价并申请批准

   按实际提供商费率计算这 5 行，报告单案例的最小值、中位数和最大值，再乘以获批的案例数与重复次数。然后加入选定的评分器形态、重试次数和 hillclimb 上限。先展示这套公式，再申请运行完整评测。

这一顺序与已发布实现一致：先测量一次获批的付费试跑，检查其用量，然后才估算整套评测。历史平均值不能替代这一步，因为缓存状态、工具循环、effort、重试和输出长度都属于当前应用，而不属于某个平均应用。

开发者、运营负责人和采购方分别该做什么？

开发者应让成本在应用边界可观测。 如果入口隐藏了 model、usage 或 stop_reason，就应在编写完整运行器之前，把这些字段加入最终事件。保留提供商原生的缓存字段，并单独附上裁判用量。很多团队都会撞上同一堵墙：报告做得很漂亮，底层数据行却不完整。完整评测一旦结束，缺失的 token 分类往往再也无法还原。

运营负责人应掌握乘法和批准关卡。 要求在一页中列清案例数、重复次数、变体数、评分器调用、重试策略和 hillclimb 最大轮数。只写“24 个案例”的预算并不完整；写明 144 次应用执行、评分器形态、实测单案例用量和停止上限，预算才具备可审查性。

采购方应追问报价包含哪一层。 它是否覆盖 Claude Code 编排、应用模型、裁判、云提供商加价、工具费用、重试和优化轮次？供应商完全可能如实报出一个很便宜的裁判价格，却没有包含占据主要支出的应用运行。应要求对方提供试跑数据行和计算公式，而不只是一个总数。

谁该现在行动、暂缓，或继续使用插件评测？

如果应用已经有一个稳定入口、有一项待做的决策，并且你能安全审查 5 个代表性案例，现在就可以行动。 prompt 迁移、模型变更、路由策略调整或工具变更都是合适目标，因为评测可以比较具体的变更前后效果。

如果运行器还不能安全调用生产逻辑，就先等等。 首先隔离数据库写入、对外消息、破坏性工具和可变的外部状态。如果也没有人能够批准输入或评分器，同样应该暂缓。增加执行次数无法挽救一场测错任务的评测。

如果问题是 Claude Code 插件到底有没有价值，就继续使用原生插件评测路径。 该工作流按设计对比 WITH-plugin 和 W/OUT-plugin 两组会话。本站的 Claude Code 插件评测指南 介绍了这套独立对照。应用 build-eval 面向应用入口，并不是用通用基准替代插件对照实验。

如果已经有可信的运行器和评分器，则无需受此影响。 继续复用即可。公开实现明确建议改造现有组件，而不是一律换成新框架。真正有价值的新增部分，可能是批准纪律、用量采集或 hillclimb 循环，而非一套新的测试栈。

哪些说法被夸大了？

这套工作流降低了搭建门槛，却不会让评测变得自动、客观或免费。 Claude 可以提出案例，但仍需要人来判断它们是否代表生产场景。它可以推荐评分器，但仍需要人确认：标准答案能够通过、空答案无法通过，而且模型裁判没有把表达风格误当成正确性。

Hillclimbing 也不是免费的优化器。它会有意运行更多变体、读取失败结果、提出补丁，然后再次评测。留出集可以防止一种过拟合，却不能免除足够的案例、足够的重复次数或支出上限。

只有底层数据行完整，报告才算证据。一份漂亮的 report.html 如果旁边都是空的 usage 字段，就无法回答成本问题。根据假设 token 数量算出的美元总价也好不到哪里去。在获批的付费试跑之前，唯一站得住脚的交付物是执行计划和当前费率表，实测总额应暂时留空。

周一就做这件事

给一个负责人一项边界明确的试跑任务，而不是一句没有终点的“去做评测”。 周一，选定客服路由器的现有入口，写出上面的 5 个合成工单，并使用固定标签的程序化评分器。和负责客服政策的运营人员一起审查输入及预期路由。

然后申请批准恰好运行 5 次应用执行。检查 results.jsonl、一份 trace、每一类用量和 stop_reason，再按实际提供商费率给这些数据行定价。只有完成这一步，才应该提出包含 24 个案例、3 次重复和 2 个变体的方案，以及相应的裁判、重试与 hillclimb 上限。

决策规则很直接：试跑用量不完整，就不批准完整运行预算。