Anthropic 发布 Claude Platform 降本指南并更新 claude-api 技能

性能与成本往往被视为一种权衡：想要花得更少，就得接受更差的结果。但在实践中我们发现，许多使用 Claude Platform 的应用只需三项调整，就能在不牺牲性能的前提下削减成本：最大化提示词缓存命中率、在升级到前沿 Claude 模型时移除提示词中的反模式，以及根据任务校准投入力度。我们已将这些指导整理进 claude-api skill 中。在本文中，我们将展示 Claude Code 配合 claude-api 如何常常能在维持甚至提升性能的同时找到降低成本的方法。

提示词缓存

在 Claude 生成回复之前，它会先将你的提示词处理为一种内部工作状态。这一步被称为 prefill，是处理输入中成本最高的部分。提示词缓存会保存这一状态（即键值缓存，或称 KV cache）：当请求以相同前缀开头时，Claude 会直接读回该状态，而不是重新计算。缓存读取的计费价格仅为完整输入价格的一小部分。

要确保有效利用提示词缓存，有几个实际注意事项。首先，提示词缓存与特定模型绑定。其次，提示词缓存读取必须在提示词的整个跨度上做到逐字节精确匹配。最后，提示词缓存有有限的生存时间（TTL）。

基于以上几点，这里有一些实用建议：

避免在对话中途更改 effort 或 thinking 设置。这些设置会渲染到你的内容之前的提示词中，因此它们是缓存前缀的一部分。具体到 Claude Opus 5 和 Fable 5.1，你可以在对话中途更新 effort而不会破坏缓存。

将易变的值排除在前缀之外。系统提示词中的动态时间戳或 ID 可能会在模型调用之间发生变化，从而破坏缓存。

避免使用会自行重新排序的工具定义。使用 Claude Messages API 时，提示词会按固定顺序组装，工具定义渲染在最前面。对工具定义的任何更改都会破坏缓存。

分叉对话时要小心。只有当分叉的前缀在字节级别完全一致、使用相同模型且使用相同 effort 时，子智能体和分支才共享父级的缓存。

避免同步工具调用和存活时间超过缓存 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 模型的表现，并可能无意中增加成本：

验证仪式。像“请仔细检查你的工作”或“在回复前请验证两次”这样的指令，往往会被前沿模型按字面意思理解，从而浪费模型 token。

详尽性与强调性增强词。“请做到最大限度的详尽”、“关键：你必须始终……”这类表述在使用前沿模型时，可能会导致输出冗长并产生额外的工具调用。

强制流程与草稿纸式脚手架。固定的步骤流程（例如“在草稿纸上一步步思考”）或推理模板，都是前沿模型并不需要的仪式性做法。这类脚手架会叠加在模型原生的推理能力之上，消耗不必要的模型 token。

过时的示例。针对旧模型失败模式调优的少样本示例，可能会教会前沿模型在并不需要长推理链的请求上模仿冗长的推理过程。

相互矛盾的规则。前沿模型更擅长遵循指令。相互矛盾的指令（例如"始终在政策范围内退款"与"未经上报绝不退款"）可能会被前沿模型更字面化地执行，从而导致性能下降。

过时的配置。为旧版 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 上，验证仪式（"verify twice"）会在每次退款时重复进行订单查询，从而浪费不必要的 token。强调型增强词（"be maximally thorough"）则变成了数十次多余的知识库搜索。

运行 /claude-api prompt-audit 移除了这些反模式，平均成本降低了 14.6%，准确率提升了 5.3%。成本下降是因为多余的 tool 调用和重复推理被消除了。准确率提升有三个原因。已停用的 thinking 设置导致 API 直接拒绝所有路由请求。相互矛盾的退款规则使 Opus 5 在要求客户确认的同时，扣下了四笔本应退还的款项。此外，手动草稿纸与 Opus 5 的内置思考发生冲突：在三个工单中，模型把 tool 调用写进了推理过程，却从未真正执行。

Effort

Effort 告诉 Claude“该用多大力气去工作”。在低 effort 下，Claude 通常能更快得出结论。在高 effort 下，Claude 会在回答前进行深思、验证并探索替代方案。

在同一个模型上，不同 effort 级别下的成本与性能之比可能有所不同。例如，Claude Fable 5 在低 effort 下，于 FrontierCode Diamond（最难的 50 个任务）上得分 11.5%，每个任务成本为 5.35 美元。在最高 effort 下，Fable 5 得分 30.9%，每个任务成本为 19.00 美元；调整 effort 使得分提升了约 2.7 倍（+19 个百分点），而成本约为原来的 3.5 倍（图 4）。

