Claude Platform 三个方法帮你降成本同时不丢性能

性能和成本通常被视为一种权衡：为了花费更少，你接受更差的结果。在实践中，我们发现许多使用Claude Platform的应用程序可以通过三个修复措施在不牺牲性能的情况下降低成本：最大化提示缓存命中率、在升级到前沿Claude模型时移除提示中的反模式，以及根据任务校准努力程度。我们已将这些指导纳入claude-api技能中。在本文中，我们展示了Claude Code配合claude-api如何经常找到降低成本同时保持或提升性能的方法。

提示缓存

在Claude生成响应之前，它首先将你的提示处理为内部工作状态。这一步称为预填充，是处理输入中成本较高的部分。提示缓存保存该状态（键值对，即KV缓存）：当请求以相同前缀开始时，Claude会读回它而不是重新计算。缓存读取按完整输入价格的一小部分计费。

为确保有效使用提示缓存，有几个实际考虑因素。首先，提示缓存绑定到特定模型。其次，提示缓存读取必须在提示的整个跨度内字节完全一致。最后，提示缓存具有有限的生存时间（TTL）。

考虑到这些要点，有几个实用技巧：

- 避免在对话中途更改努力或思考设置。这些设置会在你的内容之前渲染到提示中，因此它们是缓存前缀的一部分。具体对于Claude Opus 5和Fable 5.1，你可以在对话中途更新努力设置而不会破坏缓存。
- 将易变值排除在前缀之外。系统提示中的动态时间戳或ID可能在不同模型调用之间变化，从而破坏缓存。
- 避免工具定义自行重新排序。使用Claude Messages API时，提示按固定顺序组装，工具定义渲染在顶部。工具定义的任何更改都会破坏缓存。
- 分叉对话时要小心。子代理和分支仅在分叉的前缀字节完全一致、使用相同模型且使用相同努力设置时共享父级的缓存。
- 避免同步工具调用和子代理超过缓存TTL。如果代理阻塞在长时间运行的工具调用或子代理上，缓存可能在结果返回前过期。下一轮必须重写缓存，价格为正常输入价格的1.25倍（1小时缓存为2倍），而不是便宜的读取价格。

如何修复

我们积累了一些关于提示缓存管理的经验教训：

- 仔细监控提示缓存命中率。Claude Console提供提示缓存诊断，包括提示缓存未命中的原因（图1）。如果命中率意外下降，缓存诊断API会准确告诉你两个请求在何处出现分歧。

图1. Claude Console可以通过比较连续请求并识别提示前缀在何处出现分歧来诊断意外的提示缓存未命中。

- 延迟加载不常用的工具。预先声明所有工具，但将不常用的标记为defer_loading：它们保持在缓存前缀之外，仅在Claude通过工具搜索查找时附加到对话中，从而保留缓存。
- 将系统提示更新作为消息应用。Claude Platform允许你在对话中途将系统指令作为消息添加，而不是编辑系统提示，这保留了缓存。
- 布局请求，使稳定部分保持稳定。先添加静态上下文（工具定义和系统提示），然后将增长的对话放在它们之后（图2）。

图2. 组织提示以确保动态内容附加到稳定前缀的末尾。

- 在提示缓存已经会被破坏时更改模型或努力设置。某些操作（如压缩）已经重写了缓存的大部分（对话）。这是切换模型或努力设置的好时机，因为你反正要支付未命中的费用。
- 随着对话增长移动缓存断点。使用Claude Platform，你可以设置自动缓存，将缓存断点自动应用于最后一个可缓存块。
- 预热缓存。为减少延迟，发送一个max_tokens: 0且带有显式缓存断点的请求。这会处理提示并将其写入缓存而不生成任何内容。如果你在会话开始时运行它（例如，在用户输入时），第一个真实请求将命中热缓存。
- 不要超过提示缓存TTL。5分钟缓存TTL从请求开始计算。如果代理阻塞在运行超过5分钟的工具调用或子代理请求上，父级的缓存会在结果返回前过期。在这种情况下，考虑在前缀上设置1小时TTL。

指令

提示可能会积累修补模型弱点的指令。这些指令可能相对于最新Claude模型的能力发生漂移。以下是常见的提示“反模式”，它们会削弱前沿Claude模型并可能无意中增加成本：

