cache_control:
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 (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 блоков перед вашей финальной точкой разрыва
Ограничения кэша
Минимальная длина кэшируемого промпта составляет:- 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. Однако блоки мышления МОГУТ быть кэшированы вместе с другим содержимым, когда они появляются в предыдущих ассистентских ходах. При кэшировании таким образом они СЧИТАЮТСЯ входными токенами при чтении из кэша. - Подблоки содержимого (такие как цитаты) сами по себе не могут быть кэшированы напрямую. Вместо этого кэшируйте блок верхнего уровня. В случае цитат блоки содержимого документа верхнего уровня, которые служат исходным материалом для цитат, могут быть кэшированы. Это позволяет вам эффективно использовать кэширование промптов с цитатами, кэшируя документы, на которые будут ссылаться цитаты.
- Пустые текстовые блоки не могут быть кэшированы.
Что делает кэш недействительным
Изменения кэшированного содержимого могут сделать недействительным часть или весь кэш. Как описано в Структурирование вашего промпта, кэш следует иерархии: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 час за дополнительную плату. Чтобы использовать расширенный кэш, включитеttl в определение cache_control следующим образом:
cache_creation_input_tokens равно сумме значений в объекте cache_creation.
Когда использовать кэш на 1 час
Если у вас есть промпты, которые используются с регулярной периодичностью (т. е. системные промпты, которые используются чаще, чем каждые 5 минут), продолжайте использовать кэш на 5 минут, так как он будет продолжать обновляться без дополнительных затрат. Кэш на 1 час лучше всего использовать в следующих сценариях:- Когда у вас есть промпты, которые, вероятно, используются реже, чем каждые 5 минут, но чаще, чем каждый час. Например, когда побочный агент агента будет работать дольше 5 минут, или когда вы сохраняете длительный чат с пользователем и обычно ожидаете, что пользователь может не ответить в течение следующих 5 минут.
- Когда задержка важна и ваши последующие промпты могут быть отправлены за пределами 5 минут.
- Когда вы хотите улучшить использование вашего лимита скорости, так как попадания в кэш не вычитаются из вашего лимита скорости.
Смешивание различных TTL
Вы можете использовать управление кэшем на 1 час и 5 минут в одном запросе, но с важным ограничением: Записи в кэш с более длительным TTL должны появляться перед более короткими TTL (т. е. запись в кэш на 1 час должна появляться перед любыми записями в кэш на 5 минут). При смешивании TTL мы определяем три места выставления счётов в вашем промпте:- Позиция
A: Количество токенов при самом высоком попадании в кэш (или 0, если нет попаданий). - Позиция
B: Количество токенов при самом высоком блокеcache_controlна 1 час послеA(или равноA, если таких нет). - Позиция
C: Количество токенов при последнем блокеcache_control.
B и/или C больше, чем A, они обязательно будут промахами в кэше, потому что A — это самое высокое попадание в кэш.- Токены чтения из кэша для
A. - Токены записи в кэш на 1 час для
(B - A). - Токены записи в кэш на 5 минут для
(C - B).
Примеры кэширования промптов
Чтобы помочь вам начать работу с кэшированием промптов, мы подготовили кулинарную книгу кэширования промптов с подробными примерами и лучшими практиками. Ниже мы включили несколько фрагментов кода, которые демонстрируют различные паттерны кэширования промптов. Эти примеры показывают, как реализовать кэширование в различных сценариях, помогая вам понять практическое применение этой функции:Пример кэширования большого контекста
Пример кэширования большого контекста
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 блоков содержимого перед вашей желаемой точкой кэша
- Вы хотите кэшировать разделы, которые обновляются с разной частотой, независимо
- Вам нужен явный контроль над тем, что кэшируется для оптимизации затрат
Добавляют ли точки разрыва кэша дополнительные затраты?
Добавляют ли точки разрыва кэша дополнительные затраты?
- Запись содержимого в кэш (на 25% больше, чем базовые входные токены для TTL 5 минут)
- Чтение из кэша (10% от базовой цены входных токенов)
- Обычные входные токены для некэшированного содержимого
Какое время жизни кэша?
Какое время жизни кэша?
Сколько точек разрыва кэша я могу использовать?
Сколько точек разрыва кэша я могу использовать?
cache_control) в вашем промпте.Доступно ли кэширование промптов для всех моделей?
Доступно ли кэширование промптов для всех моделей?
Как кэширование промптов работает с расширенным мышлением?
Как кэширование промптов работает с расширенным мышлением?
Как я включу кэширование промптов?
Как я включу кэширование промптов?
cache_control в ваш запрос API.Могу ли я использовать кэширование промптов с другими функциями API?
Могу ли я использовать кэширование промптов с другими функциями API?
Как кэширование промптов влияет на ценообразование?
Как кэширование промптов влияет на ценообразование?
Могу ли я вручную очистить кэш?
Могу ли я вручную очистить кэш?
Как я могу отследить эффективность моей стратегии кэширования?
Как я могу отследить эффективность моей стратегии кэширования?
cache_creation_input_tokens и cache_read_input_tokens в ответе API.Что может нарушить кэш?
Что может нарушить кэш?
Как кэширование промптов обрабатывает конфиденциальность и разделение данных?
Как кэширование промптов обрабатывает конфиденциальность и разделение данных?
- Ключи кэша генерируются с использованием криптографического хеша промптов до точки управления кэшем. Это означает, что только запросы с идентичными промптами могут получить доступ к определённому кэшу.
- Кэши специфичны для организации. Пользователи в одной организации могут получить доступ к одному и тому же кэшу, если они используют идентичные промпты, но кэши не делятся между различными организациями, даже для идентичных промптов.
- Механизм кэширования разработан для поддержания целостности и конфиденциальности каждого уникального разговора или контекста.
-
Безопасно использовать
cache_controlв любом месте ваших промптов. Для экономии затрат лучше исключить из кэширования высоко переменные части (например, произвольный ввод пользователя).
Могу ли я использовать кэширование промптов с Batches API?
Могу ли я использовать кэширование промптов с Batches API?
- Соберите набор запросов сообщений, которые имеют общий префикс.
- Отправьте пакетный запрос только с одним запросом, который имеет этот общий префикс и блок кэша на 1 час. Это будет записано в кэш на 1 час.
- Как только это завершится, отправьте остальные запросы. Вам придётся отслеживать задание, чтобы узнать, когда оно завершится.
Почему я вижу ошибку `AttributeError: 'Beta' object has no attribute 'prompt_caching'` в Python?
Почему я вижу ошибку `AttributeError: 'Beta' object has no attribute 'prompt_caching'` в Python?
Почему я вижу 'TypeError: Cannot read properties of undefined (reading 'messages')'?
Почему я вижу 'TypeError: Cannot read properties of undefined (reading 'messages')'?