A voice that never leaves the device

There is a version of this article that flatters us, and it is easy to write: our reading voice runs entirely on your machine, nothing you read is ever uploaded, privacy wins. All true. The version worth reading starts elsewhere — with the admission that the cloud voices are better than ours — and works forward from there to why we took the trade anyway.

The technical facts first. The voice in our app is KittenTTS nano, an open-weight neural text-to-speech model of about fifteen million parameters, running in the browser — not streamed from a server, not installed as an operating-system component, but executing in the same tab that renders the words. Eight voices ship with it. Because the model is where the text is, the text goes nowhere: reading aloud happens with zero bytes uploaded, and it keeps working with the network cable pulled out.

Fifteen million parameters is, by the standards of 2026, almost comically small. The whole model weighs a few dozen megabytes — small enough to arrive with the page and vanish with the tab. The neural voices you hear from the large platforms are orders of magnitude larger, trained on more speech than any human hears in a lifetime, and refined by teams whose budgets exceed our company’s existence. The comparison is not close, and we will not pretend it is.

The gap, conceded properly

Here is what the cloud voices do better, stated as plainly as we can. Their prosody is superior: they place sentence stress more naturally, shape questions as questions, and carry the long intonational arc of a complex sentence in a way a small model approximates but does not match. They pronounce rare words, names and borrowings more reliably. They recover more gracefully from strange input — tables, code, fragments. On expressive material read at length, we think most listeners in a blind comparison would pick the large model, and so would we.

We should also concede what we cannot measure. “Most listeners would pick the large model” is our judgement from using both, not a study we can cite; blind comparisons of reading-length synthetic speech, as opposed to short demonstration clips, are thin on the ground. It is possible the gap matters less across an hour of prose than it does in a ten-second demo. It is also possible it matters more. We have not seen it tested.

A small local voice, for its part, occasionally flattens a sentence, mis-stresses an unusual compound, or gives a proper noun a pronunciation its owner would not recognise. These are real defects. For our purpose they are also survivable defects, because the voice in a reading tool is not a performance — it is a metronome and a second channel, and the qualities that matter most for that job turn out to be different ones: latency, availability, and knowing with certainty where the audio is made.

There is a useful comparison from typography. A display face and a reading face are judged by different standards: the display face must be beautiful at a glance, the reading face must disappear over an hour. Voices divide the same way. A voice that reads to you for forty minutes succeeds by not accumulating irritation — steady pace, clean word boundaries, no artefacts that snag attention — and a small model tuned for that job can meet the bar sooner than the beauty comparison suggests.

Why we take the trade

The first reason is the obvious one. A cloud voice hears everything you read with it — every contract, every medical letter, every unfinished draft — because transmitting the text is how the audio gets made. That is not an accusation of misuse; it is a description of the pipeline. Our position, argued at length in offline by design, is that reading is among the most private things a person does with a machine, and offline text to speech is the only architecture in which the privacy claim needs no trust to check. One HTML file, a network tab you can watch, nothing leaving. The proof is inspection, not policy.

The second reason is less discussed: an offline voice is always there. It works on the train, behind hospital wi-fi, in a school that blocks third-party endpoints, in a country where the platform’s service is unavailable, and in ten years if the vendor is gone — the model’s weights are open, so the voice cannot be discontinued by anyone, including us. A reading habit is a daily practice, and a practice tool that depends on someone else’s server has a failure mode a practice tool should not have.

Institutions sharpen the point. A school or a firm can put this voice in front of readers without writing a data-processing agreement for every document a pupil or employee might open, because there is no processing anywhere but the machine in the room. Whole categories of text — case files, patient letters, unpublished manuscripts — sit outside what a cloud voice can responsibly be used for, and no discount changes that.

And latency, which sounds trivial until you feel it. Speech generated in the tab starts now — no round trip, no buffering, no server having a bad day. When the voice is doing pacing work rather than performance work, immediacy matters more than beauty, and one of our two clock modes could not exist over a network at all.

The privacy claim needs no trust to check. That is the whole argument.

Architecture as evidence

Two clocks

A voice inside a reading tool raises a question performance audio never faces: who holds the clock? In our app the audio can be the master clock — speech-led, the words on screen keeping time with the voice, which suits readers who want to be carried — or it can follow the reader, speaking whatever the visual pace delivers, so the eyes stay in charge and the voice shadows them. The two modes feel surprisingly different in use, and which one helps seems to vary by reader and by text; the wider argument about listening and reading is taken up in reading versus listening.

Reader-led mode is the one the network could never deliver: the voice must react the instant your pace changes, not a round trip later. And it inherits our rhythm engine, so “reader-led” does not mean metronomic — dwell already stretches, up to about 2.8 times, on long words, commas, sentence ends and numerals, and the voice follows that punctuation-shaped rhythm rather than a flat rate. Whether speech-led or reader-led produces better recall for you is exactly the kind of question our exportable session data lets you test on yourself, and we would rather you ran that experiment than took our guess.

Where small voices go next

What follows is speculation, ours, and marked as such. The trend that produced a usable fifteen-million-parameter voice has not stopped, and it is being pushed from below — by open-weight research, by phones that want voices without connectivity, by regulation that increasingly frowns on shipping user text abroad. Our bet is that within a few years the local voice will be, for reading purposes, indistinguishable from the cloud voice on most prose, and the cloud’s remaining edge will be confined to performance: audiobooks, characters, emotion on demand. Nobody has tested this and neither have we; it is a reading of a curve, not a fact.

If that happens, the interesting consequence is not that apps like ours sound better. It is that the default flips. Once quality is local, transmitting text to a server to have it spoken becomes a choice that needs a justification, where today it is a default that never gets questioned. Architectures rarely change because the better one wins an argument; they change because the cheaper one becomes good enough, and small models are becoming good enough at a pace that surprises even the people building them.

In the meantime we live with the flattened sentence and the odd mangled surname, and we think the trade reads differently once it is stated as what it is: a slightly worse voice that has never heard of you, against a beautiful one that hears everything. Said aloud — in either voice — it does not sound like a close call.