# Кэширование промптов Anthropic: как проверить попадания и понять, экономит ли оно > Кэширование промптов Anthropic может снизить затраты на ввод, когда стабильный префикс используется повторно, но записи в кэш стоят дороже обычного ввода. Вот как включить кэширование промптов Claude, проверить попадания и рассчитать точку безубыточности. Кэширование промптов Anthropic легко включить — и легко истолковать неверно. Первый запрос может обойтись дороже, последующий запрос может промахнуться мимо кэша без ошибки, а «кэшированный» префикс может оказаться слишком коротким, чтобы пройти порог. **Короткий ответ:** поставьте точку останова кэша в конце контента, который остаётся неизменным между запросами, затем убедитесь, что последующий ответ сообщает `cache_read_input_tokens` больше нуля, используя [поля usage в ответе Anthropic](https://platform.claude.com/docs/en/build-with-claude/prompt-caching). Оцените стоимость первой записи в кэш и каждого чтения относительно ожидаемого числа переиспользований: на Claude Sonnet 5.5 одно чтение в пределах пятиминутного окна окупает надбавку за запись; часовому кэшу нужно два чтения. Эти цифры API не говорят о том, как учитываются лимиты подписки Claude. Цены и сведения о продуктах ниже проверены 4 октября 2026 года. ## Как работает кэширование промптов Anthropic и как его включить? Кэширование промптов Claude переиспользует совпадающий префикс промпта, чтобы модель могла прочитать закэшированный ввод вместо того, чтобы снова обрабатывать его как новый. Для первого теста API используйте автоматическое кэширование: добавьте поле верхнего уровня `cache_control` в запрос Messages. В существующий Python-вызов Anthropic Messages API добавьте этот аргумент запроса (вставьте его в `client.messages.create(...)`): ```python cache_control={"type": "ephemeral"} ``` Эта настройка cache control верхнего уровня Anthropic взята из [документации по кэшированию промптов](https://platform.claude.com/docs/en/build-with-claude/prompt-caching). Текущие примеры используют `client.messages.create(...)`; старый путь `client.beta.prompt_caching.messages.create(...)` больше не требуется. Для статического документа или набора инструментов явная точка останова на уровне блока позволяет точно контролировать, где заканчивается переиспользуемый префикс. Anthropic допускает до четырёх точек останова. Чтобы проверить попадание, сделайте два запроса с той же моделью и неизменным префиксом, причём второй запрос должен начаться до истечения срока кэша. Прочитайте объект `usage` в ответе: | Поле | Что оно сообщает | | ----------------------------- | ---------------------------------------------------- | | `cache_creation_input_tokens` | Токены ввода, записанные в кэш в этом ответе | | `cache_read_input_tokens` | Токены ввода, выданные из кэша | | `input_tokens` | Незакэшированный ввод после последней точки останова | Первый запрос должен показать создание кэша. Последующий запрос должен показать чтения из кэша; при автоматическом кэшировании новый «хвост» также может быть записан. Anthropic определяет общий ввод как сумму этих трёх полей, поэтому не используйте `input_tokens` отдельно как общий размер промпта. Если оба счётчика кэша равны нулю, промпт не был закэширован. Ответ API об использовании подтверждает поведение на уровне запроса, которое вы наблюдали; он не устанавливает долю попаданий для всей вашей рабочей нагрузки в продакшене. ## Какой кэш использовать: пятиминутный или часовой? Используйте пятиминутный кэш, когда вызовы переиспользуют один и тот же префикс в пределах пяти минут. Выбирайте часовой вариант, когда реальные промежутки регулярно превышают это окно, но укладываются в час. Anthropic запускает отсчёт TTL в момент начала запроса, а не окончания его ответа; четырёхминутный стрим оставляет примерно одну минуту на прибытие следующего запроса. Точка безубыточности зависит от числа успешных чтений, а не от того, есть ли у промпта просто точка останова. Для простого сравнения возьмём один фиксированный префикс на 100,000 токенов на Claude Sonnet 5.5. Текущая [таблица цен Anthropic](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) указывает $2 за миллион обычных токенов ввода, $2.50 за миллион записей в пятиминутный кэш, $4 за миллион записей в часовой кэш и $0.20 за миллион чтений. Чтение стоит 0.1× от базового ввода для этой модели. При `R` чтениях из кэша закэшированный префикс стоит `write rate + (R × read rate)`. Без кэширования он стоит `base rate × (1 + R)`. Это даёт следующие итоги только для префикса; вывод и меняющиеся «хвосты» запросов исключены: | Чтений после первой записи, в пределах TTL | Без кэша | 5-минутный кэш | Часовой кэш | | -----------------------------------------: | -------: | -------------: | ------------: | | 0 | $0.20 | $0.25 (125%) | $0.40 (200%) | | 1 | $0.40 | $0.27 (67.5%) | $0.42 (105%) | | 2 | $0.60 | $0.29 (48.3%) | $0.44 (73.3%) | | 4 | $1.00 | $0.33 (33%) | $0.48 (48%) | | 10 | $2.20 | $0.45 (20.5%) | $0.60 (27.3%) | Проценты — это стоимость с кэшем, делённая на стоимость без кэша. На этой модели и при этих допущениях пятиминутное кэширование дешевле после одного чтения; часовое кэширование становится дешевле после двух. Первая запись в часовой кэш стоит вдвое дороже обычного тарифа ввода, поэтому увеличение TTL автоматически не означает экономию. Текущие множители стоимости чтения из кэша у Anthropic различаются для некоторых моделей — 5% для Opus 5.5 и 2.5% для Fable 5.1 и Mythos 5.1, — поэтому пересчитывайте по строке той модели, которую вы действительно вызываете. Цены проверены в октябре 2026 года. [Пост Роя Деркса в LinkedIn](https://www.linkedin.com/posts/gethackteam_prompt-caching-can-make-your-llm-api-bill-activity-7494319569314967552-RBjc) разбирает гипотетический сценарий, который объясняет жалобы «кэширование подняло мне счёт»: агент запускается каждые 10 минут с переиспользуемым промптом на 100,000 токенов, поэтому каждый из его десяти вызовов приходит после того, как пятиминутная запись истекла. Каждый вызов платит запись по 1.25× и ни один не получает чтение по 0.1×, так что $10 некэшированного ввода превращаются в $12.50 — на 25% больше. Это разобранный сценарий, а не измеренная рабочая нагрузка. Сравните собственные счётчики использования и интервалы вызовов, прежде чем строить на нём прогнозы. ## Почему мой кэш не получает попаданий? Попадание в кэш требует того же префикса вплоть до отмеченной точки останова и достаточной длины промпта. | Что вы видите | Вероятная причина | Исправление | | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Оба счётчика кэша остаются нулевыми | Отмеченный префикс короче минимума модели. Для Claude Sonnet 5.5 [текущий минимум — 512 токенов](https://platform.claude.com/docs/en/build-with-claude/prompt-caching); более короткие запросы выполняются без ошибки кэша. | Включите достаточно стабильного контента, чтобы превысить минимум модели, затем проверьте usage следующего ответа. | | Полная или большая перезапись следует за небольшим изменением запроса | Изменённые байты находятся до точки останова. [Таблица инвалидации Anthropic](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) охватывает правки определений инструментов, переключателей веб-поиска, цитирования и скорости, `tool_choice`, изображений и настроек thinking; изменения определений инструментов инвалидируют весь кэш. | Держите стабильные инструкции и определения инструментов в начале; перенесите метки времени, значения для каждого запроса и новый ввод пользователя после точки останова статического префикса. | | Меняющийся последний блок записывается заново при каждом вызове | [Автоматическое кэширование](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) перемещает точку останова на последний кэшируемый блок; если этот блок меняется, переиспользуемой записи на стабильной более ранней границе нет. | Поставьте явную точку останова на последнем блоке, который остаётся неизменным. | | Промежуток неожиданно вызывает запись | [Срок жизни кэша](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) истёк, или долгий ответ израсходовал большую часть TTL до начала следующего запроса. | Измеряйте интервалы между началами запросов; используйте `ttl: "1h"`, если ваше ожидаемое окно переиспользования этого требует и дополнительная плата за запись окупается. | | Инструменты или сообщения выглядят идентично, но чтения падают | Порядок или сериализация изменили префикс. [Руководство Anthropic по устранению неполадок](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) предупреждает, что нестабильный порядок ключей JSON внутри блоков `tool_use` может нарушить переиспользование. | Держите порядок инструментов и сообщений стабильным и сериализуйте структурированные значения детерминированно. | Префикс запроса упорядочен как `tools`, затем `system`, затем `messages`. Изменение в начале этой последовательности инвалидирует последующий закэшированный контент. Точка останова — это граница, на которой Anthropic записывает запись; она не ищет назад и не создаёт отсутствующую запись кэша для более раннего стабильного блока. Её поиск в прошлом может найти только записи, которые предыдущие запросы уже записали. См. [руководство Anthropic по инвалидации и точкам останова](https://platform.claude.com/docs/en/build-with-claude/prompt-caching), когда поля usage показывают промах, который вы не можете объяснить. ## Как работает кэширование промптов в Claude Code? Claude Code управляет кэшированием промптов автоматически. Вам не нужно добавлять `cache_control` в обычную сессию Claude Code. Его слои запроса размещают системный промпт и контекст проекта перед растущим разговором, поэтому изменение более раннего слоя может инвалидировать всё, что идёт после него. TTL зависит от аутентификации: текущее [руководство по кэшированию промптов Claude Code](https://code.claude.com/docs/en/prompt-caching) указывает один час для основного разговора по подписке, но пять минут для API-ключей и облачных провайдеров по умолчанию. Claude Code v2.1.242 и новее поддерживает настройки TTL для каждого «ведра». Чтобы запросить один час для обоих вёдер с помощью документированной переменной окружения, установите `ENABLE_PROMPT_CACHING_1H=1`; отдельные настройки или переменные окружения могут иметь приоритет, поэтому проверьте список приоритетов в руководстве, прежде чем предполагать, какой TTL применился. Для сводки по сессии выполните `/usage`. Блок Session в Claude Code сообщает долю попаданий в кэш и число промахов основного разговора после его первого ответа. Для доказательств на уровне запроса руководство документирует `cache_creation_input_tokens` и `cache_read_input_tokens`; на v2.1.251 и новее данные его status-line предоставляют объект `prompt_cache`. Эти счётчики полезнее, чем вывод о промахе только по долгой паузе. Отображение `Prompt cache (main)` в Claude Code может включать вероятную причину, но транскрипт одной сессии — не универсальный диагноз. Например, [issue по Anthropic Claude Code](https://github.com/anthropics/claude-code/issues/94728) сообщает о двух измеренных возобновлениях фонового подагента на v2.1.273, оба диагностированы как `messages_changed`, с записями в кэш на 243,214 и 398,622 токена. Относитесь к этому как к отчёту, специфичному для версии и сценария; используйте собственные данные об использовании и текущие примечания к релизу, прежде чем приписывать изменение счёта общему дефекту продукта. ## Что меняется для кэширования промптов на Amazon Bedrock и OpenRouter? Кэширование промптов Bedrock и кэширование промптов OpenRouter следуют тому же принципу — переиспользовать подходящий стабильный префикс, — но поверхность API и поведение маршрутизации различаются у разных провайдеров. | Путь | Что отличается | Практическая проверка | | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Anthropic API | Добавьте автоматический `cache_control` верхнего уровня или разместите явные точки останова на уровне блоков. Текущая документация указывает до четырёх точек останова и минимальную длину в токенах для каждой модели. | Читайте `usage.cache_creation_input_tokens` и `usage.cache_read_input_tokens` Anthropic. | | Amazon Bedrock | [AWS документирует как неявное, так и явное кэширование промптов](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html). Поддержка, минимум токенов, TTL и поля API различаются по моделям. Для явного кэширования Claude AWS предлагает упрощённую единственную контрольную точку в конце статического контента и проверяет назад примерно 20 блоков контента; точный синтаксис контрольной точки и запроса зависит от `InvokeModel` против `Converse`. | Проверьте карточку модели Bedrock для конкретной модели и региона, затем изучите поля usage в ответе провайдера. Не копируйте вслепую payload Anthropic API. | | OpenRouter | [Руководство OpenRouter](https://openrouter.ai/docs/guides/best-practices/prompt-caching) документирует автоматическое кэширование верхнего уровня и явные маркеры для каждого блока. Оно может использовать sticky-маршрутизацию провайдера после закэшированного запроса, чтобы отправлять последующие вызовы на тот же эндпоинт; ручной порядок провайдеров имеет приоритет. Его Responses API предоставляет автоматическое кэширование, тогда как поблочные элементы управления в стиле Anthropic там не представлены. | Держите стабильную сессию или начальные сообщения и проверяйте, какой провайдер обслужил каждый запрос; изменения маршрута могут повлиять на переиспользование. | На Bedrock [текущее платформенное руководство Anthropic](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) говорит, что устаревшие интеграции Bedrock для Opus 4.6 и более ранних отклоняют автоматическое поле верхнего уровня; явные точки останова — документированный путь там. [Текущая страница AWS](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html) определяет поддержку, минимумы и TTL для каждой модели. Следуйте странице для вашей конкретной модели, а не переносите то старое правило интеграции на каждую модель Claude на Bedrock. Если вы строите слой провайдеров, держите свежий ввод, чтения из кэша и записи в кэш как отдельные значения использования. В Muvon мы разрабатываем Octolib; его адаптер Anthropic отображает поля API `cache_read_input_tokens` и ephemeral-записи раздельно, чтобы итог на уровне шлюза не скрывал различие. Наши заметки об [использовании токенов LLM и едином слое провайдеров](/blog/lessons-building-a-unified-llm-provider-layer-in-rust) объясняют более широкую проблему учёта. Для видимости на уровне прокси см. [LLM-прокси OctoHub](/blog/introducing-octohub-llm-proxy-for-observability); о компромиссах стоимости маршрутизации моделей см. [наше руководство по маршрутизации LLM](/blog/running-one-ai-agent-across-many-models). Теперь вы можете включить кэширование, сделать два запроса, проверить поле чтения и сравнить измеренный ритм переиспользования с датированной таблицей цен. Если эти четыре проверки не сходятся, перестаньте оптимизировать оценочный счёт и сначала изучите префикс и маршрут провайдера. — Don --- _В Muvon мы разрабатываем Octolib и держим чтения и записи кэша видимыми как отдельные поля использования. Если вы найдёте ответ провайдера, из-за которого эти числа трудно свести, [откройте issue](https://github.com/Muvon/octolib/issues)._