Промпт-кэширование и Sticky Routing: Как снизить стоимость LLM в 10 раз

Представьте себе типичный сценарий работы современного AI-агента. Вы отправляете запрос системе, которая должна выполнить сложную задачу. Но прежде чем модель ответит, она должна «прочитать» инструкцию, определить доступные инструменты, изучить схемы данных и вспомнить правила безопасности. Эти системные промпты, определения инструментов и контекстные документы могут занимать тысячи токенов. И самое неприятное заключается в том, что при каждом новом сообщении в диалоге (каждом «ходе» или turn) вы платите за загрузку этих одних и тех же данных заново. В шеститомном сессии вы фактически оплачиваете один и тот же системный блок шесть раз, хотя изменилось только последнее сообщение пользователя или результат выполнения инструмента.

Это не просто неэффективно — это финансово невыгодно. Однако технологии промпт-кэширования (prompt caching) и Sticky Routing (липкого маршрутизации) от OpenRouter предлагают элегантное решение. Кэширование позволяет провайдеру читать повторяющуюся часть промпта из кэша по сниженной цене, а Sticky Routing гарантирует, что последующие запросы будут попадать на тот же сервер, где этот кэш «теплый» и доступен. В этой статье мы подробно разберем, как это работает, где кроются скрытые расходы и как правильно настроить агентов для максимальной экономии.

01Сколько стоит кэширование: математика экономии

Главный вопрос, который волнует любого разработчика или продукт-менеджера: «Сколько это сэкономит мне денег?». Ответ зависит от провайдера, но потенциал экономии огромен. Чтение из кэша (cache read) стоит от 0.1x до 0.5x от обычной цены входного токена. Это означает, что вы платите всего 10-50% от стандартной стоимости за каждый токен, который уже был закэширован.

Повторяющаяся часть промпта — это обычно самая дорогая часть. Длинные системные инструкции, определения инструментов (tools), JSON-схемы, правила безопасности (guardrails), извлеченные документы (retrieved documents) или примеры (few-shot examples) — все это остается неизменным на протяжении всего сеанса. Без кэширования каждый ход обходится в полную цену. С кэшированием первый запрос записывает эти данные в кэш, а последующие читают их по льготному тарифу.

Давайте посмотрим на сравнительную таблицу цен для различных провайдеров через OpenRouter. Обратите внимание, что точная сумма в долларах зависит от модели, но множители (multipliers) показывают, как кэшированный ввод соотносится с обычным для конкретного провайдера.

02Куда уходят деньги: запись против чтения

Важно понимать, что промпт-кэширование имеет две составляющие стоимости: запись (write) и чтение (read). Запись происходит, когда провайдер сохраняет повторяющуюся часть промпта. Чтение происходит, когда последующий запрос использует эти сохраненные данные. Вы выходите в плюс только тогда, когда одно и то же содержимое читается достаточно много раз, чтобы покрыть стоимость его первоначальной записи.

На некоторых провайдерах стоимость записи превышает стоимость обычного входного токена. Например, у Anthropic стоимость записи в кэш составляет 1.25x от цены ввода для стандартного времени жизни (TTL) 5 минут и 2.0x для TTL 1 час. Это означает, что если вы сделаете один запрос с кэшированием, который никогда больше не будет использоваться, вы заплатите больше, чем если бы просто отправили тот же промпт без кэширования.

Для разовых запросов кэширование может не иметь смысла. Но для многооборотных агентов повторение является нормой: агент сохраняет одни и те же инструкции, инструменты, схемы и политический контекст на протяжении всей сессии. Поэтому стоимость записи окупается за несколько ходов.

Рекомендация по выбору TTL (Time To Live): используйте 5-минутный кэш для коротких всплесков активности, когда следующий ход наступает быстро. Используйте 1-часовой кэш, когда сессия может приостановиться на длительное время, но содержимое все еще стоит сохранить. Это особенно актуально для сложных рабочих процессов, где пользователь может подумать над ответом несколько минут.

03Почему теплый кэш не всегда помогает в следующем запросе?

