调整提示缓存、指令和投入程度，可以在不牺牲应用性能的情况下降低 Claude 的成本。
性能和成本通常被视为一种权衡：为了花更少的钱，你接受更差的结果。实际上，我们发现许多使用 Claude Platform 的应用可以通过三项调整来削减成本而不牺牲性能：最大化提示缓存命中率、在升级到前沿 Claude 模型时移除提示中的反模式、以及根据任务校准投入程度。我们已将这些指导整合到 claude-api 技能 中。在本文中，我们将展示 Claude Code 结合 claude-api 技能如何经常找到降低成本同时保持或提升性能的方法。
提示缓存
在 Claude 生成响应之前，它首先将你的提示处理成内部工作状态。这一步称为 预填充，是处理输入中成本较高的部分。提示缓存会保存该状态（即键值对或 KV 缓存）：当请求以相同前缀开始时，Claude 会读取它而不是重新计算。缓存读取的计费价格仅为完整输入价格的一小部分。
为了确保有效使用提示缓存，有几个实际考虑因素。首先，提示缓存绑定到特定模型。其次，提示缓存读取必须在整个前缀上实现 字节精确。最后，提示缓存有一个有限的生存时间（TTL）。
考虑到这些要点，这里有一些实用技巧：
- 在对话中途更改投入程度设置时要小心。这些设置会在你的内容之前渲染到提示中，因此它们是缓存前缀的一部分。只有特定的 Claude 模型（包括 Opus 5 和 Fable 5.1）允许你在不破坏缓存的情况下在对话中途更新投入程度。
- 将易变的值排除在前缀之外。系统提示中的动态时间戳或 ID 可能会在模型调用之间发生变化，从而破坏缓存。
- 避免使用会自行重新排序的工具定义。使用 Claude messages API 时，提示会按照固定顺序组装，工具定义渲染在顶部。对工具定义的任何更改都会破坏缓存。
- 分叉对话时要小心。子 Agent 和分支只有在分叉的前缀字节相同、使用相同模型且投入程度相同时，才会共享父级的缓存。
如何修复
我们积累了一些关于提示缓存管理的经验：
- 仔细监控你的提示缓存命中率。Claude Console 和缓存诊断 API 提供提示缓存诊断信息，包括缓存未命中的原因（图 1）以及两个请求在何处出现差异。
- 延迟加载不常用的工具。预先声明所有工具，但将不常用的工具标记为 defer_loading：它们会保留在缓存前缀之外，仅在 Claude 通过工具搜索查找时才追加到对话中，从而保留缓存。
- 将系统提示更新作为消息应用。某些 Claude 模型允许你在对话中途将系统指令作为消息添加，而不是编辑系统提示，这样可以保留缓存。
- 安排请求，使稳定部分保持稳定。首先添加静态上下文（工具定义和系统提示），然后将不断增长的对话放在它们后面（图 2）。
- 在提示缓存即将被破坏时更改模型或投入程度。某些操作，如压缩，已经重写了大部分缓存（对话）。这是切换模型或投入程度的好时机，因为你无论如何都要为缓存未命中付费。
- 随着对话增长移动缓存断点。使用 Claude Platform，你可以设置自动缓存，将缓存断点应用于最后一个可缓存块。
- 预热缓存。为了减少延迟，发送一个带有 max_tokens: 0 和显式缓存断点的请求，使用与实际流量相同的投入程度设置。这会处理提示并将其写入缓存，而不生成任何内容。如果你在会话开始时运行它（例如，当用户正在输入时），第一个真实请求将命中一个已预热的缓存。
- 不要超过提示缓存 TTL。5 分钟的缓存 TTL 从请求开始计时。如果 Agent 在工具调用或子 Agent 请求上阻塞超过 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 显示了六个提示的平均值）。
使用 Opus 5 时，验证仪式（“验证两次”）通过在每个退款请求上重复订单查找来使用不必要的 token。强调增强器（“做到最大限度的详尽”）变成了数十次不必要的知识库搜索。
运行 /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 在获得足够证据之前就停止了。它进行的工具调用更少，因此可能根据第一个搜索结果而不是第三个来回答。它在困难步骤上思考更少，并跳过了它通常会对自己运行的检查。答案看起来完成了，但它是基于部分信息构建的。
如何修复
有一些有用的方法来校准投入程度：
- 在较低投入程度下测试更强的模型。一个更强的模型在低投入程度下可能比一个较弱的模型在高投入程度下工作更便宜。例如，在 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 及其默认（高）投入程度开始。hillclimber 首先尝试了 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：它会分析你的支出去向，应用成本降低措施，并且如果你提供评估，它会展示节省与性能之间的权衡。
cost-optimize 首先找出你的 token 去向：如果你有 Claude Admin API 密钥，则来自你组织的使用和成本报告；如果你的应用记录了它，则来自每个 API 响应中的 usage 对象；如果两者都不可用，则通过读取你的请求构建代码并进行估算。
然后它对可用的节省措施进行排序，从提示缓存开始，修剪每个请求携带的内容（包括 prompt-audit），限制输出，以及批处理无人值守的工作。如果你提供评估，它会进一步计算跨投入程度和模型选择的成本与性能。我们在四个公开基准测试上以 Sonnet 5 为基线运行了此功能（图 7）：
- 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 发现默认配置已经正确缓存。节省来自将投入程度设置为中等，并将 Agent 的输出限制为几个简洁的句子。每个任务的中位步骤从 29 步减少到 17 步，提示 token 从 75.2M 下降到 33.7M。
开始使用
当你迁移到前沿 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 读取失败的训练案例来指导搜索，最终配置在保留的测试集上进行评分。
了解更多：
作者：Lance Martin (@RLanceMartin)，Brad Abrams (@brada)，Isabella He (@IsabellaKHe)，以及 Ben Lehrburger (@benlehrburger)。
