利用 Claude 平台降低成本并提升性能 | Claude by Anthropic

性能和成本通常被视为一对权衡：要减少支出，就得接受更差的结果。但在实践中，我们发现，使用 Claude Platform 的许多应用可以通过三项改进，在不牺牲性能的情况下降低成本：最大化提示缓存命中率、升级到前沿 Claude 模型时移除提示中的反模式，以及根据任务调整投入程度。我们已将这些指导纳入 claude-api skill。在本文中，我们将展示 Claude Code 配合 claude-api skill，通常如何在保持或提升性能的同时找到降低成本的方法。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.

提示词缓存Prompt cache

在 Claude 生成响应之前，它会先将你的提示处理成一个内部工作状态。这个步骤称为预填充（prefill），是处理输入时成本最高的部分。提示缓存会保存该状态（键值缓存，即 KV 缓存）：当请求以相同的前缀开头时，Claude 会直接读取该状态，而不是重新计算。缓存读取的计费仅为完整输入价格的一小部分。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.

要确保有效使用提示缓存，需要注意几个实际问题。首先，提示缓存与特定模型绑定。其次，提示缓存读取时，提示前缀必须逐字节完全一致。最后，提示缓存的生存时间（TTL）有限。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:

• 请谨慎在对话过程中途更改 effort 设置。这些设置会渲染到你的内容之前的提示中，因此属于缓存前缀的一部分。只有部分 Claude 模型（包括 Opus 5 和 Fable 5.1）支持在不中断缓存的情况下于对话过程中途更新 effort。
  Be careful changing effort setting mid-conversation. These settings render into the prompt ahead of your content, so they are part of the cached prefix. Only with select Claude models, including Opus 5 and Fable 5.1, can you update effort mid-conversation without breaking the cache.

• 将易变值排除在前缀之外。系统提示中的动态时间戳或 ID 可能会在模型调用之间发生变化，从而破坏缓存。
  Keep volatile values out of the prefix. A dynamic timestamp or ID in the system prompt can change across model calls, and break the cache. 

• 避免使用会自行重新排序的工具定义。使用 Claude Messages API 时，提示词会按固定顺序组装，并将工具定义渲染在顶部。对工具定义的任何更改都会破坏缓存。
  Avoid tool definitions that reorder themselves. When using the Claude Messages API, the prompt is assembled in a fixed order with tool definitions rendered at the top. Any change to the tool definition will break the cache. 

• 创建对话分支时请务必小心。只有当分支的前缀逐字节完全一致、使用相同的模型并采用相同的推理力度时，子代理和分支才会共享父级的缓存。
  Be careful when forking conversations. Subagents and branches only share the parent’s cache when the fork’s prefix is byte-identical, on the same model, and using the same effort. 

如何修复它How to fix it

我们总结出了几条有关提示词缓存管理的经验：We’ve accumulated a few lessons for prompt cache management: 

• 请仔细监控您的提示缓存命中率。Claude Console 和缓存诊断 API 提供提示缓存诊断信息，包括提示缓存未命中的原因（图 1），以及两个请求具体在哪一处出现了差异。
  Monitor your prompt cache hit rate carefully. Claude Console and the cache diagnostics API provide prompt cache diagnostics, including reasons for prompt cache misses (Figure 1) and exactly where two requests diverged.

请仔细监控提示词缓存命中率。Claude Console 和缓存诊断 API 提供提示词缓存诊断信息，包括提示词缓存未命中的原因（图 1），以及两个请求具体从何处开始出现差异。Monitor your prompt cache hit rate carefully. Claude Console and the cache diagnostics API provide prompt cache diagnostics, including reasons for prompt cache misses (Figure 1) and exactly where two requests diverged.