Теплый кэш помогает только в том случае, если следующий запрос попадает на тот же конечный пункт (endpoint) провайдера, где он был сохранен. Это фундаментальное ограничение распределенных систем.

Когда запросы могут маршрутизироваться к множеству провайдеров, первый ход может записать кэш у одного провайдера, а второй ход может попасть к другому. Второй провайдер не имеет «теплого» кэша для чтения. Запрос все еще работает, но вы платите полную цену, а поле cached_tokens в ответе остается низким или равным нулю. Это частая причина, по которой разработчики думают, что кэширование не работает, хотя на самом деле проблема в маршрутизации.

Именно поэтому OpenRouter сочетает Sticky Routing с промпт-кэшированием. После кэшированного запроса мы маршрутизируем последующие запросы для той же модели обратно к тому же провайдеру, где кэш-цена чтения дешевле обычной. Если этот «липкий» провайдер становится недоступным, OpenRouter автоматически переходит к следующему доступному провайдеру, не прерывая запрос.

По умолчанию OpenRouter распознает разговор, хэшируя его первое системное или developer-сообщение и первое несистемное сообщение. Это работает, когда эти начальные сообщения остаются неизменными. Однако агенты часто нарушают это правило: они могут переписывать свои первые сообщения, суммируя состояние, переупорядочивая контекст инструментов или добавляя новые метаданные запуска. Когда начальные сообщения меняются, хэш меняется, и разговор может попасть к другому провайдеру. Решение — явное использование session_id.

04Принудительное удержание кэша с помощью session_id

Для агентов и многооборотных сессий критически важно устанавливать параметр session_id. Когда вы передаете его, OpenRouter использует его напрямую как ключ для Sticky Routing, вместо того чтобы выводить ключ из начальных сообщений.

С session_id Sticky Routing активируется после первого успешного запроса, еще до того, как произойдет первое попадание в кэш (cache hit). Без него «липкость» начинается только после обнаружения кэша. Для многооборотных агентов это разница между надежным кэшем с первого хода и кэшем, который работает лишь иногда.

Вы можете отправить session_id как поле тела запроса или через заголовок x-session-id. Держите его стабильным для всего разговора или запуска агента и следите, чтобы он не превышал 256 символов.

curl https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "model": "anthropic/claude-sonnet-4.6",
  "session_id": "my-agent-session-abc123",
  "messages": [{"role": "system", "content": "..."}]
}'

from openrouter import OpenRouter

client = OpenRouter()

resp = client.chat.send(
    model="anthropic/claude-sonnet-4.6",
    session_id="my-agent-session-abc123",
    messages=[{"role": "system", "content": "..."}]
)

import { OpenRouter } from '@openrouter/sdk';

const openRouter = new OpenRouter({ apiKey: process.env.OPENROUTER_API_KEY });

const response = await openRouter.chat.send({
  model: 'anthropic/claude-sonnet-4.6',
  session_id: 'my-agent-session-abc123',
  messages: [{ role: 'system', content: '...' }],
});

Используйте значение, которое соответствует единице работы: поток чата, тикет поддержки, запуск рабочего процесса или задача агента. Не создавайте новый session_id для каждого хода, иначе запросы перестанут попадать на провайдер, который держит кэш.

Если вы используете модели роутера, такие как Auto Router или Pareto Router, стабильность сессии также фиксирует модель, выбранную роутером, а не только провайдера. Это предотвращает переключение моделей в середине сессии, обеспечивая согласованность поведения и сохранение кэша.

05Как подтвердить, что промпт-кэширование работает?

Самый быстрый способ проверить работу кэширования — это инспекция использования (usage inspection). В ответе API обратите внимание на поле usage.prompt_tokens_details.cached_tokens. Оно показывает, сколько токенов было прочитано из кэша. Если это значение больше нуля, запрос попал в кэш.

Также существует поле cache_write_tokens, которое показывает, сколько токенов было записано во время запроса с записью в кэш. Вот пример ответа:

