Skip to main content
Если вы используете Claude Code, Cline, Cursor или вручную пишете собственные вызовы Claude API, кэширование промптов — самый эффективный способ снизить ваш счет — входные token из кэша тарифицируются всего по 0.1×, то есть со скидкой 90%. Эта страница основана на официальной документации Anthropic (docs.claude.com/en/docs/build-with-claude/prompt-caching) и адаптирована под настройку APIYI с примерами, готовыми к копированию и вставке.

В одном предложении

Пометьте длинный, повторно используемый префикс prompt (системные инструкции / длинный документ / few-shot примеры) с помощью cache_control. Сервер сохраняет его; при следующем запросе с тем же префиксом он пропускает повторную обработку — примерно в 10× дешевле и быстрее. Он истекает после периода неактивности.

Зачем это нужно — посмотрите на коэффициенты

Относительно базовой цены входных token у модели (): Точки безубыточности:
  • TTL 5 минут: достаточно всего 2 повторных использования одного и того же префикса, чтобы выйти в ноль (1.25 + 0.1 = 1.35, дешевле, чем 2.0 за два запроса без кэша).
  • TTL 1 час: нужно 3 повторных использования, чтобы выйти в ноль (2 + 0.2 = 2.2, дешевле, чем 3.0).
TTL — это скользящее окно: каждое попадание в кэш сбрасывает таймер истечения, поэтому активные разговоры не истекают у вас под носом. Только реальное бездействие сверх TTL приводит к вытеснению.

Хорошо подходит

  • Один и тот же длинный системный prompt вызывается много раз (агенты, чат-боты)
  • Многоходовые разговоры (каждый предыдущий ход становится повторно используемым префиксом)
  • Пакетная обработка одного документа (50 вопросов по одному контракту)
  • RAG, где стабильные извлеченные фрагменты формируют префикс

Плохо подходит

  • Каждый prompt отличается с первой же буквы
  • Все очень короткое и ни разу не превышает минимальный порог для конкретной модели (ниже)

Три жестких требования

Все три обязательны.

1. Явный маркер cache_control

content не может быть простой строкой. Это должен быть массив блоков содержимого, с cache_control, прикрепленным к блоку, который вы хотите кэшировать:

2. Длина должна превышать минимальное значение для каждой модели

Если содержимое короче минимума модели, оно не будет кэшироваться даже с маркером (ошибки не будет, просто будет пропущено без уведомления). Проверено по официальной документации Anthropic:
Английский текст в среднем составляет примерно 0.75 слова на token, поэтому для Sonnet 4.6 нужно около 1,500+ слов стабильного содержимого, чтобы кэширование имело смысл. Всегда обращайтесь к официальной документации Anthropic за актуальными порогами — они могут меняться между версиями модели.

3. Префикс должен совпадать побайтно

Кэширование основано на префиксе: от начала запроса до маркера cache_control поток байтов должен быть идентичным предыдущему запросу. Любое изменение одного символа — пробельные символы, порядок ключей JSON, временная метка — считается новым префиксом и создает новую запись вместо попадания в кэш. Практическое правило: стабильные данные — в начале, изменчивые — в конце.

Минимальный рабочий пример

Отправьте два запроса, используя один и тот же длинный документ, но разные вопросы. Первый записывает, второй попадает в кэш:
Ожидаемый вывод:
Во втором вызове read ≈ в первом вызове write — тот же префикс используется повторно.

Как определить, было ли попадание в кэш — три поля usage

В каждом ответе, usage сообщает: Итого входные tokens = сумма всех трех. Пока cache_read_input_tokens > 0, вы экономите деньги.

Самые распространенные подводные камни

Кэширование промптов работает только с нативным форматом Anthropic (/v1/messages). Когда вы вызываете Claude через формат, совместимый с OpenAI (/v1/chat/completions), поля кэша не вернутся независимо от того, что вы отправляете. Для Claude Code, Cline, Cursor и подобных клиентов с высокой частотой запросов нативный формат обязателен, если вы хотите контролировать свой счет.

Продвинутое: многоходовые диалоги

Разместите cache_control на последнем блоке контента последнего сообщения пользователя. Каждый новый ход автоматически расширяет кэшированный диапазон чтения до конца предыдущего хода:
Два жёстких ограничения, о которых следует помнить:
  • Не более 4 cache_control точек разрыва на запрос.
  • Окно поиска префикса у каждой точки разрыва — не более 20 блоков контента назад; все, что старше, не будет учитываться при попадании в кэш. Иными словами, в очень длинных диалогах отметка только последнего хода не покроет всю предыдущую историю.
Распространенный шаблон: размещайте по одной точке разрыва на определениях инструментов, system prompt, длинных документах и последнем ходе диалога — используя все 4 слота, чтобы разделы, изменяющиеся с разной скоростью, не делали кэш друг друга недействительным.

Об APIYI и кэшировании

APIYI передает поля кэша сквозным образом. cache_control, который вы отправляете, без изменений передается во upstream Claude (AWS Claude или Claude Official), а возвращаемые cache_creation_input_tokens / cache_read_input_tokens напрямую возвращаются вам — в вашем коде не требуется никакой специальной адаптации.
Как проверить самостоятельно:
  1. При первом запросе, usage.cache_creation_input_tokens > 0 (запись выполнена).
  2. Через несколько секунд отправьте тот же префикс еще раз — вы должны увидеть usage.cache_read_input_tokens > 0 (попадание).
  3. На панели тарификации будут отдельно указаны cache writes и cache reads с теми же официальными коэффициентами (1.25× / 2× / 0.1×).

Краткое повторение

1. Пометьте это

cache_control: {"type": "ephemeral"} на блоке контента — обычная строка content никогда не кэшируется.

2. Достаточно длинно

Sonnet 4.6 ≥ 2,048 tokens; Opus 4.x / Haiku 4.5 ≥ 4,096 tokens, иначе пропускается без предупреждения.

3. Стабильный префикс

Стабильное в начале, изменчивое в конце; один символ расхождения убивает попадание в кэш.

4. Проверьте использование

Только cache_read_input_tokens > 0 доказывает, что вы действительно сэкономили.

Связанные ссылки