Кэширование ответов, оно же response caching, позволяет не запускать модель повторно, если она уже обработала идентичный запрос. Вместо новой генерации вы мгновенно получаете готовый ответ, а счётчики usage равны нулю. Для разработчика это особенно полезно при перезапуске агентов, прогоне тестов и повторных запросах LLM. На api.vega.chat кэш включён по умолчанию — ничего настраивать не нужно, экономия начинается с первого повторного запроса. Но «почти такой же» запрос не подходит: попасть в кэш можно только при точном совпадении ключа.

Фича работает через api.vega.chat — это 100% OpenRouter-совместимый прокси: вместо https://openrouter.ai/api/v1 используется https://api.vega.chat/api/v1, ключ создаётся в личном кабинете на api.vega.chat/dashboard. Все примеры ниже уже написаны под VEGA и проверены на живом API.

Что доступно через API ВЕГА — коротко

Чтобы сразу стало понятно, что из статьи можно применить прямо сейчас:

Возможность	Работает через api.vega.chat
Кэширование идентичных запросов	включено по умолчанию
`X-OpenRouter-Cache: false` — выключить кэш на запрос	да
`X-OpenRouter-Cache-TTL: <сек>` — свой срок жизни записи	да
`X-OpenRouter-Cache-Clear: true` — принудительно обновить запись	да
Статусные заголовки ответа (`Status`, `Age`, `TTL`, `Source-Id`)	да
Привязка кэша к вашему API-ключу	да
Пресеты с `cache_enabled`	нет — пресеты создаются только в кабинете OpenRouter, через прокси они доступны лишь на чтение

Как работает кэширование ответов

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

При первом обращении запрос получает статус MISS: уходит провайдеру, успешный ответ сохраняется. При повторном идентичном запросе приходит HIT: роутер возвращает сохранённый результат, не обращаясь к модели и не расходуя её rate limit.

Кэшируются только ответы 200 OK, включая стриминговые. Поддерживаются четыре эндпоинта:

/api/v1/chat/completions;
/api/v1/responses;
/api/v1/messages;
/api/v1/embeddings.

Важно не путать с provider prompt caching. Тот работает внутри инфраструктуры провайдера и у многих моделей включён автоматически: скидка на повторный префикс промпта приходит сама, в поле cached_tokens. Response caching — другой механизм: сохраняется целый ответ. Разница видна в счёте: HIT возвращает ответ бесплатно, а чтение из prompt-кэша идёт со скидкой, не в ноль. Зато prompt-кэшу достаточно совпадения префикса — бит-в-бит идентичный запрос не нужен. На чистом OpenRouter response caching включают явно, заголовком, а на api.vega.chat он уже работает по умолчанию — заголовки нужны только для управления. Оба механизма можно использовать вместе.

Кэш включён по умолчанию — заголовки нужны для управления

На api.vega.chat кэширование включено по умолчанию: идентичные запросы попадают в кэш без всяких заголовков, TTL записи — 300 секунд. Обычный запрос уже экономит:

Bash

curl -i https://api.vega.chat/api/v1/chat/completions \
  -H "Authorization: Bearer $VEGA_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary '{
    "model": "google/gemini-2.5-flash",
    "messages": [
      {"role": "user", "content": "Объясни идемпотентность в двух предложениях"}
    ],
    "temperature": 0,
    "stream": false
  }'

Запустите команду, дождитесь завершения и повторите её без изменений: первый ответ вернётся с X-OpenRouter-Cache-Status: MISS, второй — с HIT.

На чистом OpenRouter механика та же, но там кэш нужно включать вручную заголовком X-OpenRouter-Cache: true — на ВЕГА это необязательно. Заголовки остаются для управления:

http

X-OpenRouter-Cache: false      # выключить кэш для конкретного запроса
X-OpenRouter-Cache-TTL: 3600   # свой срок жизни записи вместо 300 секунд
X-OpenRouter-Cache-Clear: true # принудительно обновить запись

Что значит «идентичный запрос»: ключ кэша и ловушки

Практическое правило: отправляйте запрос бит-в-бит одинаково. Единственная оговорка: пробелы в JSON нормализуются и на ключ не влияют.

Ключ состоит из:

text

API-ключ + модель + тип эндпоинта + режим стриминга
+ SHA-256 нормализованного тела запроса

То есть совпадения текста промпта недостаточно.

Порядок полей JSON имеет значение

Эти тела создают разные ключи:

JSON

{"model":"google/gemini-2.5-flash","messages":[]}

JSON

{"messages":[],"model":"google/gemini-2.5-flash"}

Перестановка полей при сборке объекта может превратить ожидаемый HIT в MISS. Для повторяемых запросов используйте стабильный порядок сериализации.

Явный дефолт отличается от пропущенного поля

Запрос с temperature: 1.0 отличается от запроса без temperature, даже если поведение модели предполагается одинаковым.