{
  "usage": {
    "prompt_tokens": 10339,
    "completion_tokens": 60,
    "total_tokens": 10399,
    "prompt_tokens_details": {
      "cached_tokens": 10318,
      "cache_write_tokens": 21
    }
  }
}

В этом примере большая часть токенов промпта пришла из кэша, и этот ход не записывал новую запись в кэш. Вы можете проверять поведение кэша в трех местах: в детальном представлении на странице Activity, в API /api/v1/generation и в объекте usage.prompt_tokens_details, возвращаемом с ответами API.

Используйте поле cache_discount, чтобы увидеть, сколько сэкономила генерация. На провайдерах с платной записью вы можете увидеть отрицательную скидку на ходу записи, потому что запись в кэш стоит дороже обычного ввода. На последующих ходах чтения скидка должна стать положительной.

06Почему происходит промах по кэшу (cache miss) и как его избежать?

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

1. Промпт ниже минимального порога провайдера

У каждого провайдера есть минимальный размер промпта, и ниже него ничего не кэшируется. Например, у Anthropic для Claude Opus 4.5-4.8 и Haiku 4.5 требуется 4,096 токенов; для Haiku 3.5 — 2,048; для Sonnet 4, 4.5, 4.6 требуется 1,024 токенов. У OpenAI порог составляет 1,024 токена. У Gemini 2.5 Pro — 4,096, а у Flash — 1,024.

Если ваше повторяющееся содержимое находится ниже этого минимума, кэширование не начнется. Не заполняйте запрос мусорным текстом только для того, чтобы достичь порога. Используйте кэширование там, где у вас уже есть много повторяющегося контента: инструменты, схемы, извлеченные документы, примеры или тексты политик.

2. Кэш истек между ходами

Кэши живут недолго. Стандартный срок у Anthropic — 5 минут, с опцией 1 час для более длительных сессий. Имплицитный кэш Gemini длится около 3-5 минут и не сбрасывается при чтении. Как только кэш истекает, следующий запрос должен записать новый.

Если ваши пользователи часто делают паузы между ходами, используйте более длительный TTL, где это поддерживается, или настройте агента так, чтобы он принимал новую запись после периодов простоя.

3. Начало промпта постоянно меняется

Автоматическое и имплицитное кэширование лучше всего работают, когда начало промпта остается неизменным. Размещайте стабильный контент первым: системные инструкции, инструменты, схемы и фиксированные справочные материалы. Размещайте изменяющийся контент позже: вопросы пользователя, временные метки, временное состояние, результаты инструментов и кратковременные метаданные.

Мелкие детали имеют значение. Временная метка в первом системном сообщении делает промпт «новым» при каждом ходе. Переместите ее в более позднее сообщение пользователя или инструмента, если она не должна быть частью кэшируемого контента.

4. Запрос сместился к другому провайдеру

Кэш живет там, где он был записан. Если последующий запрос маршрутизируется к другому конечному пункту провайдера, этот пункт не может прочитать предыдущий кэш.

Для рабочих процессов агентов установите session_id и позвольте Sticky Routing удерживать сессию на провайдере с теплым кэшем. Один нюанс: если вы вручную установите provider.order, ваш порядок имеет приоритет над Sticky Routing. Используйте provider routing controls, если вам нужен определенный порядок провайдеров.

07Что это значит на практике: интеграция кэширования и Sticky Routing

Если ваш агент отправляет один и тот же контент при каждом ходе, вот чек-лист для оптимизации:

1. Разместите стабильный контент первым: системный промпт, определения инструментов, схемы, политики и долгосрочный контекст.
2. Разместите изменяющийся контент позже: сообщения пользователя, результаты инструментов, временные метки и состояние, специфичное для запуска.
3. Включите промпт-кэширование для провайдеров, требующих явного cache_control (например, Anthropic и Alibaba Qwen).
4. Установите стабильный session_id для разговора или рабочего процесса.
5. Проверяйте cached_tokens и cache_discount, чтобы подтвердить, что чтения происходят.

