Grok Voice Agent API: endpoint, цена, аутентификация и маршрут интеграции (апрель 2026)

Если вам нужно подключить realtime-голос у xAI, лучше сразу уйти от общего вопроса “есть ли у них voice API”. Для разработчика полезный ответ намного конкретнее: текущий открытый вход — Grok Voice Agent API с endpoint wss://api.x.ai/v1/realtime. На 6 апреля 2026 года публичная self-serve спецификация показывает $0.05 / мин, 100 одновременных сессий на команду и 30 минут максимум на сессию. Практически важны три вещи: long-lived API key должен жить только на backend; browser и mobile клиенты должны работать через ephemeral token; а если вам нужна не живая двухсторонняя сессия, а только озвучка готового ответа, то начинать следует не с realtime-маршрута, а с отдельного Text to Speech API.

“

На 6 апреля 2026 года этот материал перепроверен по текущим Voice Agent docs, pricing/model page, voice overview, TTS docs, product page и release notes xAI. Там, где публичные страницы оставляют серую зону, я сохраняю эту границу явно, а не закрываю ее памятью.

Сначала разберите, какой голосовой маршрут вам вообще нужен

Чаще всего путаница начинается с того, что Voice Agent API, TTS, STT и готовые voice frameworks сваливают в один слой. Для проектирования это плохая отправная точка.

Это не словесная придирка, а архитектурная развилка. Если продукт требует turn-taking, аудио туда-обратно, tools в ходе разговора или phone-agent сценарий, правильный выбор — Voice Agent API. Если же ваше приложение и так полностью управляет состоянием и голос нужен только в конце как канал вывода, TTS проще и для интеграции, и для бюджета.

xAI на product page также упоминает Speech to Text. Но на 6 апреля 2026 года разработчику стоит быть осторожным: ясная публичная docs route действительно есть для Voice Agent API и TTS, а для self-serve STT столь же явного маршрута нет. Это не означает, что xAI не умеет speech-to-text. Это означает только то, что сегодня STT не стоит подавать как подтвержденный публичный developer contract без актуальной docs page из той же проверки.

Поэтому самый надежный расклад такой:

• Voice Agent API — когда live voice session и есть продукт
• TTS API — когда голос нужен только как финальный output
• STT — пока остается осторожной, не до конца подтвержденной зоной

Вся публичная информация, с которой можно начинать уже сегодня

Самый быстрый и безопасный путь до первой рабочей сессии

xAI описывает базовый сценарий довольно прямо:

1. открыть WebSocket на wss://api.x.ai/v1/realtime
2. отправить session.update
3. создать пользовательское сообщение через conversation.item.create
4. запросить ответ через response.create

Если вы начинаете с trusted backend, минимальный JavaScript выглядит так:

js
import WebSocket from "ws";

const ws = new WebSocket("wss://api.x.ai/v1/realtime", {
  headers: {
    Authorization: `Bearer ${process.env.XAI_API_KEY}`,
  },
});

ws.on("open", () => {
  ws.send(
    JSON.stringify({
      type: "session.update",
      session: {
        voice: "eve",
        instructions: "You are a helpful assistant.",
        turn_detection: { type: "server_vad" },
      },
    }),
  );

  ws.send(
    JSON.stringify({
      type: "conversation.item.create",
      item: {
        type: "message",
        role: "user",
        content: [{ type: "input_text", text: "Hello!" }],
      },
    }),
  );

  ws.send(JSON.stringify({ type: "response.create" }));
});

Это хороший первый шаг, потому что он сразу фиксирует границу аутентификации. Настоящий ключ остается у вас на backend, и там же контролируется вся socket-сессия. Browser audio capture, WebRTC, phone routing и более тяжелую orchestration можно добавлять после того, как базовый цикл уже подтвержден.

Чаще всего команды ломают себе безопасность в момент, когда решают: “если этот ключ работает на сервере, значит и в браузере пойдет”. Документация xAI говорит обратное: client-side apps должны использовать ephemeral tokens. Для этого существует POST https://api.x.ai/v1/realtime/client_secrets. Backend выпускает короткоживущую credential, а клиент уже с ней открывает realtime socket. В browser path xAI отдельно документирует префикс xai-client-secret. в sec-websocket-protocol.

