Anthropic 发布 Claude Platform 降本指南：提示词缓存、清理反模式与校准 effort

Anthropic 官方博客介绍用三项手段降低 Claude Platform 成本而不牺牲性能：提高提示词缓存命中率、清除旧模型遗留的提示词反模式、按任务校准 effort。

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

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

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

考虑到以上几点，这里有一些实用建议：

我们积累了一些提示词缓存管理的经验：

提示词中可能会积累一些针对模型弱点打补丁的指令。这些指令可能会相对于最新 Claude 模型的能力产生偏移。以下是一些常见的提示词“反模式”，它们会阻碍前沿 Claude 模型的发挥，并可能无意中增加成本：

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

例如，我们在一个客户支持基准测试上测试了从 Opus 4.8 到 Opus 5 的模型迁移。我们从一份干净的提示词开始，每次植入一种反模式（一个已废弃的思考设置、一对相互矛盾的退款规则、一个手动草稿板、“verify twice”、“be maximally thorough”以及一个强制性的六步流程），从而得到六份遗留提示词。

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

在 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 告诉 Claude“该多努力地工作”。在低 effort 下，Claude 通常能更快得出结论。在高 effort 下，Claude 会在回答前进行深思、验证并探索替代方案。

同一模型在不同 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% 的成本。这一增益落在基准测试的逐次运行噪声范围内，因此你多付了钱却得不到可衡量的提升。

努力水平可能在两个方向上出现校准偏差：

有一些有用的方法来校准努力水平：

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

我们在一个客户支持基准测试上运行了它，从 Opus 4.8 的默认（高）努力水平开始。爬山算法首先尝试了低努力水平的 Opus 5，并应用提示词审计来移除强制性的工具调用惯例、草稿本步骤和相互矛盾的规则。这使 Opus 4.8 的基线在训练准确率上达到了 98.9%，并将每张工单的成本降至 2.6 美分。

随后它降级到低努力水平的 Sonnet 5，每张工单成本更低，仅为 1 美分，但准确率降至 88.9%。通过阅读失败的训练工单，Claude 在提示词中添加了路由规则和退款上限交叉引用，使 Sonnet 5 在相同成本下恢复到 98.9% 的准确率。

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

提示词缓存、指令和努力水平是降低成本的常见手段。我们的文档涵盖了更多内容。为了对使用 Claude API 的应用程序代码进行全面的成本审计，我们新增了 /claude-api cost-optimize 命令：它会分析你的支出流向，应用成本削减措施，并且如果你提供了评估，它还会展示节省成本与性能之间的权衡关系。

成本优化首先从定位你的 token 流向开始：如果你有 Claude Admin API 密钥，就从你组织的用量与成本报告入手；如果你的应用会记录日志，就从每个 API 响应中的 usage 对象入手；如果两者都不可行，就通过阅读你的请求构建代码并进行估算。

随后，它会按优先级排列可用的节省方案，从提示词缓存开始，再到精简每个请求携带的内容（包括一次提示词审计）、限制输出长度，以及将无人值守任务批量化。如果你提供了评测集，它还能更进一步，在不同投入级别和模型选择之间计算成本与性能表现。

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

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

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

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

Performance and cost are often viewed as a trade-off: to spend less, you accept worse results. In practice, we've found that many applications using Claude Platform can cut costs without giving up performance with three fixes: maximize the prompt cache hit rate, remove anti-patterns from your prompts when upgrading to frontier Claude models, and calibrate effort to the task. We've put this guidance into the claude-api skill. In this article, we show how Claude Code with the claude-api skill can often find ways to reduce cost while maintaining or improving performance.

Before Claude generates a response, it first processes your prompt into an internal working state. This step, called prefill, is the expensive part of handling input. Prompt caching saves that state (the key–value, or KV, cache): when a request starts with the same prefix, Claude reads it back instead of recomputing it. Cache reads are billed at a fraction of the full input price.

There are a few practical considerations to ensure effective use of the prompt cache. First, the prompt cache is pinned to a specific model. Second, prompt cache reads must be byte-exact across the prompt prefix. Finally, the prompt cache has a limited time-to-live (TTL).

With these points in mind, there are a few practical tips:

We’ve accumulated a few lessons for prompt cache management:

Prompts can accumulate instructions that patch model weaknesses. These instructions can drift relative to the capabilities of the latest Claude models. Here are common prompting “anti-patterns” that hobble frontier Claude models and can inadvertently increase costs:

We've updated the claude-api skill with a new command that watches out for these anti-patterns. In Claude Code, run /claude-api prompt-audit against your prompts, skills, or tool descriptions. The audit covers anything in your working directory, including application code that calls the Claude API and Claude Code's own configuration (e.g., CLAUDE.md or skills).

