降低 Claude API 成本同时保持性能

# 通过 Claude 平台降低成本、提升性能

调整提示缓存、指令和推理力度，可在不牺牲应用性能的前提下降低 Claude 的使用成本。

性能与成本通常被视为一种权衡：花费越少，结果越差。但在实践中，我们发现许多使用 Claude 平台的应用可以通过三项改进在不牺牲性能的情况下削减成本：最大化提示缓存命中率、在升级到前沿 Claude 模型时从提示词中移除反模式，以及根据任务校准推理力度。我们已将这些指导方针整合到 claude-api 技能中。本文将展示搭载 claude-api 技能的 Claude Code 如何在维持或提升性能的同时，找到降低成本的方法。（https://github.com/anthropics/skills/tree/main/skills/claude-api）

## 提示缓存

在 Claude 生成响应之前，它首先会将你的提示词处理成一个内部工作状态。这一步骤称为预填充（prefill），是处理输入中开销最大的部分。提示缓存会保存该状态（即键值缓存，简称 KV 缓存）：当一个请求以相同的前缀开头时，Claude 会直接读取已保存的状态，而无需重新计算。缓存读取的计费仅为完整输入价格的一小部分。（https://platform.claude.com/docs/en/about-claude/pricing）

要确保有效使用提示缓存，需要注意几个实际问题。第一，提示缓存绑定到特定模型。第二，提示缓存读取必须在前缀上逐字节完全一致。最后，提示缓存具有有限的生存时间（TTL）。（https://platform.claude.com/docs/en/build-with-claude/prompt-caching#ttl-support）

考虑到这些要点，以下是几条实用建议：

- 谨慎在对话中途更改推理力度设置。这些设置会渲染到提示词中你内容的前面，因此它们是缓存前缀的一部分。只有在特定 Claude 模型（包括 Opus 5 和 Fable 5.1）中，才能在对话中途更新推理力度而不破坏缓存。（https://platform.claude.com/docs/en/build-with-claude/effort#changing-effort-mid-conversation）

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

- 避免工具定义发生重排序。使用 Claude 消息 API 时，提示词按固定顺序组装，工具定义渲染在最前面。对工具定义的任何更改都会破坏缓存。（https://platform.claude.com/docs/en/build-with-claude/prompt-caching#structuring-your-prompt）

- 分叉对话时需谨慎。只有当分支的前缀与父级完全逐字节一致、使用相同模型且采用相同推理力度时，子智能体和分支才能共享父级的缓存。

如何修复

我们积累了一些关于提示缓存管理的经验教训：（https://claude.com/blog/lessons-from-building-claude-code-prompt-caching-is-everything）

- 仔细监控你的提示缓存命中率。Claude Console 和缓存诊断 API 提供提示缓存诊断功能，包括缓存未命中的原因（图 1）以及两个请求发生分歧的确切位置。（https://platform.claude.com/docs/en/build-with-claude/cache-diagnostics）

- 延迟加载不常用的工具。预先声明所有工具，但将不常用的工具标记为 defer_loading：它们不会出现在缓存前缀中，仅在 Claude 通过工具搜索查找时才追加到对话中，从而保留缓存。（https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-use-with-prompt-caching#defer-loading-and-cache-preservation）

- 将系统提示更新作为消息应用。某些 Claude 模型允许你在对话中途以消息形式添加系统指令，而无需编辑系统提示，这样可以保留缓存。（https://platform.claude.com/docs/en/build-with-claude/mid-conversation-system-messages#when-to-use-a-mid-conversation-system-message）

- 合理布局请求，使稳定部分保持稳定。将静态内容（工具定义和系统提示）放在最前面，将不断增长的对话内容放在其后（图 2）。

