用途：提示缓存复用已处理的前缀，缓存读取成本约为全新输入的 10%，适合大段重复上下文（系统提示、长文档、代码库、多轮对话、工具定义）。当重复内容超过 1024 tokens（Haiku 为 2048）时适用。
两种 TTL：5 分钟（ephemeral）适合会话、活跃交互，写入成本约 1.25 倍输入；1 小时适合系统提示、知识库、代码库，写入成本约 2 倍输入。两者缓存读取均约 0.1 倍输入成本。跨会话或跨独立用户用 1h，会话内复用用 5min。
用法：在 system、tools、messages 的文本块上设置 cache_control: { type: "ephemeral", ttl: "1h" }。每个请求最多 4 个缓存断点，断点之前的内容作为前缀被缓存，典型位置为系统提示末尾、工具定义末尾、大文档末尾、对话历史末尾；当前轮次不缓存。多轮对话中把 5m 断点放在最后一条 assistant 消息上，随对话增长复用累积缓存。可与 1M 上下文（请求头 anthropic-beta: context-1m-2025-08-07）配合，使长上下文更可负担。
限制与注意：缓存命中要求断点前前缀逐字节一致，系统提示中的时间戳、UUID、工具顺序变化、修改更早消息、更换模型都会导致未命中；低于最小长度时 cache_control 被静默忽略。可通过 response.usage 的 cache_creation_input_tokens 与 cache_read_input_tokens 计算命中率，稳定前缀的生产负载目标为 80% 以上。常见反模式包括断点前放动态内容、未设断点、缓存小于最小值、忽略命中率、对跨会话知识库使用 5m。调试零命中时逐字节对比相邻请求，检查模型、区域或参数变化。具体价格与平台细节资料未提供。