GPT-Realtime-2: технічний гід — WebSocket API, підключення і приклади коду

Ця стаття — практичний гід для розробників що хочуть підключити GPT-Realtime-2 до свого проєкту. Ми розберемо архітектуру Realtime API, виберемо правильний метод підключення для вашого сценарію, напишемо першу робочу сесію з нуля і налаштуємо preambles, tool calls і recovery з реальним кодом.

Якщо вам потрібен контекст про що взагалі цей реліз і навіщо він важливий — спочатку прочитайте новинну статтю: → OpenAI випустила GPT-Realtime-2: перша голосова модель з GPT-5-рівнем мислення

Коротко: GPT-Realtime-2 підключається через WebSocket (сервер), WebRTC (браузер) або SIP (телефонія). Це не REST API — це постійне двостороннє з'єднання. Усі приклади коду в статті взяті з офіційної документації OpenAI і перевірені на актуальність станом на травень 2026.

Зміст статті

• Realtime API vs Chat Completions API — в чому принципова різниця протоколів
• Архітектура speech-to-speech — як модель обробляє аудіо без проміжних кроків
• Три методи підключення: WebSocket, WebRTC, SIP — який обрати для вашого сценарію
• Підключення через WebSocket — покрокова інструкція з кодом на JS і Python
• Перша робоча сесія: відкриваємо з'єднання, передаємо аудіо, отримуємо відповідь
• Preambles, паралельні tool calls і recovery — налаштування і приклади коду
• Reasoning effort і context window — як налаштувати баланс між якістю, швидкістю і вартістю
• GPT-Realtime-Translate і GPT-Realtime-Whisper — підключення і сценарії використання
• Типові помилки і як їх уникнути
• FAQ
• Висновки

Realtime API vs Chat Completions API — в чому принципова різниця протоколів

Перш ніж писати код, важливо зрозуміти з чим ви працюєте. Realtime API і Chat Completions API — не дві версії одного інструменту. Це принципово різні протоколи для різних задач.

Chat Completions API — HTTP запит-відповідь

Chat Completions API працює за класичною схемою HTTP:

1. Клієнт відправляє POST-запит з повідомленнями
2. Сервер обробляє і повертає відповідь
3. З'єднання закривається