Базовое правило отсюда простое:

• backend first — это самый быстрый и безопасный старт
• browser / mobile direct — только после того, как backend уже умеет выпускать ephemeral token

Полезно заранее знать и runtime defaults:

• базовый режим turn detection — server_vad
• PCM по умолчанию — 24 kHz
• поддерживаемые форматы — audio/pcm, audio/pcmu, audio/pcma
• публичные built-in voices — eve, ara, rex, sal, leo

Это не декоративные параметры. Они показывают, что API уже оформлен как маршрут для реальных voice-продуктов, а не только как demo surface.

Как считать деньги: minute rate — это только нижний слой

Публичную self-serve спецификацию можно сократить до такого вида:

Но практический бюджет на этом не заканчивается. Самая важная строка на voice pages xAI — не сама минутная ставка, а уточнение, что tools тарифицируются отдельно. Если voice agent внутри разговора дергает function calling, web search, X search, collections или MCP-backed tools, эти вызовы не входят в $0.05 / мин. Minute rate — это пол сессии, а не полный счет.

Простой пример показывает разницу. Десятиминутная voice session по базовой ставке стоит около $0.50. Если в этой же сессии агент делает 20 вызовов web_search, а текущая публичная цена tools — $5 / 1,000 calls, то только поисковый слой добавляет около $0.10. Сам по себе масштаб не пугает, но он меняет экономическую модель: вы строите “voice app” или “retrieval/search agent с аудио-входом и выходом”?

Открыто опубликованные цены на tools сейчас включают как минимум:

• web_search: $5 / 1,000 calls
• x_search: $5 / 1,000 calls
• code_execution: $5 / 1,000 calls
• collections_search / file_search: $2.50 / 1,000 calls

Еще одна ловушка — читать регион и инфраструктуру как одно и то же. Открытая pricing/model page показывает us-east-1 для self-serve route. Product page одновременно говорит о multi-region infrastructure и custom rate limits. Это не один и тот же контракт. Для открытого developer surface ориентируйтесь на pricing/model page. Более широкое infrastructure language стоит воспринимать как enterprise framing, пока у вас нет отдельной договоренности.

Поэтому первый budgeting question должен звучать не “сколько минут говорит пользователь”, а “сколько tools использует средняя сессия и действительно ли эти вызовы нужны в каждом turn”.

Этого уже достаточно для реальных voice workloads, но не надо додумывать лишнего

Если читать разные страницы xAI вперемешку, Voice Agent API легко кажется то слишком широким, то слишком узким. Практически важная трактовка такая: уже открыто опубликованных функций хватает для вполне реальных agent workloads.

Текущая документация явно подтверждает:

• live two-way voice conversation over WebSocket
• built-in voices
• server_vad turn handling
• несколько audio formats, включая telephony-friendly μ-law и A-law
• web_search, x_search, file_search, remote MCP tools и custom functions
• compatibility entrypoint для OpenAI Realtime-style clients

Этого уже достаточно для browser assistants, phone agents, support flows, retrieval-backed voice interfaces и operator copilots. На практике важно удержать две мысли.

Первая: tools — это не боковая функция, а часть основного developer route.
Это не API, который просто “говорит голосом”. Если продукту нужен live lookup, внутренний retrieval или custom functions прямо в ходе разговора, xAI уже оформляет это как стандартную, а не экспериментальную траекторию.

Вторая: compatibility помогает, но не делает миграцию нулевой по стоимости.
xAI пишет, что многие OpenAI Realtime clients и SDK можно завести, просто сменив base URL на wss://api.x.ai/v1/realtime. Это реально полезно. Но та же документация фиксирует различия в event names и unsupported events. Один из самых понятных примеров — response.text.delta у xAI против response.output_text.delta, который могут ждать OpenAI GA-style clients.

Из этого следует рабочее правило миграции:

• общий session mental model во многом переносится
• event handling нельзя считать идентичным по умолчанию
• compatibility note ускоряет старт, но не заменяет один внимательный проход по xAI-specific differences

Если вы уже уперлись не в xAI, а в media plumbing, пора смотреть на frameworks