请仔细监控提示缓存命中率。Claude Console 和缓存诊断 API 提供提示缓存诊断信息，包括提示缓存未命中的原因（图 1），以及两个请求具体从何处开始出现差异。Monitor your prompt cache hit rate carefully. Claude Console and the cache diagnostics API provide prompt cache diagnostics, including reasons for prompt cache misses (Figure 1) and exactly where two requests diverged.

• 延迟加载不常使用的工具。预先声明所有工具，但将不常使用的工具标记为 defer_loading：它们会留在缓存前缀之外，只有当 Claude 通过工具搜索查找它们时，才会被追加到对话中，从而保留缓存。
  Defer rarely used tools. Declare all your tools up front but mark the rarely used ones defer_loading: they stay out of the cached prefix and are appended into the conversation only when Claude looks them up with tool search, so the cache is preserved.

• 将系统提示更新作为消息应用。Claude Platform 允许你在对话中途将系统指令作为消息添加，而无需编辑系统提示，从而保留缓存。
  Apply system prompt updates as messages. Claude Platform lets you add a system instruction as a message mid-conversation instead of editing the system prompt, which preserves the cache.

• 组织请求，使稳定部分保持不变。先添加静态上下文（工具定义和系统提示），再将不断增长的对话内容置于其后（图 2）。
  Lay out the request out so the stable part stays stable. Add static context (tool definitions and the system prompt) first and the growing conversation behind them (Figure 2).

• 当提示缓存本来就会失效时，再更改模型或推理力度。某些操作（例如压缩）本身就会重写缓存中的大部分内容（即对话）。这是切换模型或推理力度的好时机，因为无论如何你都要为缓存未命中付费。
  Make changes to model or effort when the prompt cache will already be broken. Certain operations, like compaction, already rewrite much of the cache (the conversation). That is a good moment to switch model or effort, since you are paying for a miss anyway.

• 随着对话不断增长，移动缓存断点。使用 Claude Platform，您可以设置自动缓存，将缓存断点应用于最后一个可缓存块。
  Move the cache breakpoint as the conversation grows. With Claude Platform, you can set automatic caching to apply the cache breakpoint to the last cacheable block. 

• 预热缓存。为降低延迟，发送一个设置 max_tokens: 0 并显式指定缓存断点的请求。这样会处理提示词并将其写入缓存，而不会生成任何内容。如果在会话开始时运行此请求（例如用户正在输入时），第一个实际请求就能命中已预热的缓存。
  Pre-warm the cache. To reduce latency, send a request with max_tokens: 0 and an explicit cache breakpoint. This processes the prompt and writes it to the cache without generating anything. If you run it at session start (for example, while a user is typing), the first real request hits a warm cache.

• 不要超过提示缓存的 TTL。5 分钟的缓存 TTL 从请求开始时计算。如果代理因工具调用或子代理请求而阻塞，且这些调用或请求的运行时间超过 5 分钟，那么父级缓存会在结果返回之前过期。在这类情况下，可以考虑将前缀的 TTL 设置为 1 小时。
  Don’t exceed the prompt cache TTL. The 5-minute cache TTL counts from the start of the request. If an agent blocks on tool calls or subagent requests that run longer than 5 minutes, the parent's cache expires before the result comes back. In cases like this, consider setting a 1-hour TTL on the prefix instead.

说明Instructions

提示词可能会不断积累用于弥补模型弱点的指令。这些指令可能会相对于最新 Claude 模型的能力发生偏移。以下是一些常见的提示词“反模式”，它们会限制前沿 Claude 模型的性能，并可能无意中增加成本：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:

• 验证仪式。诸如“仔细检查你的工作”或“回复前验证两次”之类的指示，前沿模型往往会按字面理解，从而浪费令牌。
  Verification rituals. Instructions like "double-check your work” or "verify twice before responding” are often taken literally by frontier models and can waste tokens.

• 详尽程度和强调增强语。对前沿模型进行操作时，“务必做到最大程度的详尽”，“重要：你必须始终……”等表述可能会导致内容冗长并增加工具调用次数。
  Thoroughness and emphasis boosters. "Be maximally thorough," "CRITICAL: YOU MUST ALWAYS…" can lead to verbosity and extra tool calls when working with frontier models.