For example, we tested a model migration from Opus 4.8 to Opus 5 on a customer support benchmark. We started from a clean prompt and planted one anti-pattern at a time (a retired thinking setting, a pair of contradictory refund rules, a manual scratchpad, "verify twice", "be maximally thorough", and a mandatory six-step procedure), giving six legacy prompts.

We ran each on Opus 4.8, on Opus 5 with only the model ID changed, and on Opus 5 after running /claude-api prompt-audit once per prompt (Figure 3 shows the average across the six).

With Opus 5, verification rituals ("verify twice") use unnecessary tokens by duplicating order lookup on every refund. Emphasis boosters ("be maximally thorough") became dozens of unneeded knowledge-base searches.

Running /claude-api prompt-audit removed the anti-patterns, decreasing costs by 14.6% and increasing accuracy by 5.3% on average. Cost dropped because extra tool calls and duplicated reasoning were eliminated. Accuracy rose for three reasons. The retired thinking setting made the API reject every routing request outright. The contradictory refund rules led Opus 5 to withhold four refunds it owed while it asked the customer to confirm. And the manual scratchpad collided with Opus 5's built-in thinking: on three tickets it wrote the tool call inside its reasoning and never executed it.

Effort tells Claude “how hard to work.” At low effort Claude generally reaches conclusions faster. At high effort, Claude deliberates, verifies, and explores alternatives before answering.

Cost-versus-performance across effort levels on a single model can vary. For example, Claude Fable 5 scores 11.5% at low effort for $5.35 per task on FrontierCode Diamond (the hardest 50 tasks). At max effort, Fable 5 gets 30.9% for $19.00 per task; changing effort raises the score about 2.7x (+19 points) for about 3.5x the cost (Figure 4).

On Claude Fable 5.1, Humanity's Last Exam (without tools) shows a steep curve with a diminishing last step. It scores about 53% at low effort for about $0.30 per question and about 61% at max effort for about $2.23; the last step up to max adds about half a point for 46% more cost. The gain falls inside the benchmark's run-to-run noise, so you pay more for no measurable gain.

Effort can be miscalibrated in either direction:

There are some useful ways to calibrate effort:

This calibration often involves running an evaluation across models and effort levels. In Claude Code, /claude-api hillclimb performs this search for you: it splits your evaluation into train and test sets, proposes configuration changes, and reads failing train examples to fix what it finds.

We ran it on a customer support benchmark, starting from Opus 4.8 at its default (high) effort. The hillclimber first tried Opus 5 at low effort, applying prompt-audit to remove mandatory tool-call rituals, scratchpad steps, and contradictory rules. That cleared the Opus 4.8 baseline at 98.9% train accuracy and cut cost to 2.6 cents per ticket.

It then stepped down to Sonnet 5 at low effort, which was cheaper still at 1 cent per ticket, but accuracy fell to 88.9%. Reading the failing train tickets, Claude added routing rules and a refund-cap cross-reference to the prompt, bringing Sonnet 5 back to 98.9% at the same cost.

On the 14 held-out tickets the search never saw, the final configuration scored 90.5% against the original setup's 78.6%, at about one fifth the cost.

Prompt caching, instructions, and effort are common levers for reducing cost. Our documentation covers even more. To run a holistic cost audit of application code that uses the Claude API, we've added /claude-api cost-optimize: it profiles where your spend goes, applies cost reductions, and, if you provide an evaluation, shows how savings trade off with performance.

cost-optimize starts by finding where your tokens go: from your organization's usage and cost reports if you have a Claude Admin API key, from the usage object on each API response if your application logs it, or, failing both, by reading your request-building code and estimating.

It then ranks the available savings, starting with prompt caching, trimming what each request carries (including a prompt-audit), bounding output, and batching unattended work. If you supply an evaluation, it goes further and computes cost and performance across effort levels and model choices.

We ran this on four public benchmarks, starting with Sonnet 5 as a baseline (Figure 7):

Start with /claude-api prompt-audit when you've migrated to a frontier Claude model and want to check your existing prompts against it. It scans the prompts, skills, and tool descriptions in your working directory. This can be application code that calls the Claude API or Claude Code's configuration (CLAUDE.md, skills). It removes common anti-patterns that hobble frontier models.

Reach for /claude-api cost-optimize when your application uses the Claude API and you want a cost audit. It profiles token spend and then tests different levers: it applies prompt-audit, but also checks for ways to lower cost via prompt caching, batching unattended work, or bounding output. If you provide an evaluation, it measures the effort and model selection trade-offs.

Finally, use /claude-api hillclimb for an iterative search over cost and performance. Given an evaluation, Claude splits it into train and test sets, then proposes updates to your application that aim to reduce cost while maintaining baseline performance. Claude reads the failing train cases to guide the search, and the final configuration is scored on the held-out test set.

To learn more:

来源：Claude：Blog（网页）· claude.com