Чтобы получить чистый Markdown любой страницы, добавьте .md к URL страницы.
Для полного индекса документации см. https://api.vega.chat/docs/llms.txt.
Для полного содержания документации см. https://api.vega.chat/docs/llms-full.txt.
Для интеграции AI‑клиентов (Claude Code, Cursor и др.) подключитесь к серверу MCP по адресу https://api.vega.chat/docs/_mcp/server.
Кеширование подсказок
Чтобы сэкономить на расходах на вывод, вы можете включить кеширование подсказок у поддерживаемых провайдеров и моделей.
Большинство провайдеров автоматически включают кеширование подсказок, но имейте в виду, что некоторые (см. ниже Alibaba и Anthropic) требуют включать его для каждого сообщения отдельно.
При использовании кеширования (будь то автоматическое в поддерживаемых моделях или через свойство cache_control), VEGA использует provider sticky routing для максимального количества попаданий в кеш — подробнее см. раздел Provider Sticky Routing ниже.
Provider Sticky Routing
Чтобы максимизировать процент попаданий в кеш, VEGA использует provider sticky routing для направления последующих запросов к тому же конечному пункту провайдера после кешированного запроса. Это работает автоматически как с неявным кешированием (например, OpenAI, DeepSeek, Gemini 2.5), так и с явным кешированием (например, точки прерывания cache_control от Anthropic).
Как это работает:
- После запроса, использующего кеширование подсказок, VEGA запоминает, какой провайдер обслужил ваш запрос.
- Последующие запросы к той же модели направляются к тому же провайдеру, поддерживая ваш кеш в «тёплом» состоянии.
- Привязка к провайдеру активируется только тогда, когда стоимость чтения кеша у провайдера ниже, чем обычная цена за подсказку, гарантируя экономию.
- Если выбранный провайдер становится недоступным, VEGA автоматически переключается на следующий лучший провайдер.
- Привязка к провайдеру не используется, если вы задаёте ручной порядок провайдеров через
provider.order— в этом случае приоритет имеет ваш явный порядок.
Гранулярность привязки к провайдеру:
Привязка к провайдеру отслеживается на уровне аккаунта, модели и беседы. По умолчанию VEGA идентифицирует беседы, хешируя первое системное (или developer) сообщение и первое сообщение, не являющееся системным, в каждом запросе, поэтому запросы с одинаковыми начальными сообщениями направляются к одному и тому же провайдеру. Это означает, что разные беседы естественно привязываются к разным провайдерам, улучшая балансировку нагрузки и пропускную способность, одновременно поддерживая кеш в «тёплом» состоянии внутри каждой беседы.
Использование session_id для привязанных сессий
Для более явного контроля над привязкой к провайдеру вы можете передать session_id в запросе. Когда session_id присутствует, VEGA использует его напрямую в качестве ключа привязки, вместо того чтобы генерировать его из хеширования сообщений. Это особенно полезно в многошаговых агентных рабочих процессах, где начальные сообщения могут изменяться между запросами, но вы всё равно хотите направлять их к одному и тому же провайдеру.
Вы можете указать session_id двумя способами:
- Тело запроса: включите
session_idкак поле верхнего уровня в теле запроса. Если указаны оба, значение из тела имеет приоритет. - Заголовок: установите HTTP‑заголовок
x-session-id.
session_id может содержать не более 256 символов.
{
"model": "anthropic/claude-sonnet-4",
"session_id": "my-agent-session-abc123",
"messages": [
{
"role": "user",
"content": "Continue our conversation..."
}
]
}Когда session_id установлен, привязка к провайдеру активируется при любом успешном запросе — даже до того, как будет замечено использование кеша — так что последующие запросы в той же сессии сразу получают выгоду от кеширования подсказок. Без session_id привязка активируется только после обнаружения попадания в кеш.
Проверка использования кеша
Чтобы увидеть, сколько кеширование сэкономило на каждой генерации, вы можете:
- Нажать кнопку деталей на странице Activity.
- Воспользоваться API
/api/v1/generation, описанным здесь. - Проверить объект
prompt_tokens_detailsв ответе об использовании, включённом в каждый ответ API.
Поле cache_discount в теле ответа покажет, сколько было сэкономлено за счёт использования кеша. Некоторые провайдеры, такие как Anthropic, могут иметь отрицательную скидку при записи в кеш, но положительную скидку (снижающую общую стоимость) при чтении из кеша.
Поля объекта usage
Объект usage в ответах API содержит детальные метрики кеша в поле prompt_tokens_details:
{
"usage": {
"prompt_tokens": 10339,
"completion_tokens": 60,
"total_tokens": 10399,
"prompt_tokens_details": {
"cached_tokens": 10318,
"cache_write_tokens": 0
}
}
}Ключевые поля:
cached_tokens: количество токенов, считанных из кеша (попадание в кеш). Когда значение больше нуля, вы получаете выгоду от кешированного контента.cache_write_tokens: количество токенов, записанных в кеш. Появляется в первом запросе при создании новой записи кеша.
OpenAI
Изменения цен на кеширование:
- Запись в кеш: бесплатно
- Чтение из кеша: (в зависимости от модели) стоимость 0.25x или 0.5x цены оригинального ввода
Нажмите здесь, чтобы посмотреть цены на кеширование OpenAI по моделям.
Кеширование подсказок в OpenAI автоматизировано и не требует дополнительной настройки. Минимальный размер подсказки — 1024 токена.
Нажмите здесь, чтобы узнать больше о кешировании подсказок в OpenAI и его ограничениях.
Grok
Изменения цен на кеширование:
- Запись в кеш: бесплатно
- Чтение из кеша: стоимость {GROK_CACHE_READ_MULTIPLIER}x цены оригинального ввода
Нажмите здесь, чтобы посмотреть цены на кеширование Grok по моделям.
Кеширование подсказок в Grok автоматизировано и не требует дополнительной настройки.
Moonshot AI
Изменения цен на кеширование:
- Запись в кеш: бесплатно
- Чтение из кеша: стоимость {MOONSHOT_CACHE_READ_MULTIPLIER}x цены оригинального ввода
Кеширование подсказок в Moonshot AI автоматизировано и не требует дополнительной настройки.
Groq
Изменения цен на кеширование:
- Запись в кеш: бесплатно
- Чтение из кеша: стоимость {GROQ_CACHE_READ_MULTIPLIER}x цены оригинального ввода
Кеширование подсказок в Groq автоматизировано и не требует дополнительной настройки. В настоящее время доступно на моделях Kimi K2.
Нажмите здесь, чтобы посмотреть документацию Groq.
Alibaba Qwen
Изменения цен на кеширование при явном кешировании:
- Запись в кеш: стоимость {ALIBABA_CACHE_WRITE_MULTIPLIER}x цены оригинального ввода
- Чтение из кеша: стоимость {ALIBABA_CACHE_READ_MULTIPLIER}x цены оригинального ввода
Alibaba требует явных точек прерывания кеша. Добавьте cache_control: { "type": "ephemeral" } к блокам контента, которые вы хотите кешировать, используя тот же синтаксис, что и у Anthropic. Записи в кеш используют TTL 5 минут.
Явное кеширование в Alibaba доступно для моделей deepseek/deepseek-v3.2, qwen/qwen3-max, qwen/qwen-plus, qwen/qwen3.6-plus, qwen/qwen3-coder-plus и qwen/qwen3-coder-flash. Точки доступа Snapshot, включая qwen/qwen3.5-plus-02-15 и qwen/qwen3.5-flash-02-23, не поддерживают явное кеширование.
Пример
{
"model": "qwen/qwen3-coder-plus",
"messages": [
{
"role": "user",
"content": [
{
"type": "text",
"text": "Use the reference below when answering."
},
{
"type": "text",
"text": "HUGE TEXT BODY",
"cache_control": {
"type": "ephemeral"
}
},
{
"type": "text",
"text": "Summarize the main implementation details."
}
]
}
]
}Anthropic Claude
Изменения цен на кеширование:
- Запись в кеш (TTL 5 минут): стоимость {ANTHROPIC_CACHE_WRITE_MULTIPLIER}x цены оригинального ввода
- Запись в кеш (TTL 1 час): стоимость 2x цены оригинального ввода
- Чтение из кеша: стоимость {ANTHROPIC_CACHE_READ_MULTIPLIER}x цены оригинального ввода
Существует два способа включить кеширование подсказок в Anthropic:
- Автоматическое кеширование: добавьте единственное поле
cache_controlна верхнем уровне вашего запроса. Система автоматически применяет точку прерывания кеша к последнему кешируемому блоку и продвигает её вперёд по мере роста беседы. Лучший вариант для многошаговых диалогов. - Явные точки прерывания кеша: разместите
cache_controlнепосредственно на отдельных блоках контента для тонкой настройки того, что именно кешировать. Ограничение — четыре явные точки прерывания. Рекомендуется использовать их для больших объёмов текста, таких как карточки персонажей, CSV‑данные, RAG‑данные, главы книг и т.д.
Автоматическое кеширование (верхний уровень cache_control) поддерживается только когда запросы направляются непосредственно к провайдеру Anthropic. Amazon Bedrock и Google Vertex AI в настоящее время не поддерживают cache_control верхнего уровня — когда он присутствует, VEGA будет направлять запросы только к провайдеру Anthropic и исключать конечные точки Bedrock и Vertex. Явные точки прерывания cache_control на уровне блоков работают со всеми совместимыми с Anthropic провайдерами, включая Bedrock и Vertex.
Поддержка Responses API: Responses API поддерживает только автоматическое кеширование через cache_control верхнего уровня. Явные точки прерывания cache_control внутри элементов input не доступны через Responses API — используйте Chat Completions или Anthropic Messages API, если нужны тонкие точки прерывания.
По умолчанию кеш истекает через 5 минут, но вы можете увеличить срок до 1 часа, указав "ttl": "1h" в объекте cache_control.
Нажмите здесь, чтобы узнать больше о кешировании подсказок Anthropic и его ограничениях.
Минимальные требования к токенам
У каждой модели есть минимальная длина подсказки, пригодной для кеширования (см. ограничения кеша Anthropic):
- 4 096 токенов: Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6, Claude Opus 4.5, Claude Haiku 4.5
- 2 048 токенов: Claude Haiku 3.5
- 1 024 токена: Claude Sonnet 4.6, Claude Sonnet 4.5, Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4
Подсказки короче этих минимумов не будут кешироваться.
Параметры TTL кеша
VEGA поддерживает два значения TTL кеша для Anthropic:
- 5 минут (по умолчанию):
"cache_control": { "type": "ephemeral" } - 1 час:
"cache_control": { "type": "ephemeral", "ttl": "1h" }
TTL в 1 час полезен для длительных сессий, когда необходимо сохранять кешированный контент между несколькими запросами без повторных расходов на запись в кеш. TTL в 1 час стоит дороже при записях в кеш (2x базовой цены ввода против 1.25x для TTL 5 минут), но может экономить деньги в длительных сессиях, избегая повторных записей в кеш. TTL в 1 час для явных точек прерывания кеша поддерживается всеми провайдерами моделей Claude (Anthropic, Amazon Bedrock и Google Vertex AI).
Примеры
Автоматическое кеширование (рекомендовано для многошаговых диалогов)
При автоматическом кешировании добавьте cache_control на верхний уровень запроса. Система автоматически кеширует весь контент до последнего кешируемого блока:
{
"model": "~anthropic/claude-sonnet-latest",
"cache_control": { "type": "ephemeral" },
"messages": [
{
"role": "system",
"content": "You are a historian studying the fall of the Roman Empire. You know the following book very well: HUGE TEXT BODY"
},
{
"role": "user",
"content": "What triggered the collapse?"
}
]
}По мере роста беседы точка прерывания кеша автоматически продвигается, охватывая растущую историю сообщений.
Автоматическое кеширование с TTL 1 час:
{
"model": "~anthropic/claude-sonnet-latest",
"cache_control": { "type": "ephemeral", "ttl": "1h" },
"messages": [
{
"role": "system",
"content": "You are a helpful assistant."
},
{
"role": "user",
"content": "What is the meaning of life?"
}
]
}Явные точки прерывания кеша (тонкая настройка)
Пример кеширования системного сообщения (TTL по умолчанию 5 минут):
{
"messages": [
{
"role": "system",
"content": [
{
"type": "text",
"text": "You are a historian studying the fall of the Roman Empire. You know the following book very well:"
},
{
"type": "text",
"text": "HUGE TEXT BODY",
"cache_control": {
"type": "ephemeral"
}
}
]
},
{
"role": "user",
"content": [
{
"type": "text",
"text": "What triggered the collapse?"
}
]
}
]
}Пример кеширования пользовательского сообщения с TTL 1 час:
{
"messages": [
{
"role": "user",
"content": [
{
"type": "text",
"text": "Given the book below:"
},
{
"type": "text",
"text": "HUGE TEXT BODY",
"cache_control": {
"type": "ephemeral",
"ttl": "1h"
}
},
{
"type": "text",
"text": "Name all the characters in the above book"
}
]
}
]
}DeepSeek
Изменения цен на кеширование:
- Запись в кеш: стоимость такая же, как у оригинального ввода
- Чтение из кеша: стоимость {DEEPSEEK_CACHE_READ_MULTIPLIER}x цены оригинального ввода
Кеширование подсказок в DeepSeek автоматизировано и не требует дополнительной настройки.
Google Gemini
Неявное кеширование
Модели Gemini 2.5 Pro и 2.5 Flash теперь поддерживают неявное кеширование, предоставляя автоматическую функцию кеширования, аналогичную автоматическому кешированию OpenAI. Неявное кеширование работает без проблем — не требуется ручная настройка или дополнительные точки прерывания cache_control.
Изменения цен:
- Нет расходов на запись в кеш или хранение.
- Кешированные токены стоят {GOOGLE_CACHE_READ_MULTIPLIER}x оригинальной цены за ввод.
Обратите внимание, что TTL в среднем 3‑5 минут, но может варьироваться. Для Gemini 2.5 Flash требуется минимум {GOOGLE_CACHE_MIN_TOKENS_2_5_FLASH} токенов, а для Gemini 2.5 Pro — минимум {GOOGLE_CACHE_MIN_TOKENS_2_5_PRO} токенов, чтобы запросы могли быть кешированы.
Официальное объявление от Google
Чтобы максимизировать попадания в неявный кеш, сохраняйте начальную часть массивов сообщений одинаковой между запросами. Вариации (например, вопросы пользователя или динамические элементы контекста) размещайте ближе к концу подсказки/запросов.
Изменения цен для кешированных запросов:
- Запись в кеш: Стоимость равна цене токенов ввода плюс 5 минут хранения кеша, рассчитывается так:
Cache write cost = Input token price + (Cache storage price × (5 minutes / 60 minutes))
- Чтение из кеша: Стоимость {GOOGLE_CACHE_READ_MULTIPLIER}× оригинальной цены токенов ввода.
Поддерживаемые модели и ограничения
Только некоторые модели Gemini поддерживают кеширование. Пожалуйста, обратитесь к документации по ценам Gemini API от Google для актуальной информации.
Записи в кеш имеют время жизни (TTL) 5 минут, которое не обновляется. По истечении 5 минут кеш истекает и необходимо создать новый кеш.
У моделей Gemini обычно минимум 4096 токенов для записи в кеш. Кешированные токены учитываются в максимальном лимите токенов модели. Gemini 2.5 Pro имеет минимум {GOOGLE_CACHE_MIN_TOKENS_2_5_PRO} токенов, а Gemini 2.5 Flash — минимум {GOOGLE_CACHE_MIN_TOKENS_2_5_FLASH} токенов.
Как работает кеширование подсказок Gemini в VEGA:
VEGA упрощает управление кешем Gemini, абстрагируя сложности:
- Вам не нужно вручную создавать, обновлять или удалять кеши.
- Вам не нужно явно управлять именами кешей или TTL.
Как включить кеширование подсказок Gemini:
Кеширование Gemini в VEGA требует явного вставления точек прерывания cache_control в содержимое сообщений, аналогично Anthropic. Мы рекомендуем использовать кеширование в основном для больших фрагментов контента (например, CSV‑файлы, объёмные карточки персонажей, данные RAG или обширные текстовые источники).
Нет ограничения на количество точек прерывания cache_control, которые вы можете включить в запрос. VEGA будет использовать только последнюю точку прерывания для кеширования Gemini в обычном содержимом сообщений. Включение нескольких точек прерывания безопасно и может помочь поддерживать совместимость с Anthropic, но только последняя будет использована для Gemini.
У Gemini есть единственное поле systemInstruction, и кешированный контент Gemini рассматривает его как неизменяемый. В VEGA это означает, что cache_control внутри первого сообщения system или developer может кешировать нормализованную системную подсказку, но не может сохранять некешируемый динамический хвост в том же сообщении. Если вам нужно, чтобы часть подсказки оставалась динамичной, переместите динамический контент в более позднее сообщение user, а не добавляйте его после кешируемого блока в первом сообщении system.
Примеры
Пример кеширования системного сообщения
{
"messages": [
{
"role": "system",
"content": [
{
"type": "text",
"text": "You are a historian studying the fall of the Roman Empire. Below is an extensive reference book:"
},
{
"type": "text",
"text": "HUGE TEXT BODY HERE",
"cache_control": {
"type": "ephemeral"
}
}
]
},
{
"role": "user",
"content": [
{
"type": "text",
"text": "What triggered the collapse?"
}
]
}
]
}Этот шаблон работает, когда кешируемый системный контент стабилен между запросами. Если нужен динамический сегмент подсказки, разместите его в более позднем сообщении user, а не как некешируемый завершающий контент в первом сообщении system.
Пример кеширования пользовательского сообщения
{
"messages": [
{
"role": "user",
"content": [
{
"type": "text",
"text": "Based on the book text below:"
},
{
"type": "text",
"text": "HUGE TEXT BODY HERE",
"cache_control": {
"type": "ephemeral"
}
},
{
"type": "text",
"text": "List all main characters mentioned in the text above."
}
]
}
]
}