Стратегия prompt caching

Спроектируй prompt cache стратегию для {{agent_name}} (system prompt ~{{system_prompt_size}} токенов). Цель — cache hit rate ≥ 80% и положительный ROI.

Mental model

Prompt cache работает как HTTP cache: ставишь cache_control маркер в конец блока — и всё ДО этой точки кешируется как cache breakpoint. При следующем запросе модель сравнивает префикс. Если совпадает — берёт из кеша.

Экономика (Anthropic):

• Cache write: 1.25x обычной цены input
• Cache read: 0.1x (90% скидка)
• TTL: 5 минут (default ephemeral) или 1 час (premium, дороже write)

ROI положительный если кеш читается ≥ 2 раз за TTL. Это почти всегда true для активных агентов.

Что кешировать (порядок приоритета)

1. System prompt — самое очевидное. Меняется редко, нужен на каждый запрос. Cache must.
2. Few-shot examples — если у тебя 5-10 примеров на 3-5K токенов, это второй блок.
3. Knowledge base / context — документация продукта, FAQ, политики. Если ≤ 100K токенов и общие для запросов.
4. Tool definitions — большие JSON Schema для tools (особенно MCP с 20+ tools).
5. Conversation history до текущего turn — для длинных диалогов.

Что НЕ кешировать

• ❌ User message — он уникален каждый раз, кеш не сработает.
• ❌ Контент < 1024 токенов (Claude Sonnet/Opus) или < 2048 (Haiku) — минимум для cache block.
• ❌ Динамические значения (timestamp, user_id, current date) внутри system prompt → ломает кеш на каждом запросе.

Cache key design — главная ошибка

Кеш считается побайтово от начала промпта до cache_control маркера. Любое отличие — cache miss.

Правильно:

[system: статичные инструкции] [cache_control] | [user: динамика]

Неправильно (ломает кеш):

[system: "Ты помощник. Сегодня {{date}}. ..."] [cache_control]

Дата меняется ежедневно → кеш инвалидируется каждый день в 00:00.

Фикс: вынести динамику ПОСЛЕ cache breakpoint:

[system: статичные инструкции] [cache_control]
[user: "Сегодня {{date}}. Вопрос: ..."]

Multi-breakpoint pattern (продвинуто)

Можешь ставить до 4 cache breakpoints. Полезно для слоистого контекста:

{
  "system": [
    { "type": "text", "text": "<base persona>", "cache_control": {"type": "ephemeral"} },
    { "type": "text", "text": "<knowledge base 50K токенов>", "cache_control": {"type": "ephemeral"} },
    { "type": "text", "text": "<user-specific preferences>", "cache_control": {"type": "ephemeral"} }
  ]
}

Если меняется только третий блок — первые два остаются в кеше.

TTL: 5 минут vs 1 час

• 5 минут (ephemeral, default): для активных сессий, чатов, demo. Дёшево.
• 1 час: для batch processing, медленных eval-прогонов, low-traffic endpoints. Write cost выше (~2x), но если запросы редкие, окупается.

Правило: если запросы реже 1/мин → 1h TTL. Чаще → 5m.

Метрики

Логируй на каждом запросе:

• cache_creation_input_tokens — сколько записали
• cache_read_input_tokens — сколько прочитали из кеша
• input_tokens — обычные (не кешированные)

Cache hit rate = cache_read / (cache_read + input_tokens) × 100%. Целевой: > 80%.

Anti-patterns

• ❌ Cache breakpoint в начале промпта → кешируется ноль контента, write cost потрачен впустую.
• ❌ Динамика внутри кешируемого блока ({{user_name}}, current date) → кеш инвалидируется на каждом запросе.
• ❌ Кеширование уникального user input → ноль попаданий, только write cost.
• ❌ Слишком много breakpoints (> 4) → API rejects, ошибка.
• ❌ 1h TTL для high-traffic → переплачиваешь за write без выгоды.
• ❌ Игнорирование min token threshold → блок < 1024 токенов не кешируется, тихий миссинг.

Output

Документ "Cache Strategy" с:

1. Структурой промпта (что в каком блоке, где breakpoint).
2. Расчётом ROI: текущий cost vs прогноз с кешем (формула + цифры).
3. Списком динамических полей и куда их переместить.
4. Метриками для дашборда (cache hit rate, savings/day).
5. Триггерами для review кеша (изменения system prompt, новые examples).