• 强制性流程和草稿纸框架。固定的步骤流程（例如“在草稿纸中逐步思考”）或推理模板都是前沿模型不需要的仪式。这类框架可能叠加在原生推理之上，并消耗不必要的令牌。
  Mandatory procedures and scratchpad scaffolds. Fixed step processes (e.g., "think step by step in a scratchpad") or reasoning templates are rituals that frontier models don't need. This scaffolding can stack on top of native reasoning and use unnecessary tokens.

• 过时的示例。针对旧模型失败模式调优的少样本示例，可能会让前沿模型在不需要冗长推理链的请求上，学会模仿这种推理方式。
  Stale examples. Few-shot examples tuned to an older model's failure modes can teach a frontier model to imitate long reasoning chains on requests that don't need them.

• 相互矛盾的规则。前沿模型在遵循指令方面表现更佳。相互矛盾的指令（“始终在政策范围内退款”与“未经升级处理绝不退款”）可能会被前沿模型更字面地遵循，从而导致性能下降。
  Contradictory rules. Frontier models are better at instruction following. Contradictory instructions ("always refund within policy" vs. "never issue refunds without escalation") can be followed more literally by frontier models, resulting in degraded performance.  

• 过时的配置。为较早版本的 Claude 编写的设置（例如手动思考预算）在升级到前沿模型时可能会被 Claude Platform 拒绝。
  Dated configuration. Settings written for an older Claude generation (e.g., manual thinking budgets) can be rejected by Claude Platform when upgrading to frontier models.

如何修复它How to fix it 

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

例如，我们在一项客户支持基准测试中，测试了从 Opus 4.8 迁移到 Opus 5 的模型迁移。我们从一个干净的提示开始，每次植入一个反模式（已弃用的思考设置、一对相互矛盾的退款规则、手动草稿区、“验证两次”、“做到极致的全面”，以及强制性的六步流程），由此得到六个旧版提示。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. 

我们分别在 Opus 4.8 上运行了每个提示词，在仅更改模型 ID 的情况下于 Opus 5 上运行了每个提示词，并在每个提示词上运行一次 /claude-api prompt-audit 后于 Opus 5 上运行了每个提示词（图 3 展示了六个提示词的平均值）。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).

图 3｜从 Opus 4.8 迁移到 Opus 5 期间，提示反模式的影响。Figure 3 | The effect of prompting anti-patterns during model migration from Opus 4.8 to Opus 5.

使用 Opus 5 时，验证仪式（“验证两次”）会在每次退款时重复查询订单，从而浪费不必要的令牌。强调性指令（“务必做到最全面”）则变成了数十次不必要的知识库搜索。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. 

运行 /claude-api prompt-audit 移除了这些反模式，使成本平均降低了 14.6%，准确率提高了 5.3%。成本下降是因为消除了额外的工具调用和重复推理。准确率提升有三个原因。已弃用的 thinking 设置导致 API 直接拒绝每个路由请求。相互矛盾的退款规则导致 Opus 5 在要求客户确认的同时，拒绝了应当发放的四笔退款。此外，手动 scratchpad 与 Opus 5 内置的 thinking 发生冲突：在三个工单中，它将工具调用写进了推理过程，却从未执行该调用。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

Effort 告诉 Claude“要付出多大努力”。在较低的 effort 下，Claude 通常能更快得出结论。在较高的 effort 下，Claude 会在回答前进行思考、验证并探索各种替代方案。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. 

单个模型在不同努力程度下的成本与性能可能有所不同。例如，在 FrontierCode Diamond（难度最高的 50 个任务）上，Claude Fable 5 在低努力程度下的得分为 11.5%，每项任务的成本为 5.35 美元。在最高努力程度下，Fable 5 的得分达到 30.9%，每项任务的成本为 19.00 美元；调整努力程度后，得分提升约 2.7 倍（增加 19 个百分点），成本则约为原来的 3.5 倍（图 4）。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). 