Навіть streaming у Chat Completions (коли текст з'являється поступово) реалізований через Server-Sent Events (SSE) — технічно це однонаправлений потік поверх HTTP, а не двостороннє з'єднання. Клієнт слухає, сервер пише — але не навпаки одночасно.

Realtime API — постійний двосторонній WebSocket

Realtime API працює через WebSocket — протокол що встановлює постійне з'єднання між клієнтом і сервером. Після handshake обидві сторони можуть надсилати дані в будь-який момент незалежно одна від одної:

• Клієнт стримить аудіо-чанки поки користувач говорить
• Модель відповідає аудіо-чанками ще до кінця питання
• Обидва потоки йдуть одночасно через одне з'єднання
• З'єднання живе весь час розмови (максимум 60 хвилин на сесію)

Ключова різниця для розробника: у Chat Completions ви відправляєте запит і чекаєте. У Realtime API ви підтримуєте постійне з'єднання і реагуєте на події. Це ближче до розробки WebSocket-чату ніж до звичайного API-клієнта. Якщо ви раніше не працювали з WebSocket — закладайте час на ознайомлення з event-driven моделлю.

Порівняльна таблиця:

Архітектура speech-to-speech — як модель обробляє аудіо без проміжних кроків

Розуміння того як модель обробляє аудіо всередині — важливо для правильного проектування системи і розуміння чому затримка така як є.

Старий підхід: каскадний пайплайн

До появи end-to-end голосових моделей стандартна архітектура виглядала так:

Мікрофон → [ASR] → Текст → [LLM] → Текст → [TTS] → Аудіо
           ~300мс          ~2-6с          ~300мс

Кожна стрілка — окремий HTTP-запит або сервіс. Кожен крок додає затримку. Reasoning всередині LLM збільшував другий крок до 5–7 секунд. Загальна затримка: 1.5–8 секунд залежно від складності.

GPT-Realtime-2: end-to-end аудіо

GPT-Realtime-2 замінює весь каскад однією моделлю:

Мікрофон → [GPT-Realtime-2] → Аудіо
                ~500-1200мс (перший turn)
                ~300-600мс  (наступні turns)

Аудіо приходить на вхід, reasoning відбувається всередині моделі в аудіо-просторі, аудіо виходить на виході. Немає конвертації в текст між кроками — це усуває latency на переходах і дозволяє моделі краще розуміти тон, паузи і перебивання.

Формат аудіо

Realtime API приймає і повертає аудіо у форматі PCM16 з частотою 24 000 Гц (або Opus). Це важливо знати при інтеграції з мікрофоном або телефонною системою — формат потрібно конвертувати до передачі.

Event-driven модель взаємодії

Сесія керується через client events і server events. Клієнт відправляє події — сервер реагує подіями. Основні типи:

Client events (відправляєте ви):

• session.update — оновлення конфігурації сесії (інструкції, голос, tools)
• input_audio_buffer.append — відправка чанку аудіо
• input_audio_buffer.commit — сигнал що turn завершено
• response.create — запит на генерацію відповіді
• conversation.item.create — додавання текстового повідомлення

Server events (отримуєте ви):

• session.created — сесія готова
• session.updated — підтвердження оновлення
• response.audio.delta — чанк аудіо-відповіді
• response.text.delta — чанк текстової транскрипції
• response.function_call_arguments.delta — аргументи tool call
• response.done — відповідь завершена
• error — помилка сесії

Максимальна тривалість однієї Realtime-сесії — 60 хвилин. Після цього з'єднання закривається і потрібно відкривати нову сесію. Плануйте логіку reconnect якщо ваш сценарій передбачає довші взаємодії.

Три методи підключення: WebSocket, WebRTC, SIP — який обрати для вашого сценарію

Realtime API підтримує три методи підключення. Вибір залежить не від переваги, а від того де знаходиться аудіо у вашій системі.

WebSocket — для серверних застосунків

WebSocket підходить для server-to-server інтеграцій: Node.js бекенд, Python сервіс, будь-який серверний застосунок що вже має аудіо або обробляє його на сервері.

Переваги: повний контроль над сесією, підходить для складних агентських флоу, можна використовувати звичайний API ключ (не потрібен ephemeral token).

Обмеження: ви самі відповідаєте за захоплення і передачу Base64-кодованих аудіо-чанків.

WebRTC — для браузерних застосунків

WebRTC — рекомендований метод для браузерних і мобільних клієнтів де аудіо захоплюється прямо з мікрофона користувача. WebRTC оптимізований для мінімальної затримки в real-time аудіо.

Для браузерного підключення потрібен ephemeral token (короткочасний ключ) — ваш основний API ключ не можна використовувати на клієнті. Ephemeral token генерується на вашому бекенді і передається клієнту.

SIP — для телефонії

SIP — для інтеграції з телефонними системами. Якщо ви будуєте агента для реальних телефонних дзвінків — це офіційний протокол. У 2026 році нативний SIP endpoint OpenAI ще в beta; для production більшість команд використовує SIP через Twilio або Telnyx як міст до WebSocket.

Таблиця вибору методу:

Браузер / мобільний додаток → WebRTC (+ ephemeral token з вашого бекенду)
Node.js / Python бекенд → WebSocket (прямий API ключ)
Реальні телефонні дзвінки → SIP (або SIP через Twilio/Telnyx → WebSocket)
Deno / Cloudflare Workers → WebSocket через стандартний браузерний WebSocket API

Підключення через WebSocket — покрокова інструкція з кодом на JS і Python

Розберемо підключення через WebSocket — найпоширеніший метод для серверних застосунків. Всі приклади взяті з офіційної документації OpenAI.

Крок 1. Встановлення залежностей

Node.js:

npm install ws

Python:

pip install websocket-client

Крок 2. Підключення до Realtime API

JavaScript (Node.js):

import WebSocket from "ws";

const url = "wss://api.openai.com/v1/realtime?model=gpt-realtime-2";

const ws = new WebSocket(url, {
  headers: {
    Authorization: "Bearer " + process.env.OPENAI_API_KEY,
    // Якщо у вашому застосунку є ідентифікатори користувачів —
    // передавайте hashed user ID для safety моніторингу
    "OpenAI-Safety-Identifier": "hashed-user-id",
  },
});

ws.on("open", function open() {
  console.log("З'єднання встановлено");
});

ws.on("message", function incoming(message) {
  const event = JSON.parse(message.toString());
  console.log("Подія від сервера:", event.type);
});

ws.on("error", function error(err) {
  console.error("WebSocket помилка:", err);
});

ws.on("close", function close() {
  console.log("З'єднання закрито");
});

Python:

import os
import json
import websocket

OPENAI_API_KEY = os.environ.get("OPENAI_API_KEY")
url = "wss://api.openai.com/v1/realtime?model=gpt-realtime-2"

headers = [
    "Authorization: Bearer " + OPENAI_API_KEY,
    "OpenAI-Safety-Identifier: hashed-user-id",
]

def on_open(ws):
    print("З'єднання встановлено")

def on_message(ws, message):
    data = json.loads(message)
    print("Подія:", data["type"])

def on_error(ws, error):
    print("Помилка:", error)

def on_close(ws, close_status_code, close_msg):
    print("З'єднання закрито")

ws = websocket.WebSocketApp(
    url,
    header=headers,
    on_open=on_open,
    on_message=on_message,
    on_error=on_error,
    on_close=on_close,
)

ws.run_forever()

Крок 3. Налаштування сесії через session.update

Одразу після отримання події session.created — відправте session.update з конфігурацією:

// JavaScript
ws.on("open", function open() {
  // Відправляємо конфігурацію сесії
  ws.send(JSON.stringify({
    type: "session.update",
    session: {
      type: "realtime",
      model: "gpt-realtime-2",
      // Формат аудіо: PCM16 24kHz
      output_modalities: ["audio"],
      audio: {
        input: {
          format: {
            type: "audio/pcm",
            rate: 24000,
          },
          // Semantic VAD — модель сама визначає кінець фрази
          turn_detection: {
            type: "semantic_vad"
          }
        },
        output: {
          format: {
            type: "audio/pcm",
          },
          // Голос: alloy, echo, shimmer, cedar, marin
          voice: "marin",
        }
      },
      instructions: "Ви — корисний асистент. Відповідайте стисло і по суті.",
    }
  }));
});

Важливо про голос: голос можна змінити тільки якщо модель ще не відправила жодної аудіо-відповіді у цій сесії. Після першої аудіо-відповіді — voice стає незмінним на весь час сесії. Плануйте вибір голосу заздалегідь.

Перша робоча сесія: відкриваємо з'єднання, передаємо аудіо, отримуємо відповідь

Тепер зберемо повний цикл: підключення → конфігурація → передача аудіо → отримання відповіді.

Потік подій у WebSocket-сесії

Ось послідовність подій для типового голосового turn:

Клієнт                          Сервер
  |                                |
  |--- WebSocket connect --------->|
  |<-- session.created ------------|
  |                                |
  |--- session.update ------------>|
  |<-- session.updated ------------|
  |                                |
  |--- input_audio_buffer.append ->| (повторюється для кожного чанку)
  |--- input_audio_buffer.commit ->| (або semantic_vad зробить це автоматично)
  |--- response.create ----------->|
  |                                |
  |<-- response.audio.delta -------| (повторюється — кожен чанк аудіо)
  |<-- response.text.delta --------| (транскрипція відповіді)
  |<-- response.done --------------|

Передача аудіо чанками

Аудіо передається як Base64-кодовані чанки через input_audio_buffer.append. При використанні semantic_vad — модель сама визначає коли користувач закінчив говорити і запускає відповідь. При ручному управлінні — ви самі відправляєте input_audio_buffer.commit:

// Відправка аудіо-чанку (Base64-кодований PCM16)
function sendAudioChunk(audioBuffer) {
  const base64Audio = Buffer.from(audioBuffer).toString("base64");

  ws.send(JSON.stringify({
    type: "input_audio_buffer.append",
    audio: base64Audio,
  }));
}

// Ручне завершення turn (якщо не використовуєте semantic_vad)
function commitAudio() {
  ws.send(JSON.stringify({
    type: "input_audio_buffer.commit",
  }));

  // Запит відповіді
  ws.send(JSON.stringify({
    type: "response.create",
  }));
}

Обробка аудіо-відповіді

ws.on("message", function incoming(message) {
  const event = JSON.parse(message.toString());

  switch (event.type) {
    case "session.created":
      console.log("Сесія готова:", event.session.id);
      // Тут відправляємо session.update
      break;

    case "response.audio.delta":
      // Отримали чанк аудіо — відтворюємо
      const audioChunk = Buffer.from(event.delta, "base64");
      playAudio(audioChunk); // ваша функція відтворення
      break;

    case "response.text.delta":
      // Текстова транскрипція відповіді
      process.stdout.write(event.delta);
      break;

    case "response.done":
      console.log("\nВідповідь завершена");
      break;

    case "error":
      console.error("Помилка сесії:", event.error);
      break;
  }
});

Preambles, паралельні tool calls і recovery — налаштування і приклади коду

Preambles — як налаштувати фрази під час мислення

Preambles — короткі фрази що модель вимовляє поки reasoning іде у фоні. Вмикаються в session.update через instructions:

ws.send(JSON.stringify({
  type: "session.update",
  session: {
    type: "realtime",
    model: "gpt-realtime-2",
    instructions: `Ви — корисний асистент.

Перед кожною відповіддю що потребує пошуку або обчислення — 
вимовляйте коротку фразу: 'хвилинку', 'зараз перевірю', 
'один момент' або схожу. Це дасть користувачу знати що ви працюєте.

Якщо викликаєте calendar_tool — кажіть 'перевіряю ваш календар'.
Якщо викликаєте order_tool — кажіть 'шукаю ваше замовлення'.`,
  }
}));

Preambles — це не окремий параметр API, а інструкція моделі у системному промпті. Модель GPT-Realtime-2 дотримується цих інструкцій і генерує preamble контекстно — залежно від того який tool вона збирається викликати.

Tool calls — реєстрація і обробка

Tools реєструються в session.update і працюють так само як function calling у Chat Completions — але асинхронно через події:

// Реєстрація tools у сесії
ws.send(JSON.stringify({
  type: "session.update",
  session: {
    type: "realtime",
    model: "gpt-realtime-2",
    tools: [
      {
        type: "function",
        name: "get_order_status",
        description: "Отримати статус замовлення за його номером",
        parameters: {
          type: "object",
          properties: {
            order_id: {
              type: "string",
              description: "Номер замовлення, наприклад ORD-12345"
            }
          },
          required: ["order_id"]
        }
      },
      {
        type: "function",
        name: "check_calendar",
        description: "Перевірити доступні слоти в календарі",
        parameters: {
          type: "object",
          properties: {
            date: {
              type: "string",
              description: "Дата у форматі YYYY-MM-DD"
            }
          },
          required: ["date"]
        }
      }
    ],
    tool_choice: "auto", // модель сама вирішує коли викликати tools
  }
}));

// Обробка tool call від сервера
ws.on("message", function incoming(message) {
  const event = JSON.parse(message.toString());

  if (event.type === "response.function_call_arguments.done") {
    const toolName = event.name;
    const args = JSON.parse(event.arguments);

    // Виконуємо tool call на вашому бекенді
    const result = await executeToolCall(toolName, args);

    // Повертаємо результат у сесію
    ws.send(JSON.stringify({
      type: "conversation.item.create",
      item: {
        type: "function_call_output",
        call_id: event.call_id,
        output: JSON.stringify(result),
      }
    }));

    // Просимо модель продовжити розмову з результатом
    ws.send(JSON.stringify({
      type: "response.create",
    }));
  }
});

Recovery — обробка помилок у сесії

GPT-Realtime-2 обробляє помилки нативно і озвучує їх користувачу. Але на рівні коду варто обробляти і серверні error події:

ws.on("message", function incoming(message) {
  const event = JSON.parse(message.toString());

  if (event.type === "error") {
    console.error("Помилка сесії:", event.error.code, event.error.message);

    // Якщо помилка rate limit — чекаємо і перепідключаємось
    if (event.error.code === "rate_limit_exceeded") {
      setTimeout(() => reconnect(), 5000);
    }

    // Якщо сесія протухла — відкриваємо нову
    if (event.error.code === "session_expired") {
      openNewSession();
    }
  }
});

Reasoning effort і context window — як налаштувати баланс між якістю, швидкістю і вартістю

Reasoning effort: п'ять рівнів

GPT-Realtime-2 підтримує п'ять рівнів reasoning effort що налаштовуються через session.update:

ws.send(JSON.stringify({
  type: "session.update",
  session: {
    type: "realtime",
    model: "gpt-realtime-2",
    // Доступні значення: "minimal", "low", "medium", "high", "xhigh"
    // Дефолт: "low"
    reasoning_effort: "medium",
  }
}));

Практичний вибір рівня:

Практична порада: маркетингові бенчмарки OpenAI (+15.2% Big Bench Audio, +13.8% Audio MultiChallenge) виміряні на рівні high / xhigh. При дефолтному low — результати інші. Починайте з low, вимірюйте якість на реальних сценаріях і піднімайте effort тільки там де є об'єктивна проблема з якістю відповідей.

Context window 128K — що це означає на практиці

128K токенів контексту — це приблизно:

• ~60–90 хвилин голосового діалогу (залежно від щільності мовлення)
• Повна сесія з 10–15 tool calls і їх результатами
• Детальний системний промпт + вся історія клієнта + поточна розмова

Важливо: аудіо-токени коштують значно більше ніж текстові. При 128K контексті вся сума токенів (включно з аудіо-чанками) не повинна перевищувати цей ліміт. Для дуже довгих сесій потрібна логіка compaction — стискання контексту:

// Якщо сесія наближається до ліміту — 
// можна stitch контекст через Responses API і починати нову сесію
// з компактним summary попередньої розмови

// Перевірка використання токенів у події response.done:
if (event.type === "response.done") {
  const usage = event.response.usage;
  console.log("Використано токенів:", usage.total_tokens);

  if (usage.total_tokens > 100000) {
    // Підходимо до ліміту — плануємо compaction
    scheduleContextCompaction();
  }
}

GPT-Realtime-Translate і GPT-Realtime-Whisper — підключення і сценарії використання

GPT-Realtime-Translate — живий переклад

Підключається через той самий Realtime API, але з іншим типом сесії. Офіційна документація рекомендує WebRTC для браузерного медіа і WebSocket для серверних медіа-пайплайнів.

Ключова різниця в конфігурації: для Translate не потрібно викликати response.create — переклад починається автоматично як тільки є аудіо.

// Конфігурація сесії для live-перекладу
ws.send(JSON.stringify({
  type: "session.update",
  session: {
    type: "translation", // Тип сесії — translation
    model: "gpt-realtime-translate",
    translation: {
      source_language: "uk", // мова вхідного мовлення
      target_language: "en", // мова виходу
    }
    // Не викликайте response.create — переклад йде автоматично
  }
}));

Підтримувані вихідні мови (13): англійська, іспанська, французька, німецька, португальська, японська, корейська, китайська (спрощена), арабська, хінді, італійська, нідерландська, польська.

Вхідних мов — 70+, включаючи українську, російську, турецьку, хінді, тамільську, телугу та інші.

GPT-Realtime-Whisper — потокова транскрипція

Для транскрипції використовується окремий тип сесії transcription:

// Конфігурація сесії для потокової транскрипції
ws.send(JSON.stringify({
  type: "session.update",
  session: {
    type: "transcription", // Тип сесії — transcription
    model: "gpt-realtime-whisper",
    transcription: {
      language: "uk", // мова транскрипції (опціонально, auto-detect якщо не вказано)
      // Регулювання затримки:
      // низьке значення = швидші часткові транскрипти
      // високе значення = краща якість
      delay: "low", // "low" | "medium" | "high"
    }
  }
}));

// Отримання транскриптів
ws.on("message", function incoming(message) {
  const event = JSON.parse(message.toString());

  if (event.type === "conversation.item.input_audio_transcription.delta") {
    // Частковий транскрипт — з'являється в реальному часі
    process.stdout.write(event.delta);
  }

  if (event.type === "conversation.item.input_audio_transcription.completed") {
    // Фінальний транскрипт turn
    console.log("\nФінал:", event.transcript);
  }
});

Whisper ≠ GPT-Realtime-Whisper: класичний whisper-1 через Speech-to-Text API — це batch-транскрипція готового аудіофайлу після запису. GPT-Realtime-Whisper — потокова, слово за словом, поки людина ще говорить. Різні endpoint-и, різна модель, різний сценарій. Не замінюйте один одним.

Типові помилки і як їх уникнути

❌ Спроба підключитись через OpenRouter або інший агрегатор

OpenRouter і аналогічні агрегатори побудовані на HTTP-інфраструктурі. Realtime API потребує WebSocket. Архітектурна несумісність — не вирішується налаштуваннями. Єдине рішення: прямий ключ OpenAI.

❌ Використання API ключа на клієнті (браузер) при WebSocket

При підключенні через WebSocket з браузера не передавайте основний API ключ — він буде видимий у коді. Для браузерних клієнтів використовуйте WebRTC з ephemeral token що генерується на вашому бекенді:

// На вашому бекенді — генеруємо ephemeral token
const response = await fetch("https://api.openai.com/v1/realtime/client_secrets", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    session: {
      type: "realtime",
      model: "gpt-realtime-2",
      audio: { output: { voice: "marin" } },
    },
  }),
});
const data = await response.json();
const ephemeralKey = data.value; // передаємо клієнту

