Claude API 提示缓存（Prompt Caching）实战

摘要当你的 Claude API 请求里塞进了一份长文档、一大段系统提示或几十个 few-shot 示例每次调用都在为同样的内容重复付费。提示缓存prompt caching就是为解决这个痛点而生把固定不变的前缀缓存起来命中后这部分输入的费用大幅下降。本文用实战视角讲清 Claude API 提示缓存的原理、代码写法、命中条件与省钱效果并说明如何通过 jiekou.vip 在国内稳定使用这一能力。一、为什么长上下文这么贵Claude API 按输入和输出 token 计费。长上下文场景客服知识库问答、代码库分析、合同审阅的特点是每次请求都带着同一大坨固定内容只有末尾的用户问题在变。假设系统提示 文档共 5 万 token用户每次只问几十字那 99% 的输入费用都花在了重复的前缀上。这正是提示缓存能大幅优化的地方。二、提示缓存的原理提示缓存的思路很朴素把请求里固定不变的前缀标记为可缓存。第一次调用时Anthropic 接口会把这段前缀写入缓存这次会有一点写入开销之后一段时间内的请求只要前缀完全一致就直接命中缓存这部分输入按远低于原价的费率计费。关键点在于前缀和完全一致缓存是从头开始按块匹配的所以你要把不变的内容system 提示、文档、示例放在前面把每次都变的用户输入放在最后。任何靠前位置的改动都会让后面的缓存失效。三、代码实战Python 写法用官方 anthropic SDK在需要缓存的内容块上加cache_control标记即可。以缓存一份长文档为例from anthropic import Anthropic client Anthropic( api_key你的_jiekou_KEY, base_url平台文档给出的 base_url, ) long_document ……这里是一份很长的产品手册全文…… resp client.messages.create( modelclaude-sonnet-4-6, max_tokens1024, system[ {type: text, text: 你是产品支持助手只依据文档回答。}, { type: text, text: long_document, cache_control: {type: ephemeral}, }, ], messages[{role: user, content: 退货政策是几天}], ) print(resp.usage) # 关注 cache 相关字段这里把长文档放进 system 数组并打上cache_control。第一次请求写入缓存之后针对同一文档的不同提问都能命中输入成本骤降。返回的usage里会有缓存创建与缓存读取的 token 数用来验证是否真的命中。四、命中缓存的三个前提想让缓存真正生效注意三点前缀必须完全一致。哪怕改一个空格、换一个日期靠前的缓存块就会失效。把动态内容如当前时间、用户名放到缓存块之后。要达到最小可缓存长度。太短的内容不会被缓存长文档、大段系统提示才划算。缓存有存活时间。默认缓存是短时的ephemeral一段时间不用会过期。高频访问的场景收益最大低频访问可能频繁触发重新写入。五、什么场景收益最大提示缓存最适合同一份长前缀被反复调用的场景客服 / 文档问答同一份知识库被成千上万次提问命中代码库分析把关键源码作为固定上下文反复对它提问批量处理用同一套长指令 few-shot 示例处理大批数据多轮长对话把靠前的固定历史缓存起来。这些场景里缓存往往能把输入成本削掉一大半比单纯换更便宜的模型还立竿见影。反过来如果你每次请求内容都完全不同缓存就派不上用场。六、结合模型分级把成本压到极致提示缓存不是孤立的招数配合模型分级效果更好。把固定长文档缓存起来后简单提问交给 claude-haiku-4-5复杂分析用 claude-sonnet-4-6只有疑难任务才动用 claude-opus-4-8。缓存削减重复输入的费用分级路由控制单价两者叠加Claude API 的整体成本能被压到相当低的水平。在国内使用这套能力网络稳定是前提。通过 jiekou.vip 接入按平台文档把 base_url 换成对应地址即可按量计费提示缓存等原生能力都能正常使用。若遇到 404先检查 URL 尾部是否多写或少写了/v1另外要注意区分接口地址和控制台地址接口地址以文档为准。小结提示缓存是把 Claude API 长上下文成本打下来的关键武器把固定前缀标记为可缓存命中后输入费用大幅下降。用好它的诀窍是固定内容靠前、动态内容靠后、前缀完全一致。再叠加模型分级成本还能进一步压缩。通过 jiekou.vip 在国内稳定接入这套能力你就能既省钱又省心地跑好长上下文应用。