Picking a local text-to-speech model in 2026: read the weights license, not the README
The best-sounding open TTS models are almost all non-commercial, and the badge on the repo does not tell you that. Here is the survey I ran before putting a voice in my own tooling.
I wanted my own tools to read answers back to me without sending the text anywhere. Before picking a model I had four agents survey the field: benchmark evidence, Apple Silicon reality, and about 180 live vendor pages.
Two findings changed the decision, and neither is visible from a repo's front page.
The license split is deliberate and it is everywhere
The pattern across the field in 2026 is a permissive license on the code and a restrictive license on the weights. The weights are the thing you actually need.
| Project | Code | Weights |
|---|---|---|
| F5-TTS | MIT | CC-BY-NC-4.0 |
| Spark-TTS | Apache-2.0 | CC-BY-NC-SA-4.0 |
| Higgs Audio v3 | Apache-2.0 | Research / non-commercial |
| Breeze TTS 2 | Apache-2.0 | Research / non-commercial |
| XTTS-v2 | MPL-2.0 | CPML, non-commercial |
| Kokoro-82M | Apache-2.0 | Apache-2.0 |
Secondary sources get this wrong constantly. I read pages confidently describing Fish Speech as Apache-2.0; its own LICENSE file defines commercial use to include your internal business operations.
XTTS-v2 is worse than restricted, it is unresolvable. Coqui shut down in January 2024, so there is no longer an entity that can sell you a commercial license. Ever.
MegaTTS3 deserves its own warning. ByteDance withheld the encoder weights, so cloning a voice means uploading your audio sample to a Google Drive queue they control and waiting for them to return a file. A maintainer confirmed in the issue tracker that the uploaded voice "will be made public for everyone."
The best-scoring open model on the human-preference leaderboard, Breeze TTS 2, beats ElevenLabs v3 and is research-licensed and CUDA-only. It is an impressive demo you cannot ship.
Published benchmarks are almost never run on a Mac
Every vendor RTF figure is measured on an H100, a 4090, or an L20. On an Apple M4 the numbers land somewhere else entirely:
| Model | Time to first audio | Speed |
|---|---|---|
| Kokoro | 489 ms | 15.3× realtime |
| Pocket-TTS | 44 ms | 7.8× |
| Chatterbox Turbo | 5.07 s | 1.4× |
| Chatterbox 1.2B | 31.4 s | 0.29× |
| F5-TTS v1 | 45.5 s | 0.09× |
F5-TTS at 0.09× means 45 seconds of compute for four seconds of speech. Any 2024-era guide recommending it for a Mac is repeating a claim that was never tested there.
One root cause explains most of the Apple Silicon failures: Output channels > 65536 not supported at the MPS device. It is the same BigVGAN vocoder bug across Chatterbox, IndexTTS, Spark-TTS, MeloTTS and VoxCPM. Setting PYTORCH_ENABLE_MPS_FALLBACK=1 does not reliably fix it, and when it appears to work it has silently routed you to the CPU. On Apple Silicon, prefer an MLX or GGUF reimplementation over PyTorch and MPS every time.
I picked Kokoro, and then spent the effort somewhere else
Kokoro-82M is Apache-2.0 on both halves, scored the highest UTMOS of six small models in an independent benchmark, and ranks above Chatterbox on blind human preference while being roughly six times smaller. On my machine it runs at 4 to 5× realtime warm, 420 to 850ms per sentence, with the model held resident so no utterance pays the 2.5s load.
Then I found the thing that mattered more than the model. On URLs and file paths, the best text-to-speech system in the world posts about 34% word error. On plain prose the same system posts 0.5%. Two orders of magnitude, unsolved by anyone, closed models included.
My assistant's replies are mostly file paths, repository names and dollar amounts. So the preprocessing layer earns more than any model swap:
IN : **Two things need you.** `field-ops-api` has 51 uncommitted
files on `local/portfolio-demo`. That exchange cost $0.1471.
OUT: Two things need you. field ops api has 51 uncommitted files
on local slash portfolio demo. That exchange cost 15 cents.
Markdown stripped, app/Caret.tsx spoken as "app slash Caret dot t s x", initialisms spelled out, and decimal points said aloud because Kokoro reads 3.14 as "three" then "fourteen."
That last detail is the argument for a rule-based front end over an autoregressive one. Kokoro's mistakes are deterministic, so I can fix them once in a lexicon. A model that normalizes implicitly may mangle a version number differently on every run, and you have no lever.
Read the weights license before you listen to the samples, and measure on the hardware you own rather than the hardware in the paper.
Want this built instead of read?
I build the internal apps, automations and integrations described in these notes. Whether you need a week of it or a full-time engineer — scoped up front and documented as I go, so you own it afterwards.