Skip to main content
This page is the single source of truth for which languages work on which product today. We publish what is GA and benchmarked, what is accepted but not yet measured, and what is roadmap, so you can plan an integration without guessing.
Short version: English is GA and benchmarked across every product. Omni is going multilingual: agents can be configured for fr, es, de, and hi end to end (recognition, reasoning, and voice), with per-language availability being enabled in stages, French first, then Spanish, German, and Hindi. For Hear/Cue, the language hint is accepted and forwarded to the engine, but recognition accuracy for non-English is not yet published. For a non-English voice pipeline outside Omni’s supported set, the pattern is Cue (turn detection + your knowledge base) + your own LLM and TTS.

​
Status at a glance

Legend. GA · benchmarked = supported and we publish accuracy numbers. Accepted as a hint = the language parameter is forwarded to the engine and may work, but we make no published accuracy guarantee yet. Roadmap = planned, not available today.

​
Hear & Cue (speech-to-text)

The streaming endpoint (GET /v1/audio/transcriptions/stream) and the batch endpoint (POST /v1/transcription/jobs) accept an optional language parameter:
  • language is an ISO-639-1 hint forwarded to the engine.
  • It is one hint per session, there is no mid-session auto-detect and no per-turn language switching today.
  • English is the GA, benchmarked language. Published English accuracy: ~1.6% WER on clean audio and ~4.8% WER on an 8 kHz telephony/accented corpus (see Benchmarks).
  • Other ISO-639-1 codes are accepted and forwarded, but we do not yet publish accuracy for them. Treat non-English STT as unmeasured until the numbers land on the benchmarks page.
The OpenAI-compatible synchronous endpoint (POST /v1/audio/transcriptions) is English-only today: a non-English language there is rejected with 400 unsupported_language rather than forwarded, so a wrong-language request fails loudly instead of silently returning a mis-transcribed transcript. The hint behavior described above applies to the streaming endpoint and async batch jobs. For an end-to-end non-English pipeline, use Omni.

​
Indian languages & code-mixed speech

This is a frequent request, so we are explicit about it. Today PyAI does not publish word-error-rate numbers for Hindi, Tamil, Telugu, Bengali, Marathi, Kannada, Malayalam, Gujarati, or Punjabi, nor for code-mixed Hinglish / Tanglish (Roman + native script mixed with English). The language hint will accept these codes, but you should not assume production accuracy until we publish measured results.
If your product depends on Indian-language or code-mixed transcription accuracy, validate on your own audio before committing. Talk to us and we will run a joint accuracy evaluation against your real call samples, that measurement is the right go/no-go signal, not this page. The benchmark harness we use for this lives in the repo at evals/benchmarks/hear-multilingual.benchmark.json.

​
Omni (agentic voice)

Omni runs the full loop, speech-to-text, the brain, and text-to-speech, on the PyAI engine, and it is going multilingual: en (default), fr, es, de, and hi, end to end. Set the language once on the agent profile and every call on that agent runs in it:
  • language is an agent-level setting (an agent is “a Spanish agent”). It can also be sent per session in the configure frame, which wins over the profile (see the Omni protocol reference). Absent or null means en, exactly the pre-multilingual behavior.
  • Availability is staged per language: French first, then Spanish, German, and Hindi. Configuring an agent for a language before its rollout reaches your traffic degrades gracefully: the session falls back to English and the call proceeds (the configured ack reports language_active and language_fallback: true), and the call bills as what was actually served. Ask us if you need early access.
  • Hindi has two voice tiers. standard is included in the base Omni rate and fits web and app experiences. natural is the telephony-premium tier and bills a per-minute add-on on top of the base Omni minutes (see Pricing & metering). Other languages are single-tier today.
  • Per-phone-number language mapping and automatic language detection are fast-follows, not part of this rollout.
For a language outside this set, use the composable path:
  1. Cue, stream call audio for turn detection (and optional knowledge-base grounding) on GET /v1/audio/transcriptions/stream.
  2. Your LLM, generate the reply from the Cue transcript + grounding.
  3. Your TTS, synthesize the reply in the target language and play it back.

​
Speak (text-to-speech)

The Speak catalog (GET /v1/voices) is English voices only today. This includes several Indian-English accent voices (filter ?region=india), but those speak English (language: "en"), not Hindi/Tamil/etc. There is no native Indian-language (or other non-English) TTS in the catalog yet, and POST /v1/audio/speech has no language parameter. For non-English speech output, bring your own TTS in the composable path above. Non-English voices and non-English voice cloning are on the roadmap.

​
How accuracy gets published

We gate engine quality in CI with an offline benchmark harness (evals/) and publish the headline numbers on the Benchmarks page. As languages are measured, their numbers appear there and this matrix is updated. If you need a number that isn’t published yet, ask, an unpublished number means “not measured to our bar,” not “hidden.”

​
See also

Stream speech-to-text

Feed live call audio into Hear / Cue streaming.

Omni wire protocol

Connect, configure, and the live-vs-roadmap field table.

Telephony audio (8 kHz)

μ-law ↔ PCM16 at 8 kHz for phone legs.

Pricing & metering

Per-second billing and the rate card.