Skip to main content
Если вы используете Claude Code, Cline, Cursor или самостоятельно пишете собственные вызовы Claude API, кэширование промптов — самый важный рычаг для снижения тарификации — кэшированные input tokens тарифицируются всего по 0.1×, со скидкой 90%. Эта страница основана на официальной документации Anthropic (platform.claude.com/docs/en/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:
Этот порог не уменьшается монотонно с увеличением номера версии — не пытайтесь угадать его. Самые неочевидные пары: Opus 5 требуется всего 512, тогда как более старым Opus 4.6 / 4.5 требуется 4,096 — разница в 8 раз. Для Haiku 4.5 также требуется 4,096, что больше, чем для более старой Haiku 3.5 (2,048). Поэтому не работают ни правило «у более новых моделей пороги ниже», ни правило «у меньших моделей пороги ниже». Проверяйте таблицу при каждой смене модели.
В английском тексте в среднем примерно 0,75 слова на один token. На практике: для Opus 5 кэширование начинается примерно со 380+ слов стабильного содержимого, для Sonnet 5 / Sonnet 4.6 требуется около 770 слов, а для Opus 4.6 / Haiku 4.5 — примерно 3 000 слов, прежде чем кэширование начнёт работать. Всегда сверяйтесь с официальной документацией Anthropic, чтобы узнать актуальные пороги — они могут меняться между версиями моделей.
Измерено в APIYI (2026-07-29). Мы проверили порог записи, постепенно увеличивая размер фиксированного префикса: claude-opus-5 не вызвало записи в кэш при 301 token, но вызвало её при 614, что ограничивает официальный порог 512; claude-sonnet-5 не вызвало записи при 612, но вызвало её при 1 250, что ограничивает официальный порог 1 024. Оба результата соответствуют приведённой выше таблице.

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

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

Минимальный запускаемый пример

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

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

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

Наиболее распространённые ошибки

Резервный сценарий безопасности в семействе Fable нарушает работу кэша. claude-fable-5 / claude-fable-5-1 поставляются со встроенными классификаторами безопасности. Когда запрос содержит контент высокого риска, модель либо отказывает (HTTP 200 с stop_reason: "refusal"), либо переключается на семейство Opus, а поле верхнего уровня model в ответе точно отражает модель, которая фактически ответила. Это нормальное поведение на стороне модели, а не проблема шлюза.Влияние на кэширование: резервный сценарий меняет модель и, следовательно, ключ кэша, поэтому этот ход не может прочитать то, что записали предыдущие ходы; попадания возобновляются, когда следующий ход снова выполняется на Fable. Отклонённый ход всё ещё может сообщать cache_creation_input_tokens, но эта запись никогда не будет прочитана позднее. В многоходовых сессиях агента это проявляется как изолированные ходы, в которых read падает до 0, а write снова резко возрастает.Что делать: проверяйте в ответе model и stop_reason, прежде чем судить о промахе только по usage; скорректируйте отклонённый ввод перед повторной отправкой вместо дословного повтора; минимизировать такие промахи помогает соблюдение политик в содержимом диалога. Подробности об отказах, резервном сценарии и тарификации приведены в примечаниях к запуску Fable 5.1.
Prompt Cache работает только с нативным форматом 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"} на блоке контента — plain-string content никогда не кэшируется.

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

Opus 5 ≥ 512; Sonnet 5 / Sonnet 4.6 ≥ 1,024; Opus 4.7 ≥ 2,048; Opus 4.6 / Haiku 4.5 ≥ 4,096 tokens, иначе пропускается без уведомления.

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

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

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

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

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

  • Родительская страница: Claude API Basics
  • Руководства по настройке клиента: Claude Code integration · Cherry Studio integration
  • Получение / управление token: https://api.apiyi.com/token
  • Официальная документация Anthropic: platform.claude.com/docs/en/build-with-claude/prompt-caching