Limits and known gaps
What does not work, stated plainly. This page exists so nobody discovers these the hard way, and so an AI assistant reading these docs gives honest answers.
There are no rate limits
You will never see a 429 from this API. If a request is slow under load it is because it is waiting its turn, and the response tells you so — /v1/translate even reports queued_ms separately from inference_ms so slow is never mistaken for stuck.
What actually constrains you
| Constraint | The real number |
|---|---|
| Concurrent calls | Provisioned per account rather than fixed, so the honest answer is to tell us how many lines you need. What is fixed is the behaviour past your ceiling: requests queue and each gets slower. Nothing is rejected and no call is dropped. |
| Round trip to India | Our compute is not in India yet, which adds roughly 200ms for an Indian caller on top of every figure on the benchmarks page. For Indian traffic this is often the largest single number in your budget, and it is the next thing we are moving. It also means we cannot support a data-residency requirement today. |
| Reply model quotas | The reply model is served by a third party under quotas we do not set. In practice it is not what you hit first, but it is not ours to raise either. |
| Translation throughput | Lower than the speech path, and serialised. Twelve concurrent translation requests completed in 14.5s in total. Fine alongside calls; not a batch translation service. |
| Recording storage | Unlimited in practice, and off by default. Recording a call without telling the other party is unlawful in many places, so turning it on is a decision you take per agent. |
Not built
Voice cloning now works, on a different model
This section used to say cloning was not good enough, and that was true of the engine we tried it on: a cloned voice speaking a language other than the one it was recorded in scored 0.149 similarity to the original, where two completely different people score 0.213. It sounded like neither the original speaker nor a consistent character.
It is live now, on a purpose-built cloning model rather than that one. Upload a recording to POST /v1/voices, or use the Voice tab in the dashboard. Measured on our own GPU through a simulated phone line, it never once over-ran its expected duration across thirty-one generations — where the preset engine over-ran on three of six Hindi sentences, and over-running is what a held tone is. Tamil transcribed back perfectly, three for three.
The honest caveat: the model is version 0.5 and nobody has published a listening test for it. Preview any voice through the phone-line audition before you rely on it. It is also non-streaming, so a reply takes about 410ms to synthesise against 96ms for the preset engine — measured as fully covered by the filler that already plays while the model thinks, leaving about 500ms to spare, so the caller hears no extra silence.
The preset voices are unchanged: all 19 languages in both genders, every one verified, every one auditionable before you choose it.
Billing
There is no billing system, no invoice, no payment method and no metered price. The usage screen shows the minutes and calls your line handled and stops there. It is labelled usage rather than billing for exactly that reason: calling it a bill would imply four things exist that do not.
Per-user permissions
Accounts are real and isolated from one another, but within an account there is a single level of access. Anyone with a key can read every call, transcript and recording on that account, and can revoke every other key. There are no roles and no read-only keys. So treat a key as full account access, and make one per integration — then a single one can be revoked without disturbing the rest.
Speech detection struggles in noisy places
Detection calibrates on the first few hundred milliseconds of each call and adapts to that line, which makes turn taking reliable. What it does not do well is tell speech apart from sustained background noise — a loud shop, a television in the room, a busy street will all trigger it. A caller in a quiet room is fine; a caller outside a market is not. This is our most common real-world failure and it is next on the list.
Token-by-token LLM streaming
stream: true is accepted on /v1/chat/completions and ignored; the reply arrives whole. On a call this matters less than it sounds, because synthesis is the long pole and the filler cache already covers the wait.
A conversation needs both halves, and only 10 languages have both
Bengali, Gujarati, Hindi, Indian English, Kannada, Malayalam, Marathi, Punjabi, Tamil and Telugu. Those are two-way: understood by the transcriber we ship and speakable by a voice we ship. Plan against this number and nothing else.
Hear but cannot speak: Odia. Transcribed correctly, then answered in whichever language the agent is configured for. Translate into a language with a voice, or fall back to text.
Speak but cannot hear, nine: Assamese, Bhojpuri, Bodo, Chhattisgarhi, Dogri, Magahi, Maithili, Nepali and Sanskrit. An agent can deliver a message in these and cannot understand the reply, which suits an announcement and not a conversation.
This page previously said seven languages could be transcribed but not spoken, and other pages claimed 22 understood. Both counted models that are not what a call runs on — one needs an explicit language code, another wants 16kHz, neither has a streaming path. The figures above come from the shipped default only.
Quality is not flat across the languages we list
Measured on real human speech (FLEURS) with the default model: Hindi word error rate 0.104, Telugu 0.219, Tamil 0.277. Hindi, Tamil, Telugu, Bengali and Marathi are good. Bodo, Santali, Dogri, Manipuri, Sanskrit, Kashmiri, Sindhi and Konkani are weak — for everyone, including large commercial vendors, because the training data does not exist.
Listing a language is honest. Promising equal quality across all of them is not.
The 8kHz telephony penalty, now measured
This used to be the largest open question on this page. It has been measured: word error rate goes from 0.204 at 16kHz to 0.252 after a round trip through 8kHz mulaw, and character error rate from 0.099 to 0.121.
So telephony costs about 5 points of WER — real, but considerably less than most people fear. You do not need to plan around it.
Language detection has one hard failure
Hindi versus Urdu cannot be reliably separated by audio. They are near-identical when spoken and differ mainly in script and formal vocabulary. Published accuracy for that family is 58.7%. Do not build a feature that depends on it.
Telugu versus Tamil is fine — different family, clearly different sounds, 85.9% published. Always pass restrict_to when you can narrow the candidate set; it is the single biggest accuracy lever on that endpoint.
Compliance not yet handled
- DPDP Act 2023. Voice recordings are personal data. Fine for synthetic test audio; needs a real answer before customer calls flow through.
- DLT registration and DNC scrubbing. Required for outbound calling in India. Not built.
- Voice cloning consent. Every model licence in this stack forbids non-consensual cloning, so
POST /v1/voicesrequires an explicit consent flag and logs every request. It is the one place where "no restrictions" does not apply, because removing the restriction would breach the licences the whole stack depends on.
What we are working on next, in order
- Compute in India. Removes roughly 200ms from every request for an Indian caller, which is larger than any remaining model-level win, and it is what makes a data-residency answer possible.
- Speech detection in noisy places. The current detector is good at turn taking and poor at telling speech from a loud shop or a television. This is the most common real-world complaint and it has a known fix.
- Code-mixed transcription. Sentences that switch between a regional language and English mid-clause are transcribed less reliably than monolingual ones, and that is the normal way Indians speak on the phone.
- Roles and read-only keys. Today a key is full account access, which is fine for one person and wrong for a team.
- Billing. There is none.