Не меняйте между повторами набор параметров: «значение по умолчанию» и отсутствие значения образуют разные тела. Учтите и обратное: если ВЕГА сама подставляет параметр (например, session_id для sticky-роутинга или provider с разрешённым фолбэком), то тело «с ним» и «без него, но с тем же эффектом» могут свестись к одному ключу — и вы получите HIT там, где чистый OpenRouter дал бы MISS.

Стриминг и API-ключ разделяют кэш

stream: true и stream: false создают отдельные записи. Тип эндпоинта тоже входит в ключ: между Chat Completions и Responses общего попадания не будет.

Кэш привязан к конкретному API-ключу, а не аккаунту или организации. Другой ключ не увидит запись; после ротации кэш нового ключа пуст. На ВЕГА это соблюдается автоматически: в апстримное тело подставляется session_id с идентификатором вашего ключа, поэтому записи кэша разных ключей не пересекаются — даже если вы пришлёте свой session_id, он уйдёт с префиксом ключа.

Заголовки HTTP-Referer, X-Title и provider-specific заголовки в ключ не входят. Мультимодальные запросы поддерживаются: содержимое base64 тоже участвует в хэшировании.

TTL и управление кэшем запроса

По умолчанию запись живёт 300 секунд, пять минут. Диапазон TTL: от 1 до 86 400 секунд, максимум сутки.

Задать своё время можно так:

http

X-OpenRouter-Cache-TTL: 3600

Передавайте целое число: нечисловые значения игнорируются, дроби отбрасываются, значения вне диапазона ограничиваются его границами.

Чтобы удалить старый результат и получить новый:

http

X-OpenRouter-Cache-Clear: true

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

Кэш-заголовки в инструментах вайбкодинга

На api.vega.chat кэш работает без заголовков, поэтому настройки из этого раздела нужны в двух случаях: вы идёте в OpenRouter напрямую и кэш надо включать заголовком X-OpenRouter-Cache: true, либо хотите TTL, отличный от 300 секунд. Не каждый агент умеет отправлять произвольные HTTP-заголовки, и расклад по инструментам неравномерный.

Инструмент	Как задаётся TTL	Что уходит в запросе
OpenClaw	`responseCacheTtlSeconds` в конфиге модели	`X-OpenRouter-Cache: true` и `X-OpenRouter-Cache-TTL`
Hermes Agent	`response_cache_ttl` в `config.yaml` или переменная `HERMES_OPENROUTER_CACHE_TTL`	те же заголовки
Goose	`OPENAI_CUSTOM_HEADERS="X-OpenRouter-Cache=true,X-OpenRouter-Cache-TTL=3600"` или поле `headers` в JSON кастом-провайдера	любые заголовки
Aider	`extra_headers` в `.aider.model.settings.yml`	любые заголовки

OpenClaw — единственный, кто отправляет кэш-заголовки из коробки: они включаются на уровне модели связкой responseCache: true и responseCacheTtlSeconds, понимаются и алиасы response_cache_ttl_seconds и responseCacheTtl. Оговорка существенная: заголовки уходят только на проверенных маршрутах openrouter.ai — через кастомный baseURL, включая api.vega.chat, OpenClaw их не шлёт. Для ВЕГА это некритично: кэш включён и так, просто TTL останется дефолтным.

Hermes Agent от Nous Research собирает заголовки функцией build_or_headers: включается конфигом {"response_cache": true, "response_cache_ttl": 3600} или переменными HERMES_OPENROUTER_CACHE и HERMES_OPENROUTER_CACHE_TTL. Невалидный TTL — отрицательный, нечисловой, вне диапазона от 1 до 86 400 секунд — отбрасывается.

Goose принимает произвольные заголовки для OpenAI-совместимых провайдеров: через OPENAI_CUSTOM_HEADERS в формате HEADER_A=VALUE_A,HEADER_B=VALUE_B или через поле headers в JSON-файле кастом-провайдера. В Desktop-версии заголовки не задаются — только CLI или конфиг-файл. Раз заголовки произвольные, тот же приём работает и с api.vega.chat.

У Aider заголовки прописываются в настройках модели:

YAML

- name: openrouter/anthropic/claude-sonnet-4
  extra_params:
    extra_headers:
      X-OpenRouter-Cache: "true"
      X-OpenRouter-Cache-TTL: "3600"

Cline, Roo Code и Kilo Code кастомные заголовки не отправляют. У Cline такой настройки в OpenRouter-провайдере просто нет, запрос на неё висит открытым feature request'ом. Kilo Code умеет прокидывать только поля тела запроса через providerOptions.openrouter, заголовки — нет. Через api.vega.chat эти инструменты всё равно попадают в кэш, потому что он включён по умолчанию, но свой TTL задать не смогут.