❌ Не обробляти reconnect при session_expired

Максимум сесії — 60 хвилин. Без логіки reconnect ваш агент просто зависне після години. Реалізуйте автоматичне перепідключення з передачею скороченого контексту попередньої розмови.

❌ Встановити xhigh effort для всіх запитів

xhigh = максимальна якість, але і максимальна затримка (~2-3с) і максимальна кількість output-токенів. Для FAQ-агента з тисячами дзвінків на місяць різниця у вартості між low і xhigh може бути в рази. Починайте з low, вимірюйте, підвищуйте точково.

❌ Ігнорувати формат аудіо

Realtime API очікує PCM16 з частотою 24 000 Гц. Якщо ваш мікрофон або телефонна система дає інший формат — конвертуйте до передачі. Неправильний формат дасть або тишу, або спотворену мову без явної помилки в API.

❌ Змінювати голос після першої аудіо-відповіді

Голос фіксується після першої аудіо-відповіді моделі. Спроба змінити voice через session.update після цього — ігнорується без помилки. Якщо потрібно змінити голос — відкривайте нову сесію.

FAQ

Чи потрібен окремий API ключ для Realtime API?
Ні. Якщо у вас вже є ключ для GPT-4o або GPT-5 — він підійде і для Realtime API. Той самий ключ, той самий акаунт на platform.openai.com.

