提示词缓存是一项强大的功能,通过允许从提示词中的特定前缀恢复来优化您的API使用。这种方法可以显著减少重复任务或具有一致元素的提示词的处理时间和成本。 以下是如何使用Messages API和cache_control块实现提示词缓存的示例:
curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "system": [
      {
        "type": "text",
        "text": "You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.\n"
      },
      {
        "type": "text",
        "text": "<the entire contents of Pride and Prejudice>",
        "cache_control": {"type": "ephemeral"}
      }
    ],
    "messages": [
      {
        "role": "user",
        "content": "Analyze the major themes in Pride and Prejudice."
      }
    ]
  }'

# 使用相同的输入再次调用模型,直到缓存检查点
curl https://api.anthropic.com/v1/messages # rest of input
JSON
{"cache_creation_input_tokens":188086,"cache_read_input_tokens":0,"input_tokens":21,"output_tokens":393}
{"cache_creation_input_tokens":0,"cache_read_input_tokens":188086,"input_tokens":21,"output_tokens":393}
在此示例中,《傲慢与偏见》的全文使用cache_control参数进行缓存。这使得可以在多个API调用中重复使用这个大型文本,而无需每次都重新处理。仅更改用户消息允许您在利用缓存内容的同时提出关于这本书的各种问题,从而获得更快的响应和提高的效率。

提示词缓存如何工作

当您发送启用了提示词缓存的请求时:
  1. 系统检查是否已从最近的查询中缓存了提示词前缀(直到指定的缓存断点)。
  2. 如果找到,它使用缓存版本,减少处理时间和成本。
  3. 否则,它处理完整提示词,并在响应开始后缓存前缀。
这对以下情况特别有用:
  • 包含许多示例的提示词
  • 大量上下文或背景信息
  • 具有一致指令的重复任务
  • 长多轮对话
默认情况下,缓存的生命周期为5分钟。每次使用缓存内容时,缓存会以无额外成本的方式刷新。
如果您发现5分钟太短,Anthropic还提供1小时缓存持续时间需付费。1小时缓存目前处于测试阶段。有关更多信息,请参阅1小时缓存持续时间
提示词缓存缓存完整前缀提示词缓存引用整个提示词 - toolssystemmessages(按该顺序)直到并包括用cache_control指定的块。

定价

提示词缓存引入了新的定价结构。下表显示了每个支持的模型每百万个令牌的价格:
ModelBase Input Tokens5m Cache Writes1h Cache WritesCache Hits & RefreshesOutput 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参数标记可重用内容的结尾以进行缓存。 缓存前缀按以下顺序创建:toolssystem,然后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缓存。但是,当思考块出现在先前的助手轮次中时,它们可以与其他内容一起缓存。以这种方式缓存时,它们在从缓存读取时确实计为输入令牌。
  • 子内容块(如引用)本身无法直接缓存。相反,缓存顶级块。 在引用的情况下,作为引用源材料的顶级文档内容块可以缓存。这允许您通过缓存引用将引用的文档来有效地使用提示词缓存。
  • 空文本块无法缓存。

什么使缓存失效

对缓存内容的修改可能会使部分或全部缓存失效。 构建您的提示词中所述,缓存遵循层次结构:toolssystemmessages。每个级别的更改会使该级别及所有后续级别失效。 下表显示了不同类型的更改会使缓存的哪些部分失效。✘表示缓存失效,✓表示缓存保持有效。
什么改变工具缓存系统缓存消息缓存影响
工具定义修改工具定义(名称、描述、参数)会使整个缓存失效
网络搜索切换启用/禁用网络搜索会修改系统提示词
引用切换启用/禁用引用会修改系统提示词
工具选择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标记,此缓存行为也会发生
有关缓存失效的更多详情,请参阅什么使缓存失效 工具使用示例
请求1:用户:"巴黎的天气如何?"
响应:[thinking_block_1] + [tool_use block 1]

请求2:
用户:["巴黎的天气如何?"],
助手:[thinking_block_1] + [tool_use block 1],
用户:[tool_result_1, cache=True]
响应:[thinking_block_2] + [text block 2]
# 请求2缓存其请求内容(不是响应)
# 缓存包括:用户消息、thinking_block_1、tool_use block 1和tool_result_1

请求3:
用户:["巴黎的天气如何?"],
助手:[thinking_block_1] + [tool_use block 1],
用户:[tool_result_1, cache=True],
助手:[thinking_block_2] + [text block 2],
用户:[文本响应, cache=True]
# 非工具结果用户块导致所有思考块被忽略
# 此请求的处理方式就像思考块从未存在过一样
当包含非工具结果用户块时,它指定新的助手循环,所有先前的思考块都会从上下文中删除。 有关更多详细信息,请参阅扩展思考文档