OpenCode не шлёт X-OpenRouter-Cache-TTL намеренно: заголовок управляет кэшем ответов, а для вайбкодинга нужнее кэш промптов у провайдера. Его OpenCode продлевает до часа через cache_control: { type: "ephemeral", ttl: "1h" } внутри сообщений. Экономика у него другая: запись в часовой кэш стоит двойной input-тариф, чтение идёт за десятую часть цены, а пауза дольше пяти минут между репликами обнуляет дефолтный кэш — и префикс записывается заново. Параметр prompt_cache_ttl в теле запроса OpenRouter при этом молча игнорирует: через тело этот TTL не передать.

Для инструментов без поддержки заголовков на чистом OpenRouter есть обходной путь — пресет в личном кабинете с cache_enabled: true и cache_ttl_seconds: 3600. Тогда заголовки не нужны вовсе: настройки применяются ко всем запросам пресета, а X-OpenRouter-Cache-TTL в конкретном запросе при необходимости их переопределит. Так работают даже Cline, Roo Code и Cursor. На api.vega.chat пресет не создать — через прокси они доступны только на чтение, поэтому заменить дефолтный TTL здесь может только заголовок.

Ещё один нюанс — браузер. Если инструмент обращается к OpenRouter напрямую из браузера, кастомные заголовки отсечёт CORS: в Access-Control-Allow-Headers разрешён фиксированный список, и X-OpenRouter-Cache-TTL туда не входит.

Где кэш API действительно выручает

Перезапуск агентного воркфлоу

Агент выполнил несколько шагов и упал. При повторном запуске уже пройденные шаги могут вернуться из кэша. Условие: запросы должны совпасть, а записи ещё существовать. Изменившаяся история сообщений или параметры дадут MISS.

Юнит-тесты

После первого прогона идентичные запросы возвращают сохранённые ответы. Это делает повторные прогоны быстрыми и воспроизводимыми в пределах жизни записей. Для детерминизма первой генерации используйте temperature: 0 или фиксированный seed.

Повторные запросы приложения

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

Ограничения response caching

Одновременные запросы не объединяются

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

TTL не гарантирует сохранность

При нехватке памяти запись может быть вытеснена раньше срока. Лимита на число записей нет, но рассчитывать на кэш как на постоянное хранилище нельзя.

Высокая температура не создаёт разнообразия при HIT

Возвращается сохранённый ответ, а не новая генерация. Если нужны разные варианты, выключите кэш на запрос через X-OpenRouter-Cache: false, обновите запись через X-OpenRouter-Cache-Clear или используйте короткий TTL.

Бесплатный хит всё равно резервирует средства

API ВЕГА резервирует оценочную стоимость запроса до обращения к модели. Если баланс не покрывает резерв, придёт 402 — даже когда запрос попал бы в кэш и стоил ноль. После HIT резерв возвращается автоматически.

Account-level ZDR несовместим с кэшем

Механизм требует временного хранения ответа, поэтому при Zero Data Retention на уровне аккаунта не работает. Параметр отдельного запроса provider.zdr на это не влияет.

Ответы хранятся в edge-инфраструктуре на время TTL, затем автоматически удаляются. Они доступны только создавшему их API-ключу, не используются для обучения и не передаются третьим лицам.

Как проверить, что вы попали в кэш

Смотрите на заголовки ответа. Первый вызов обычно выглядит так:

http

X-OpenRouter-Cache-Status: MISS
X-OpenRouter-Cache-TTL: 300

Повторный:

http

X-OpenRouter-Cache-Status: HIT
X-OpenRouter-Cache-Age: 12
X-OpenRouter-Cache-TTL: 288
X-OpenRouter-Cache-Source-Id: <id-исходной-генерации>

На HIT поле TTL показывает оставшееся время, Age показывает возраст записи. Каждый ответ получает новый X-Generation-Id; связь с исходной генерацией показывает X-OpenRouter-Cache-Source-Id.

Дополнительное подтверждение — нулевые счётчики:

JSON

{
  "usage": {
    "prompt_tokens": 0,
    "completion_tokens": 0,
    "total_tokens": 0
  }
}

Итоговая проверка проста: тот же API-ключ, то же тело, тот же эндпоинт и режим стриминга, а в ответе HIT и нулевой usage. Если видите MISS, проверяйте не только промпт, но и сериализацию, параметры и срок жизни записи.

Как попасть в кэш запроса?

Что доступно через API ВЕГА — коротко

Как работает кэширование ответов

Кэш включён по умолчанию — заголовки нужны для управления

Что значит «идентичный запрос»: ключ кэша и ловушки

Порядок полей JSON имеет значение

Явный дефолт отличается от пропущенного поля

Стриминг и API-ключ разделяют кэш

TTL и управление кэшем запроса

Кэш-заголовки в инструментах вайбкодинга

Где кэш API действительно выручает

Перезапуск агентного воркфлоу

Юнит-тесты

Повторные запросы приложения

Ограничения response caching

Одновременные запросы не объединяются

TTL не гарантирует сохранность

Высокая температура не создаёт разнообразия при HIT

Бесплатный хит всё равно резервирует средства

Account-level ZDR несовместим с кэшем

Как проверить, что вы попали в кэш

Комментарии