在 Claude Fable 5.1 上，Humanity's Last Exam（不使用工具）呈现出一条陡峭的曲线，但最后一步的收益递减。低推理力度下得分约为 53%，每道题成本约 0.30 美元；最大推理力度下得分约为 61%，每道题成本约 2.23 美元；最后提升至最大力度仅增加约半个百分点，却带来 46% 的额外成本。这一增益落在该基准测试多次运行的噪声范围内，因此你付出了更多成本，却没有获得可测量的提升。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:

• 假设越高越好。付出过多努力可能导致过度思考。Claude 花费的思考时间超过了任务所需的程度，这会增加成本和延迟，并可能降低回答质量。只有在仍有证据可供寻找时，思考才会有所帮助。
  Assuming higher is always better. High effort can cause over-thinking. Claude spends more time deliberating than the task warrants, which adds cost and latency and can degrade answer quality. Deliberation only helps while there's still evidence to find. 

• 倾向于减少工作量。如果设置得过低，Claude 会在获得足够证据之前停止。它会减少工具调用次数，因此可能会根据第一个搜索结果作答，而不是查看第三个结果。面对困难步骤时，它思考得更少，并跳过通常会自行执行的检查。答案看起来已经完成，但实际上是建立在不完整的信息之上的。
  Biasing to low effort. Set too low, Claude stops before it has enough evidence. It makes fewer tool calls, so it may answer from the first search result instead of the third. It thinks less on hard steps and skips the check it would normally run on its own. The answer looks finished, but it's built on partial information. 

如何修复它How to fix it 

有一些有用的方法可以校准投入程度：There are some useful ways to calibrate effort: 

• 以更低的工作量测试更强的模型。低工作量下的强模型，成本可能低于高工作量（高工作量）运行的弱模型。例如，在 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%。
  Test stronger models at lower effort. A stronger model at low effort can be cheaper than a weaker model working hard (high effort). For example, on CursorBench 3.2, Claude Fable 5.1 at low effort matches the performance of Fable 5 at high effort at a third of the cost (Figure 5). Two things make the newer model cheaper: at low effort it does less work per task, and Fable 5.1's prompt-cache reads are priced at $0.25 per million tokens versus $1.00 for Fable 5. Even at Fable 5's prices, Fable 5.1 at low effort would cost about 40% less.

• 理解任务形态。在一系列努力程度下测量应用性能，是了解特定任务成本与性能权衡的有用方法。在未达到饱和的评估中，如果不同努力程度下的成本性能曲线较为平坦，则表明该任务并不受思考计算量的限制；增加努力程度并不会带来收益。
  Understand your task shape. Measuring application performance across a sweep of effort levels is a useful way to understand the cost-performance tradeoff for your particular task. On a non-saturated evaluation, a flat cost-performance curve across effort levels suggests that the task is not bound by thinking compute; increasing effort is not beneficial.

这种校准通常涉及在不同模型和工作量级别上运行评估。在 Claude Code 中，/claude-api hillclimb 会为你执行这一搜索：它将评估拆分为训练集和测试集，提出配置更改建议，并读取失败的训练示例以修复发现的问题。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.

我们在一个客户支持基准测试上运行了该方法，起点是默认（高）投入级别的 Opus 4.8。hillclimber 首先以低投入级别尝试了 Opus 5，并应用 prompt-audit 移除强制性的工具调用流程、草稿步骤和相互矛盾的规则。这使其以 98.9% 的训练准确率超过了 Opus 4.8 基线，并将每个工单的成本降至 2.6 美分。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.

