Prompt Caching в 2026: как реально экономить на повторяющемся контексте

Короткая версия

Что важно в 2026:

1. OpenAI кэширует автоматически при префиксе >= 1024 токенов.
2. Anthropic позволяет явно ставить cache_control и выбирать 5m или 1h.
3. Gemini имеет implicit caching по умолчанию и explicit caching с TTL и storage billing.
4. Экономика зависит не только от скидки на cache hit, но и от TTL, write price, частоты повторов и структуры промпта.
5. Главная метрика не “включили кэш”, а cache hit rate.

Быстрое сравнение

У нас support-agent. В каждый запрос летят policy, definitions tools, два long examples и свежий вопрос пользователя. Что кэшировать?

1. Что именно кэшируется

Во всех трёх экосистемах ключевая идея одна: кэшируется не “готовый ответ”, а уже обработанный prefix state модели. Поэтому prompt caching работает только когда запросы имеют одинаковое начало.

Из этого следуют два production-правила:

• всё стабильное должно стоять в начале;
• всё динамическое должно быть в конце.

Если вы вставляете в system prompt текущую дату, random ID или user-specific block выше стабильного контекста, вы почти наверняка убиваете hit rate.

2. OpenAI: automatic caching, retention policy и prompt_cache_key

У OpenAI prompt caching работает автоматически на recent models, gpt-4o и новее. Официальный guide прямо говорит:

• кэш активируется на промптах 1024+ токенов;
• hit возможен только для exact prefix matches;
• можно передавать prompt_cache_key, чтобы улучшать routing;
• default retention policy — in_memory;
• для части моделей доступен 24h extended retention;
• usage возвращает cached_tokens.

Практически это означает:

• если у вас длинный стабильный developer/system prefix, код можно вообще не менять и всё равно получить cached input economics;
• если у вас high-volume endpoint с несколькими крупными prefix families, prompt_cache_key помогает не смешивать их;
• cached tokens не освобождают вас от rate limits: docs OpenAI отдельно пишут, что caching rate limits не меняет.

3. Anthropic: самый управляемый prompt caching

У Anthropic картина теперь более богатая, чем в старых гайдах:

• есть automatic caching на top-level cache_control;
• есть explicit breakpoints на отдельных блоках;
• default TTL — 5 minutes;
• можно выбрать 1 hour;
• поддерживается до 4 breakpoints;
• cache hit стоит 0.1x base input price;
• 5m cache write стоит 1.25x;
• 1h cache write стоит 2x.

Особенно важны нюансы, которые легко упустить:

• кэшируется полный prefix в порядке tools -> system -> messages;
• lookback window ограничен 20 блоками;
• cache hit становится возможен только после того, как первый запрос начал возвращать ответ;
• cache hits не вычитаются из rate limits.

Именно поэтому Anthropic удобно использовать там, где:

• длинный policy / tool layer живёт долго;
• growing conversation требует контролировать breakpoint position;
• нужна предсказуемая cache economics, а не “может сработать, а может нет”.

4. Gemini: implicit vs explicit context caching

У Gemini API важно не путать два механизма:

• implicit caching включён по умолчанию на большинстве Gemini-моделей;
• explicit caching создаёт отдельный cached object с выбранным TTL.

Официальные docs прямо говорят:

• implicit caching не гарантирует экономию, но автоматически передаёт savings, если hit случился;
• explicit caching нужен, когда вы хотите гарантированный reuse и готовы добавить отдельный шаг создания cache object;
• у explicit caching TTL по умолчанию 1 hour, но его можно задавать;
• у Gemini 2.5 Flash minimum token limit для implicit caching — 1024;
• у Gemini 2.5 Pro и Gemini 3.1 Pro Preview — 4096.

Экономика у Gemini считается не только по discounted cached tokens, но и по storage price. Поэтому explicit cache чаще всего оправдан, когда:

