译者说明本文为 Claude Developers 原文的非官方中文翻译。原文及图片版权归 Anthropic 和原作者所有本文不声明原创。调优提示缓存、指令和推理强度可以在不牺牲应用性能的前提下降低 Claude 的使用成本。人们常把性能与成本看作一组取舍想少花钱就得接受更差的结果。我们的实践却表明很多使用 Claude Platform 的应用只需做三件事就能在不牺牲性能的情况下降低成本尽可能提高提示缓存命中率升级到前沿 Claude 模型时清除提示词中的反模式根据任务校准推理强度effort。我们已经把这些建议写进了 claude-api skill。本文会展示 Claude Code 如何借助这个 skill 找到降低成本、同时维持甚至提升性能的办法。提示缓存Claude 在生成回复之前会先把提示词处理成一种内部工作状态。这个步骤叫作预填充prefill是处理输入时成本最高的部分。提示缓存会保存这个状态也就是键值缓存key-value cache简称 KV cache。当一个新请求以相同的前缀开头时Claude 会直接读取已保存的状态而不是重新计算。缓存读取的计费只相当于完整输入价格的一小部分。要让提示缓存真正发挥作用有几件事需要注意。第一提示缓存绑定于特定模型。第二读取缓存要求前缀在字节层面完全一致。最后提示缓存有有限的生存时间TTL。基于这些限制可以先从下面几件事做起谨慎在对话中途修改 effort 设置。这些设置会被渲染到实际内容之前因此属于缓存前缀的一部分。只有部分 Claude 模型包括 Opus 5 和 Fable 5.1允许你在对话中途更新 effort而不破坏缓存。不要把易变值放进前缀。系统提示词里的动态时间戳或 ID 可能在不同模型调用之间变化从而导致缓存失效。避免工具定义自行重排。使用 Claude Messages API 时提示词会按固定顺序组装工具定义位于顶部。工具定义发生任何变化都会破坏缓存。分叉对话时要谨慎。子智能体和分支只有在分叉后的前缀与父对话逐字节一致、使用相同模型并采用相同 effort 时才能共享父对话的缓存。如何修复我们在实践中积累了几条管理提示缓存的经验密切监控提示缓存命中率。Claude Console 和缓存诊断 API 会提供缓存诊断信息包括未命中的原因见图 1以及两个请求究竟从哪里开始出现差异。图 1Claude Console 可以比较请求找出提示前缀究竟从哪里开始出现差异从而诊断意外的提示缓存未命中。延迟加载不常用的工具。仍然需要在一开始声明所有工具但可以把很少使用的工具标记为 defer_loading。它们不会进入缓存前缀只有当 Claude 通过工具搜索找到它们时才会被追加到对话中因此不会破坏缓存。把系统提示词更新作为消息追加。部分 Claude 模型允许你在对话中途用一条消息添加系统指令而不必直接修改系统提示词这样可以保留缓存。安排请求结构让稳定的部分保持稳定。先放静态上下文例如工具定义和系统提示词再把持续增长的对话放在后面见图 2。图 2按照缓存机制组织提示词。在提示缓存本来就会失效时再切换模型或 effort。某些操作本来就会重写大部分缓存内容例如上下文压缩compaction。既然无论如何都要承担一次缓存未命中的成本这就是切换模型或 effort 的合适时机。随着对话增长移动缓存断点。Claude Platform 支持自动缓存可以把缓存断点自动移动到最后一个可缓存块。预热缓存。为了降低延迟可以用与真实流量相同的 effort 设置发送一个max_tokens: 0且带有显式缓存断点的请求。它只处理提示词并写入缓存不生成任何内容。如果在会话开始时就执行这一步例如趁用户还在输入时第一条真实请求就能命中已经预热的缓存。不要超过提示缓存的 TTL。5 分钟的缓存 TTL 从请求开始时计时。如果智能体被工具调用或子智能体请求阻塞超过 5 分钟父智能体的缓存会在结果返回前过期。遇到这种情况可以考虑为前缀设置 1 小时 TTL。指令提示词里常会逐渐堆积一些用来弥补模型弱点的指令。随着最新 Claude 模型的能力变化这些指令可能已经不再适配。下面这些常见的提示词“反模式”会拖累前沿 Claude 模型还可能在无意中增加成本验证仪式。“double-check your work”或“verify twice before responding”之类的指令常被前沿模型逐字执行白白消耗 token。彻底性与强调增幅器。“Be maximally thorough”或“CRITICAL: YOU MUST ALWAYS…”会让前沿模型输出得更冗长并执行更多工具调用。强制流程与草稿区脚手架。固定步骤例如“think step by step in a scratchpad”以及固定的推理模板都是前沿模型并不需要的仪式。它们会叠加在模型原生推理之上消耗不必要的 token。过时的示例。针对旧模型失败模式调过的少样本示例可能教会前沿模型在简单请求上也模仿冗长的推理链。互相矛盾的规则。前沿模型更擅长遵循指令也可能更严格地执行矛盾指令。例如“在政策允许范围内一律退款”与“未经升级处理绝不退款”同时出现时模型表现反而会下降。过时的配置。为旧一代 Claude 编写的设置例如手动 thinking budget可能会被使用新模型的 Claude Platform 直接拒绝。如何修复我们更新了 claude-api skill新增了一个专门检查这些反模式的命令。在 Claude Code 中对提示词、skill 或工具描述运行/claude-api prompt-audit。它会检查工作目录中的所有相关内容包括调用 Claude API 的应用代码以及 Claude Code 自身的配置例如CLAUDE.md或 skills。举个例子。我们在一个客服基准上测试了从 Opus 4.8 迁移到 Opus 5 的过程。起点是一份干净的提示词然后每次植入一种反模式已弃用的 thinking 设置、一对互相矛盾的退款规则、手动草稿区、“verify twice”、“be maximally thorough”以及强制执行的六步流程。最终得到六份旧式提示词。我们分别用三种配置运行每一份提示词Opus 4.8只改模型 ID 的 Opus 5以及对每份提示词运行一次/claude-api prompt-audit后的 Opus 5。图 3 展示的是六份提示词的平均结果。图 3从 Opus 4.8 迁移到 Opus 5 时提示词反模式带来的影响。在 Opus 5 上“verify twice”这样的验证仪式会在每次退款时重复查询订单造成不必要的 token 消耗。“be maximally thorough”这样的强调增幅器则会演变成几十次多余的知识库搜索。运行/claude-api prompt-audit清除这些反模式后平均成本下降了 14.6%准确率提高了 5.3%。成本下降是因为额外的工具调用和重复推理被消除了。准确率上升有三个原因。第一已弃用的 thinking 设置会让 API 直接拒绝所有路由请求。第二矛盾的退款规则让 Opus 5 暂扣了四笔本应支付的退款并要求客户再次确认。第三手动草稿区与 Opus 5 的内置思考发生冲突在三张工单上它把工具调用写进了推理过程却没有真正执行。Effort推理强度Effort 告诉 Claude“要投入多少功夫”。低 effort 时Claude 通常会更快得出结论高 effort 时它会在回答前投入更多思考、验证并探索其他方案。同一模型在不同 effort 档位下的成本与性能关系可能差别很大。以 Claude Fable 5 为例在 FrontierCode Diamond 最难的 50 个任务上它以低 effort 运行时得分为 11.5%每项任务成本为 5.35 美元以最高 effort 运行时得分为 30.9%每项任务成本为 19.00 美元。也就是说把 effort 从低档调到最高档得分约为原来的 2.7 倍增加 19 个百分点而成本约为原来的 3.5 倍见图 4。在 Claude Fable 5.1 上Humanitys Last Exam不使用工具的曲线很陡但最后一步的收益明显递减。低 effort 时它的得分约为 53%每道题成本约 0.30 美元最高 effort 时得分约 61%每道题成本约 2.23 美元。从次高档升到最高档只增加约 0.5 个百分点成本却多了 46%。这点增益落在基准测试不同运行之间的噪声范围内也就是说多花的钱没有带来可测量的提升。图 4Fable 5 在 FrontierCode Diamond 上不同 effort 档位的性能与成本。Effort 在两个方向上都可能校准失当以为越高越好。高 effort 可能导致过度思考。Claude 花在推敲上的时间超过任务实际需要不仅增加成本和延迟还可能降低回答质量。只有在仍有证据可查时继续推敲才有帮助。一味偏向低 effort。设置得太低Claude 可能在证据不足时就停下来。它会减少工具调用例如只看第一条搜索结果而不是继续查看第三条在困难步骤上思考更少也会跳过原本会自行执行的检查。答案看起来已经完成基础却只是片面信息。如何修复校准 effort 时可以采用下面几种方法用更强的模型搭配更低的 effort。更强模型以低 effort 工作可能比弱一些的模型全力运行更便宜。例如在 CursorBench 3.2 上Claude Fable 5.1 以低 effort 运行时性能与 Fable 5 的高 effort 相当成本却只有三分之一。新模型更便宜有两个原因低 effort 让它在每项任务上做更少的工作Fable 5.1 的提示缓存读取价格是每百万 token 0.25 美元而 Fable 5 为 1.00 美元。即使按照 Fable 5 的价格计算Fable 5.1 以低 effort 运行成本仍会低约 40%。图 5Fable 5 与 Fable 5.1 在 CursorBench 3.2 上不同 effort 档位的表现。先理解你的任务形态。在多个 effort 档位上逐档测量应用性能能帮助你看清特定任务的成本与性能关系。如果一项尚未饱和的评测在不同 effort 档位上呈现平坦的成本与性能曲线说明任务并不受思考计算量限制提高 effort 没有益处。这类校准往往需要跨模型、跨 effort 档位运行评测。在 Claude Code 中/claude-api hillclimb会替你完成这项搜索它把评测拆成训练集和测试集提出配置调整方案并阅读训练集中失败的样例再针对发现的问题进行修复。我们在一个客服基准上运行了它起点是默认使用高 effort 的 Opus 4.8。爬山优化器先尝试低 effort 的 Opus 5同时用 prompt-audit 移除强制工具调用仪式、草稿区步骤和矛盾规则。这个配置超过了 Opus 4.8 的基线训练集准确率达到 98.9%每张工单的成本降到 2.6 美分见图 6。图 6爬山式搜索同时改善成本与性能。接着它把模型降到低 effort 的 Sonnet 5成本进一步降到每张工单 1 美分但准确率跌至 88.9%。Claude 阅读训练集中失败的工单后在提示词中补充了路由规则和退款上限的交叉引用使 Sonnet 5 在成本不变的情况下重新达到 98.9%。在搜索过程从未见过的 14 张留出工单上最终配置得分为 90.5%原始配置为 78.6%而成本约为原来的五分之一。自动降低成本提示缓存、指令和 effort 是常见的降本杠杆我们的文档还介绍了更多方法。为了对使用 Claude API 的应用代码执行完整成本审计我们新增了/claude-api cost-optimize。它会分析支出流向、应用降本措施如果你提供评测还会展示节省成本与性能之间的取舍。cost-optimize首先会找出 token 花在哪里。如果你有 Claude Admin API key它会读取组织的用量与成本报告如果应用记录了每次 API 响应中的 usage 对象它会读取这些数据两者都没有时它会分析构造请求的代码并做估算。接着它会给可用的节省方案排序先检查提示缓存再精简每个请求携带的内容包括运行 prompt-audit、限制输出上限并对无人值守任务使用批处理。如果你提供评测它还会进一步计算不同 effort 档位与模型选择下的成本和性能。我们以 Sonnet 5 为基线在四项公开基准上运行了这套流程见图 7LegalBench成本降低约 58%cost-optimize建议在任务之间缓存共享前缀、使用低 effort并通过 Batch API 批量处理任务。Thinking token 从 102,779 降到 8,284通过率的变化仍在噪声范围内成本下降约 58%。tau2-bench retail成本降低约 73%通过显式放置缓存断点来实现提示缓存后cost-optimize将支出降低了 72%通过率保持不变。OfficeQA Pro成本降低约 52%cost-optimize加入了批处理和文档缓存把成本从 136.20 美元降到 64.87 美元。SWE-bench Verified成本降低约 55%cost-optimize发现默认配置的缓存已经正确生效。节省主要来自把 effort 设为中等并把智能体输出限制在几句简洁的话内。每项任务的步骤中位数从 29 降到 17提示 token 从 75.2M 降到 33.7M。图 7在四项基准上使用/claude-api cost-optimize后成本与性能的变化。开始使用如果你刚迁移到前沿 Claude 模型想检查现有提示词先用/claude-api prompt-audit。它会扫描工作目录中的提示词、skills 和工具描述包括调用 Claude API 的应用代码以及 Claude Code 的配置CLAUDE.md、skills。它会移除那些拖累前沿模型的常见反模式。如果你的应用使用 Claude API并且需要一次成本审计可以使用/claude-api cost-optimize。它先分析 token 支出再测试不同的降本手段除了运行 prompt-audit还会检查提示缓存、无人值守任务批处理和限制输出上限等机会。若提供评测它还会衡量 effort 与模型选择之间的取舍。最后使用/claude-api hillclimb在成本与性能之间执行搜索。Claude 会把评测拆成训练集和测试集再提出以降低成本、维持基线性能为目标的应用更新。它通过阅读训练集中的失败样例来指导搜索最后只在留出的测试集上评估最终配置。延伸阅读Claude Platform 成本与智能优化文档成本优化 Cookbookclaude-api skill该 skill 也内置于 Claude CodeClaude Blog 上的本文版本原文作者Lance MartinRLanceMartin、Brad Abramsbrada、Isabella HeIsabellaKHe和 Ben Lehrburgerbenlehrburger。
使用 Claude Platform 降低成本并提升性能
译者说明本文为 Claude Developers 原文的非官方中文翻译。原文及图片版权归 Anthropic 和原作者所有本文不声明原创。调优提示缓存、指令和推理强度可以在不牺牲应用性能的前提下降低 Claude 的使用成本。人们常把性能与成本看作一组取舍想少花钱就得接受更差的结果。我们的实践却表明很多使用 Claude Platform 的应用只需做三件事就能在不牺牲性能的情况下降低成本尽可能提高提示缓存命中率升级到前沿 Claude 模型时清除提示词中的反模式根据任务校准推理强度effort。我们已经把这些建议写进了 claude-api skill。本文会展示 Claude Code 如何借助这个 skill 找到降低成本、同时维持甚至提升性能的办法。提示缓存Claude 在生成回复之前会先把提示词处理成一种内部工作状态。这个步骤叫作预填充prefill是处理输入时成本最高的部分。提示缓存会保存这个状态也就是键值缓存key-value cache简称 KV cache。当一个新请求以相同的前缀开头时Claude 会直接读取已保存的状态而不是重新计算。缓存读取的计费只相当于完整输入价格的一小部分。要让提示缓存真正发挥作用有几件事需要注意。第一提示缓存绑定于特定模型。第二读取缓存要求前缀在字节层面完全一致。最后提示缓存有有限的生存时间TTL。基于这些限制可以先从下面几件事做起谨慎在对话中途修改 effort 设置。这些设置会被渲染到实际内容之前因此属于缓存前缀的一部分。只有部分 Claude 模型包括 Opus 5 和 Fable 5.1允许你在对话中途更新 effort而不破坏缓存。不要把易变值放进前缀。系统提示词里的动态时间戳或 ID 可能在不同模型调用之间变化从而导致缓存失效。避免工具定义自行重排。使用 Claude Messages API 时提示词会按固定顺序组装工具定义位于顶部。工具定义发生任何变化都会破坏缓存。分叉对话时要谨慎。子智能体和分支只有在分叉后的前缀与父对话逐字节一致、使用相同模型并采用相同 effort 时才能共享父对话的缓存。如何修复我们在实践中积累了几条管理提示缓存的经验密切监控提示缓存命中率。Claude Console 和缓存诊断 API 会提供缓存诊断信息包括未命中的原因见图 1以及两个请求究竟从哪里开始出现差异。图 1Claude Console 可以比较请求找出提示前缀究竟从哪里开始出现差异从而诊断意外的提示缓存未命中。延迟加载不常用的工具。仍然需要在一开始声明所有工具但可以把很少使用的工具标记为 defer_loading。它们不会进入缓存前缀只有当 Claude 通过工具搜索找到它们时才会被追加到对话中因此不会破坏缓存。把系统提示词更新作为消息追加。部分 Claude 模型允许你在对话中途用一条消息添加系统指令而不必直接修改系统提示词这样可以保留缓存。安排请求结构让稳定的部分保持稳定。先放静态上下文例如工具定义和系统提示词再把持续增长的对话放在后面见图 2。图 2按照缓存机制组织提示词。在提示缓存本来就会失效时再切换模型或 effort。某些操作本来就会重写大部分缓存内容例如上下文压缩compaction。既然无论如何都要承担一次缓存未命中的成本这就是切换模型或 effort 的合适时机。随着对话增长移动缓存断点。Claude Platform 支持自动缓存可以把缓存断点自动移动到最后一个可缓存块。预热缓存。为了降低延迟可以用与真实流量相同的 effort 设置发送一个max_tokens: 0且带有显式缓存断点的请求。它只处理提示词并写入缓存不生成任何内容。如果在会话开始时就执行这一步例如趁用户还在输入时第一条真实请求就能命中已经预热的缓存。不要超过提示缓存的 TTL。5 分钟的缓存 TTL 从请求开始时计时。如果智能体被工具调用或子智能体请求阻塞超过 5 分钟父智能体的缓存会在结果返回前过期。遇到这种情况可以考虑为前缀设置 1 小时 TTL。指令提示词里常会逐渐堆积一些用来弥补模型弱点的指令。随着最新 Claude 模型的能力变化这些指令可能已经不再适配。下面这些常见的提示词“反模式”会拖累前沿 Claude 模型还可能在无意中增加成本验证仪式。“double-check your work”或“verify twice before responding”之类的指令常被前沿模型逐字执行白白消耗 token。彻底性与强调增幅器。“Be maximally thorough”或“CRITICAL: YOU MUST ALWAYS…”会让前沿模型输出得更冗长并执行更多工具调用。强制流程与草稿区脚手架。固定步骤例如“think step by step in a scratchpad”以及固定的推理模板都是前沿模型并不需要的仪式。它们会叠加在模型原生推理之上消耗不必要的 token。过时的示例。针对旧模型失败模式调过的少样本示例可能教会前沿模型在简单请求上也模仿冗长的推理链。互相矛盾的规则。前沿模型更擅长遵循指令也可能更严格地执行矛盾指令。例如“在政策允许范围内一律退款”与“未经升级处理绝不退款”同时出现时模型表现反而会下降。过时的配置。为旧一代 Claude 编写的设置例如手动 thinking budget可能会被使用新模型的 Claude Platform 直接拒绝。如何修复我们更新了 claude-api skill新增了一个专门检查这些反模式的命令。在 Claude Code 中对提示词、skill 或工具描述运行/claude-api prompt-audit。它会检查工作目录中的所有相关内容包括调用 Claude API 的应用代码以及 Claude Code 自身的配置例如CLAUDE.md或 skills。举个例子。我们在一个客服基准上测试了从 Opus 4.8 迁移到 Opus 5 的过程。起点是一份干净的提示词然后每次植入一种反模式已弃用的 thinking 设置、一对互相矛盾的退款规则、手动草稿区、“verify twice”、“be maximally thorough”以及强制执行的六步流程。最终得到六份旧式提示词。我们分别用三种配置运行每一份提示词Opus 4.8只改模型 ID 的 Opus 5以及对每份提示词运行一次/claude-api prompt-audit后的 Opus 5。图 3 展示的是六份提示词的平均结果。图 3从 Opus 4.8 迁移到 Opus 5 时提示词反模式带来的影响。在 Opus 5 上“verify twice”这样的验证仪式会在每次退款时重复查询订单造成不必要的 token 消耗。“be maximally thorough”这样的强调增幅器则会演变成几十次多余的知识库搜索。运行/claude-api prompt-audit清除这些反模式后平均成本下降了 14.6%准确率提高了 5.3%。成本下降是因为额外的工具调用和重复推理被消除了。准确率上升有三个原因。第一已弃用的 thinking 设置会让 API 直接拒绝所有路由请求。第二矛盾的退款规则让 Opus 5 暂扣了四笔本应支付的退款并要求客户再次确认。第三手动草稿区与 Opus 5 的内置思考发生冲突在三张工单上它把工具调用写进了推理过程却没有真正执行。Effort推理强度Effort 告诉 Claude“要投入多少功夫”。低 effort 时Claude 通常会更快得出结论高 effort 时它会在回答前投入更多思考、验证并探索其他方案。同一模型在不同 effort 档位下的成本与性能关系可能差别很大。以 Claude Fable 5 为例在 FrontierCode Diamond 最难的 50 个任务上它以低 effort 运行时得分为 11.5%每项任务成本为 5.35 美元以最高 effort 运行时得分为 30.9%每项任务成本为 19.00 美元。也就是说把 effort 从低档调到最高档得分约为原来的 2.7 倍增加 19 个百分点而成本约为原来的 3.5 倍见图 4。在 Claude Fable 5.1 上Humanitys Last Exam不使用工具的曲线很陡但最后一步的收益明显递减。低 effort 时它的得分约为 53%每道题成本约 0.30 美元最高 effort 时得分约 61%每道题成本约 2.23 美元。从次高档升到最高档只增加约 0.5 个百分点成本却多了 46%。这点增益落在基准测试不同运行之间的噪声范围内也就是说多花的钱没有带来可测量的提升。图 4Fable 5 在 FrontierCode Diamond 上不同 effort 档位的性能与成本。Effort 在两个方向上都可能校准失当以为越高越好。高 effort 可能导致过度思考。Claude 花在推敲上的时间超过任务实际需要不仅增加成本和延迟还可能降低回答质量。只有在仍有证据可查时继续推敲才有帮助。一味偏向低 effort。设置得太低Claude 可能在证据不足时就停下来。它会减少工具调用例如只看第一条搜索结果而不是继续查看第三条在困难步骤上思考更少也会跳过原本会自行执行的检查。答案看起来已经完成基础却只是片面信息。如何修复校准 effort 时可以采用下面几种方法用更强的模型搭配更低的 effort。更强模型以低 effort 工作可能比弱一些的模型全力运行更便宜。例如在 CursorBench 3.2 上Claude Fable 5.1 以低 effort 运行时性能与 Fable 5 的高 effort 相当成本却只有三分之一。新模型更便宜有两个原因低 effort 让它在每项任务上做更少的工作Fable 5.1 的提示缓存读取价格是每百万 token 0.25 美元而 Fable 5 为 1.00 美元。即使按照 Fable 5 的价格计算Fable 5.1 以低 effort 运行成本仍会低约 40%。图 5Fable 5 与 Fable 5.1 在 CursorBench 3.2 上不同 effort 档位的表现。先理解你的任务形态。在多个 effort 档位上逐档测量应用性能能帮助你看清特定任务的成本与性能关系。如果一项尚未饱和的评测在不同 effort 档位上呈现平坦的成本与性能曲线说明任务并不受思考计算量限制提高 effort 没有益处。这类校准往往需要跨模型、跨 effort 档位运行评测。在 Claude Code 中/claude-api hillclimb会替你完成这项搜索它把评测拆成训练集和测试集提出配置调整方案并阅读训练集中失败的样例再针对发现的问题进行修复。我们在一个客服基准上运行了它起点是默认使用高 effort 的 Opus 4.8。爬山优化器先尝试低 effort 的 Opus 5同时用 prompt-audit 移除强制工具调用仪式、草稿区步骤和矛盾规则。这个配置超过了 Opus 4.8 的基线训练集准确率达到 98.9%每张工单的成本降到 2.6 美分见图 6。图 6爬山式搜索同时改善成本与性能。接着它把模型降到低 effort 的 Sonnet 5成本进一步降到每张工单 1 美分但准确率跌至 88.9%。Claude 阅读训练集中失败的工单后在提示词中补充了路由规则和退款上限的交叉引用使 Sonnet 5 在成本不变的情况下重新达到 98.9%。在搜索过程从未见过的 14 张留出工单上最终配置得分为 90.5%原始配置为 78.6%而成本约为原来的五分之一。自动降低成本提示缓存、指令和 effort 是常见的降本杠杆我们的文档还介绍了更多方法。为了对使用 Claude API 的应用代码执行完整成本审计我们新增了/claude-api cost-optimize。它会分析支出流向、应用降本措施如果你提供评测还会展示节省成本与性能之间的取舍。cost-optimize首先会找出 token 花在哪里。如果你有 Claude Admin API key它会读取组织的用量与成本报告如果应用记录了每次 API 响应中的 usage 对象它会读取这些数据两者都没有时它会分析构造请求的代码并做估算。接着它会给可用的节省方案排序先检查提示缓存再精简每个请求携带的内容包括运行 prompt-audit、限制输出上限并对无人值守任务使用批处理。如果你提供评测它还会进一步计算不同 effort 档位与模型选择下的成本和性能。我们以 Sonnet 5 为基线在四项公开基准上运行了这套流程见图 7LegalBench成本降低约 58%cost-optimize建议在任务之间缓存共享前缀、使用低 effort并通过 Batch API 批量处理任务。Thinking token 从 102,779 降到 8,284通过率的变化仍在噪声范围内成本下降约 58%。tau2-bench retail成本降低约 73%通过显式放置缓存断点来实现提示缓存后cost-optimize将支出降低了 72%通过率保持不变。OfficeQA Pro成本降低约 52%cost-optimize加入了批处理和文档缓存把成本从 136.20 美元降到 64.87 美元。SWE-bench Verified成本降低约 55%cost-optimize发现默认配置的缓存已经正确生效。节省主要来自把 effort 设为中等并把智能体输出限制在几句简洁的话内。每项任务的步骤中位数从 29 降到 17提示 token 从 75.2M 降到 33.7M。图 7在四项基准上使用/claude-api cost-optimize后成本与性能的变化。开始使用如果你刚迁移到前沿 Claude 模型想检查现有提示词先用/claude-api prompt-audit。它会扫描工作目录中的提示词、skills 和工具描述包括调用 Claude API 的应用代码以及 Claude Code 的配置CLAUDE.md、skills。它会移除那些拖累前沿模型的常见反模式。如果你的应用使用 Claude API并且需要一次成本审计可以使用/claude-api cost-optimize。它先分析 token 支出再测试不同的降本手段除了运行 prompt-audit还会检查提示缓存、无人值守任务批处理和限制输出上限等机会。若提供评测它还会衡量 effort 与模型选择之间的取舍。最后使用/claude-api hillclimb在成本与性能之间执行搜索。Claude 会把评测拆成训练集和测试集再提出以降低成本、维持基线性能为目标的应用更新。它通过阅读训练集中的失败样例来指导搜索最后只在留出的测试集上评估最终配置。延伸阅读Claude Platform 成本与智能优化文档成本优化 Cookbookclaude-api skill该 skill 也内置于 Claude CodeClaude Blog 上的本文版本原文作者Lance MartinRLanceMartin、Brad Abramsbrada、Isabella HeIsabellaKHe和 Ben Lehrburgerbenlehrburger。