Yandex Realtime vs OpenAI Realtime: developer measured latency and migrated production

On July 6, 2026, OpenAI released gpt-realtime — a "speech-to-speech" engine with support for interruptions and natural intonation. A developer building a voice AI receptionist for business on the Russian tech stack quickly assembled a prototype in one evening, compared three approaches by latency, and migrated production to Yandex Realtime.

What did the latency measurements show?

The author measured end-to-end latency using the same method for three variants and got a clear picture.

• Yandex Realtime — ~330 ms (direct connection in Russia without VPN)
• OpenAI gpt-realtime — ~740 ms (VPN-only; not available directly from Russia)
• Old three-tier pipeline (STT → LLM → TTS) — ~4.4 seconds

Yandex beats OpenAI by a factor of two purely due to geography: VPN adds hundreds of milliseconds that no code optimization can remove. The three-tier approach loses to both by a landslide — a 13x difference against Yandex is too large for a voice interface where a pause longer than 500 ms feels like the system is "freezing."

Where both engines stumble

With OpenAI, the developer immediately ran into a 400 endpoint error — it occurs with an incorrect WebSocket request structure and is documented almost nowhere. Debugging took up much of the evening.

The second problem is more serious: the engine struggles with Russian accents. The language model was trained predominantly on English, and this is not fixable by tweaking system prompts — it's an architectural limitation.

Yandex has a higher entry barrier at the authorization level: three access roles and a closed OAuth→IAM exchange that is not documented in detail anywhere. The documentation assumes the developer already works within the Yandex.Cloud ecosystem. Without understanding this scheme, obtaining the first working token is non-trivial.

"Yandex speaks Russian natively.

OpenAI — it doesn't, and this is a fundamental problem for a voice product on the Russian market," the author concludes.

How the migration to Yandex Realtime went

After the measurements, the decision was obvious: the author rewrote production across three key areas.

WebSocket bridge instead of REST. Yandex Realtime works through a persistent WebSocket connection rather than one-off HTTP requests. This required rewriting the audio transmission logic: instead of chunked upload — live PCM streaming.

Live PCM player instead of MP3. The previous scheme encoded responses in MP3 before playback, which added latency. Direct work with PCM removed this step and eliminated artifacts during interruptions — the MP3 codec didn't have time to "close" the frame during sudden stopping.

Interruption without headphones. Yandex Realtime supports echo cancellation at the engine level, so the bot correctly reacts to interruptions even through ordinary speakers. In the old three-tier pipeline this was fundamentally impossible.

The most labor-intensive part turned out to be authorization: it was necessary to manually work through the OAuth→IAM token exchange because there are almost no ready examples in Python.

What this means

For voice products on the Russian market, the choice between OpenAI Realtime and Yandex Realtime is primarily a choice between the convenience of the first prototype and the quality of Russian language in production. Yandex wins on latency and pronunciation, but requires understanding IAM. The old three-tier pipeline belongs in the past: 4.4 seconds of waiting — that's no longer a conversation but an answering machine from 2005.

Frequently asked questions

Can you use OpenAI Realtime in Russia without a VPN?

No: as of July 2026, the service is not available directly from Russian IP addresses. VPN inevitably adds latency and raises it from a potential ~400 ms to ~740 ms under real conditions.

How does Yandex Realtime differ from regular SpeechKit?

Yandex Realtime is a full duplex "speech-to-speech" engine on a single persistent WebSocket connection with support for interruptions. SpeechKit is separate STT and TTS services that need to be manually stitched together into a three-tier pipeline with 4+ second latency.