- 在提示缓存即将失效时更改模型或努力程度。某些操作（如压缩）已经会重写大量缓存内容（即对话）。这正是切换模型或努力程度的好时机，因为无论如何你都要为缓存未命中付费。(https://platform.claude.com/docs/en/build-with-claude/compaction) (https://cognition.com/blog/devin-fusion)

- 随着对话增长移动缓存断点。在 Claude Platform 上，你可以设置自动缓存，将缓存断点应用于最后一个可缓存块。(https://platform.claude.com/docs/en/build-with-claude/prompt-caching#automatic-caching)

- 预热缓存。为降低延迟，可使用 `max_tokens: 0` 并设置明确的缓存断点发送请求，使用与实际流量相同的努力程度设置。这会处理提示并将其写入缓存，而不生成任何内容。如果在会话开始时运行此操作（例如，在用户输入时），第一个真实请求就能命中已预热的缓存。

- 不要超过提示缓存的 TTL。5 分钟的缓存 TTL 从请求开始时计算。如果一个智能体阻塞在工具调用或子智能体请求上，且运行时间超过 5 分钟，则父级缓存会在结果返回之前过期。在这种情况下，可以考虑为前缀设置 1 小时的 TTL。(https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligence)

## 说明

提示可能会积累用于修补模型缺陷的指令。随着最新 Claude 模型能力的变化，这些指令可能会逐渐过时。以下是一些常见的提示"反模式"，它们会束缚前沿 Claude 模型，并可能无意中增加成本：(https://x.com/trq212/status/2080710971228918066)

- **验证仪式。** "仔细检查你的工作"或"在回复前验证两次"等指令往往会被前沿模型字面理解，从而浪费 token。

- **彻底性与强调增强词。** "尽可能彻底"、"重要：你必须始终……"等表述在与前沿模型配合使用时，可能导致冗长输出和额外的工具调用。

- **强制性流程与草稿架构。** 固定步骤流程（例如"在草稿中一步步思考"）或推理模板是前沿模型不需要的仪式。这类脚手架可能叠加在原生推理之上，消耗不必要的 token。

- **过时的示例。** 针对旧模型失败模式调整的少样本示例，可能会引导前沿模型在不需要时模仿冗长的推理链。

- **相互矛盾的规则。** 前沿模型在遵循指令方面更为严格。相互矛盾的指令（"在政策范围内始终退款"与"未经上报不得退款"）可能被前沿模型更字面地执行，导致性能下降。

- **过时的配置。** 为旧版 Claude 编写的设置（例如手动思考预算）可能会被 Claude Platform 在使用新模型时拒绝。

**修复方法**

我们为 claude-api 技能更新了一条新命令，专门检测这些反模式。在 Claude Code 中，针对你的提示、技能或工具描述运行 `/claude-api prompt-audit`。该审计覆盖工作目录中的所有内容，包括调用 Claude API 的应用代码以及 Claude Code 自身的配置（例如 CLAUDE.md 或技能）。(http://claude.md/)

例如，我们测试了一次从 Opus 4.8 到 Opus 5 的模型迁移，基准为客户支持场景。我们从一个干净的提示开始，每次植入一个反模式（一个已弃用的思考设置、一对相互矛盾的退款规则、一个手动草稿、"验证两次"、"尽可能彻底"以及一个强制性六步流程），共产生六个遗留提示。

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

在 Opus 5 上，验证仪式（"double verify"）会在每次退款时重复查询订单，浪费了不必要的 token。强调增强词（"be maximally thorough"）则触发了数十次多余的知识库搜索。

运行 /claude-api prompt-audit 消除了这些反模式，平均降低了 14.6% 的成本，并将准确率提升了 5.3%。成本下降是因为消除了多余的工具调用和重复推理。准确率提升有三个原因：已弃用的 thinking 设置导致 API 完全拒绝所有路由请求；矛盾的退款规则让 Opus 5 在应当退款的四笔交易中暂停处理，转而要求客户确认；手动草稿区与 Opus 5 内置 thinking 机制产生冲突：在三张工单中，它将工具调用写入了推理过程，但从未实际执行。

## Effort

Effort 告诉 Claude "需要付出多大努力"。在低 effort 下，Claude 通常能更快得出结论。在高 effort 下，Claude 会在给出答案前进行深思熟虑、反复验证并探索多种方案。（https://platform.claude.com/docs/en/build-with-claude/effort）

单一模型在不同 effort 级别下的成本与性能之间存在权衡。例如，Claude Fable 5 在 FrontierCode Diamond（最难的 50 道题）上，低 effort 得分为 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（不使用工具）呈现出一条陡峭的曲线，最后一步收益递减。低 effort 下得分约为 53%，每题约 0.30 美元；最高 effort 下得分约为 61%，每题约 2.23 美元；最后一步升至最高 effort 仅增加约半个百分点，成本却增加约 46%。这一提升落在基准测试的运行间噪声范围内，因此付出更多成本却无可测量的收益。

Effort 可能在两个方向上出现偏差：

- 误以为越高越好。高 effort 可能导致过度思考。Claude 花费大量时间深思熟虑，超出任务实际所需，增加了成本和延迟，还可能降低答案质量。只有在仍有证据可挖掘时，深思熟虑才有帮助。

- 偏向低 effort。设置过低时，Claude 会在收集到足够证据之前就停止。它进行的工具调用更少，可能基于第一条搜索结果而非第三条来作答。它在困难步骤上思考不足，跳过了原本会自行执行的检查。答案看起来完整，实则建立在不完整的信息之上。

如何修正

以下是一些校准 effort 的实用方法：

- 在较低 effort 下测试更强的模型。低 effort 下的更强模型，可能比努力工作（高 effort）的较弱模型更经济。例如，在 CursorBench 3.2 上，低 effort 的 Claude Fable 5.1 能以三分之一的成本达到高 effort 的 Fable 5 的性能水平（图 5）。新模型更经济有两个原因：低 effort 下每项任务的工作量更少，且 Fable 5.1 的提示词缓存读取价格为每百万 token 0.25 美元，而 Fable 5 为 1.00 美元。即便按 Fable 5 的价格计算，低 effort 的 Fable 5.1 成本也会低约 40%。（https://www-cdn.anthropic.com/0339e6a7c5c7b87f5c07798616dc32c215d14235/Claude%20Fable%205.1%20&%20Claude%20Mythos%205.1%20System%20Card.pdf）

- 了解你的任务形态。在不同努力程度下衡量应用性能，是理解你特定任务的成本-性能权衡的有效方式。在未饱和的评估中，跨努力程度的平坦成本-性能曲线表明该任务不受思考算力的制约，增加努力程度并无裨益。(https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligence#tune-effort)

这种校准通常需要跨模型和努力程度运行评估。在 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`：它分析你的支出去向，应用降本措施，并在你提供评估的情况下，展示节省与性能之间的权衡关系。(https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligence#cut-spend-without-losing-quality)

`cost-optimize` 首先找出你的 token 流向：如果你拥有 Claude Admin API 密钥，则从你组织的使用量和成本报告中获取；如果你的应用记录了日志，则从每个 API 响应的使用量对象中获取；若以上两者均不可用，则通过读取你的请求构建代码来进行估算。(https://platform.claude.com/docs/en/manage-claude/usage-cost-api)

随后它对可用的节省方案进行排序，依次从提示词缓存、精简每次请求携带的内容（包括 prompt-audit）、限制输出范围，以及对无人值守的任务进行批处理开始。如果你提供评估，它还会进一步计算不同努力程度和模型选择下的成本与性能。我们以 Sonnet 5 为基准，在四个公开基准测试上运行了此功能（图 7）：(https://platform.claude.com/docs/en/build-with-claude/batch-processing)

- LegalBench（约降低 58% 成本）：`cost-optimize` 建议对跨任务的共享前缀进行缓存，设置低努力程度，并通过 Batch API 处理任务。思考 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` 发现默认配置已正确启用缓存。节省来自将努力程度设置为中等，并将智能体的输出限制为几句简洁的语句。每项任务的中位步骤数从 29 降至 17，提示词 token 数从 7520 万降至 3370 万。

## 开始使用

当你迁移到前沿 Claude 模型并希望检查现有提示词时，可以从 /claude-api prompt-audit 开始。它会扫描你工作目录中的提示词、技能和工具描述，适用于调用 Claude API 的应用代码或 Claude Code 的配置文件（CLAUDE.md、技能文件）。它会移除那些制约前沿模型发挥的常见反模式。

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

最后，使用 /claude-api hillclimb 对成本和性能进行搜索优化。给定一个评估集，Claude 会将其拆分为训练集和测试集，然后提出旨在降低成本同时保持基线性能的应用更新方案。Claude 读取失败的训练样本来引导搜索，最终配置在留出的测试集上进行评分。

了解更多：

- 查看我们的文档（https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligence#cut-spend-without-losing-quality）

- 查看我们的降本 Cookbook（https://platform.claude.com/cookbook/cost-optimization-cost-optimization#prompt-caching）

- 查看 claude-api 技能；该技能也已内置于 Claude Code（https://github.com/anthropics/skills/tree/main/skills/claude-api）

- 查看 Claude 博客上的相关文章（https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform）

作者：Lance Martin（@RLanceMartin）、Brad Abrams（@brada）、Isabella He（@IsabellaKHe）和 Ben Lehrburger（@benlehrburger）。