缓存存储和共享

  • 组织隔离:缓存在组织之间隔离。不同的组织永远不会共享缓存,即使他们使用相同的提示词。
  • 精确匹配:缓存命中需要100%相同的提示词段,包括直到并包括用缓存控制标记的块的所有文本和图像。
  • 输出令牌生成:提示词缓存对输出令牌生成没有影响。您收到的响应将与不使用提示词缓存时收到的响应相同。

1小时缓存持续时间

如果您发现5分钟太短,Anthropic还提供1小时缓存持续时间需付费 要使用扩展缓存,请在cache_control定义中包含ttl,如下所示:
"cache_control": {
    "type": "ephemeral",
    "ttl": "5m" | "1h"
}
响应将包含详细的缓存信息,如下所示:
{
    "usage": {
        "input_tokens": ...,
        "cache_read_input_tokens": ...,
        "cache_creation_input_tokens": ...,
        "output_tokens": ...,

        "cache_creation": {
            "ephemeral_5m_input_tokens": 456,
            "ephemeral_1h_input_tokens": 100,
        }
    }
}
请注意,当前的cache_creation_input_tokens字段等于cache_creation对象中值的总和。

何时使用1小时缓存

如果您有定期使用的提示词(即每5分钟以上使用一次的系统提示词),请继续使用5分钟缓存,因为这将继续以无额外成本的方式刷新。 1小时缓存最适合用于以下场景:
  • 当您有可能每5分钟使用一次以上,但每小时使用一次以下的提示词时。例如,当代理端代理需要超过5分钟时,或者当存储与用户的长聊天对话时,您通常预期该用户在接下来的5分钟内可能不会响应。
  • 当延迟很重要且您的后续提示词可能在5分钟后发送时。
  • 当您想改进您的速率限制利用率时,因为缓存命中不会从您的速率限制中扣除。
5分钟和1小时缓存在延迟方面的行为相同。对于长文档,您通常会看到改进的首令牌时间。

混合不同的TTL

您可以在同一请求中使用1小时和5分钟缓存控制,但有一个重要的限制:具有较长TTL的缓存条目必须出现在较短TTL之前(即1小时缓存条目必须出现在任何5分钟缓存条目之前)。 混合TTL时,我们在您的提示词中确定三个计费位置:
  1. 位置A:最高缓存命中处的令牌计数(如果没有命中则为0)。
  2. 位置B:在A之后的最高1小时cache_control块处的令牌计数(如果不存在则等于A)。
  3. 位置C:最后一个cache_control块处的令牌计数。
如果B和/或C大于A,它们必然是缓存未命中,因为A是最高缓存命中。
您将被收费:
  1. 位置A的缓存读取令牌。
  2. 位置(B - A)的1小时缓存写入令牌。
  3. 位置(C - B)的5分钟缓存写入令牌。
以下是3个示例。这描绘了3个请求的输入令牌,每个请求都有不同的缓存命中和缓存未命中。每个都有不同的计算定价,如彩色框所示。 混合TTL图表

提示词缓存示例

为了帮助您开始使用提示词缓存,我们准备了一个提示词缓存食谱,其中包含详细的示例和最佳实践。 以下是几个代码片段,展示了各种提示词缓存模式。这些示例演示了如何在不同场景中实现缓存,帮助您理解此功能的实际应用:
curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "system": [
        {
            "type": "text",
            "text": "You are an AI assistant tasked with analyzing legal documents."
        },
        {
            "type": "text",
            "text": "Here is the full text of a complex legal agreement: [Insert full text of a 50-page legal agreement here]",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": "What are the key terms and conditions in this agreement?"
        }
    ]
}'
此示例演示了基本的提示词缓存使用,缓存法律协议的全文作为前缀,同时保持用户指令未缓存。对于第一个请求:
  • input_tokens:仅用户消息中的令牌数
  • cache_creation_input_tokens:整个系统消息中的令牌数,包括法律文档
  • cache_read_input_tokens:0(第一个请求没有缓存命中)
对于缓存生命周期内的后续请求:
  • input_tokens:仅用户消息中的令牌数
  • cache_creation_input_tokens:0(没有新的缓存创建)
  • cache_read_input_tokens:整个缓存系统消息中的令牌数
curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "tools": [
        {
            "name": "get_weather",
            "description": "Get the current weather in a given location",
            "input_schema": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "The city and state, e.g. San Francisco, CA"
                    },
                    "unit": {
                        "type": "string",
                        "enum": ["celsius", "fahrenheit"],
                        "description": "The unit of temperature, either celsius or fahrenheit"
                    }
                },
                "required": ["location"]
            }
        },
        # many more tools
        {
            "name": "get_time",
            "description": "Get the current time in a given time zone",
            "input_schema": {
                "type": "object",
                "properties": {
                    "timezone": {
                        "type": "string",
                        "description": "The IANA time zone name, e.g. America/Los_Angeles"
                    }
                },
                "required": ["timezone"]
            },
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": "What is the weather and time in New York?"
        }
    ]
}'
在此示例中,我们演示了缓存工具定义。cache_control参数放在最后一个工具(get_time)上,以将所有工具指定为静态前缀的一部分。这意味着所有工具定义,包括get_weatherget_time之前定义的任何其他工具,都将作为单个前缀缓存。当您有一组一致的工具想要在多个请求中重复使用而无需每次都重新处理它们时,此方法很有用。对于第一个请求:
  • input_tokens:用户消息中的令牌数
  • cache_creation_input_tokens:所有工具定义和系统提示词中的令牌数
  • cache_read_input_tokens:0(第一个请求没有缓存命中)
对于缓存生命周期内的后续请求:
  • input_tokens:用户消息中的令牌数
  • cache_creation_input_tokens:0(没有新的缓存创建)
  • cache_read_input_tokens:所有缓存工具定义和系统提示词中的令牌数
curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "system": [
        {
            "type": "text",
            "text": "...long system prompt",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Hello, can you tell me more about the solar system?",
                }
            ]
        },
        {
            "role": "assistant",
            "content": "Certainly! The solar system is the collection of celestial bodies that orbit our Sun. It consists of eight planets, numerous moons, asteroids, comets, and other objects. The planets, in order from closest to farthest from the Sun, are: Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, and Neptune. Each planet has its own unique characteristics and features. Is there a specific aspect of the solar system you would like to know more about?"
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Good to know."
                },
                {
                    "type": "text",
                    "text": "Tell me more about Mars.",
                    "cache_control": {"type": "ephemeral"}
                }
            ]
        }
    ]
}'
在此示例中,我们演示了如何在多轮对话中使用提示词缓存。在每个轮次中,我们用cache_control标记最后一条消息的最后一个块,以便对话可以增量缓存。系统将自动查找并使用最长的先前缓存前缀以进行后续消息。也就是说,先前用cache_control块标记的块稍后不会被标记,但如果它们在5分钟内被命中,它们仍然会被视为缓存命中(也是缓存刷新!)。此外,请注意cache_control参数放在系统消息上。这是为了确保如果这从缓存中被逐出(在5分钟以上未使用后),它将在下一个请求中被添加回缓存。此方法对于在进行中的对话中维护上下文而无需重复处理相同信息很有用。当正确设置此方法时,您应该在每个请求的使用响应中看到以下内容:
  • input_tokens:新用户消息中的令牌数(将最少)
  • cache_creation_input_tokens:新助手和用户轮次中的令牌数
  • cache_read_input_tokens:对话中直到上一个轮次的令牌数
curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "tools": [
        {
            "name": "search_documents",
            "description": "Search through the knowledge base",
            "input_schema": {
                "type": "object",
                "properties": {
                    "query": {
                        "type": "string",
                        "description": "Search query"
                    }
                },
                "required": ["query"]
            }
        },
        {
            "name": "get_document",
            "description": "Retrieve a specific document by ID",
            "input_schema": {
                "type": "object",
                "properties": {
                    "doc_id": {
                        "type": "string",
                        "description": "Document ID"
                    }
                },
                "required": ["doc_id"]
            },
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "system": [
        {
            "type": "text",
            "text": "You are a helpful research assistant with access to a document knowledge base.\n\n# Instructions\n- Always search for relevant documents before answering\n- Provide citations for your sources\n- Be objective and accurate in your responses\n- If multiple documents contain relevant information, synthesize them\n- Acknowledge when information is not available in the knowledge base",
            "cache_control": {"type": "ephemeral"}
        },
        {
            "type": "text",
            "text": "# Knowledge Base Context\n\nHere are the relevant documents for this conversation:\n\n## Document 1: Solar System Overview\nThe solar system consists of the Sun and all objects that orbit it...\n\n## Document 2: Planetary Characteristics\nEach planet has unique features. Mercury is the smallest planet...\n\n## Document 3: Mars Exploration\nMars has been a target of exploration for decades...\n\n[Additional documents...]",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": "Can you search for information about Mars rovers?"
        },
        {
            "role": "assistant",
            "content": [
                {
                    "type": "tool_use",
                    "id": "tool_1",
                    "name": "search_documents",
                    "input": {"query": "Mars rovers"}
                }
            ]
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "tool_result",
                    "tool_use_id": "tool_1",
                    "content": "Found 3 relevant documents: Document 3 (Mars Exploration), Document 7 (Rover Technology), Document 9 (Mission History)"
                }
            ]
        },
        {
            "role": "assistant",
            "content": [
                {
                    "type": "text",
                    "text": "I found 3 relevant documents about Mars rovers. Let me get more details from the Mars Exploration document."
                }
            ]
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Yes, please tell me about the Perseverance rover specifically.",
                    "cache_control": {"type": "ephemeral"}
                }
            ]
        }
    ]
}'
此综合示例演示了如何使用所有4个可用的缓存断点来优化提示词的不同部分:
  1. 工具缓存(缓存断点1):最后一个工具定义上的cache_control参数缓存所有工具定义。
  2. 可重用指令缓存(缓存断点2):系统提示词中的静态指令被单独缓存。这些指令在请求之间很少变化。
  3. RAG上下文缓存(缓存断点3):知识库文档被独立缓存,允许您更新RAG文档而不使工具或指令缓存失效。
  4. 对话历史缓存(缓存断点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个内容块
  • 您想独立缓存以不同频率更新的部分
  • 您需要对缓存内容进行显式控制以优化成本
示例:如果您有系统指令(很少变化)和RAG上下文(每天变化),您可能会使用两个断点来单独缓存它们。
不,缓存断点本身是免费的。您只需为以下内容付费:
  • 将内容写入缓存(比基础输入令牌多25%,用于5分钟TTL)
  • 从缓存读取(基础输入令牌价格的10%)
  • 未缓存内容的常规输入令牌
断点的数量不会影响定价 - 只有缓存和读取的内容量重要。
缓存的默认最小生命周期(TTL)是5分钟。每次使用缓存内容时,此生命周期都会刷新。如果您发现5分钟太短,Anthropic还提供1小时缓存TTL
您可以在提示词中定义最多4个缓存断点(使用cache_control参数)。
不,提示词缓存目前仅适用于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 (已弃用)。
缓存的系统提示词和工具将在思考参数更改时被重复使用。但是,思考更改(启用/禁用或预算更改)将使具有消息内容的先前缓存提示词前缀失效。有关缓存失效的更多详情,请参阅什么使缓存失效有关扩展思考的更多信息,包括其与工具使用和提示词缓存的交互,请参阅扩展思考文档
要启用提示词缓存,请在您的API请求中包含至少一个cache_control断点。
是的,提示词缓存可以与其他API功能(如工具使用和视觉功能)一起使用。但是,更改提示词中是否有图像或修改工具使用设置将破坏缓存。有关缓存失效的更多详情,请参阅什么使缓存失效
提示词缓存引入了新的定价结构,其中缓存写入成本比基础输入令牌多25%,而缓存命中仅成本为基础输入令牌价格的10%。
目前,没有办法手动清除缓存。缓存前缀在最少5分钟不活动后自动过期。
您可以使用API响应中的cache_creation_input_tokenscache_read_input_tokens字段监控缓存性能。
有关缓存失效的更多详情,请参阅什么使缓存失效,包括需要创建新缓存条目的更改列表。
提示词缓存设计有强大的隐私和数据分离措施:
  1. 缓存键是使用提示词的加密哈希生成的,直到缓存控制点。这意味着只有具有相同提示词的请求才能访问特定缓存。
  2. 缓存是特定于组织的。同一组织内的用户如果使用相同的提示词,可以访问相同的缓存,但缓存不会在不同组织之间共享,即使对于相同的提示词也是如此。
  3. 缓存机制设计用于维护每个唯一对话或上下文的完整性和隐私。
  4. 在提示词中的任何位置使用cache_control是安全的。为了成本效率,最好将高度可变的部分(例如用户的任意输入)排除在缓存之外。
这些措施确保提示词缓存在提供性能优势的同时维护数据隐私和安全。
是的,可以将提示词缓存与您的Batches API请求一起使用。但是,由于异步批处理请求可以并发处理并以任何顺序处理,缓存命中是尽力而为的基础。1小时缓存可以帮助改进您的缓存命中。最具成本效益的使用方式如下:
  • 收集一组具有共享前缀的消息请求。
  • 发送一个仅包含此共享前缀和1小时缓存块的单个请求的批处理请求。这将被写入1小时缓存。
  • 一旦完成,提交其余请求。您必须监控作业以了解何时完成。
这通常比使用5分钟缓存更好,因为批处理请求通常需要5分钟到1小时之间的时间来完成。我们正在考虑改进这些缓存命中率并使此过程更直接的方法。
此错误通常在您升级SDK或使用过时代码示例时出现。提示词缓存现在已正式推出,因此您不再需要beta前缀。而不是:
python client.beta.prompt_caching.messages.create(...)
只需使用:
python client.messages.create(...)
此错误通常在您升级SDK或使用过时代码示例时出现。提示词缓存现在已正式推出,因此您不再需要beta前缀。而不是:
TypeScript
client.beta.promptCaching.messages.create(...)
只需使用:
client.messages.create(...)