cache_control块实现提示词缓存的示例:
JSON
cache_control参数进行缓存。这使得可以在多个API调用中重复使用这个大型文本,而无需每次都重新处理。仅更改用户消息允许您在利用缓存内容的同时提出关于这本书的各种问题,从而获得更快的响应和提高的效率。
提示词缓存如何工作
当您发送启用了提示词缓存的请求时:- 系统检查是否已从最近的查询中缓存了提示词前缀(直到指定的缓存断点)。
- 如果找到,它使用缓存版本,减少处理时间和成本。
- 否则,它处理完整提示词,并在响应开始后缓存前缀。
- 包含许多示例的提示词
- 大量上下文或背景信息
- 具有一致指令的重复任务
- 长多轮对话
提示词缓存缓存完整前缀提示词缓存引用整个提示词 -
tools、system和messages(按该顺序)直到并包括用cache_control指定的块。定价
提示词缓存引入了新的定价结构。下表显示了每个支持的模型每百万个令牌的价格:| Model | Base Input Tokens | 5m Cache Writes | 1h Cache Writes | Cache Hits & Refreshes | Output Tokens |
|---|---|---|---|---|---|
| Claude Opus 4.1 | $15 / MTok | $18.75 / MTok | $30 / MTok | $1.50 / MTok | $75 / MTok |
| Claude Opus 4 | $15 / MTok | $18.75 / MTok | $30 / MTok | $1.50 / MTok | $75 / MTok |
| Claude Sonnet 4.5 | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
| Claude Sonnet 4 | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
| Claude Sonnet 3.7 | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
| Claude Sonnet 3.5 (deprecated) | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
| Claude Haiku 4.5 | $1 / MTok | $1.25 / MTok | $2 / MTok | $0.10 / MTok | $5 / MTok |
| Claude Haiku 3.5 | $0.80 / MTok | $1 / MTok | $1.6 / MTok | $0.08 / MTok | $4 / MTok |
| Claude Opus 3 (deprecated) | $15 / MTok | $18.75 / MTok | $30 / MTok | $1.50 / MTok | $75 / MTok |
| Claude Haiku 3 | $0.25 / MTok | $0.30 / MTok | $0.50 / MTok | $0.03 / MTok | $1.25 / MTok |
上表反映了提示词缓存的以下定价倍数:
- 5分钟缓存写入令牌是基础输入令牌价格的1.25倍
- 1小时缓存写入令牌是基础输入令牌价格的2倍
- 缓存读取令牌是基础输入令牌价格的0.1倍
如何实现提示词缓存
支持的模型
提示词缓存目前支持:- Claude Opus 4.1
- Claude Opus 4
- Claude Sonnet 4.5
- Claude Sonnet 4
- Claude Sonnet 3.7
- Claude Sonnet 3.5 (已弃用)
- Claude Haiku 4.5
- Claude Haiku 3.5
- Claude Haiku 3
- Claude Opus 3 (已弃用)
构建您的提示词
将静态内容(工具定义、系统指令、上下文、示例)放在提示词的开头。使用cache_control参数标记可重用内容的结尾以进行缓存。
缓存前缀按以下顺序创建:tools、system,然后messages。此顺序形成一个层次结构,其中每个级别都建立在前一个级别之上。
自动前缀检查如何工作
您可以在静态内容的末尾使用一个缓存断点,系统将自动找到最长的匹配前缀。 以下是它的工作原理:- 当您添加
cache_control断点时,系统会自动检查所有先前内容块边界处的缓存命中(在您的显式断点之前最多约20个块) - 如果这些先前位置中的任何一个与来自早期请求的缓存内容匹配,系统将使用最长的匹配前缀
- 这意味着您不需要多个断点来启用缓存 - 末尾的一个就足够了
何时使用多个断点
如果您想要以下情况,可以定义最多4个缓存断点:- 缓存以不同频率变化的不同部分(例如,工具很少变化,但上下文每天更新)
- 对缓存内容有更多控制
- 确保缓存最终断点之前超过20个块的内容
重要限制:自动前缀检查仅从每个显式断点向后查看约20个内容块。如果您的提示词在缓存断点之前有超过20个内容块,除非您添加额外的断点,否则早于该位置的内容将不会被检查缓存命中。
缓存限制
最小可缓存提示词长度为:- 1024个令牌,用于Claude Opus 4.1、Claude Opus 4、Claude Sonnet 4.5、Claude Sonnet 4、Claude Sonnet 3.7、Claude Sonnet 3.5 (已弃用)和Claude Opus 3 (已弃用)
- 4096个令牌,用于Claude Haiku 4.5
- 2048个令牌,用于Claude Haiku 3.5和Claude Haiku 3
cache_control标记也是如此。任何缓存少于此令牌数的请求将在没有缓存的情况下处理。要查看提示词是否被缓存,请参阅响应使用字段。
对于并发请求,请注意缓存条目仅在第一个响应开始后才可用。如果您需要并行请求的缓存命中,请在发送后续请求之前等待第一个响应。
目前,“ephemeral”是唯一支持的缓存类型,默认生命周期为5分钟。
理解缓存断点成本
缓存断点本身不会增加任何成本。 您只需为以下内容付费:- 缓存写入:当新内容写入缓存时(比基础输入令牌多25%,用于5分钟TTL)
- 缓存读取:当使用缓存内容时(基础输入令牌价格的10%)
- 常规输入令牌:对于任何未缓存的内容
cache_control断点不会增加您的成本 - 您仍然根据实际缓存和读取的内容支付相同的金额。断点只是让您控制哪些部分可以独立缓存。
可以缓存的内容
请求中的大多数块都可以用cache_control指定为缓存。这包括:
- 工具:
tools数组中的工具定义 - 系统消息:
system数组中的内容块 - 文本消息:
messages.content数组中的内容块,用于用户和助手轮次 - 图像和文档:
messages.content数组中的内容块,在用户轮次中 - 工具使用和工具结果:
messages.content数组中的内容块,在用户和助手轮次中
cache_control标记以启用该部分请求的缓存。
无法缓存的内容
虽然大多数请求块都可以缓存,但有一些例外:-
思考块无法直接用
cache_control缓存。但是,当思考块出现在先前的助手轮次中时,它们可以与其他内容一起缓存。以这种方式缓存时,它们在从缓存读取时确实计为输入令牌。 - 子内容块(如引用)本身无法直接缓存。相反,缓存顶级块。 在引用的情况下,作为引用源材料的顶级文档内容块可以缓存。这允许您通过缓存引用将引用的文档来有效地使用提示词缓存。
- 空文本块无法缓存。
什么使缓存失效
对缓存内容的修改可能会使部分或全部缓存失效。 如构建您的提示词中所述,缓存遵循层次结构:tools → system → messages。每个级别的更改会使该级别及所有后续级别失效。
下表显示了不同类型的更改会使缓存的哪些部分失效。✘表示缓存失效,✓表示缓存保持有效。
| 什么改变 | 工具缓存 | 系统缓存 | 消息缓存 | 影响 |
|---|---|---|---|---|
| 工具定义 | ✘ | ✘ | ✘ | 修改工具定义(名称、描述、参数)会使整个缓存失效 |
| 网络搜索切换 | ✓ | ✘ | ✘ | 启用/禁用网络搜索会修改系统提示词 |
| 引用切换 | ✓ | ✘ | ✘ | 启用/禁用引用会修改系统提示词 |
| 工具选择 | ✓ | ✓ | ✘ | 对tool_choice参数的更改仅影响消息块 |
| 图像 | ✓ | ✓ | ✘ | 在提示词中的任何位置添加/删除图像会影响消息块 |
| 思考参数 | ✓ | ✓ | ✘ | 对扩展思考设置的更改(启用/禁用、预算)会影响消息块 |
| 传递给扩展思考请求的非工具结果 | ✓ | ✓ | ✘ | 当在启用扩展思考的请求中传递非工具结果时,所有先前缓存的思考块都会从上下文中删除,并且上下文中跟随这些思考块的任何消息都会从缓存中删除。有关更多详情,请参阅使用思考块缓存。 |
跟踪缓存性能
使用这些API响应字段监控缓存性能,在响应中的usage内(或如果流式传输则在message_start事件中):
cache_creation_input_tokens:创建新条目时写入缓存的令牌数。cache_read_input_tokens:为此请求从缓存检索的令牌数。input_tokens:未从缓存读取或用于创建缓存的输入令牌数。
有效缓存的最佳实践
要优化提示词缓存性能:- 缓存稳定的、可重用的内容,如系统指令、背景信息、大型上下文或频繁的工具定义。
- 将缓存内容放在提示词的开头以获得最佳性能。
- 战略性地使用缓存断点来分离不同的可缓存前缀部分。
- 定期分析缓存命中率并根据需要调整您的策略。
针对不同用例的优化
根据您的场景定制您的提示词缓存策略:- 对话代理:减少扩展对话的成本和延迟,特别是那些具有长指令或上传文档的对话。
- 编码助手:通过在提示词中保留相关部分或代码库的摘要版本来改进自动完成和代码库问答。
- 大型文档处理:将完整的长篇材料(包括图像)合并到您的提示词中,而不会增加响应延迟。
- 详细指令集:共享广泛的指令、程序和示例列表以微调Claude的响应。开发人员通常在提示词中包含一两个示例,但使用提示词缓存,您可以通过包含20多个高质量答案的多样化示例来获得更好的性能。
- 代理工具使用:增强涉及多个工具调用和迭代代码更改的场景的性能,其中每个步骤通常需要新的API调用。
- 与书籍、论文、文档、播客转录本和其他长篇内容交谈:通过将整个文档嵌入提示词中并让用户提出问题来激活任何知识库。
排查常见问题
如果遇到意外行为:- 确保缓存部分相同,并在调用中的相同位置用cache_control标记
- 检查调用是否在缓存生命周期内进行(默认5分钟)
- 验证
tool_choice和图像使用在调用之间保持一致 - 验证您缓存的令牌数至少为最小数量
- 系统会自动检查先前内容块边界处的缓存命中(在您的断点之前约20个块)。对于超过20个内容块的提示词,您可能需要在提示词中较早的位置添加额外的
cache_control参数以确保所有内容都可以缓存 - 验证您的
tool_use内容块中的键具有稳定的排序,因为某些语言(例如Swift、Go)在JSON转换期间随机化键顺序,破坏缓存
对
tool_choice的更改或提示词中任何位置的图像的存在/不存在将使缓存失效,需要创建新的缓存条目。有关缓存失效的更多详情,请参阅什么使缓存失效。使用思考块缓存
当使用扩展思考与提示词缓存时,思考块具有特殊行为: 与其他内容自动缓存:虽然思考块无法用cache_control显式标记,但当您使用工具结果进行后续API调用时,它们会作为请求内容的一部分被缓存。这通常在工具使用期间发生,当您传递思考块以继续对话时。
输入令牌计数:当思考块从缓存读取时,它们在您的使用指标中计为输入令牌。这对成本计算和令牌预算很重要。
缓存失效模式:
- 当仅提供工具结果作为用户消息时,缓存保持有效
- 当添加非工具结果用户内容时,缓存失效,导致所有先前的思考块被删除
- 即使没有显式
cache_control标记,此缓存行为也会发生
缓存存储和共享
- 组织隔离:缓存在组织之间隔离。不同的组织永远不会共享缓存,即使他们使用相同的提示词。
- 精确匹配:缓存命中需要100%相同的提示词段,包括直到并包括用缓存控制标记的块的所有文本和图像。
- 输出令牌生成:提示词缓存对输出令牌生成没有影响。您收到的响应将与不使用提示词缓存时收到的响应相同。
1小时缓存持续时间
如果您发现5分钟太短,Anthropic还提供1小时缓存持续时间需付费。 要使用扩展缓存,请在cache_control定义中包含ttl,如下所示:
cache_creation_input_tokens字段等于cache_creation对象中值的总和。
何时使用1小时缓存
如果您有定期使用的提示词(即每5分钟以上使用一次的系统提示词),请继续使用5分钟缓存,因为这将继续以无额外成本的方式刷新。 1小时缓存最适合用于以下场景:- 当您有可能每5分钟使用一次以上,但每小时使用一次以下的提示词时。例如,当代理端代理需要超过5分钟时,或者当存储与用户的长聊天对话时,您通常预期该用户在接下来的5分钟内可能不会响应。
- 当延迟很重要且您的后续提示词可能在5分钟后发送时。
- 当您想改进您的速率限制利用率时,因为缓存命中不会从您的速率限制中扣除。
5分钟和1小时缓存在延迟方面的行为相同。对于长文档,您通常会看到改进的首令牌时间。
混合不同的TTL
您可以在同一请求中使用1小时和5分钟缓存控制,但有一个重要的限制:具有较长TTL的缓存条目必须出现在较短TTL之前(即1小时缓存条目必须出现在任何5分钟缓存条目之前)。 混合TTL时,我们在您的提示词中确定三个计费位置:- 位置
A:最高缓存命中处的令牌计数(如果没有命中则为0)。 - 位置
B:在A之后的最高1小时cache_control块处的令牌计数(如果不存在则等于A)。 - 位置
C:最后一个cache_control块处的令牌计数。
如果
B和/或C大于A,它们必然是缓存未命中,因为A是最高缓存命中。- 位置
A的缓存读取令牌。 - 位置
(B - A)的1小时缓存写入令牌。 - 位置
(C - B)的5分钟缓存写入令牌。
提示词缓存示例
为了帮助您开始使用提示词缓存,我们准备了一个提示词缓存食谱,其中包含详细的示例和最佳实践。 以下是几个代码片段,展示了各种提示词缓存模式。这些示例演示了如何在不同场景中实现缓存,帮助您理解此功能的实际应用:大型上下文缓存示例
大型上下文缓存示例
input_tokens:仅用户消息中的令牌数cache_creation_input_tokens:整个系统消息中的令牌数,包括法律文档cache_read_input_tokens:0(第一个请求没有缓存命中)
input_tokens:仅用户消息中的令牌数cache_creation_input_tokens:0(没有新的缓存创建)cache_read_input_tokens:整个缓存系统消息中的令牌数
缓存工具定义
缓存工具定义
cache_control参数放在最后一个工具(get_time)上,以将所有工具指定为静态前缀的一部分。这意味着所有工具定义,包括get_weather和get_time之前定义的任何其他工具,都将作为单个前缀缓存。当您有一组一致的工具想要在多个请求中重复使用而无需每次都重新处理它们时,此方法很有用。对于第一个请求:input_tokens:用户消息中的令牌数cache_creation_input_tokens:所有工具定义和系统提示词中的令牌数cache_read_input_tokens:0(第一个请求没有缓存命中)
input_tokens:用户消息中的令牌数cache_creation_input_tokens:0(没有新的缓存创建)cache_read_input_tokens:所有缓存工具定义和系统提示词中的令牌数
继续多轮对话
继续多轮对话
cache_control标记最后一条消息的最后一个块,以便对话可以增量缓存。系统将自动查找并使用最长的先前缓存前缀以进行后续消息。也就是说,先前用cache_control块标记的块稍后不会被标记,但如果它们在5分钟内被命中,它们仍然会被视为缓存命中(也是缓存刷新!)。此外,请注意cache_control参数放在系统消息上。这是为了确保如果这从缓存中被逐出(在5分钟以上未使用后),它将在下一个请求中被添加回缓存。此方法对于在进行中的对话中维护上下文而无需重复处理相同信息很有用。当正确设置此方法时,您应该在每个请求的使用响应中看到以下内容:input_tokens:新用户消息中的令牌数(将最少)cache_creation_input_tokens:新助手和用户轮次中的令牌数cache_read_input_tokens:对话中直到上一个轮次的令牌数
综合应用:多个缓存断点
综合应用:多个缓存断点
-
工具缓存(缓存断点1):最后一个工具定义上的
cache_control参数缓存所有工具定义。 - 可重用指令缓存(缓存断点2):系统提示词中的静态指令被单独缓存。这些指令在请求之间很少变化。
- RAG上下文缓存(缓存断点3):知识库文档被独立缓存,允许您更新RAG文档而不使工具或指令缓存失效。
-
对话历史缓存(缓存断点4):助手的响应用
cache_control标记以启用对话进行时的增量缓存。
- 如果您仅更新最后的用户消息,所有四个缓存段都会被重复使用
- 如果您更新RAG文档但保持相同的工具和指令,前两个缓存段会被重复使用
- 如果您更改对话但保持相同的工具、指令和文档,前三个段会被重复使用
- 每个缓存断点可以根据应用程序中的更改内容独立失效
input_tokens:最后一条用户消息中的令牌数cache_creation_input_tokens:所有缓存段中的令牌数(工具+指令+RAG文档+对话历史)cache_read_input_tokens:0(没有缓存命中)
input_tokens:仅新用户消息中的令牌数cache_creation_input_tokens:添加到对话历史的任何新令牌cache_read_input_tokens:所有先前缓存的令牌(工具+指令+RAG文档+先前对话)
- 具有大型文档上下文的RAG应用程序
- 使用多个工具的代理系统
- 需要维护上下文的长时间运行的对话
- 需要独立优化提示词不同部分的应用程序
常见问题
我需要多个缓存断点还是一个在末尾就足够了?
我需要多个缓存断点还是一个在末尾就足够了?
在大多数情况下,在静态内容末尾的单个缓存断点就足够了。 系统会自动检查所有先前内容块边界处的缓存命中(在您的断点之前最多20个块),并使用最长的匹配前缀。您只需要多个断点,如果:
- 您在所需缓存点之前有超过20个内容块
- 您想独立缓存以不同频率更新的部分
- 您需要对缓存内容进行显式控制以优化成本
缓存断点会增加额外成本吗?
缓存断点会增加额外成本吗?
不,缓存断点本身是免费的。您只需为以下内容付费:
- 将内容写入缓存(比基础输入令牌多25%,用于5分钟TTL)
- 从缓存读取(基础输入令牌价格的10%)
- 未缓存内容的常规输入令牌
缓存生命周期是多长?
缓存生命周期是多长?
缓存的默认最小生命周期(TTL)是5分钟。每次使用缓存内容时,此生命周期都会刷新。如果您发现5分钟太短,Anthropic还提供1小时缓存TTL。
我可以使用多少个缓存断点?
我可以使用多少个缓存断点?
您可以在提示词中定义最多4个缓存断点(使用
cache_control参数)。提示词缓存是否适用于所有模型?
提示词缓存是否适用于所有模型?
提示词缓存如何与扩展思考配合使用?
提示词缓存如何与扩展思考配合使用?
我如何启用提示词缓存?
我如何启用提示词缓存?
要启用提示词缓存,请在您的API请求中包含至少一个
cache_control断点。我可以将提示词缓存与其他API功能一起使用吗?
我可以将提示词缓存与其他API功能一起使用吗?
是的,提示词缓存可以与其他API功能(如工具使用和视觉功能)一起使用。但是,更改提示词中是否有图像或修改工具使用设置将破坏缓存。有关缓存失效的更多详情,请参阅什么使缓存失效。
提示词缓存如何影响定价?
提示词缓存如何影响定价?
提示词缓存引入了新的定价结构,其中缓存写入成本比基础输入令牌多25%,而缓存命中仅成本为基础输入令牌价格的10%。
我可以手动清除缓存吗?
我可以手动清除缓存吗?
目前,没有办法手动清除缓存。缓存前缀在最少5分钟不活动后自动过期。
我如何跟踪我的缓存策略的有效性?
我如何跟踪我的缓存策略的有效性?
您可以使用API响应中的
cache_creation_input_tokens和cache_read_input_tokens字段监控缓存性能。什么会破坏缓存?
什么会破坏缓存?
有关缓存失效的更多详情,请参阅什么使缓存失效,包括需要创建新缓存条目的更改列表。
提示词缓存如何处理隐私和数据分离?
提示词缓存如何处理隐私和数据分离?
提示词缓存设计有强大的隐私和数据分离措施:
- 缓存键是使用提示词的加密哈希生成的,直到缓存控制点。这意味着只有具有相同提示词的请求才能访问特定缓存。
- 缓存是特定于组织的。同一组织内的用户如果使用相同的提示词,可以访问相同的缓存,但缓存不会在不同组织之间共享,即使对于相同的提示词也是如此。
- 缓存机制设计用于维护每个唯一对话或上下文的完整性和隐私。
-
在提示词中的任何位置使用
cache_control是安全的。为了成本效率,最好将高度可变的部分(例如用户的任意输入)排除在缓存之外。
我可以将提示词缓存与Batches API一起使用吗?
我可以将提示词缓存与Batches API一起使用吗?
是的,可以将提示词缓存与您的Batches API请求一起使用。但是,由于异步批处理请求可以并发处理并以任何顺序处理,缓存命中是尽力而为的基础。1小时缓存可以帮助改进您的缓存命中。最具成本效益的使用方式如下:
- 收集一组具有共享前缀的消息请求。
- 发送一个仅包含此共享前缀和1小时缓存块的单个请求的批处理请求。这将被写入1小时缓存。
- 一旦完成,提交其余请求。您必须监控作业以了解何时完成。
为什么我在Python中看到错误`AttributeError: 'Beta' object has no attribute 'prompt_caching'`?
为什么我在Python中看到错误`AttributeError: 'Beta' object has no attribute 'prompt_caching'`?
此错误通常在您升级SDK或使用过时代码示例时出现。提示词缓存现在已正式推出,因此您不再需要beta前缀。而不是:只需使用:
为什么我看到'TypeError: Cannot read properties of undefined (reading 'messages')'?
为什么我看到'TypeError: Cannot read properties of undefined (reading 'messages')'?
此错误通常在您升级SDK或使用过时代码示例时出现。提示词缓存现在已正式推出,因此您不再需要beta前缀。而不是:只需使用:
TypeScript