随后，它在低工作量模式下切换到 Sonnet 5，成本进一步降至每张工单 1 美分，但准确率也降到了 88.9%。通过阅读处理失败的火车票工单，Claude 在提示词中加入了路由规则和退款上限交叉引用，使 Sonnet 5 在成本不变的情况下恢复到 98.9% 的准确率。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.

在搜索从未见过的 14 个留出工单上，最终配置的得分为 90.5%，而原始设置为 78.6%，成本约为其五分之一。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.

自动化降低成本Automating cost reduction

提示缓存、指令和工作量是降低成本的常用手段。我们的文档还介绍了更多方法。为了对使用 Claude API 的应用代码进行全面的成本审计，我们新增了 /claude-api cost-optimize：它会分析您的支出流向，应用成本削减措施；如果您提供评估结果，还会展示节省的成本与性能之间的权衡。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 首先要确定你的 token 用在了哪里：如果你拥有 Claude Admin API 密钥，可以查看组织的使用情况和成本报告；如果应用记录了每次 API 响应中的 usage 对象，也可以从中获取；如果两者都无法做到，则需要阅读构建请求的代码并进行估算。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. 

我们在四个公开基准测试上运行了该方法，并以 Sonnet 5 作为基线（图 7）：We ran this on four public benchmarks, starting with Sonnet 5 as a baseline (Figure 7):

• LegalBench（成本降低约 58%）：成本优化方案是建议在各任务之间缓存共享前缀、设置较低的工作量，并通过 Batch API 处理任务。思考令牌数从 102,779 降至 8,284，但通过率仍处于噪声范围内，成本下降了约 58%。
  LegalBench (~58% lower cost):  cost-optimize proposed caching a shared prefix across tasks, setting low effort, and processing tasks via the Batch API. Thinking tokens fell from 102,779 to 8,284, but pass rate stayed within noise and cost dropped by ~58%.

• tau2-bench 零售场景（成本降低约 73%）：通过实施带有显式断点设置的提示缓存，cost-optimize 在保持通过率不变的同时，将支出降低了 73%。
  tau2-bench retail (~73% lower cost): By implementing prompt caching with explicit breakpoint placement, cost-optimize reduced spend by 73% while keeping pass rate flat.

• OfficeQA Pro（成本降低约 52%）：通过成本优化新增了批处理和文档缓存功能，使成本从 136.20 美元降至 64.87 美元。
  OfficeQA Pro (~52% lower cost): cost-optimize added batch processing and document caching, which brought cost down from $136.20 to $64.87. 

• SWE-bench Verified（成本降低约 55%）：cost-optimize 发现默认配置已经能够正确缓存。节省成本的原因在于将 effort 设置为 medium，并将代理的输出限制为仅几句简洁的句子。每项任务的步骤数中位数从 29 步降至 17 步，提示词 token 数从 7520 万降至 3370 万。
  SWE-bench Verified (~55% lower cost): cost-optimize  found that the default config already caches correctly. Savings came from setting effort to medium and constraining the agent’s output to just a few concise sentences. Median steps per task went from 29 to 17 and prompt tokens fell from 75.2M to 33.7M. 

‍‍

入门Getting started

迁移到前沿 Claude 模型后，如果想检查现有提示词与该模型的适配情况，请从 /claude-api prompt-audit 开始。它会扫描工作目录中的提示词、技能和工具描述。这些内容可以是调用 Claude API 的应用程序代码，也可以是 Claude Code 的配置（CLAUDE.md、技能）。它会移除那些限制前沿模型性能的常见反模式。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.

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

最后，使用 /claude-api hillclimb 在成本与性能之间进行迭代搜索。给定一项评估后，Claude 会将其拆分为训练集和测试集，然后提出旨在降低成本并保持基准性能的应用更新方案。Claude 会读取训练集中失败的案例来指导搜索，最终配置则会在留出的测试集上进行评分。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: 

• 请参阅我们的文档，此处
  See our documentation, here
• 请参阅我们的食谱集。
  See our cookbook, here

‍‍