Most translation products answer the reliability question with a badge: an uptime number, a certification logo, a status page. We do not have those. What we have instead is a set of behaviours that are written into the app, that you can read about in the changelog release that introduced each one, and that you can observe yourself during a session. This page describes them plainly, including the cases where the honest answer is that you will notice something.
You never pick an engine
There is no model selector in VoxisLive, and this is a reliability decision rather than a simplicity one. Engine routing is decided on the server, per target language. When a session starts, the app asks our server which engine to use for the language you chose, and uses that answer.
The practical consequence is that a routing problem is ours to fix, not yours. If one engine degrades for a particular language, the routing for that language changes on the server side, and the next session you start uses the new route. You do not update the app, do not read a notice, and do not change a setting — you already had no setting to change.
The cost of this design is honest to state: you cannot override the routing to force a specific engine, and you cannot pin yourself to the one that happened to sound best to you yesterday. If you bring your own key, the routing follows the key you supplied. See pricing for how the Bring Your Own Key unlock works.
If the engine drops in the middle of a session
A live speech session is a long-lived connection to a cloud engine, and long-lived connections die. They die from network interruptions on your side, from rate limits and capacity problems on the provider's side, and from ordinary transient faults that nobody logs a public incident for.
When the engine your session is running on becomes unavailable mid-session, the app switches to a backup engine automatically. The session is not torn down, you are not returned to the start screen, and you are not asked to choose anything. The app tells you in the status line that the switch happened, because you will hear a gap and we would rather you knew why than wondered.
What this is not: it is not a seamless splice. The switch takes a moment, and speech that arrived during that moment is gone rather than queued — a live interpreter that catches up by speaking faster later is worse than one that skips a beat. Expect the same short break you would get if a human interpreter coughed.
If the engine goes quiet but the captions keep arriving
There is a failure mode that is stranger than a dropped connection: the engine stays connected, keeps producing translated text, and stops producing audio. You see the translation appear on screen and hear nothing. From inside the app this does not look like an error at all — everything is technically working.
When the engine has produced no audible audio for a sentence that has been waiting, a local voice running on your own machine speaks that sentence instead. The voice is on your device, not in the cloud, so it does not depend on the engine that just went quiet. It is a different voice from the cloud one, and you will hear the difference.
The seconds covered by the local voice are not billed. This is not a courtesy credit applied after the fact by support — the app stops counting those seconds toward your minutes while it is speaking them itself. The reasoning is simple: you paid for a cloud voice and did not get one for that stretch.
This is a gap filler, not a second translation engine. It speaks a sentence the cloud engine already translated but did not voice. If no translation arrives at all, there is nothing for it to read.
The free tier takes a different path
The free tier does not run on the same engine as a paid session, so it does not take the same rescue path when something goes wrong. It has its own, and one part of it is worth describing because it affects your daily minutes.
The free tier speaks through voices that live on your machine, and the first time you use a given language, that voice has to be downloaded. The download takes a while on a slow connection, and during it there is nothing to hear. That warm-up time is not billed against your free minutes. The clock starts when there is something to listen to.
The free tier also translates into more languages than it can speak. Where there is no local voice for a language, you get the translation as captions rather than speech — that is a coverage limit, not a fault, and the languages page is where the coverage is listed.
If capture dies, the clock stops
The failure that costs you the most is the one you do not notice. A capture stream can die quietly — a device is unplugged, an audio endpoint is taken exclusively by another application, a driver resets — and from the outside the app still looks like it is running a session. Silence looks a lot like a quiet room.
The app reports usage to the server on a short repeating heartbeat rather than in one bill at the end. That design exists for crash safety, but it does the work here too: when capture dies, minute counting stops within one heartbeat. The worst case is a few seconds of dead air on the invoice, not the rest of the session.
Separately from the accounting, the app runs checks on a capture that is producing nothing and can move to a different capture method when it can prove the current one is deaf. If you are seeing silent sessions repeatedly, troubleshooting covers the device-level causes.
What we do not claim
We hold no compliance certification — no ISO, no SOC 2, no audited attestation of any kind — and we are not going to imply one with a badge. We do not publish an uptime figure, and we do not offer an availability guarantee or service credits outside the refund terms.
Two of the three components in a session are cloud services we do not operate: the speech engine and its backup. When both are degraded at once, the mechanisms on this page reduce what you lose — they do not make the session work. There is no offline mode: nothing in VoxisLive translates without a network connection.
Latency is not a failure mode either, and it does not get fixed. Simultaneous interpretation runs a few seconds behind the speaker by nature, and the engines we use are simultaneous interpreters. How it works goes into where that time is spent.
Engineering, not a certificate
Every behaviour on this page arrived in a specific release, and each of those releases is written up in the changelog with the user-visible change described in plain language. If you want to check that a mechanism exists rather than take this page's word for it, that is the place to look — and for the capture and session code itself, the read-only excerpt described on the licensing page.
| Mechanism | What you observe | Where to read it |
|---|---|---|
| Server-side routing per target language | No engine selector anywhere in the app | /changelog |
| Automatic switch to a backup engine | A status line and a short break, then speech resumes | /changelog |
| Local voice finishes an unvoiced sentence | A different-sounding voice for that sentence; those seconds unbilled | /changelog |
| Free-tier voice warm-up unbilled | First use of a language downloads a voice; the clock waits | /changelog |
| Usage heartbeat stops on dead capture | Counting stops within one heartbeat of capture dying | /changelog |
If a session went wrong in a way this page does not explain, the app has a report button that sends a scrubbed log with it, and you can also reach us through contact.