在 Claude Fable 5.1 上，Humanity's Last Exam（不使用工具）呈现出陡峭的曲线，最后一步的提升逐渐递减。低强度推理下，每题约 0.30 美元，得分约 53%；最高强度推理下，每题约 2.23 美元，得分约 61%；从低强度提升到最高强度的最后一步，仅增加约半个百分点的得分，却要多付出 46% 的成本。这一增益落在基准测试自身运行噪声范围内，因此你多付了钱却得不到可衡量的提升。

图 4. 在 FrontierCode Diamond 上，Fable 5 在不同推理强度下的性能与成本对比。

推理强度可能在两个方向上出现校准偏差：

假设越高一定越好。高强度推理可能导致过度思考。Claude 花在斟酌上的时间超过了任务本身所需，这会增加成本/延迟，还可能降低回答质量。只有在仍有证据可挖掘时，深入思考才有帮助。

偏向低强度推理。设置得过低时，Claude 在掌握足够证据之前就停了下来。它发起的工具调用更少，因此可能只依据第一条搜索结果作答，而不是第三条。它在困难步骤上思考得更少，也会跳过它通常会自行执行的检查。回答看起来是完整的，但建立在片面的信息之上。

如何修正

有一些实用的方法来校准推理强度：

以更低投入测试更强模型。低投入下的更强模型，可能比高投入下苦苦工作的较弱模型更便宜。例如，在 CursorBench 3.2 上，Claude Fable 5.1 在低投入下即可达到 Fable 5 在高投入下的性能，而成本仅为后者的三分之一（图 5）。新模型更便宜有两个原因：低投入下它每个任务做的工作更少，而且 Fable 5.1 的提示词缓存读取定价为每百万 token 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，并应用提示词审计来移除强制性的工具调用惯例、草稿步骤和相互矛盾的规则。这使它在 98.9% 的训练准确率上超越了 Opus 4.8 的基线，并将每次工单的成本降至 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 首先会找出你的 token 都花在了哪里：如果你有 Claude Admin API 密钥，就从你组织的用量与成本报告中查找；如果你的应用会记录日志，就从每个 API 响应的 usage 对象中查找；如果两者都不可行，就阅读你构建请求的代码并进行估算。

然后它会为可用的节省方案排序，从提示词缓存开始，接着是精简每个请求携带的内容（包括提示词审计）、限制输出长度，以及通过批处理处理无人值守的工作。如果你提供了评估集，它还会更进一步，计算不同投入程度和模型选择下的成本与性能。

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

LegalBench（成本降低约 58%）： cost-optimize 建议跨任务缓存共享前缀、设置低投入程度，并通过 Batch API 处理任务。思考 token 从 102,779 个降至 8,284 个，但通过率保持在噪声范围内，成本下降了约 58%。

tau2-bench retail（成本降低约 73%）：通过实施带有显式断点放置的提示词缓存，cost-optimize 在保持通过率不变的同时将支出降低了 73%。

OfficeQA Pro（成本降低约 52%）：cost-optimize 增加了批处理与文档缓存，使成本从 $136.20 降至 $64.87。

SWE-bench Verified（成本降低约 55%）： cost-optimize 发现默认配置本身已能正确缓存。成本节省来自将 effort 设为 medium，并限制智能体的输出仅为几句简洁的话。每个任务的中位步骤数从 29 步降至 17 步，提示词 token 从 7520 万降至 3370 万。

图 7. 使用 /claude-api cost-optimize 后各基准测试中成本与性能的变化。

快速上手

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

当你的应用程序使用 Claude API 且你希望进行成本审计时，可以使用 /claude-api cost-optimize。它会分析 token 支出，然后测试不同的手段：它会应用 prompt-audit，同时也会检查是否可以通过提示词缓存、对无人值守任务进行批处理或限制输出来降低成本。如果你提供了评估集，它还会衡量 effort 与模型选择之间的权衡。

最后，使用 /claude-api hillclimb 对成本与性能进行迭代搜索。在给定评估集的情况下，Claude 会将其拆分为训练集和测试集，然后提出针对你应用程序的更新建议，目标是在维持基线性能的同时降低成本。Claude 会阅读训练集中失败的案例来引导搜索，最终配置会在留出的测试集上进行评分。

了解更多：

查看我们的文档，请点击此处

查看我们的示例代码库，请点击此处

视频 · 前往原文观看