- 验证仪式。像“仔细检查你的工作”或“在响应前验证两次”这样的指令通常被前沿模型字面理解，可能浪费令牌。
- 彻底性和强调增强器。“做到最大程度地彻底”、“关键：你必须始终……”在使用前沿模型时可能导致冗长和额外的工具调用。
- 强制程序和草稿纸脚手架。固定步骤过程（例如，“在草稿纸上逐步思考”）或推理模板是前沿模型不需要的仪式。这种脚手架可能叠加在原生推理之上，使用不必要的令牌。
- 过时的示例。针对旧模型失败模式调整的少样本示例可能教会前沿模型在不需要的请求上模仿长推理链。
- 矛盾的规则。前沿模型更擅长遵循指令。矛盾的指令（“始终在政策范围内退款”与“未经升级绝不退款”）可能被前沿模型更字面地遵循，导致性能下降。
- 过时的配置。为旧版Claude世代编写的设置（例如，手动思考预算）在升级到前沿模型时可能被Claude Platform拒绝。

如何修复

我们更新了claude-api技能，添加了一个新命令来监视这些反模式。在Claude Code中，对你的提示、技能或工具描述运行/claude-api prompt-audit。审计涵盖工作目录中的任何内容，包括调用Claude API的应用程序代码和Claude Code自身的配置（例如，CLAUDE.md或技能）。

例如，我们在客户支持基准上测试了从Opus 4.8到Opus 5的模型迁移。我们从干净的提示开始，一次植入一个反模式（一个已退役的思考设置、一对矛盾的退款规则、一个手动草稿纸、“验证两次”、“做到最大程度地彻底”和一个强制六步程序），得到六个遗留提示。

我们在Opus 4.8上运行每个提示，在仅更改模型ID的Opus 5上运行，以及在每个提示运行一次/claude-api prompt-audit后的Opus 5上运行（图3显示六个的平均值）。

图3. 从Opus 4.8迁移到Opus 5期间提示反模式的影响。

使用Opus 5时，验证仪式（“验证两次”）通过每次退款时重复订单查找来使用不必要的令牌。强调增强器（“做到最大程度地彻底”）变成了数十次不必要的知识库搜索。

运行/claude-api prompt-audit移除了反模式，平均降低成本14.6%并提高准确性5.3%。成本下降是因为消除了额外的工具调用和重复推理。准确性上升有三个原因。已退役的思考设置导致API立即拒绝每个路由请求。矛盾的退款规则导致Opus 5扣留了四次应退的退款，同时要求客户确认。手动草稿纸与Opus 5的内置思考冲突：在三张工单上，它将工具调用写在推理内部而从未执行。

努力程度

努力程度告诉Claude“要多努力地工作”。在低努力下，Claude通常更快地得出结论。在高努力下，Claude在回答前会深思、验证并探索替代方案。

单个模型在不同努力水平下的成本与性能比可能有所不同。例如，Claude Fable 5在FrontierCode Diamond（最难的50个任务）上以低努力获得11.5%的得分，每个任务成本$5.35。在最大努力下，Fable 5获得30.9%，每个任务成本$19.00；改变努力程度将得分提高约2.7倍（+19个百分点），成本约为3.5倍（图4）。

在Claude Fable 5.1上，Humanity's Last Exam（无工具）显示出陡峭的曲线，最后一步收益递减。它在低努力下得分约53%，每个问题成本约$0.30，在最大努力下得分约61%，每个问题成本约$2.23；最后一步提升到最大努力仅增加约半个百分点，成本增加46%。该增益在基准测试的运行间噪声范围内，因此你支付更多却得不到可衡量的收益。

图4. Fable 5在FrontierCode Diamond上不同努力水平下的性能与成本。

努力程度可能在任一方向上校准不当：

- 假设越高越好。高努力可能导致过度思考。Claude花费比任务所需更多的时间深思，这增加了成本/延迟并可能降低答案质量。深思仅在仍有证据可寻时才有帮助。
- 偏向低努力。设置过低时，Claude在获得足够证据前停止。它进行更少的工具调用，因此可能从第一个搜索结果而不是第三个回答。它在困难步骤上思考更少，并跳过它通常会自行运行的检查。答案看起来已完成，但建立在部分信息之上。

如何修复

有一些有用的方法来校准努力程度：

- 在低努力下测试更强的模型。低努力下的更强模型可能比高努力下工作的较弱模型更便宜。例如，在CursorBench 3.2上，Claude Fable 5.1在低努力下匹配Fable 5在高努力下的性能，成本仅为三分之一（图5）。两个因素使新模型更便宜：在低努力下每个任务做的工作更少，且Fable 5.1的提示缓存读取定价为每百万令牌$0.25，而Fable 5为$1.00。即使按Fable 5的价格，低努力下的Fable 5.1成本也会低约40%。

