用 Claude Code 的三个命令
优化 API 成本

三个命令来自 Anthropic 开源仓 anthropics/skills 中的 claude-api skill，Claude Code 加载其中的说明与脚本后即可使用。Anthropic 负责 Claude Platform 与这项 skill 的工程师 Lance Martin，在 2026 年 9 月 8 日的官方博客中介绍了它们的分工与实测结果。缓存、旧提示词与 effort 的降本机制已在前篇《按每个任务算成本》中展开，这篇接着看命令如何执行这些优化。

三个命令对评测集的要求不同。这里的 eval 指一组用于衡量配置准确率与成本的任务。

官方按上述顺序介绍了适用场景：模型升级后检查提示词，API 应用需要降本时审计成本，有评测集时再搜索配置。这些命令并非都要等评测集准备好才能使用。

Anthropic 在一个客服基准上测试了 Opus 4.8 → Opus 5 的迁移。实验从一份干净提示词出发，每次只植入一个反模式，形成六份旧提示词：一个已弃用的 thinking 设置、一对矛盾的退款规则、一个手工 scratchpad、verify twice、be maximally thorough，以及一个强制六步流程。

每份提示词都在三种配置下评测：使用 Opus 4.8；只更换 model ID，改用 Opus 5；先运行 /claude-api prompt-audit，再改用 Opus 5。图 3 展示六份提示词的平均结果。

审计后，平均成本降 14.6%，准确率升 5.3%。图中的三个点分别是：Opus 4.8 旧提示词 2.52¢ · 89.4%；Opus 5 未审计 3.43¢ · 91.7%；Opus 5 审计后 2.93¢ · 97.0%。图内把审计这一步标为 +5.3 点、−0.49¢。

同一句「核验两遍」，在 Opus 5 上变成了每次退款都查询两遍订单；「尽可能彻底」则触发了几十次不必要的知识库搜索。博客将成本下降归因于删除了这些多余调用和重复推理。

准确率的改善，博客追溯到了三个具体故障：

• 已弃用的 thinking 设置让 API 拒绝了所有路由请求。
• 两条退款规则互相矛盾，Opus 5 因而暂扣了四笔本应退还的款项，转而要求客户确认。
• 手工 scratchpad 要求模型把推理过程写出来，却与内建 thinking 互相干扰。三张工单中的工具调用只写进了推理过程，没有执行。

这次实验中的 5.3 点和 14.6% 都来自 eval 测量。没有 eval，prompt-audit 仍能删除反模式，却无法衡量这些改动对任务表现的影响；effort 的取舍同样需要 eval 才能判断。

在 Cognition 的编码基准 FrontierCode 上，Diamond 子集包含其中最难的 50 题。Fable 5 从 low 的 11.5%、每任务 $5.35，升到 max 的 30.9%、每任务 $19.00：成本增至约 3.5 倍，分数增至约 2.7 倍（+19 点）。图 4 标注的差值为 +19.4 点，中间三档没有标注具体点值。

Fable 5.1 的最后一档收益则明显缩小。在 Humanity's Last Exam 上，low 约 53%、每题约 $0.30，max 约 61%、每题约 $2.23。这项由 Center for AI Safety 与 Scale AI 联合推出的基准包含 2,500 道专家级跨学科题目，博客中的测试不使用工具。最后一步升到 max 只增加约半分，成本却提高 46%。这点增益仍未超出重复运行时分数的自然波动范围，博客据此判断，增加的成本没有带来可测的收益。

换一代模型，结果又不同。在 Cursor 基于真实会话构建的编码 agent 基准 CursorBench 3.2 上，Fable 5.1 的 low 追平 Fable 5 的 high，成本只有三分之一。博客给出了两个原因：低档每项任务做的工作更少，缓存读取也更便宜。Fable 5.1 的缓存读价为每百万 token $0.25，Fable 5 为 $1.00。即使按 Fable 5 的价格计算，Fable 5.1 的低档仍便宜约 40%。图 5 没有标注各点的具体数值。

博客提醒，effort 过高或过低都可能影响质量：过高时，模型可能在任务已经不需要继续推敲的地方反复思考，增加成本和延迟；过低时，又可能证据不足就停止，只看第一条搜索结果而不再查看第三条，或跳过原本会自行执行的检查。回答看似完整，依据却不充分。

校准时，官方建议既测试更强模型的低档配置，也在同一任务上逐档评测 effort。如果评测得分尚未达到上限，提高 effort 后表现仍无变化，就提示这项任务可能不受推理投入限制。跨模型、跨档位反复运行评测的工作，可以交给 hillclimb。

换成 Sonnet 5 后，训练集准确率一度下降；Claude 随后读取失败工单、补充规则，才在不增加成本的情况下恢复到 98.9%。这次搜索同时调整了模型、effort 和提示词。

最后，用搜索期间未见过的 14 张工单测试：新配置准确率为 90.5%，原配置为 78.6%，成本约为原来的五分之一。这与训练集上的 98.9% 对 74.4% 是两组结果。

优化顺序相对固定：先检查缓存，再精简每次请求携带的内容，其中包括运行 prompt-audit；随后限制输出，并把无人值守的工作交给 Batch API。只有提供 eval 后，它才会继续计算 effort 与模型选择带来的成本和性能取舍。

四个公开基准都以 Sonnet 5 为起点，但采用的降本手段不同。

在法律分类基准 LegalBench 上，cost-optimize 建议跨任务共享缓存前缀、使用 low effort，并通过 Batch API 执行任务。thinking token 从 102,779 降到 8,284，pass rate 的变化未超出运行噪声范围，成本约降 58%。

在客服 agent 基准的零售场景 tau2-bench retail 上，优化集中在提示缓存和显式 breakpoint，成本降 73%，pass rate 持平。

在文档问答基准 OfficeQA Pro 上，加入批处理和文档缓存后，成本从 $136.20 降到 $64.87，约降 52%。

在编码 agent 基准 SWE-bench Verified 上，原配置已经正确使用缓存，节省来自将 effort 调到 medium，并把 agent 输出限制为几句简短的话。每项任务的中位步数从 29 降到 17，prompt token 从 75.2M 降到 33.7M，成本约降 55%。

四个基准的分数变化置信区间都跨零。成本虽都下降，节省的来源却不同：tau2-bench 靠缓存，SWE-bench Verified 的缓存原本已正确，改的是 effort 和输出长度。cost-optimize 先检查应用的实际开销，再选择优化手段。

请求中，工具定义和系统提示等稳定内容放在前面，持续增长的对话放在后面。为保持前缀不变，博客给出了两项配套做法：不常用的工具标记为 defer_loading，保留声明，但等 Claude 通过工具搜索找到后再加入对话；系统指令需要更新时，以新消息追加，不改原有系统提示。

换模型或调整 effort 的时机，也会影响缓存开销。博客建议等到缓存本来就要重写时再改，例如对长对话做 compaction（压缩重写）时。对话持续增长后，缓存断点也要后移；Claude Platform 的自动缓存可以将断点放在最后一个可缓存块上。

预热则可以提前完成：发送带显式缓存断点的 max_tokens: 0 请求，只处理提示词、写入缓存，不生成内容。第一个真实请求就能直接读取已准备好的缓存。

等待工具或子 agent 返回的时间，也计入缓存的有效期。默认的 5 分钟 TTL 从请求发出时开始计时；工具调用或子 agent 请求若耗时超过 5 分钟，父级缓存可能在结果返回前过期。下一轮便要重新写入缓存，价格为正常输入价的 1.25 倍，1 小时档则为 2 倍。针对这类长时间等待，博客建议考虑为前缀设置 1 小时 TTL。