Во многих статьях route через raw API и route через framework противопоставляют как “лучше” и “хуже”. На практике это вопрос момента.

Если ваш основной вопрос пока в том:

• можно ли вообще быстро поднять рабочую realtime-сессию
• как правильно провести auth boundary
• как посчитать реальную стоимость с учетом tools

то raw Voice Agent API чаще всего и есть лучший старт. Он уже достаточен, чтобы доказать ценность интеграции, не затаскивая вас в более тяжелый media stack слишком рано.

Смысл переходить к готовому voice framework появляется тогда, когда команда уже спотыкается не об xAI, а об такие вещи:

• browser audio capture и playback pipeline слишком сложны сами по себе
• phone routing, telephony и media forwarding стали главным bottleneck
• WebRTC и deployment topology уже тяжелее, чем сам realtime socket

xAI в voice overview прямо отправляет к LiveKit, Twilio, WebRTC и telephony examples. Это хороший сигнал: когда настоящая сложность смещается из “подключить xAI” в “управлять media и orchestration”, framework начинает давать больше, чем еще один день ручной работы вокруг raw API.

Практическое разделение выглядит так:

• Voice Agent API — когда live conversation и есть продукт
• TTS API — когда нужен только one-shot speech output
• Готовый voice framework — когда media plumbing, телефония и orchestration стали тяжелее самого xAI connection

Если вы приходите из OpenAI Realtime, сначала проверьте это

Совместимость, о которой пишет xAI, действительно делает вход проще, чем многим кажется. Но сводить ее к формуле “drop-in compatible” все равно не стоит. Точнее сказать так:

1. Общая схема переносится. Stateful realtime session, streaming events, live audio и tool use остаются узнаваемыми.
2. Endpoint меняется. Основной контракт теперь живет на wss://api.x.ai/v1/realtime.
3. Некоторые event names отличаются. Разница между response.output_text.delta и response.text.delta — уже достаточный пример.
4. Некоторых событий нет. xAI явно перечисляет conversation.item.retrieve, conversation.item.truncate и ряд других unsupported events.

Ценность этого раздела — не в brand comparison, а в чистой migration hygiene. Если у вас уже есть Realtime-oriented client architecture, xAI действительно будет проще, чем полностью новый протокол. Но первый production pass должен проверять event-level behavior, а не только успешный socket handshake.

FAQ

Какой точный endpoint у Grok Voice Agent API?
Используйте wss://api.x.ai/v1/realtime.

Сколько сейчас стоит открытая self-serve поверхность?
Текущая публичная страница показывает $0.05 / мин или $3.00 / час. Вызовы tools считаются отдельно.

Можно ли подключаться прямо из браузера?
Да, но безопасный путь — сначала выпустить ephemeral token на backend и уже им подключать клиента. Long-lived API key в browser code хранить нельзя.

Voice Agent API и TTS API — это одно и то же?
Нет. Voice Agent API — realtime WebSocket API для живого диалога. TTS API — отдельный REST API для разовой генерации речи.

Поддерживаются ли tools?
Да. xAI явно документирует web_search, x_search, file_search, remote MCP tools и custom functions.

Есть ли уже публичный self-serve Speech to Text API?
Product page упоминает Speech to Text, но в этой проверке docs route для Voice Agent API и TTS была заметно яснее. Поэтому STT безопаснее пока считать неподтвержденной публичной developer route.

Какие сейчас публичные лимиты?
Открытая pricing/model page показывает 100 одновременных сессий на команду и максимум 30 минут на сессию.

Вывод

Самый полезный ответ на запрос про “Grok Voice Agent API” состоит не просто в том, что API существует. Важнее другое: xAI уже достаточно четко показал разработчикам свой realtime route, и по нему можно начинать работу, если вы с первого дня разделяете три вещи — точный WebSocket endpoint, auth boundary между server key и client token и второй ценовой слой поверх minute rate. Если именно live voice product и есть ваш сценарий, Voice Agent API — правильная стартовая точка. Если вам нужна только разовая озвучка, быстрее и естественнее перейти на TTS. А если настоящий bottleneck уже сместился в media plumbing, телефонию и orchestration, тогда имеет смысл смотреть на готовые voice frameworks.