A voice call never leaves your machine because two separate engines run locally: whisper.cpp turns your speech into text in about half a second per ten seconds spoken, and a text-to-speech engine turns her reply back into audio, with the default voice engine synthesizing faster than real time. No per-minute cost, no recording sent anywhere, and the failure modes are measurable, not mysterious.
Press the phone icon, talk, and she answers out loud. Nothing about that sentence involves a server.
Two separate engines make it work. One listens: it turns your spoken words into text the model can read. One speaks: it turns her written reply back into audio you can hear. Both run on your own machine, and both have a measurable cost in time, which is the part most explanations of “local voice” skip entirely. They wave at “it’s fast” without ever putting a number next to that claim.
I can, because I have actually measured this on hardware I own.
Speech recognition is one engine, not one per platform
The short version: the same speech-to-text engine, whisper.cpp, runs on both macOS and Windows, and on an Apple Silicon Mac it transcribes roughly ten seconds of speech in about half a second.
Most local AI projects end up with a different speech engine per operating system because the fast options are usually GPU-vendor-specific. Whisper.cpp avoids that trap: it is a single, well-optimized C++ implementation of OpenAI’s Whisper model that runs efficiently on Apple’s Metal and on ordinary CPUs alike, so the same engine covers seven languages on both platforms instead of forking the codebase per OS.
There is a design choice underneath that number that matters more than the number itself: this is batch transcription on detected silence, not streaming. The engine waits until you stop talking, then transcribes the whole utterance in one pass. Streaming speech recognition, where the model tries to transcribe word by word as you talk, sounds like it should feel faster, and for English it often does. For Polish, the measured word error rate on a streaming model runs roughly double what the same model achieves in batch mode. Waiting a beat for a correct transcript beats guessing in real time and getting it wrong.
On a MacBook Pro M3 Pro, a ten-second utterance transcribes in around half a second. That half-second isn’t a marketing number. It’s the actual latency of the actual model file, on Metal, doing real work.
Her voice is two engines, not one
The short version: there is a small, fast default voice engine that ships with the app, and a separate, heavier premium engine you can opt into if you want to clone a specific voice.
The default is called Supertonic. It’s small on disk, around 380 MB, runs as an ONNX model, and covers six of the app’s seven shipped languages out of the box. It does not depend on espeak or any external phonemizer, which sounds like a technical footnote until you consider that a lot of open TTS projects quietly ship a GPL-licensed dependency buried three layers deep. Supertonic sidesteps that whole category of problem by not needing it.
Measured on the same M3 Pro, Supertonic synthesizes speech with a real-time factor between 0.21 and 0.32. In plain terms, 3.4 seconds of spoken Polish came out of the engine in 0.71 seconds. It generates audio faster than a person would speak it, which is exactly the property you want for a voice call that shouldn’t feel like it’s buffering.
The second tier, Chatterbox, is what powers voice cloning: feed it a short reference clip of a voice, and it learns to speak in that voice going forward. It covers all seven of the app’s languages, including the one Supertonic misses, and it does noticeably more computation per sentence in exchange for that flexibility. On constrained hardware, that extra work shows up as a slower time-to-first-audio, sometimes one to three seconds instead of a fraction of a second. That’s a real trade-off, not a hidden cost, and it’s the reason the app treats the two engines as genuinely separate choices instead of pretending one just replaces the other.
Three real bugs show exactly where this time budget breaks
This is the part a generic explanation of local voice can’t give you, because it requires having actually shipped the thing and watched it fail in specific, fixable ways.
Her voice was re-learning itself before every single sentence. To speak in a given voice, Chatterbox studies a short reference clip first. For a while, it was doing that study again, from scratch, for every sentence in a reply, even though the reference clip never changed. Measured cost: roughly three quarters of a second of pure overhead per sentence, spent re-analyzing audio the engine had already analyzed moments earlier. A three-sentence reply lost about two seconds to a computation that should have happened exactly once per call. Fixed by caching the analysis instead of repeating it.
Her reply text and her voice were competing for the same graphics card. Generating the words of a reply and synthesizing the audio for that reply are two separate jobs, and for a while both were allowed to run on the GPU at the same time. On some hardware that kind of contention doesn’t just add the two costs together, it multiplies them, because neither job gets the card’s full attention. The fix was sequencing: finish composing the reply first, then speak it, instead of racing both at once. The always-on default voice was never affected by this, since it barely touches the GPU to begin with; it only showed up when the heavier, opt-in engine was active.
The pause that decides when you’ve finished talking was tuned too tight. Speech recognition doesn’t know you’re done until it detects a stretch of silence. That threshold was set to 0.7 seconds, which is shorter than a perfectly ordinary pause between two sentences in normal speech. The practical effect: say something in two sentences, and the system sometimes decided you’d finished after the first one, cutting the second one off entirely and never hearing it. Moved to 0.9 seconds, which is enough headroom for a natural mid-thought pause without making the whole exchange feel sluggish.
None of these are exotic problems. They’re the ordinary cost of building something real: a caching gap, a resource-contention race, and a threshold that needed a different number. What makes them worth writing down is that most of what gets published about “local AI voice” is theoretical, and none of it mentions failure modes this specific, because none of it was actually running in production for real users.
Why any of this is worth the trade
The short version: no per-minute pricing, no audio leaving your machine, and a one-time hardware cost instead of a running bill.
A cloud voice API bills you by the minute or by the character, forever, for as long as you use it. A local engine costs you disk space once and a slice of your CPU or GPU while it’s running, and that’s the entire bill. Nobody is listening to figure out what to charge you next month, because there’s no server in the loop to listen from. The trade you’re actually making isn’t speed for privacy, since a well-tuned local pipeline is fast enough that the difference is barely perceptible. The real trade is a small, fixed cost in RAM and disk against a cost that would otherwise scale with how much you actually talk to her, which for most people who use a voice feature regularly, adds up fast.
If you want to hear the difference for yourself rather than take a number on a page for it, grab the app and start a call. The whole pipeline described above, listening, thinking, and speaking, runs the moment you press the phone icon, on whatever machine you’re reading this on right now.
Questions people ask
Does offline voice work without any internet connection at all?
Yes, as long as you are using the local voices and the on-device speech recognition, which is the default. There is an optional cloud speech-to-text picker in Settings for anyone who wants it, but nothing about a call requires an internet connection when it is off.
Why does the first sentence sometimes take a moment longer than the rest?
The speech recognition engine only starts transcribing once it detects you have stopped talking, not while you are still speaking. That short pause after you finish is the engine catching up, and on a reasonably capable machine it is well under a second for a normal sentence.
Is a cloned voice slower than the default voice?
Usually, yes, though it depends on your hardware. The default voice engine is small and tuned for speed. The premium engine that supports voice cloning does more work per sentence in exchange for a closer match to a specific voice, and on some setups that trade-off is worth it and on others it is not.
What actually determines how fast this feels?
Two things: whether the speech recognition and the reply generation are fighting for the same processor or graphics card at the same time, and whether the text-to-speech engine has to redo expensive setup work on every sentence instead of once per call. Both are solvable, and both have been real bugs in this app at different points.
Try her free for 7 days.
No card. Keep her for $20 once, or walk away. Her soul file is yours either way.
Bring her home, try free