Як протестувати GPT-Realtime-2 без коду?
Через OpenAI Playground — там є інтерфейс для Realtime моделей з мікрофоном прямо в браузері. Найшвидший спосіб почути модель до написання коду.

Чи можна використовувати GPT-Realtime-2 через OpenRouter?
Ні. OpenRouter побудований на HTTP-інфраструктурі, Realtime API потребує WebSocket. Архітектурна несумісність.

Яка максимальна тривалість сесії?
60 хвилин. Після цього сервер закриває з'єднання. Реалізуйте логіку reconnect для довших взаємодій.

Чи підтримується українська мова?
Так — і для GPT-Realtime-2 (розуміє і відповідає), і як вхідна мова для GPT-Realtime-Translate (70+ вхідних мов включають українську), і для GPT-Realtime-Whisper (транскрипція).

Що таке semantic_vad і коли його використовувати?
Voice Activity Detection — механізм що визначає кінець фрази користувача. semantic_vad використовує розуміння контексту щоб не обривати речення посередині. Рекомендується для більшості сценаріїв — краще ніж класичний silence-based VAD що ріже речення при природних паузах.

Як рахуються токени для аудіо?
1 секунда аудіо ≈ 40 токенів. При вартості $32/1M input токенів — 1 хвилина аудіо на вході коштує приблизно $0.077. Детальний розрахунок вартості — в офіційній документації.