Для грубой оценки представьте агента, который повторяет одни и те же 10,000 токенов в течение 6 ходов. Вот как выглядит стоимость в зависимости от сценария:

• Без кэширования: Полный ввод на каждом ходу. Итого: 6.0x от стоимости одного некешированного хода.
• Anthropic 5-минутный кэш + Sticky Routing: 1.25x за запись на первом ходу, 0.1x за чтения на последующих. Итого: 1.75x.
• Провайдер с бесплатной записью + 0.25x чтения: 1.0x за запись, 0.25x за чтения. Итого: 2.25x.
• Провайдер с бесплатной записью + 0.5x чтения: 1.0x за запись, 0.5x за чтения. Итого: 3.5x.

Этот пример охватывает только повторяющееся содержимое. Он игнорирует меньшие изменяющиеся сообщения и токены вывода модели. Экономия растет с количеством ходов.

Когда что использовать:

• Используйте автоматическое кэширование для многооборотных разговоров, где повторяющийся контент растет вместе с разговором.
• Используйте явные точки кэширования (cache breakpoints), когда вы точно знаете, какие большие блоки должны кэшироваться: извлеченные документы, длинные справочные файлы, карактер-карты, CSV-данные или тексты политик.
• Используйте session_id для сессий агентов, тикетов поддержки, потоков чата и любых разговоров, где начальные сообщения могут меняться между ходами.
• Используйте 1-часовой кэш для более длительных сессий Anthropic, где стандартные 5 минут могут истечь между ходами. Используйте стандартный для коротких, плотных диалогов.

Когда ваш агент снова и снова отправляет один и тот же дорогой контент, кэшированные чтения и Sticky Routing не позволяют этому контенту стать самой дорогой частью цикла.

08Часто задаваемые вопросы (FAQ)

Поддерживает ли OpenRouter промпт-кэширование?
Да. OpenRouter поддерживает промпт-кэширование у всех поддерживаемых провайдеров и моделей. Большинство провайдеров включают его автоматически, в то время как Anthropic и Alibaba Qwen используют cache_control для явного кэширования. Чтения из кэша стоят от 0.1x до 0.5x от обычного ценообразования ввода в зависимости от провайдера, поэтому повторно используемый префикс становится намного дешевле после первого запроса.

Сколько стоят закэшированные токены в OpenRouter?
Чтения из кэша стоят от 0.1x до 0.5x от обычного ценообразования ввода. Anthropic, DeepSeek и Alibaba Qwen могут читать по ставке 0.1x. OpenAI читает по ставке 0.25x-0.50x. Gemini, Grok и Moonshot читают по 0.25x. Groq читает по 0.5x.

Почему промпт-кэширование не работает через OpenRouter?
Распространенные причины: промпт ниже минимального порога токенов провайдера, истекший кэш, нестабильный префикс промпта или смещение провайдера между ходами. Для рабочих процессов агентов начните с установки стабильного session_id, затем проверьте cached_tokens в ответе usage, где любое значение выше нуля подтверждает попадание в кэш.

Как удерживать кэш теплым между ходами агента?
Передавайте стабильный session_id для разговора, тикета или рабочего процесса. OpenRouter использует его как ключ Sticky Routing, поэтому последующие запросы маршрутизируются обратно к тому же конечному пункту провайдера, который держит теплый кэш. С установленным session_id стабильность активируется после первого успешного запроса, до того, как будет замечено попадание в кэш.

Как проверить, сэкономило ли кэширование деньги?
Проверяйте usage.prompt_tokens_details.cached_tokens для чтений из кэша и cache_write_tokens для записей; значение cached_tokens выше нуля подтверждает попадание. Вы также можете прочитать cache_discount в ответе, чтобы увидеть эффект стоимости для каждой генерации, или открыть детальное представление на странице Activity или в API /api/v1/generation.

Работает ли кэширование с Auto Router?
Да. С установленным session_id модели роутера, такие как Auto Router, сохраняют стабильность сессии, предотвращая переключение моделей и обеспечивая непрерывность кэширования.

Источник: OpenRouter ↗