Кеширование

llmgw кеширует одинаковые non-streaming запросы на 10 минут: повторные вызовы с тем же payload отвечают быстрее и не списывают дополнительные деньги.

Как считается ключ кеша

Ключом служит SHA-256 от:

• model,
• нормализованных messages / input,
• параметров (temperature, top_p, max_tokens, tools, response_format, seed).

При temperature=0 и том же prompt попадание в кеш ожидаемо.

Когда кеш не используется

• При stream: true.
• Если в payload указано metadata.no_cache: true.
• Если модель использует собственный prompt-cache провайдера — платформа его не дублирует.

Принудительный обход

resp = client.chat.completions.create(
    model="anthropic/claude-sonnet-4.6",
    messages=[...],
    extra_body={"metadata": {"no_cache": True}},
)

Заголовок ответа

x-llmgw-cache: hit или miss показывает, был ли ответ из кеша.

Закрепление маршрута за провайдером

Чтобы увеличить долю попаданий в кеш, llmgw после запроса с кешированием промпта направляет следующие запросы на тот же эндпоинт провайдера. Это происходит автоматически как при неявном кешировании (например, у OpenAI, DeepSeek и Gemini 2.5), так и при явном кешировании (например, с помощью точек cache_control у Anthropic).

Как это работает:

• После запроса с кешированием промпта llmgw запоминает, какой провайдер обработал запрос.
• Следующие запросы к той же модели направляются тому же провайдеру, чтобы кеш оставался прогретым.
• Маршрут закрепляется только в том случае, если чтение из кеша у провайдера дешевле обычной обработки промпта. Благодаря этому кеширование всегда снижает стоимость запроса.
• Если закреплённый провайдер становится недоступен, llmgw автоматически переключается на следующего подходящего провайдера.
• Если порядок провайдеров задан вручную через provider.order, закрепление маршрута не используется: явно указанный порядок имеет приоритет.

С каким шагом закрепляется маршрут. Маршрут отслеживается на уровне аккаунта отдельно для каждой модели и беседы. По умолчанию llmgw определяет беседу по хешу первого системного сообщения (или сообщения разработчика) и первого несистемного сообщения в каждом запросе. Поэтому запросы с одинаковыми начальными сообщениями направляются одному провайдеру. При этом разные беседы могут закрепляться за разными провайдерами: нагрузка распределяется, пропускная способность сохраняется, а кеш внутри каждой беседы остаётся прогретым.

Закрепление с помощью session_id

Чтобы управлять закреплением маршрута явно, передайте в запросе session_id. В этом случае llmgw использует его как ключ маршрутизации вместо хеша сообщений. Это особенно удобно для многошаговых агентных сценариев: начальные сообщения могут меняться от запроса к запросу, но все запросы по-прежнему будут направляться одному провайдеру.

Передать session_id можно двумя способами:

• В теле запроса: добавьте session_id в корень объекта. Если значение одновременно передано и в теле, и в заголовке, приоритет имеет тело запроса.
• В заголовке: установите HTTP-заголовок x-session-id.

Длина session_id не должна превышать 256 символов. Если он не задан, llmgw использует в качестве ключа маршрутизации совместимое с OpenAI поле prompt_cache_key. Поэтому клиенты, которые уже передают prompt_cache_key, получают закрепление маршрута за сессией без дополнительных изменений.

{
  "model": "anthropic/claude-sonnet-4",
  "session_id": "my-agent-session-abc123",
  "messages": [
    {
      "role": "user",
      "content": "Продолжи наш разговор..."
    }
  ]
}

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

При использовании моделей-маршрутизаторов закрепляется не только провайдер, но и выбранная маршрутизатором модель. Это не позволяет маршрутизатору выбирать новую модель на каждом шаге беседы.

Группировка запросов разных модальностей

Помимо закрепления маршрута, llmgw использует session_id, чтобы объединять запросы одной сессии в журнале. Один session_id связывает шаги беседы, повторные попытки и запросы разных модальностей, благодаря чему всю сессию агента можно проследить целиком.

Группировка работает для синхронных эндпоинтов, а не только для Chat Completions:

• Chat и Responses: передавайте session_id в теле запроса или в заголовке x-session-id.
• Embeddings, реранкинг, распознавание и синтез речи, генерация изображений и видео: передавайте заголовок x-session-id. Эти эндпоинты не принимают session_id в теле запроса. Значение используется только для группировки, поэтому закрепление маршрута к ним не применяется.

Ограничение в 256 символов действует для обоих способов передачи. Используйте одинаковый x-session-id во всём мультимодальном сценарии, чтобы собрать все генерации в одной сессии. Например, агент может распознать аудио, обратиться к чат-модели, а затем сгенерировать изображение.

Batch API пока не группирует генерации по session_id.