Picking a Voice That Never Leaves the House

I needed to pick a voice for Atlas. That decision took longer than building the wake word detection did, which surprised me, because on paper choosing a text-to-speech model sounds like the easy part. It was not, and the reason it was not is the whole point of this post.

Six months ago the answer would have been trivial. You reach for whatever cloud API sounds best, wire up an API key, and move on. But Atlas runs local and air-gapped, on hardware I own, and the entire premise falls apart the moment the voice model phones home. An assistant that is always listening and keeps its perception in the building, then ships my requests out to a cloud endpoint the instant it needs to speak back, is not air-gapped. It is air-gapped for the parts that are convenient and connected for the part that is hard, which is just connected with extra steps.

So the real question was never "which TTS sounds most human." It was "which one can I run entirely on my own box, with no network call, fast enough to answer a wake word." That reframing is the actual work. Once the question was right, the evaluation almost fell out on its own.

What a TTS model is actually doing

It helps to know what you are shrinking before you talk about shrinking it. Nearly every modern TTS system does the same three things in sequence. First it converts text to phonemes, the atomic sound units of speech, because "read" and "read" are spelled identically and sound nothing alike, and the model has to disambiguate. Then it turns those phonemes into acoustic features, usually a spectrogram, a time-frequency picture of the intended sound. Then a component called a vocoder turns that picture into an actual audio waveform you can play.

Model size and quality live mostly in the middle and final stages, and so does the compute cost. The useful thing about understanding the pipeline is that it tells you where a model can be cheap without being bad. A small model that nails phonemization and does competent acoustic modeling can sound clean, if unremarkable, at a fraction of the parameters, because a lot of what makes speech intelligible is structural rather than a function of raw model scale. Naturalness and emotional range are where the parameters actually go.

Which brings me to the happy accident underneath this entire project: there is a race to the bottom in TTS right now. Labs are competing to see how far down the size curve they can push without the quality visibly cratering, and for someone whose hard constraint is "must run on a CPU I already own," that race is a gift. I evaluated six models on exactly that axis: how small can you go before it stops sounding acceptable.

The six I actually tested

Kokoro TTS. 82M parameters, Apache 2.0 licensed, CPU-capable. This is what ended up in Atlas. It runs near real time on the same box that is already doing WhisperX transcription, with no dedicated GPU carved out for voice output. That last detail matters more than the raw quality score. My hardware budget for voice was whatever cycles were left over after the listening side, and Kokoro fit into the leftovers. 82M parameters is small enough to feel like it should not be good, and it is good enough that I stopped looking for a reason it was not.

Chatterbox, from Resemble AI. MIT licensed. The turbo variant lands around 350M parameters at roughly 75ms latency, built for self-hosted GPU deployment. Genuinely strong. It also watermarks every clip by default, which I want to call out as a good and responsible default even though I did not need it: for a private assistant talking only to me, provenance watermarking on my own voice output solves a problem I do not have. The disqualifier was not the watermark, it was the GPU. Wanting a dedicated card for voice is exactly the cost I was trying to avoid.

Qwen3-TTS, from Alibaba. Ranging from 0.6B to 1.7B parameters. The 1.7B model tested ahead of comparable open models on long-form naturalness in my listening, and if the job were narrating audiobooks it would be a serious contender. But it was also the slowest of the group, and slow is disqualifying for a wake-word assistant. The entire interaction contract of "say the word, get an answer" collapses if there is a beat of latency before it speaks. Long-form naturalness is the wrong thing to optimize for a system whose longest utterance is usually a sentence.

Kyutai TTS, from the French lab behind Moshi. The flagship is around 2B parameters, too heavy for my constraint, but their Pocket TTS release drops that to 100M parameters and is CPU-capable. It was the closest runner-up to Kokoro, and on another day with a slightly different set of clips it could have won. That it exists at all is the race-to-the-bottom thesis in a single release: a serious lab publishing a deliberately tiny CPU-runnable model right next to its flagship.

