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

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

Как учитывается кэш и какие параметры поддерживает выбранная модель.

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

Кэширование и его биллинг учитываются с серверным промптом и без него. У Claude подтверждённое чтение из кэша стоит в 10 раз дешевле обычного входа, у Opus 5.5 — в 20 раз дешевле, у Fable 5.1 — в 40 раз дешевле. Токены применённого серверного промпта оплачиваются по полной ставке input или cache read. Попадание в кэш не гарантируется.

МодельОбычный input / 1MЗапись 5m / 1MЗапись 1h / 1MЧтение / 1M
claude-haiku-5-5$0.10 (свыше 100K: $0.50)$0.125 (свыше 100K: $0.625)$0.20 (свыше 100K: $1.00)$0.01 (свыше 100K: $0.05)
claude-haiku-4-5$1.00$1.25$2.00$0.10
claude-sonnet-5-5$2.00$2.50$4.00$0.20
claude-sonnet-5$3.00$3.75$6.00$0.30
claude-opus-5-5$4.00$5.00$8.00$0.20
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×, для Opus 5.5 — по 0.05×, а для Fable 5.1 — по 0.025×. Тариф Fable 5 и исторические списания сохраняются. Поэтому прогрев может быть дороже обычного входа, а экономия появляется на повторных совпадающих запросах. У Haiku 5.5 запрос, весь вход которого — обычный, чтение и запись кэша — длиннее 100 000 токенов, оплачивается по ставкам «свыше 100K» из таблицы, в 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.

Кэш Codex

Codex использует автоматический кэш подписки. Учтённые чтение и запись приходят в фактическом usage и рассчитываются по ставкам запрошенной модели; обычный input не включает эти токены второй раз.

Кэш GLM

GLM возвращает фактическое чтение кэша в полях usage. Guard нормализует три разные формы и применяет отдельную низкую ставку только к реально отмеченным кэшированным токенам.

APIОбщий вводКэшЧто считать обычным вводом
Messagesusage.input_tokensusage.cache_read_input_tokensinput_tokens уже не включает cache read
Chatusage.prompt_tokensusage.prompt_tokens_details.cached_tokensprompt_tokens - cached_tokens
Responsesusage.input_tokensusage.input_tokens_details.cached_tokensinput_tokens - cached_tokens

Для glm-5.3 4000 обычных и 8000 кэшированных входных токенов стоят $0.00560000 + $0.00208000. Выход считается отдельно по $4.40 / 1M.

Кэш Gemini

Кэш Gemini только автоматический: его ведёт Google. Маркеры cache_control принимаются, но срок хранения кэша не обещается. Скидка действует только на токены, которые Google фактически прочитал из кэша: чтение оплачивается по ставке из таблицы тарифов на странице Биллинг, за запись в кэш отдельной платы нет. У gemini-4-argon чтение кэша стоит $0.10 за 1M токенов (с 03:00 МСК 1 декабря 2026 — $0.20), у gemini-3.8-flash — $0.075 (с 03:00 МСК 1 января 2027 — $0.15).

Кэш Muse

Запись в кэш Muse отдельной платы не требует, а длинный контекст оплачивается без надбавки. Чтение кэша: muse-wonder-1.0 — $0.20, muse-spark-1.3 и muse-spark-1.2 — $0.15 за 1M токенов.

Разделы

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