• контекст очень длинный;
• документы, PDF или media-context переиспользуются сериями запросов;
• вы точно знаете, что reuse будет в рамках заданного TTL.

5. Economics: где кэш действительно окупается

Старое утверждение “prompt caching всегда экономит 90%” слишком грубое. Правильнее считать по модели:

На Anthropic breakeven особенно прозрачен:

• 5m write = 1.25x, read = 0.1x: уже один read после write обычно окупает кэш;
• 1h write = 2x, read = 0.1x: нужен более длинный reuse horizon.

На OpenAI и Gemini разработчики чаще ошибаются не в math, а в архитектуре:

• стабильный prefix слишком короткий;
• identical prefix не сохраняется;
• запросы распределены слишком редко или слишком хаотично;
• hit rate никто не меряет.

6. Что кэшировать в production

Хорошие кандидаты:

• длинный system / developer prompt;
• compliance / policy bundles;
• tool schemas и tool instructions;
• few-shot examples;
• большие документы, общие для серии вопросов;
• длинный conversation prefix после compaction.

Плохие кандидаты:

• timestamps;
• request IDs;
• персонализированные переменные в начале промпта;
• retrieval chunks, которые меняются почти каждый запрос;
• короткий префикс, который даже не проходит provider threshold.

7. Что измерять

Если вы не видите usage-поля, prompt caching у вас пока не production feature, а надежда.

Минимальный набор метрик:

• cache hit rate;
• cached input tokens;
• cache writes vs cache reads;
• TTFT / latency при hit и miss;
• hit rate по endpoint / workflow;
• net savings after write/storage costs.

Особенно важно смотреть метрики по отдельным prompt families. Средний hit rate по всей системе почти всегда скрывает проблему: один endpoint работает отлично, другой никогда не попадает в cache.

OpenAI: stable prefix + retention policy

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.4-mini",
    prompt_cache_retention="in_memory",
    prompt_cache_key="support-policy-v3",
    input=[
        {
            "role": "developer",
            "content": (
                "Ты support-assistant.\n"
                "Следуй policy, не выдумывай факты, "
                "используй tools только при необходимости.\n"
                "Ниже long examples и tool contracts..."
            ),
        },
        {
            "role": "user",
            "content": "Почему мне начислили две комиссии?",
        },
    ],
)

print(response.usage)

Anthropic: automatic caching + 1h TTL

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=800,
    cache_control={"type": "ephemeral", "ttl": "1h"},
    system=[
        {
            "type": "text",
            "text": (
                "Ты support-assistant.\n"
                "Политика ответа, правила escalation, "
                "tool instructions и examples..."
            ),
        }
    ],
    messages=[
        {
            "role": "user",
            "content": "Проверь, почему оплата не прошла.",
        }
    ],
)

print(response.usage)

Anthropic: explicit breakpoint на последнем стабильном блоке

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=800,
    system=[
        {
            "type": "text",
            "text": "Policy bundle ...",
        },
        {
            "type": "text",
            "text": "Few-shot examples ...",
            "cache_control": {"type": "ephemeral"},
        },
    ],
    messages=[
        {
            "role": "user",
            "content": "Свежий вопрос пользователя",
        }
    ],
)

Gemini: explicit cache object

from google import genai
from google.genai import types

client = genai.Client()

cache = client.caches.create(
    model="gemini-2.5-flash",
    config=types.CreateCachedContentConfig(
        system_instruction="Ты аналитик договоров. Используй только текст документа.",
        contents=["LONG CONTRACT TEXT OR FILE REF"],
        ttl="3600s",
    ),
)

response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="Выдели основные риски и сроки расторжения.",
    config=types.GenerateContentConfig(
        cached_content=cache.name
    ),
)

print(response.usage_metadata)

Практический аудит

У нас quality нормальный, но support endpoint дорогой. В каждый запрос уходят long policy, 12 tool definitions и одна и та же product doc. Что проверить сначала?

Проверьте себя