Hi everyone, We’re currently trying to configure OpenAI’s real-time API in VAPI while enabling the “transcriber for all” option. This is especially important for us because we need strong support for non-English languages. Although the VAPI UI allows this configuration, once enabled the transcription quality drops significantly. From what we can see in OpenAI usage metrics, the dedicated transcriber appears to be barely used, while most of the work is still being handled by the real-time engine instead. Has anyone run into this issue before or found a workaround within VAPI? We’re wondering if there’s a recommended configuration, best practice, or limitation we might be missing. This is currently a blocker for us, so any tips, insights, or suggestions would be greatly appreciated. If you already have a solution and prefer to share it privately, feel free to DM me as well. Thanks in advance!

I’ve seen this happen, VAPI sometimes routes most audio through the real-time engine even with “transcriber for all,” which can hurt non-English accuracy. The key is tweaking chunk size and session settings so the dedicated transcriber actually handles the audio. Are you sending short snippets or full streams? I can walk you through the optimal setup privately. @YarEr

Hi, thanks for reaching out. This is expected with OpenAI Realtime models. Realtime is a native speech‑to‑speech pipeline, so it handles transcription internally and largely bypasses Vapi’s dedicated transcriber. That’s why “transcriber for all” has little effect and why non‑English transcription quality can drop. Recommendation: If strong multilingual support is important, avoid Realtime and use Vapi’s standard pipeline with a multilingual transcriber (e.g. Deepgram Nova (multi), Google STT Multilingual, or Gladia). Realtime optimizes for low latency, not multilingual accuracy. Docs: [https://docs.vapi.ai/openai-realtime\ https://docs.vapi.ai/customization/multilingual](https://docs.vapi.ai/openai-realtimehttps://docs.vapi.ai/customization/multilingual)