调整提示词缓存、指令和推理投入，可以在不牺牲应用性能的前提下降低 Claude 的使用成本。
- 分类智能体
- 产品Claude 平台
- 日期2026 年 9 月 8 日
- 阅读时间5分钟
- https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform
- 作者Lance Martin
性能和成本往往被视为一种权衡取舍：要想花得更少，就得接受更差的结果。但在实践中，我们发现许多使用 Claude Platform 的应用只需三项调整，就能在不牺牲性能的前提下降低成本：最大化提示词缓存命中率、在升级到前沿 Claude 模型时移除提示词中的反模式、以及根据任务校准推理投入。我们已将这些指导建议整合到 claude-api 技能中。在本文中，我们将展示 Claude Code 配合 claude-api 技能如何常常能找到在维持或提升性能的同时降低成本的方法。
提示词缓存
在 Claude 生成回复之前，它会先将你的提示词处理为一种内部工作状态。这一步称为预填充（prefill），是处理输入中成本最高的部分。提示词缓存会保存该状态（即键值缓存，或称 KV cache）：当请求以相同前缀开头时，Claude 会直接读回该状态，而不是重新计算。缓存读取的计费价格仅为完整输入价格的一小部分。
要确保提示词缓存的有效使用，有几个实际注意事项。首先，提示词缓存绑定在特定模型上。其次，提示词缓存的读取必须在提示词前缀上做到逐字节完全一致。最后，提示词缓存有有限的生存时间（TTL）。
考虑到这些要点，这里有一些实用建议：
- 在对话中途更改推理投入设置时要小心。这些设置会渲染到提示词中你内容的前面，因此它们属于被缓存前缀的一部分。只有在部分精选 Claude 模型（包括 Opus 5 和 Fable 5.1）上，你才能在不破坏缓存的情况下于对话中途更新推理投入设置。
- 将易变的值排除在提示词前缀之外。系统提示词中的动态时间戳或 ID 可能会在模型调用之间发生变化，从而破坏缓存。
- 避免使用会自行重新排序的工具定义。使用 Claude Messages API 时，提示词会按固定顺序组装，工具定义渲染在顶部。工具定义的任何更改都会破坏缓存。
- 分叉对话时要小心。只有当分叉的前缀字节完全相同、使用相同模型且采用相同 effort 设置时，子智能体和分支才会共享父级的缓存。
如何修复
我们积累了一些关于提示词缓存管理的经验教训：
- 仔细监控你的提示词缓存命中率。Claude Console 和缓存诊断 API 提供提示词缓存诊断信息，包括提示词缓存未命中的原因（图 1）以及两个请求在何处发生分歧。
仔细监控你的提示词缓存命中率。Claude Console 和缓存诊断 API 提供提示词缓存诊断信息，包括提示词缓存未命中的原因（图 1）以及两个请求在何处发生分歧。
仔细监控你的提示词缓存命中率。Claude Console 和缓存诊断 API 提供提示词缓存诊断信息，包括提示词缓存未命中的原因（图 1）以及两个请求具体在何处发生分叉。
- 延迟加载不常用的工具。预先声明所有工具，但将不常用的工具标记为 defer_loading：它们不会进入缓存前缀，只有在 Claude 通过工具搜索查找它们时才会被追加到对话中，从而保持缓存不被破坏。
- 以消息形式应用系统提示词更新。Claude Platform 允许你在对话中途以消息形式添加系统指令，而不是编辑系统提示词，这样可以保留缓存。
- 合理布局请求，让稳定部分保持稳定。先添加静态上下文（工具定义和系统提示词），再将不断增长的对话内容放在它们之后（图 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%。成本下降是因为多余的工具调用和重复推理被消除。准确率提升有三个原因。已停用的思考设置导致 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% 的成本。这一增益落在该基准测试多次运行之间的正常波动范围内，因此你多付了钱却得不到可衡量的收益。
思考强度可能在两个方向上出现校准偏差：
- 认为越高一定越好。高思考强度可能导致过度思考。Claude 花在斟酌上的时间超过了任务本身所需，这会增加成本和延迟，还可能降低答案质量。只有在仍有证据可挖掘时，深入思考才有帮助。
- 偏向低思考强度。设置得过低时，Claude 会在掌握足够证据之前就停下来。它发起的工具调用更少，因此可能只依据第一条搜索结果作答，而不是第三条。它在困难步骤上思考得更少，并跳过了它通常会自行运行的检查。答案看起来是完整的，但建立在部分信息之上。
如何修复
有一些实用的方法来校准投入程度（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%。
- 了解你的任务形态。在一系列投入程度上衡量应用性能，是理解特定任务成本-性能权衡的有效方法。在一个尚未饱和的评测中，如果不同投入程度下的成本-性能曲线较为平缓，则表明该任务不受思考算力限制；增加投入并不会带来收益。
这种校准通常涉及跨模型和投入程度运行评测。在 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）：
- 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 发现默认配置已经正确进行了缓存。节省主要来自将投入水平设置为中等，并将智能体的输出限制为仅几句简洁的句子。每个任务的中位步骤数从 29 降至 17，提示词 token 从 75.2M 降至 33.7M。
快速上手
当你已迁移到前沿 Claude 模型，并希望用其检查现有提示词时，可以从 /claude-api prompt-audit 开始。它会扫描你工作目录中的提示词、技能和工具描述。这些可以是调用 Claude API 的应用程序代码，也可以是 Claude Code 的配置（CLAUDE.md、skills）。它会移除那些会拖累前沿模型的常见反模式。
当你的应用程序使用 Claude API 并希望进行成本审计时，可以使用 /claude-api cost-optimize。它会分析 token 支出，然后测试不同的优化手段：它会应用 prompt-audit，同时也会检查是否可以通过提示词缓存、批量处理无人值守任务或限制输出来降低成本。如果你提供了评估集，它还会衡量工作量和模型选择之间的权衡。
最后，使用 /claude-api hillclimb 在成本与性能之间进行迭代搜索。给定一个评估集，Claude 会将其拆分为训练集和测试集，然后针对你的应用程序提出旨在降低成本同时维持基线性能的更新建议。Claude 会阅读训练集中失败的案例来引导搜索，最终配置会在留出的测试集上进行评分。
了解更多：
- 查看我们的文档，点击此处
- 查看我们的示例库，点击此处
用 Claude 变革你组织的运作方式
Tuning prompt caching, instructions, and effort can reduce Claude's cost without sacrificing application performance.
- Category
- Product
- DateSeptember 8, 2026
- Reading time5min
- https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform
- Author(s)Lance Martin
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
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:
- 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.
- 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.
- 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:
- 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.
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.
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 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.
- 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.
- 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.
- 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.
- 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.
- 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
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.
- 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
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).
Figure 3 | The effect of prompting anti-patterns during model migration from Opus 4.8 to 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.
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 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:
- 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.
- 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:
- 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.
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.
Automating cost reduction
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):
- 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 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% lower cost): cost-optimize added batch processing and document caching, which brought cost down from $136.20 to $64.87.
- 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
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: