Prompt caching: как срезать стоимость LLM в разы
Что такое prompt caching?
Prompt caching (кэширование промптов) - механизм API, при котором провайдер сохраняет уже обработанную начальную часть запроса (префикс: tools, system prompt, документы) и при совпадении префикса в следующем запросе берёт её из кэша. Эти input-токены тарифицируются со скидкой (у Claude Opus 5.5 и Sonnet 5.5 чтение стоит 5% от базовой цены), а обработка ускоряется. Кэш срабатывает только при точном совпадении префикса и живёт ограниченное время.
TL;DR
- -Кэшируется префикс запроса, а не ответ модели: любое изменение до точки кэширования обнуляет попадание, поэтому статичное идёт в начало запроса, переменное в конец.
- -У Claude Opus 5.5 и Sonnet 5.5 чтение из кэша стоит 5% от цены input, у Haiku 5.5 10%; запись стоит 1,25x (5 минут) или 2x (1 час). В замере автора на Haiku 5.5 второй запрос с кэшем на 12,6K токенов обошёлся в 12 раз дешевле первого.
- -Пятиминутный кэш окупается со второго обращения в пределах TTL, часовой с третьего; промпт, который отправляется один раз, с кэшем стоит на 25% дороже обычного.
- -OpenAI начиная с GPT-5.6 кэширует автоматически, но запись стоит 1,25x (30 минут) или 2,5x (12 часов); у Gemini по умолчанию работает implicit-кэш без гарантии попадания; у DeepSeek кэш на диске включён всегда и работает по принципу best-effort.
- -Работу кэша проверяют по полям usage (cache_read_input_tokens, cached_tokens). Частые причины промаха: время или ID в начале system prompt, изменённые tools, префикс короче минимума, пауза дольше TTL.
Prompt caching (кэширование промптов) - это механизм API, при котором провайдер сохраняет уже обработанную начальную часть запроса и при совпадении этого префикса в следующем запросе берёт её из кэша. Такие input-токены стоят дешевле: у Claude Opus 5.5 и Sonnet 5.5 чтение из кэша стоит 5% от базовой цены, у Haiku 5.5 10%. Кэш срабатывает только при точном совпадении префикса и живёт ограниченное время, от минут до часов.
В запросах к LLM API много повторов: одинаковый system prompt, описания инструментов, справочный документ, история диалога, которая растёт с каждым ходом. Без кэша каждый запрос оплачивает этот префикс по полной цене. В замере автора на Haiku 5.5 вход десятого хода диалога оказался в 57 раз больше первого, потому что вся история отправляется заново; почему так происходит, разобрано в статье про контекстное окно.
Статья о том, как устроен кэш префикса у Anthropic, OpenAI, Google Gemini и DeepSeek, сколько он стоит и с какого запроса окупается, и почему кэш часто молча не срабатывает. Цены и параметры приведены по документации вендоров на 8 ноября 2026 года. Замеры автора сделаны 7 и 8 ноября 2026 года через OpenRouter, а не напрямую в API вендоров.
Что кэшируется и почему важен порядок
Префикс запроса, а не ответ
Модель обрабатывает входные токены по порядку и для каждого вычисляет промежуточное состояние (KV-кэш). Если начало нового запроса побайтно совпадает с началом прошлого, это состояние можно не пересчитывать. Провайдер хранит его у себя и при попадании списывает за эти токены сниженную цену.
Кэшируется только вход. Ответ генерируется заново: OpenAI и DeepSeek пишут об этом прямо, у DeepSeek температура по-прежнему даёт разные ответы на одинаковый запрос. Поэтому кэш не влияет на качество ответа, он меняет цену и время обработки входа.
Совпадение нужно полное. В документации Anthropic это сформулировано так: попадание требует «100 percent identical prompt segments», включая весь текст и изображения до блока с cache_control включительно. Одна изменённая строка в начале запроса делает весь последующий текст новым префиксом.
Порядок: tools → system → messages
У Anthropic запрос кэшируется иерархически: сначала tools, затем system, затем messages. Изменение на одном уровне сбрасывает кэш этого уровня и всех следующих. Отсюда главное правило для всех вендоров: статичное в начало, переменное в конец.
| Часть запроса | Как часто меняется | Где держать |
|---|---|---|
| Описания tools | Редко, при релизе | В самом начале |
| System prompt, инструкции | Редко | После tools |
| Справочные документы, база знаний | Иногда | После system |
| История диалога | Растёт каждый ход | После документов |
| Текущий вопрос, время, ID запроса | Каждый запрос | В самом конце |
Подробнее о порядке блоков в промпте написано в статье как писать промпты. Если нужно понять, как текст превращается в оплачиваемые токены, см. токены в нейросетях.
Prompt caching и semantic cache
Это разные вещи. Semantic cache хранит готовые ответы и возвращает их на похожие вопросы, сравнивая эмбеддинги запросов; модель в этом случае не вызывается. Prompt caching работает на стороне провайдера, ответ всегда новый. Semantic cache и другие способы снизить расходы разобраны в статье про оптимизацию LLM-расходов.
Кэширование промптов: сводная таблица по вендорам
Множители указаны относительно обычной цены input-токена модели. Источники: документация Anthropic, OpenAI, Google, DeepSeek и их прайсы на 8 ноября 2026 года.
| Вендор и модель | Как включить | Чтение | Запись | TTL | Минимум, токенов |
|---|---|---|---|---|---|
| Anthropic Opus 5.5, Sonnet 5.5 | cache_control на верхнем уровне или на блоках (до 4) | 0,05x | 1,25x (5 мин), 2x (1 ч) | 5 мин или 1 ч, чтение продлевает | 512 |
| Anthropic Haiku 5.5 | то же | 0,1x | 1,25x / 2x | то же | 512 |
| Anthropic Fable 5.1 | то же | 0,025x | 1,25x / 2x | то же | 512 |
| OpenAI GPT-5.6 | автоматически; явно prompt_cache_breakpoint | 0,1x | 1,25x (30 мин), 2,5x (12 ч) | 30 мин или 12 ч | 1 024 |
| OpenAI GPT-6.1 Sol, Terra | то же | 0,05x | то же | то же | 1 024 |
| Google Gemini 3.8 Flash | implicit по умолчанию; explicit через caches.create | 0,1x | implicit: без надбавки; explicit: плата за хранение | explicit 1 ч по умолчанию; implicit не публикуется | 4 096 (implicit) |
| DeepSeek V4.1 Flash | всегда включён, кэш на диске | 0,02x | без надбавки | фиксированного нет | не указан |
В сводной таблице OpenRouter доли чтения для OpenAI, Gemini и DeepSeek указаны иначе (например, 0,25x или 0,5x для OpenAI). В таблице выше цифры взяты из первичных прайсов вендоров.
Цены в долларах за 1M токенов на 8 ноября 2026 года:
| Модель | Input | Запись | Чтение |
|---|---|---|---|
| Claude Opus 5.5 | $4 | $5 (5 мин) / $8 (1 ч) | $0,20 |
| Claude Sonnet 5.5 | $2 | $2,50 / $4 | $0,10 |
| Claude Haiku 5.5 (промпт до 100K) | $0,10 | $0,125 / $0,20 | $0,01 |
| Claude Fable 5.1 | $10 | $12,50 / $20 | $0,25 |
| GPT-6.1 Terra | $1,00 | $1,25 (30 мин) | $0,05 |
| GPT-6.1 Sol | $2,00 | $2,50 (30 мин) | $0,10 |
| Gemini 3.8 Flash (до 31.12.2026) | $0,75 | хранение explicit $0,50 за 1M токенов в час | $0,075 |
| DeepSeek V4.1 Flash (вне пика) | $0,15 | без надбавки | $0,003 |
Цены Gemini 3.8 Flash акционные: по прайсу Google с 1 января 2027 года они вдвое выше ($1,50 / $0,15 / $1,00). У DeepSeek в часы пика цены вдвое выше, чем вне пика.
Anthropic: cache_control
Без cache_control Claude API ничего не кэширует. Подробный справочник по Claude API, включая таблицу минимумов у старых моделей, есть в гайде для разработчиков. Здесь только то, что влияет на цену и на диагностику промахов.
Автоматический режим и явные точки кэширования
Есть два способа включить кэш. Автоматический: одно поле cache_control на верхнем уровне запроса. API ставит точку кэширования на последний кэшируемый блок и сдвигает её по мере роста диалога. Явный: cache_control на конкретных блоках, до 4 точек на запрос. Если использовать оба способа сразу, автоматическая точка занимает один из 4 слотов.
Пример с явной точкой на большом system prompt:
import anthropic
client = anthropic.Anthropic()
spec = open("spec.md").read() # стабильный большой контекст
def ask(question: str):
r = client.messages.create(
model="claude-sonnet-5-5",
max_tokens=512,
system=[{"type": "text", "text": spec,
"cache_control": {"type": "ephemeral"}}], # "ttl": "1h" для часа
messages=[{"role": "user", "content": question}],
)
u = r.usage
print(u.cache_creation_input_tokens, u.cache_read_input_tokens, u.input_tokens)
ask("Какие требования к безопасности?") # запись
ask("Какие требования к логированию?") # чтение
Автоматический режим в примере из документации выглядит как client.messages.create(..., cache_control={"type": "ephemeral"}, ...) без разметки блоков.
5 минут или 1 час
По умолчанию кэш живёт 5 минут, запись стоит 1,25x от цены input. Вариант "ttl": "1h" живёт час, запись стоит 2x. Чтение в обоих случаях бесплатно продлевает срок жизни. Отсчёт идёт с начала запроса, время генерации ответа входит в TTL. Если в одном запросе есть записи с обоими сроками, часовые должны стоять раньше пятиминутных.
Часовой кэш нужен, когда паузы между обращениями к одному префиксу длиннее 5 минут: агент ждёт пользователя, задача запускается по расписанию. Окупается он с третьего обращения, а на двух может выйти дороже, чем вообще без кэша.
Как читать usage
| Поле | Что означает |
|---|---|
cache_creation_input_tokens | Токены, записанные в кэш (по ставке записи) |
cache_read_input_tokens | Токены, прочитанные из кэша (по ставке чтения) |
input_tokens | Токены после последней точки кэширования, по обычной цене |
cache_creation.ephemeral_5m_input_tokens, ephemeral_1h_input_tokens | Разбивка записи по сроку жизни |
Полный вход равен сумме трёх первых полей. Если оба кэш-поля равны нулю, кэш не участвовал: префикс короче минимума или cache_control не дошёл до API.
Что сбрасывает кэш
По таблице инвалидации в документации Anthropic на 8 ноября 2026 года:
| Что изменилось | Кэш tools | Кэш system | Кэш messages |
|---|---|---|---|
| Определения tools (имена, описания, параметры) | сброшен | сброшен | сброшен |
Включение web search или citations, настройка speed | сохранён | сброшен | сброшен |
tool_choice, добавление или удаление изображений | сохранён | сохранён | сброшен |
Параметры thinking, effort | зависит от модели | зависит от модели | сброшен |
На практике набор tools держат неизменным между вызовами, а переключатели вроде web search не меняют посреди диалога.
Ещё одно ограничение: для каждой точки кэширования API проверяет не больше 20 позиций назад. В длинном диалоге, где между текущей точкой и прошлой записью больше 20 блоков, попадание теряется. Решение: вторая явная точка ближе к началу или автоматический режим, который сдвигает точку сам.
OpenAI: автоматический кэш и явные точки
Начиная с GPT-5.6 у OpenAI два режима. Implicit включён по умолчанию: OpenAI сам ставит точку в конце последнего подходящего сообщения. Explicit кэширует только по точкам, которые расставил разработчик. Минимум 1 024 видимых input-токена.
Главное изменение по сравнению с прошлыми моделями: запись больше не бесплатна. До GPT-5.6 надбавки за запись не было. На GPT-5.6 и новее запись стоит 1,25x при сроке 30 минут и 2,5x при сроке 12 часов. Чтение стоит 0,1x, на GPT-6.1 Sol и Terra 0,05x. Срок задаётся в prompt_cache_options, точки ставятся полем prompt_cache_breakpoint, до 4 записей на запрос.
Тело запроса к Responses API с явной точкой кэширования:
{
"model": "gpt-6.1-terra",
"prompt_cache_options": {"mode": "explicit", "ttl": "30m"},
"input": [
{"role": "developer", "content": [{
"type": "input_text",
"text": "<стабильные инструкции, от 1024 токенов>",
"prompt_cache_breakpoint": {"mode": "explicit"}
}]},
{"role": "user", "content": "<текущий вопрос>"}
]
}
В явном режиме без точек кэширования кэша нет. Результат виден в usage.input_tokens_details: cached_tokens (чтение), cache_write_tokens (запись) и cache_write_tokens_details с разбивкой на ttl_30m_tokens и ttl_12h_tokens. Обычный input по формуле из документации: input_tokens − cached_tokens − cache_write_tokens.
Параметр prompt_cache_key на GPT-5.6 и новее для попаданий не нужен. Он пригодится, чтобы раздельно учитывать кэш по клиентам или пользователям. На старых моделях ключ влиял на маршрутизацию запросов, а срок задавался параметром prompt_cache_retention.
Ещё две детали из документации OpenAI: кэшированные токены входят в лимит TPM, ручной очистки кэша нет.
Gemini и DeepSeek
Gemini: implicit и explicit
Google называет механизм context caching (кэширование контекста). У Gemini 2.5 и новее implicit-кэш включён по умолчанию, настраивать ничего не нужно. Google советует ставить большое общее содержимое в начало запроса и отправлять похожие запросы близко по времени. Минимум для Gemini 3.8 Flash 4 096 токенов. Срок жизни implicit-кэша Google не публикует. В документации OpenRouter сказано, что в среднем это 3-5 минут.
Explicit-кэш создаётся отдельно через client.caches.create(...), затем его имя передаётся в generate_content через cached_content. По умолчанию он живёт 1 час, срок задаётся строкой вида "300s". Кроме чтения, оплачивается хранение: у Gemini 3.8 Flash $0,50 за 1M токенов в час до 31 декабря 2026 года. Explicit работает только через generateContent на моделях Gemini 3 и 2.5; в Interactions API и на линейке Gemini 4 и новее его нет.
Explicit-кэш окупается при плотном потоке запросов к одному большому документу. Для редких обращений implicit дешевле: за хранение платить не нужно, но и попадание не гарантировано.
DeepSeek: кэш на диске
У DeepSeek кэш контекста включён для всех пользователей, код менять не нужно. Попадания видны в полях prompt_cache_hit_tokens и prompt_cache_miss_tokens. Фиксированного TTL нет: кэш очищается, когда перестаёт использоваться, по документации обычно через несколько часов или дней. Работа описана как best-effort, 100% попаданий не гарантируются. Минимальный размер в документации не указан.
Надбавки за запись нет: промах стоит как обычный input. Чтение у V4.1 Flash стоит $0,003 за 1M против $0,15 за промах вне пика, то есть в 50 раз дешевле.
Через OpenRouter
OpenRouter передаёт параметры кэша провайдеру и возвращает результат в usage.prompt_tokens_details: cached_tokens (чтение) и cache_write_tokens (запись). Для Claude работают и верхнеуровневый cache_control, и явные блоки.
Кэш живёт у конкретного провайдера, поэтому повторный запрос должен попасть туда же. Для этого OpenRouter использует sticky routing: по документации он включается, только если у провайдера чтение из кэша дешевле обычного input, сессия держится 60 минут без запросов, ключ сессии задаётся через session_id. Ручной provider.order sticky routing отключает. Подробности про роутинг, ZDR и BYOK в гайде по OpenRouter.
Окупается ли кэш: формула и пороги
Обозначения: B - обычная цена префикса, N - число обращений к нему, w - множитель записи, r - множитель чтения. Если все обращения укладываются в TTL (с учётом продления чтением):
- без кэша: N·B;
- с кэшем: w·B + (N − 1)·r·B;
- кэш выгоден при N > (w − r) / (1 − r).
| Режим | w | r | Порог N | Выгоден с запроса |
|---|---|---|---|---|
| Claude 5 мин, Haiku 5.5 | 1,25 | 0,1 | 1,28 | 2-го |
| Claude 5 мин, Opus 5.5 / Sonnet 5.5 | 1,25 | 0,05 | 1,26 | 2-го |
| Claude 1 час, Haiku 5.5 | 2 | 0,1 | 2,11 | 3-го |
| Claude 1 час, Opus 5.5 / Sonnet 5.5 | 2 | 0,05 | 2,05 | 3-го |
| OpenAI 30 мин, GPT-6.1 Terra | 1,25 | 0,05 | 1,26 | 2-го |
| OpenAI 12 ч, GPT-6.1 Terra | 2,5 | 0,05 | 2,58 | 3-го |
| DeepSeek | 1 | 0,02 | 1 | 2-го |
Пример в деньгах: Sonnet 5.5, префикс 50K токенов. Без кэша он стоит $0,10 за запрос. Запись на 5 минут стоит $0,125, чтение $0,005. Десять запросов в пределах TTL: $1,00 без кэша против $0,125 + 9 × $0,005 = $0,17 с кэшем, экономия около 83%. С часовой записью: $0,20 + 9 × $0,005 = $0,245.
Сложнее, когда паузы длиннее 5 минут, но короче часа. Пятиминутный кэш тогда каждый раз пишется заново и стоит 1,25·N·B, на 25% дороже, чем без кэша. Часовой стоит 2·B + (N − 1)·r·B. При r = 0,1 и двух обращениях это 2,1·B против 2,0·B без кэша, то есть часовой кэш на двух запросах невыгоден. На трёх он уже окупается: 2,2·B против 3,0·B.
Убыточных сценариев два: промпт, который отправляется один раз, но с cache_control (у Claude и GPT-5.6+ плюс 25%), и паузы длиннее TTL. Для Gemini explicit к формуле добавляется плата за хранение, пропорциональная сроку жизни кэша.
Замеры: Haiku 5.5, Sonnet 5.5 и три вендора через OpenRouter
Все замеры автора сделаны через OpenRouter, Claude-запросы обслуживал провайдер Claude Platform on AWS. Время ответа включает задержки шлюза и сети. Стоимость взята из поля cost ответа OpenRouter.
Опорная проверка: 12 635 токенов на Haiku 5.5
7 ноября 2026 года два одинаковых запроса к Haiku 5.5 с system prompt на 12 635 токенов и cache_control: {type: "ephemeral"} стоили $0,00158 (запись) и $0,00013 (чтение 12 619 токенов): второй в 12 раз дешевле. Таблица и детали опубликованы в гайде по OpenRouter.
Списания сходятся с прайсом Anthropic: 12 635 × $0,10 за 1M = $0,00126, с множителем записи 1,25 это $0,00158; 12 619 × $0,01 за 1M = $0,00013. 16 токенов в чтение не попали, вероятно, это хвост после точки кэширования (user-сообщение и разметка). Время ответа 1,51 с против 1,41 с: на 12K токенов разница в пределах шума.
TTL 5 минут
8 ноября 2026 года, Haiku 5.5, тот же system prompt на 12,6K токенов:
| Время (UTC) | Шаг | cached | cache_write | Стоимость |
|---|---|---|---|---|
| 08:51:34 | запись | 0 | 12 618 | $0,00158 |
| 08:55:36 | через 4 мин | 12 618 | 0 | $0,00013 |
| 09:01:38 | через 6 мин после прошлого запроса | 0 | 12 618 | $0,00158 |
Через 4 минуты кэш читается. Через 6 минут после последнего обращения его уже нет: запрос снова пишет кэш и стоит как первый.
Префикс 80K: деньги и время до первого токена
8 ноября 2026 года, стриминг, Haiku 5.5 (три пары запись-чтение) и Sonnet 5.5 (одна запись, четыре чтения). TTFT - время до первого токена ответа.
| Модель | Шаг | Вход, токенов | TTFT, с | Стоимость |
|---|---|---|---|---|
| Haiku 5.5 | запись (3 раза) | 80 802 | 2,47 / 2,78 / 1,71 | $0,0101 |
| Haiku 5.5 | чтение (3 раза) | 80 802, из кэша 80 786 | 1,27 / 1,63 / 1,29 | $0,00081 |
| Sonnet 5.5 | запись | 80 804 | 1,69 | $0,2020 |
| Sonnet 5.5 | чтение (4 раза) | 80 804, из кэша 80 788 | 1,32 / 1,32 / 1,33 / 1,21 | $0,00815 |
На 80K чтение дешевле записи в 12,5 раза у Haiku 5.5 и в 25 раз у Sonnet 5.5. TTFT при чтении короче, но разброс большой: у Haiku 1,3-1,6 с против 1,7-2,8 с, у Sonnet около 1,3 с против 1,7 с на единственной записи. Выигрыш в первую очередь в деньгах. Время измерено через шлюз, напрямую в API цифры будут другими.
У Sonnet 5.5 на OpenRouter рассуждение нельзя отключить: reasoning: {enabled: false} возвращает ошибку 400 с текстом «Reasoning is mandatory for this endpoint and cannot be disabled». Поэтому в стоимость чтения Sonnet входят и токены рассуждения. У Haiku 5.5 рассуждение отключается.
Три вендора на одном префиксе
8 ноября 2026 года, префикс около 18K токенов, без явных параметров кэша, запросы подряд с паузой в несколько секунд:
| Модель | Провайдер | Вызов | cached | cache_write | Стоимость |
|---|---|---|---|---|---|
| GPT-6.1 Terra | OpenAI | 1 | 0 | 18 234 | $0,02282 |
| GPT-6.1 Terra | OpenAI | 2 | 18 234 | 0 | $0,00094 |
| Gemini 3.8 Flash | 1, 2 | 0, 0 | 0 | $0,01336 каждый | |
| Gemini 3.8 Flash | новый префикс, 1, 2, 3 | 0, 0, 12 261 | 0 | $0,01334 / $0,01336 / $0,00508 | |
| DeepSeek V4.1 Flash | не закреплён | 1, 2 | 0, 0 | - | $0,000115 / $0,00349 |
| DeepSeek V4.1 Flash | DeepInfra (закреплён) | 1, 2, 3 | 0, 18 304, 18 304 | - | $0,00257 / $0,0000843 / $0,0000843 |
По этим трём вендорам:
- GPT-6.1 Terra кэширует автоматически и списывает запись по повышенной ставке: 18 234 × $1,25 за 1M ≈ $0,0228. Чтение дешевле записи в 24 раза.
- У Gemini 3.8 Flash implicit-кэш сработал только на третьем вызове и частично, 12 261 токен из 17 779. Попадание не гарантировано.
- Без закреплённого провайдера два одинаковых запроса к DeepSeek V4.1 Flash ушли к разным провайдерам (Relace и Wafer), кэша не было, а цена отличалась в 30 раз. С провайдером, закреплённым через
provider: {order: [...], allow_fallbacks: false}, чтение стало дешевле в 30 раз со второго вызова. Это цены DeepInfra, а не прайс DeepSeek.
Где кэш даёт больше всего
Агенты и coding-агенты
Агентный цикл отправляет одни и те же tools и system prompt на каждом шаге, а история растёт. Это лучший случай для кэша: префикс большой, обращения частые, паузы короткие. Автоматический режим Anthropic сдвигает точку кэширования вслед за историей, поэтому каждый шаг читает почти весь прошлый контекст из кэша. Если агент ждёт ответа пользователя дольше 5 минут, стоит посчитать часовой вариант по формуле выше. Как устроены агентные циклы, описано в гайде по AI-агентам.
RAG с большим фиксированным контекстом
Если в каждом запросе одна и та же база знаний на десятки тысяч токенов, кэш снижает цену её повторной отправки на 90-95% у большинства моделей Claude и OpenAI (не считая первой записи). Найденные фрагменты и вопрос пользователя идут после неё. Когда выгоднее держать всё в контексте с кэшем, а когда искать фрагменты, разобрано в статье Context Engineering vs RAG.
Чат-боты и поддержка
Длинная инструкция, политика компании и FAQ одинаковы для всех пользователей. Имя пользователя, его данные и время ставятся в конец, после точки кэширования. Иначе у каждого пользователя будет свой префикс и кэш не будет переиспользоваться.
Параллельные запросы и batch
У Anthropic запись становится доступной только после того, как начался ответ на первый запрос. Если отправить 20 запросов с одинаковым префиксом одновременно, каждый из них может записать кэш заново. Решение: отправить один запрос, дождаться начала ответа, затем запускать остальные параллельно.
Антипаттерны и диагностика
Время в начале промпта: замер
Типичная ошибка: строка с текущим временем, ID запроса или именем пользователя в начале system prompt. Проверка 8 ноября 2026 года на Haiku 5.5, system prompt 12,6K токенов:
| Вариант | Запрос | cached | cache_write | Стоимость |
|---|---|---|---|---|
Current time: … в начале system | 1, 2, 3 | 0, 0, 0 | 12 638 каждый | $0,00158 каждый |
статичный блок с cache_control, время отдельным блоком после него | 1 | 0 | 12 626 | $0,00158 |
| то же | 2, 3 | 12 626 | 0 | $0,00013 |
Одна меняющаяся строка в начале отключает кэш полностью, и каждый запрос платит за запись, то есть на 25% дороже, чем вообще без кэша. Исправленный вариант выглядит так:
{
"system": [
{"type": "text", "text": "<длинная статичная инструкция>",
"cache_control": {"type": "ephemeral"}},
{"type": "text", "text": "Current time: 2026-11-08T08:51:45Z"}
]
}
Другие причины промаха
- Tools генерируются динамически или в разном порядке. У Anthropic изменение tools сбрасывает весь кэш.
- Между вызовами меняются
tool_choice, параметры thinking, набор изображений. - Префикс короче минимума: 512 токенов у Claude 5.5, 1 024 у OpenAI GPT-5.6+, 4 096 у implicit-кэша Gemini 3.8 Flash. Ошибки не будет, кэша тоже.
- Пауза дольше TTL.
- Параллельные первые запросы без прогрева.
- В диалоге больше 20 блоков между точкой кэширования и прошлой записью.
- У DeepSeek и implicit-кэша Gemini попадание не гарантировано в принципе.
- Через OpenRouter: запросы уходят к разным провайдерам.
Чек-лист: работает ли кэш
- Логировать по каждому запросу три числа: прочитано из кэша, записано в кэш, обычный input.
- Считать hit rate как долю прочитанных токенов от всего входа.
- Сравнивать фактическое списание с расчётом по формуле: если запись идёт на каждом запросе, префикс меняется.
- Проверить, что первое отличие между двумя соседними запросами стоит после точки кэширования.
- Вывести hit rate на дашборд и поставить алерт на падение; как собирать такие метрики, описано в статье про LLM observability.
Поля для логирования у разных вендоров:
| Вендор | Чтение | Запись |
|---|---|---|
| Anthropic | cache_read_input_tokens | cache_creation_input_tokens |
| OpenAI | input_tokens_details.cached_tokens | input_tokens_details.cache_write_tokens |
| DeepSeek | prompt_cache_hit_tokens | нет (промах: prompt_cache_miss_tokens) |
| OpenRouter | prompt_tokens_details.cached_tokens | prompt_tokens_details.cache_write_tokens |
У Gemini имя поля зависит от API и SDK: в документации Interactions API это usage.total_cached_tokens, в generateContent счётчик приходит в usage_metadata.
Итоги
Prompt caching снижает цену повторно отправляемого префикса в 10-50 раз в зависимости от вендора и модели, но только при трёх условиях:
- Статичное идёт в начало запроса, всё, что меняется, после точки кэширования.
- Срок жизни кэша выбирается под реальные паузы между запросами: 5 минут для плотного потока, час для агентов с ожиданием пользователя.
- Попадания проверяются по usage на каждом запросе, а не предполагаются.
Кэш префикса - один из нескольких способов снизить расходы на LLM. Остальные (выбор модели под задачу, batch, semantic cache, сокращение контекста) разобраны в статье про оптимизацию LLM-расходов.