Кэширование промптов — это мощная функция, которая оптимизирует использование 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."
      }
    ]
  }'

# Call the model again with the same inputs up to the cache checkpoint
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}
В этом примере весь текст «Pride and Prejudice» кэшируется с помощью параметра cache_control. Это позволяет повторно использовать этот большой текст в нескольких вызовах API без повторной обработки каждый раз. Изменение только пользовательского сообщения позволяет вам задавать различные вопросы о книге, используя кэшированное содержимое, что приводит к более быстрым ответам и повышенной эффективности.

Как работает кэширование промптов

Когда вы отправляете запрос с включённым кэшированием промптов:
  1. Система проверяет, кэширован ли уже префикс промпта до указанной точки разрыва кэша из недавнего запроса.
  2. Если найден, она использует кэшированную версию, сокращая время обработки и затраты.
  3. В противном случае она обрабатывает полный промпт и кэширует префикс после начала ответа.
Это особенно полезно для:
  • Промптов с множеством примеров
  • Больших объёмов контекста или справочной информации
  • Повторяющихся задач с постоянными инструкциями
  • Длительных многооборотных разговоров
По умолчанию кэш имеет время жизни 5 минут. Кэш обновляется без дополнительных затрат каждый раз при использовании кэшированного содержимого.
Если вы считаете, что 5 минут — это слишком мало, Anthropic также предлагает длительность кэша в 1 час за дополнительную плату. Кэш на 1 час в настоящее время находится в бета-версии.Для получения дополнительной информации см. Длительность кэша в 1 час.
Кэширование промптов кэширует полный префиксКэширование промптов ссылается на весь промпт — tools, system и messages (в таком порядке) вплоть до и включая блок, обозначенный с помощью 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 (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 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 Opus 3 (устарела)
  • 4096 токенов для Claude Haiku 4.5
  • 2048 токенов для Claude Haiku 3.5 и Claude Haiku 3
Более короткие промпты не могут быть кэшированы, даже если отмечены с помощью cache_control. Любые запросы на кэширование меньшего количества токенов будут обработаны без кэширования. Чтобы узнать, был ли промпт кэширован, см. поля ответа об использовании fields. Для одновременных запросов обратите внимание, что запись в кэш становится доступной только после начала первого ответа. Если вам нужны попадания в кэш для параллельных запросов, дождитесь первого ответа перед отправкой последующих запросов. В настоящее время «ephemeral» — единственный поддерживаемый тип кэша, который по умолчанию имеет время жизни 5 минут.

Понимание затрат на точки разрыва кэша

Сами точки разрыва кэша не добавляют никаких затрат. Вы платите только за:
  • Записи в кэш: Когда новое содержимое записывается в кэш (на 25% больше, чем базовые входные токены для TTL 5 минут)
  • Чтения из кэша: Когда используется кэшированное содержимое (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
Для получения дополнительной информации об инвалидации кэша см. Что делает кэш недействительным. Пример с использованием инструментов:
Request 1: User: "What's the weather in Paris?"
Response: [thinking_block_1] + [tool_use block 1]

Request 2:
User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True]
Response: [thinking_block_2] + [text block 2]
# Request 2 caches its request content (not the response)
# The cache includes: user message, thinking_block_1, tool_use block 1, and tool_result_1

Request 3:
User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [thinking_block_2] + [text block 2],
User: [Text response, cache=True]
# Non-tool-result user block causes all thinking blocks to be ignored
# This request is processed as if thinking blocks were never present
Когда включён блок пользовательского сообщения, не связанный с результатом инструмента, он обозначает новый цикл ассистента и все предыдущие блоки мышления удаляются из контекста. Для получения более подробной информации см. документацию по расширенному мышлению.

Хранилище кэша и совместное использование

  • Изоляция организации: Кэши изолированы между организациями. Различные организации никогда не делят кэши, даже если они используют идентичные промпты.
  • Точное совпадение: Попадания в кэш требуют 100% идентичных сегментов промпта, включая весь текст и изображения вплоть до и включая блок, отмеченный с помощью управления кэшем.
  • Генерация выходных токенов: Кэширование промптов не влияет на генерацию выходных токенов. Ответ, который вы получите, будет идентичен тому, что вы получили бы, если бы кэширование промптов не использовалось.

Длительность кэша в 1 час

Если вы считаете, что 5 минут — это слишком мало, Anthropic также предлагает длительность кэша в 1 час за дополнительную плату. Чтобы использовать расширенный кэш, включите ttl в определение cache_control следующим образом:
"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: Количество токенов при самом высоком блоке cache_control на 1 час после A (или равно A, если таких нет).
  3. Позиция C: Количество токенов при последнем блоке cache_control.
Если B и/или C больше, чем A, они обязательно будут промахами в кэше, потому что A — это самое высокое попадание в кэш.
Вам будут выставлены счёта за:
  1. Токены чтения из кэша для A.
  2. Токены записи в кэш на 1 час для (B - A).
  3. Токены записи в кэш на 5 минут для (C - B).
Вот 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_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: Количество токенов во всех кэшированных определениях инструментов и системном промпте
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% больше, чем базовые входные токены для TTL 5 минут)
  • Чтение из кэша (10% от базовой цены входных токенов)
  • Обычные входные токены для некэшированного содержимого
Количество точек разрыва не влияет на ценообразование — имеет значение только количество кэшированного и прочитанного содержимого.
Время жизни кэша по умолчанию (TTL) составляет 5 минут. Это время жизни обновляется каждый раз при использовании кэшированного содержимого.Если вы считаете, что 5 минут — это слишком мало, Anthropic также предлагает TTL кэша в 1 час.
Вы можете определить до 4 точек разрыва кэша (используя параметры cache_control) в вашем промпте.
Нет, кэширование промптов в настоящее время доступно только для Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4.5, Claude Sonnet 4, Claude Sonnet 3.7, Claude Haiku 4.5, Claude Haiku 3.5, Claude Haiku 3 и Claude Opus 3 (устарела).
Кэшированные системные промпты и инструменты будут повторно использованы при изменении параметров мышления. Однако изменения мышления (включение/отключение или изменения бюджета) сделают недействительными ранее кэшированные префиксы промптов с содержимым сообщений.Для получения дополнительной информации об инвалидации кэша см. Что делает кэш недействительным.Для получения дополнительной информации о расширенном мышлении, включая его взаимодействие с использованием инструментов и кэшированием промптов, см. документацию по расширенному мышлению.
Чтобы включить кэширование промптов, включите по крайней мере одну точку разрыва cache_control в ваш запрос API.
Да, кэширование промптов можно использовать вместе с другими функциями API, такими как использование инструментов и возможности видения. Однако изменение наличия изображений в промпте или изменение параметров использования инструментов нарушит кэш.Для получения дополнительной информации об инвалидации кэша см. Что делает кэш недействительным.
Кэширование промптов вводит новую структуру ценообразования, где записи в кэш стоят на 25% больше, чем базовые входные токены, в то время как попадания в кэш стоят только 10% от базовой цены входных токенов.
В настоящее время нет способа вручную очистить кэш. Кэшированные префиксы автоматически истекают после минимум 5 минут неактивности.
Вы можете отслеживать производительность кэша, используя поля cache_creation_input_tokens и cache_read_input_tokens в ответе API.
См. Что делает кэш недействительным для получения дополнительной информации об инвалидации кэша, включая список изменений, которые требуют создания новой записи в кэш.
Кэширование промптов разработано с сильными мерами конфиденциальности и разделения данных:
  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(...)