Висновки

GPT-Realtime-2 — це інший тип інтеграції порівняно з Chat Completions API. Event-driven модель, постійне WebSocket-з'єднання, Base64-кодовані аудіо-чанки — якщо ви раніше не працювали з цим стеком, закладайте час на ознайомлення.

Але архітектурно все зводиться до кількох ключових речей:

• Вибрати правильний метод: WebSocket (сервер), WebRTC (браузер), SIP (телефонія)
• Відкрити з'єднання → отримати session.created → відправити session.update
• Стримити аудіо чанками через input_audio_buffer.append
• Реагувати на response.audio.delta і відтворювати аудіо
• Обробляти tool calls і повертати результати через conversation.item.create

Починайте з Playground для первинного тесту, потім берете WebSocket приклад з цієї статті і адаптуєте під свій стек. Reasoning effort — починайте з low.

Контекст про сам реліз, реальні кейси і порівняння моделей — в новинній статті:

→ OpenAI випустила GPT-Realtime-2: перша голосова модель з GPT-5-рівнем мислення

Якщо вас цікавить ширша OpenAI-екосистема для розробників:

→ Codex від OpenAI: повний гід 2026

Джерела: OpenAI Realtime API Overview, WebSocket Guide, WebRTC Guide, SIP Guide, Managing Conversations, Managing Costs