Coqui XTTS-v2. The headline feature is voice cloning from about 6 seconds of reference audio, which is genuinely impressive and genuinely not what I needed. Cloning a voice is a party trick for this use case, and it wanted a GPU I was not willing to dedicate to speech. Ruled out on the same hardware line as Chatterbox.

ElevenLabs. The best raw quality on the market, and I mean that without qualification. It was disqualified in about four seconds. Cloud only means my voice output leaves the house, and no amount of quality buys back the one property the whole system exists to preserve. This is the cleanest illustration of the reframing: the best-sounding option was the fastest rejection, and it was not close.

Why Kokoro won, and what "won" means here

Kokoro did not win because it sounded best. Chatterbox is arguably richer, Qwen3-TTS is more natural over long passages, ElevenLabs is simply better. Kokoro won because it was the only model that satisfied the constraint that actually mattered, entirely on hardware I own, fast enough for a live wake-word response, with no exceptions carved out for quality. Every model that beat it on naturalness lost on deployability, and deployability was not a tiebreaker. It was the whole competition.

That inversion is worth naming plainly, because it is the generalizable lesson. I did not pick a model by ranking quality and stopping at the best one I could afford. I picked by drawing a hard line at the constraint, discarding everything on the wrong side of it regardless of how good it was, and only then comparing what survived. When you have a genuine non-negotiable, benchmark leaderboards are close to noise, because most of what they rank has already been eliminated by a property they do not measure. The best model is not the one that tops the chart. It is the best of the ones that clear your actual bar, and your actual bar is usually not quality.

The counterargument I owe this decision

Here is where I have to be honest, because "I picked the tiny local model and quality is a commodity now" is a satisfying story that is only partly true.

The first thing I am glossing over is that I did take a real quality hit, and I am choosing to be at peace with it rather than pretending it does not exist. Kokoro is good. It is not ElevenLabs, and on an expressive utterance, something that wants genuine emotion or emphasis, you can hear the ceiling. For an assistant that mostly reads short factual replies, that ceiling is nowhere near low enough to matter. For a system meant to hold an emotionally present conversation, it might be disqualifying. I optimized hard for a constraint, and optimizing hard for one axis always costs you on the others. My use case makes that trade obviously correct. Not every use case does, and the reasoning that made Kokoro right for me would make it wrong for a grief-support companion or a character in a game.

The second is that "quality has become a commodity" is doing a lot of load-bearing work, and it is true only inside a bounded region. Down at the intelligible-and-pleasant tier, yes, it is commoditized, and there are now six credible ways to get there on modest hardware, which was not true a year ago. But the frontier of expressive, emotionally controllable, real-time voice is not commoditized at all, and that is precisely the ground the cloud providers still own. If your product lives at that frontier, air-gapping costs you something real and possibly decisive, and the honest move is to admit the constraint and the quality are in genuine tension rather than to declare the tension resolved. I resolved it by having modest voice needs. That is a fact about my requirements, not a fact about the field.

The third, smallest caveat: I evaluated six models by ear, on my clips, for my box. That is the right way to choose for a personal system and the wrong way to make a universal claim. Kyutai Pocket TTS was a hair behind on my test set and might be ahead on yours. Take the specific rankings as one person's listening notes, not a benchmark, and take the method, constraint first, quality among the survivors, as the part actually worth copying.

The question I keep coming back to

The thing I did not expect this decision to teach me is how much the right answer had moved in six months. The old instinct, reach for the best-sounding voice and let the network carry it, is not just suboptimal for a local system, it is disqualified before quality is even discussed. The property that decided it was not how human the voice sounded. It was whether the audio ever crossed my network boundary, and that is not a quality question at all.

So here is what I am genuinely unsure about, and I mean it as an open question rather than a rhetorical one. When you are choosing a model for something always-on and always-listening, is raw voice quality still the deciding factor, or has it quietly become a commodity, with the real decision moving to where the model runs, what it costs to keep running, and whether it can keep a promise about where your data goes? For Atlas the answer was clearly the latter. I am not sure yet how widely that generalizes, and I think the honest position is that it depends entirely on whether the property you cannot compromise on is one the benchmarks even measure.