Anthropic 发布了一篇 Claude Platform 成本优化的官方指南，核心观点是：成本和性能往往不是非此即彼的关系，很多应用的浪费其实来自配置不当。
文章给出了三个优化方向：最大化 prompt cache 命中率、升级模型时清除提示词中的反模式、以及根据任务复杂度校准 effort 参数。
这些建议已经封装进了 claude-api skill，可以在 Claude Code 中直接调用。在多个公开 benchmark 上的实测中，成本降幅从 52% 到 73% 不等，性能基本持平甚至有所提升。
“ 原文：Reducing cost and improving performance with Claude Platform 作者：Lance Martin、Brad Abrams、Isabella He、Ben Lehrburger
性能和成本，通常被看作一对 trade-off：想省钱，就得接受效果变差。但在实践中我们发现，很多使用 Claude Platform 的应用其实可以在不牺牲性能的前提下把成本降下来，只需要做好三件事：最大化 prompt cache 命中率、升级到前沿 Claude 模型时清除提示词中的反模式、以及根据任务复杂度校准 effort 参数。
我们已经把这些优化建议整合进了 claude-api skill。本文将展示 Claude Code 配合这个 skill，如何帮你找到降本的机会，同时保持甚至提升性能。
Claude 在生成回复之前，需要先把你的 prompt 处理成一个内部工作状态。这个步骤叫做 prefill，也是处理输入中最贵的环节。
Prompt cache 会保存这个状态（也就是 KV cache）：当下一次请求的开头和上次完全相同时，Claude 直接读取缓存，而不用重新计算。缓存读取的价格远低于正常输入价格。
要让 prompt cache 真正生效，有几个关键点需要注意：缓存是绑定具体模型的；缓存读取要求前缀逐字节完全一致；而且缓存有有限的存活时间（TTL）。
基于这些特性，有几条实用建议：
• 对话中途慎改 effort 设置。 effort 会渲染到 prompt 中、排在你的内容前面，所以它也是缓存前缀的一部分。目前只有部分 Claude 模型（包括 Opus 5 和 Fable 5.1）支持中途更新 effort 而不破坏缓存。
• 不要把动态值放在前缀里。 如果你在 system prompt 里塞了一个动态时间戳或 ID，每次请求都会变，缓存就会失效。
• 避免工具定义自行重排序。 使用 Claude Messages API 时，prompt 按固定顺序组装，工具定义排在最前面。工具定义的任何变化都会让缓存失效。
• 对话分叉时要小心。 子 Agent 和分支只有在前缀逐字节相同、使用相同模型和相同 effort 的情况下，才能共享父级的缓存。
以下是我们积累的一些优化经验：
密切监控缓存命中率。 Claude Console 和 cache diagnostics API 提供了详细的缓存诊断，包括缓存未命中的原因以及两次请求具体在哪里开始分叉。
延迟加载低频工具。 你可以预先声明所有工具，但把不常用的标记为 defer_loading：它们不会出现在缓存前缀中，只有当 Claude 通过 tool search 查找时才会追加到对话里，这样就不会破坏缓存。
用消息方式追加系统指令。 部分 Claude 模型支持把系统指令作为一条消息插入对话中间，而不是去修改 system prompt，这样可以保住缓存。
请求结构设计成「前稳后增」。 把静态内容（工具定义和 system prompt）放在前面，不断增长的对话内容放在后面。
趁缓存本来就要失效时再改配置。 有些操作（比如 compaction）本身就会重写大量对话内容，这是切换模型或 effort 的好时机——反正已经要付一次 miss 的代价了。
随对话增长移动缓存断点。 Claude Platform 支持自动缓存模式，可以把缓存断点设在最后一个可缓存的 block 上。
预热缓存。 为了降低延迟，可以发一个 max_tokens: 0 的请求加上显式的缓存断点，使用和真实流量相同的 effort 设置。这会处理 prompt 并写入缓存，但不会生成任何内容。
如果在会话开始时就做这一步（比如用户正在打字时），第一个真正的请求就能命中热缓存。
不要超出缓存 TTL。 5 分钟的缓存 TTL 从请求开始计时。如果一个 Agent 在等待工具调用或子 Agent 响应时阻塞超过 5 分钟，父级的缓存就会在结果返回前过期。
这种情况下，可以考虑把前缀的 TTL 设为 1 小时。
提示词中容易积累一些「补丁」式的指令，用来弥补旧模型的不足。随着模型升级，这些指令不仅失去了意义，还可能反过来拖累前沿模型。以下是常见的反模式：
验证仪式。 类似「double-check your work」「verify twice before responding」的指令，前沿模型会照字面执行，白白浪费 token。
全力以赴式强调。 「Be maximally thorough」「CRITICAL: YOU MUST ALWAYS…」这类指令，在前沿模型上会导致冗长输出和多余的工具调用。
固定步骤和草稿纸模板。 固化的思考流程（比如「think step by step in a scratchpad」）或推理模板，是前沿模型根本不需要的脚手架。这些脚手架会叠加在模型原生的推理能力之上，浪费 token。
过时的示例。 针对旧模型失败模式调过的 few-shot 示例，可能教会前沿模型在不需要的时候也去模仿冗长的推理链。
矛盾的规则。 前沿模型更擅长遵循指令。互相矛盾的指令（比如「始终按政策退款」和「没有升级就不退款」）会被更严格地执行，反而导致性能下降。
过时的配置。 为旧版 Claude 写的设置（比如手动思考预算）可能会被新版 Claude Platform 直接拒绝。
我们在 claude-api skill 中新增了一个检测命令。在 Claude Code 中运行 /claude-api prompt-audit，就可以扫描你的 prompt、skill 和工具描述。
审计范围覆盖工作目录下的所有内容，包括调用 Claude API 的应用代码和 Claude Code 自身的配置（CLAUDE.md、skill 等）。
我们在一个客服 benchmark 上测试了从 Opus 4.8 迁移到 Opus 5 的效果。
从一个干净的 prompt 出发，每次植入一个反模式（一个已废弃的思考设置、一对矛盾的退款规则、一个手动草稿纸、「verify twice」、「be maximally thorough」、以及一个强制六步流程），得到六个遗留 prompt。
每个 prompt 分别在三种配置下测试：Opus 4.8、直接换模型 ID 到 Opus 5、以及运行一次 prompt-audit 后的 Opus 5。下图展示的是六个 prompt 的平均结果。
Opus 5 上，验证仪式（「verify twice」）会让每次退款都多做一次重复的订单查询。全力以赴式强调（「be maximally thorough」）则触发了几十次无用的知识库搜索。
运行 prompt-audit 去掉这些反模式后，成本平均降低了 14.6%，准确率提升了 5.3%。
成本下降是因为消除了多余的工具调用和重复推理。
准确率提升则有三个原因。废弃的思考设置导致 API 直接拒绝了所有路由请求；矛盾的退款规则让 Opus 5 扣住了四笔本应退款的请求、转而去找客户确认。
而手动草稿纸和 Opus 5 的内置思考能力发生了冲突，在三个工单上模型把工具调用写在了推理过程里，但从未实际执行。
Effort 告诉 Claude「用多大力气工作」。低 effort 下 Claude 通常更快得出结论，高 effort 下则会反复推敲、验证、探索替代方案之后再回答。
不同 effort 级别下，同一模型的成本和性能差异可以很大。
例如 Claude Fable 5 在 FrontierCode Diamond（最难的 50 个任务）上，low effort 得分 11.5%，每个任务 5.35 美元；max effort 得分 30.9%，每个任务 19.00 美元。提高 effort 把得分提升了约 2.7 倍（+19 分），成本则增加了约 3.5 倍。
再看 Claude Fable 5.1 在 Humanity's Last Exam（无工具）上的表现：low effort 大约 53%，每题约 0.30 美元；max effort 大约 61%，每题约 2.23 美元。从 high 到 max 的最后一步只多了大约半个百分点，却多花了 46% 的成本。而这个提升本身落在 benchmark 的运行误差范围内，等于花了更多钱却没有可衡量的收益。
Effort 的校准可能在两个方向上出问题：
认为越高越好。 高 effort 可能导致过度思考。Claude 花了超出任务所需的时间去推敲，增加了成本和延迟，甚至可能降低回答质量。推敲只有在还有证据可以挖掘的时候才有帮助。
一味压低 effort。 设得太低，Claude 会在收集到足够证据之前就停下来。它会减少工具调用次数，可能只根据第一条搜索结果就给出答案而不是看完第三条。
在困难步骤上思考得更少，也跳过了本来会自己做的检查。答案看上去是完整的，但其实建立在不完整的信息上。
以下是几个实用的校准方法：
用更强的模型跑更低的 effort。 更强的模型在 low effort 下，可能比更弱的模型拼命跑还便宜。
例如在 CursorBench 3.2 上，Claude Fable 5.1 在 low effort 下的性能和 Fable 5 在 high effort 下持平，但成本只有后者的三分之一。
新模型更便宜有两个原因：low effort 下每个任务做的工作更少，而且 Fable 5.1 的 prompt cache 读取价格是每百万 token 0.25 美元，Fable 5 则是 1.00 美元。
即使按 Fable 5 的价格算，Fable 5.1 在 low effort 下也便宜约 40%。
理解你的任务形态。 在一组 effort 级别上跑评估，是理解你特定任务的成本-性能 trade-off 的好办法。
在一个尚未饱和的评估上，如果成本-性能曲线在不同 effort 级别之间是平的，说明任务本身不受思考计算量的约束，提高 effort 没有意义。
这种校准通常需要在多个模型和 effort 级别上跑评估。在 Claude Code 中，/claude-api hillclimb 可以替你完成这个搜索。
它会把评估拆成训练集和测试集，提出配置变更方案，并通过阅读失败的训练样例来修正发现的问题。
我们在一个客服 benchmark 上跑了 hillclimb，起点是 Opus 4.8 的默认 effort（high）。
hillclimber 首先尝试了 Opus 5 在 low effort，同时用 prompt-audit 去除了强制工具调用仪式、草稿纸步骤和矛盾规则，结果在训练集上达到 98.9% 的准确率，成本降到了每张工单 2.6 美分。
然后它尝试降级到 Sonnet 5 在 low effort，成本更低，每张工单只要 1 美分，但准确率掉到了 88.9%。
通过阅读训练集里失败的工单，Claude 在 prompt 中补充了路由规则和退款上限交叉验证，把 Sonnet 5 的准确率拉回了 98.9%，成本不变。
在搜索过程从未见过的 14 张测试工单上，最终配置得分 90.5%，而原始配置是 78.6%，成本只有原来的五分之一。
Prompt cache、提示词优化和 effort 校准是最常见的降本手段，我们的文档里还有更多方法。
为了对使用 Claude API 的应用代码做一次全面的成本审计，我们新增了 /claude-api cost-optimize：它会分析你的花费去向、应用降本措施，如果你提供了评估集，还会展示省钱和性能之间的 trade-off。
cost-optimize 首先分析你的 token 花在了哪里。如果你有 Claude Admin API key，从组织的用量和成本报告中获取；如果你的应用记录了每个 API 响应的 usage 对象，从日志中获取。
以上都没有的话，就通过阅读你的请求构建代码来估算。
然后它会对可用的优化手段排优先级：从 prompt cache 开始，到精简每个请求携带的内容（包括一次 prompt-audit）、限制输出长度、把无人值守的任务走 Batch API。
如果你提供了评估集，它还会进一步测试不同 effort 级别和模型选择下的成本与性能表现。
我们用 Sonnet 5 作为基线，在四个公开 benchmark 上测试了这个功能：
LegalBench（成本降低约 58%）： cost-optimize 建议在多个任务间缓存共享前缀、设置 low effort、使用 Batch API。思考 token 从 102,779 降到 8,284，通过率在误差范围内保持不变。
tau2-bench retail（成本降低约 73%）： 通过显式设置缓存断点来实现 prompt cache，在通过率持平的前提下把花费降低了 72%。
OfficeQA Pro（成本降低约 52%）： 增加了批处理和文档缓存，成本从 136.20 美元降到 64.87 美元。
SWE-bench Verified（成本降低约 55%）： cost-optimize 发现默认配置已经正确使用了缓存，节省来自把 effort 设为 medium 并限制 Agent 的输出只写几句简洁的话。每个任务的中位步骤数从 29 降到 17，prompt token 从 7520 万降到 3370 万。
当你迁移到前沿 Claude 模型、想检查现有 prompt 时， 从 /claude-api prompt-audit 开始。它扫描工作目录下的 prompt、skill 和工具描述，去除拖累前沿模型的常见反模式。
当你的应用使用 Claude API、想做一次成本审计时， 用 /claude-api cost-optimize。它会分析 token 花费，然后测试不同的优化手段：prompt cache、批处理无人值守任务、限制输出长度等。如果你提供了评估集，它还会衡量 effort 和模型选择的 trade-off。
当你想搜索成本和性能的最优组合时， 用 /claude-api hillclimb。给定一个评估集，Claude 会拆成训练集和测试集，然后提出旨在降本但不牺牲基线性能的配置变更方案。Claude 会阅读失败的训练样例来引导搜索，最终配置在从未见过的测试集上打分。
◇ ◆ ◇
• 原文链接：https://x.com/ClaudeDevs/status/2097369738968195513
• claude-api skill：Claude Code 内置
