Перейти к содержанию
Оплата и расходКэширование промптов

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

Автоматический кэш, явные маркеры Claude и порядок применения скидки.

Протокол модели

Кэширование и его биллинг учитываются с серверным промптом и без него. У Claude подтверждённое чтение из кэша стоит в 10 раз дешевле обычного входа, у Fable 5.1 — в 40 раз дешевле. Скидка 25%, когда применима, добавляется после расчёта стоимости кэша. Попадание в кэш не гарантируется.

МодельОбычный input / 1MЗапись 5m / 1MЗапись 1h / 1MЧтение / 1M
claude-haiku-4-5$1.00$1.25$2.00$0.10
claude-sonnet-5$3.00$3.75$6.00$0.30
claude-opus-5$5.00$6.25$10.00$0.50
claude-opus-4-8$5.00$6.25$10.00$0.50
claude-fable-5 (без серверного промпта)$10.00$12.50$20.00$1.00
claude-fable-5-1 (без серверного промпта)$10.00$12.50$20.00$0.25

Обычный некэшированный input стоит 1×. Запись в кэш на стандартные 5 минут биллится по 1.25× input, явная запись на 1 час — по 2×, последующее чтение из кэша — по 0.1×, а для Fable 5.1 — по 0.025×. Тариф Fable 5 и исторические списания сохраняются. Поэтому прогрев может быть дороже обычного входа, а экономия появляется на повторных совпадающих запросах.

Как возникает попадание

  • Кэшируется стабильный префикс запроса: определения инструментов, системный текст и начало истории сообщений.
  • Попадание — когда это начало байт-в-байт совпало с недавним запросом. Изменение даже первого символа сбрасывает совпадение целиком.
  • Кэш живёт считанные минуты и продлевается при каждом обращении.
  • Первый достаточно большой cacheable-запрос новой сессии обычно «прогревает» кэш — попадание возможно со второго. Хит не гарантирован каждому запросу — это нормально.

Как получить максимум

  1. Стабильное начало. System-промпт и инструкции одинаковы между запросами — без правок «на лету».
  2. Никаких переменных в начале. Таймстампы, случайные id, имя пользователя — только в конец промпта: изменённый первый байт убивает совпадение всего префикса.
  3. Диалог — только добавлением. Новые сообщения дописывайте в конец истории; не редактируйте и не перемешивайте старые.
  4. Стабильные tools. Один и тот же набор и порядок функций в каждом запросе — определения инструментов тоже часть префикса.
  5. Большие документы — один раз в system. Базу знаний и код кладите в начало, меняющиеся вопросы — в конец.
  6. Держите темп. Продолжение в течение нескольких минут попадает в кэш; после долгой паузы первый запрос прогреет его заново.

Явный cache_control в Messages

В Claude /v1/messages и /v1/messages/count_tokens поддерживается cache_control: автоматическое кэширование верхнего уровня и явные маркеры в допустимых блоках system/content и определениях клиентских функций. Без ttl используется 5 минут; для часа — "ttl": "1h". В usage.cache_creation разделены записи 5m/1h.

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

  • Полоса «Кэш промптов» на дашборде — сколько сэкономлено за всё время.
  • Колонка «кэш» в логе «Последние запросы» — попадание по каждому запросу.
  • В ответе API: usage.cache_read_input_tokens (Anthropic) или usage.prompt_tokens_details.cached_tokens (OpenAI).
json
{
  "usage": {
    "input_tokens": 9900,
    "cache_read_input_tokens": 27451,
    "output_tokens": 56
  }
}
ДашбордПолоса «Кэш промптов» — ваша экономия уже считаетсяБиллингСтавки и формула списания

Kimi, Composer и Grok

  • Kimi. Чтение из кэша тарифицируется отдельной пониженной ставкой; живые ставки и разбор расхода на странице Kimi · Цены, reserve и usage. Поле prompt_cache_key принимается и уходит модели как есть.
  • Composer и Grok. Маркер cache_control внутри блока принимается и игнорируется; управлять кэшем им нельзя. Кэш автоматический. Учтённое чтение возвращается в usage.cache_read_input_tokens Messages и usage.prompt_tokens_details.cached_tokens Chat Completions.
  • Запись в кэш у Composer и Grok бесплатна. Это не округление и не неизвестная величина: ставка за создание кэша нулевая, поэтому cache_creation_input_tokens в ответе всегда 0.

Разделы документации

На этой странице