图5. Fable 5与Fable 5.1在CursorBench 3.2上不同努力水平下的对比。

- 了解你的任务形态。在一系列努力水平上测量应用程序性能是理解特定任务成本-性能权衡的有用方法。在未饱和的评估中，跨努力水平的平坦性能-成本曲线表明任务不受思考计算限制；增加努力没有益处。

这种校准通常涉及跨模型和努力水平运行评估。在Claude Code中，/claude-api hillclimb为你执行此搜索：它将评估分为训练集和测试集，提出配置更改，并读取失败的训练示例来修复发现的问题。

我们在客户支持基准上运行了它，从Opus 4.8默认（高）努力开始。爬山器首先尝试低努力下的Opus 5，应用prompt-audit移除强制工具调用仪式、草稿纸步骤和矛盾规则。这超过了Opus 4.8基线，训练准确率为98.9%，成本降至每张工单2.6美分。

图6. 爬山通过更新模型选择、努力程度和提示来改善成本和性能。

然后它降级到低努力下的Sonnet 5，成本更低，每张工单1美分，但准确率降至88.9%。读取失败的训练工单后，Claude向提示添加了路由规则和退款上限交叉引用，使Sonnet 5恢复到98.9%，成本不变。

在搜索从未见过的14张保留工单上，最终配置得分90.5%，而原始设置为78.6%，成本约为五分之一。

自动化成本降低

提示缓存、指令和努力程度是降低成本的常见杠杆。我们的文档涵盖更多内容。为了对使用Claude API的应用程序代码进行整体成本审计，我们添加了/claude-api cost-optimize：它分析你的支出去向，应用成本降低措施，如果你提供评估，则显示节省与性能之间的权衡。

cost-optimize首先找到你的令牌去向：如果你有Claude Admin API密钥，则从组织的使用和成本报告中获取；如果你的应用程序记录日志，则从每个API响应的usage对象中获取；如果两者都不可用，则通过读取你的请求构建代码并估算。

然后它对可用的节省进行排序，从提示缓存开始，削减每个请求携带的内容（包括prompt-audit），限制输出，以及批处理无人值守的工作。如果你提供评估，它会进一步计算不同努力水平和模型选择下的成本和性能。

我们在四个公共基准上运行了它，以Sonnet 5作为基线（图7）：

- LegalBench（成本降低约58%）：cost-optimize建议跨任务缓存共享前缀，设置低努力，并通过Batch API处理任务。思考令牌从102,779降至8,284，但通过率保持在噪声范围内，成本下降约58%。
- tau2-bench零售（成本降低约73%）：通过实现具有显式断点放置的提示缓存，cost-optimize将支出减少73%，同时保持通过率平稳。
- OfficeQA Pro（成本降低约52%）：cost-optimize添加了批处理处理和文档缓存，将成本从$136.20降至$64.87。
- SWE-bench Verified（成本降低约55%）：cost-optimize发现默认配置已正确缓存。节省来自将努力设置为中等并限制代理输出仅为几句简洁句子。每个任务的中位步骤从29降至17，提示令牌从75.2M降至33.7M。

图7. 使用/claude-api cost-optimize跨基准的成本和性能变化。

入门

当你迁移到前沿Claude模型并想检查现有提示时，从/claude-api prompt-audit开始。它扫描工作目录中的提示、技能和工具描述。这可以是调用Claude API的应用程序代码或Claude Code的配置（CLAUDE.md、技能）。它移除削弱前沿模型的常见反模式。

当你的应用程序使用Claude API且你想要成本审计时，使用/claude-api cost-optimize。它分析令牌支出，然后测试不同的杠杆：它应用prompt-audit，但也检查通过提示缓存、批处理无人值守工作或限制输出来降低成本的方法。如果你提供评估，它会衡量努力和模型选择的权衡。

最后，使用/claude-api hillclimb进行成本和性能的迭代搜索。给定评估后，Claude将其分为训练集和测试集，然后提出旨在降低成本同时保持基线性能的应用程序更新。Claude读取失败的训练案例来指导搜索，最终配置在保留的测试集上评分。

了解更多：

- 参见我们的文档，此处
- 参见我们的食谱，此处