Anthropic 官方开发团队分享如何让 Claude API 降本不降质：缓存、提示词与 Effort 的三类优化策略
降本与性能并非只能二选一：先排除重复计算、无效指令和不匹配的思考投入，再决定是否更换模型。
阅读要点
- 缓存读取要求请求前缀按字节一致，并受模型绑定与 TTL 限制。
- 旧模型时代的核验仪式、强制步骤和矛盾规则，可能让前沿模型多做无用工作。
- Effort 应通过自己的评测逐档校准，更高并不必然更好。
- prompt-audit、cost-optimize 与 hillclimb 分别处理提示词、整体成本和配置搜索。
Anthropic 官方开发团队给出的核心判断是：Claude API 的降本，不必先从牺牲模型能力开始；先找出缓存重算、提示词遗留规则和 Effort 失配，往往更划算。
为什么账单变贵了，效果却没有同步变好？
很多团队看到 Claude API 账单上涨，第一反应是换更便宜的模型、缩短输入，或者让模型少思考。但这些做法都可能直接伤到结果质量，于是降本与性能看起来像一道单选题。
Anthropic 官方开发团队提醒：在做这道选择题之前，应该先排除另一种情况——系统正在为没有产生额外价值的工作付费。
你应该检查一次请求中的三个层面：
- 输入层：重复内容被重新 Prefill：检查缓存前缀、模型绑定和 TTL。
- 指令层：旧规则与新模型能力不再匹配：检查核验仪式、强制步骤、陈旧样例和冲突规则。
- 推理层：思考投入与任务难度不匹配：用自己的评测扫过多个 Effort 和模型组合；过高可能浪费，过低则可能损害表现。
后文的缓存优化、提示词清理和 Effort 校准正对应这三层。它们没有固定顺序：缓存命中异常就从输入层查，刚升级模型就先审提示词，已有评测集则直接比较模型与 Effort；需要系统降本时，再把缓存、批处理、输出长度和模型选择放进同一张账单里审计。
缓存开了，为什么还是在重复付费？
在大语言模型的交互中，生成回复之前必须经历一个“预填充（Prefill）”阶段。模型需要将你输入的所有文字、历史对话和工具定义转化成内部的工作状态，即键值缓存（KV Cache）。Prefill 是处理输入时成本较高的步骤。
提示词缓存（Prompt Caching）的核心逻辑非常朴素：如果当前请求的前半部分与之前某次请求的前缀完全一致，Claude 就可以直接把内存中保存的 KV 状态读取出来，而无需重新计算一遍。缓存读取的费用仅为完整输入价格的一小部分。
但接入缓存并不等于一定命中。要看清成本为何没有下降，先要理解三个约束。
先弄清缓存为什么会失效：三个硬约束
- 缓存绑定具体模型：同一份提示词缓存不能跨模型读取。
- 前缀按字节一致（Byte-exact）：缓存读取要求对应的请求前缀按字节一致；前缀发生变化，相关部分就可能无法命中。
- 有限的生命周期（TTL）：默认缓存生命周期只有 5 分钟（从请求开始计时）。如果一个智能体（Agent）中途执行复杂工具调用或等待子智能体返回超过 5 分钟，父级上下文的缓存就会超时失效。
再排查是谁破坏了前缀：四个常见来源
- 对话途中变更 Effort 设置：Effort 设置会被渲染在具体内容之前，属于缓存前缀的一部分。中途修改会改变前缀；目前只有包括 Opus 5、Fable 5.1 在内的部分模型支持对话中途更新 Effort而不破坏缓存。
- 在前缀中放入动态变量：系统提示词里的时间戳或请求 ID 每次变化，前缀也随之变化，可能导致缓存未命中。
- 工具定义发生变化：Claude Messages API 按固定顺序组装提示词，并把工具定义放在前面。工具顺序、描述或定义变化，会改变后续可复用的前缀。
- 子任务分支（Forking）未对齐环境：创建分支对话或调度 Subagent 时，只有在模型型号、Effort 强度、历史前缀字节完全一致的情况下，分支才能复用主进程的缓存。
最后修请求结构与运行时机：六种做法
针对上述问题，可以从请求结构和运行时机入手调整。