Hidayat demonstrates that Kokoro's 82M-parameter ONNX model runs faster than real-time on a modern laptop CPU with a five-minute install path (pip install kokoro-onnx). He frames this as the first genuinely-usable CPU-only TTS option — good enough for interface prompts, notifications, audiobook drafts, and accessibility layers without any GPU or cloud dependency.
By submitting the post and driving it to 347 points, speckx signal-boosts the argument that CPU-friendly local TTS is a meaningful milestone. The unusually high score for a TTS story reflects broad developer agreement that this crosses a usability threshold.
The editorial explicitly argues Kokoro's contribution isn't architectural innovation — it's built on the existing StyleTTS 2 approach. What matters is that the model is small enough (~300MB), fast enough (faster than real-time on CPU), and permissively licensed enough (Apache 2.0) that 'just run it locally' becomes the default answer, unlike prior self-hosted options that were either robotic (Piper), GPU-hungry (Bark), or legally murky.
The editorial makes the case that ElevenLabs, OpenAI tts-1, Polly, Google, and Azure have dominated by default for three years — all metered, all network-dependent, all leaking text to third parties. Kokoro breaks that default for interface prompts, notifications, and accessibility layers where ElevenLabs-tier emotional narration isn't required, reframing hosted TTS as a premium tier rather than the baseline.
Hidayat is upfront that Kokoro's output isn't ElevenLabs-tier for long emotional narration. He positions it as usable for a specific class of workloads (short prompts, drafts, accessibility) rather than a wholesale replacement, which sets realistic expectations and avoids overclaiming.
Ariya Hidayat published a walkthrough of running Kokoro, an 82M-parameter open-weights text-to-speech model, entirely on a CPU — no GPU, no external API, no telemetry. The post landed at 347 points on Hacker News, which for a TTS story is unusually high, and the comments are dominated by people confirming that yes, the thing actually works on their laptops.
Kokoro is built on a StyleTTS 2-style architecture, distributed under Apache 2.0, and ships as an ONNX model that runs through onnxruntime on plain CPU inference. The model weights are around 300MB. On a modern Apple Silicon or Ryzen laptop it generates speech faster than real-time — a 10-second clip in roughly 2-3 seconds of wall time, depending on voice and sentence length. The output isn't ElevenLabs-tier for long emotional narration, but for interface prompts, notification playback, audiobook drafts, and accessibility layers it's the first genuinely-usable CPU-only option in a while.
Ariya's post is deliberately unglamorous: a Python snippet, a `pip install kokoro-onnx`, a WAV file. That's the whole story. There's no fine-tuning ceremony, no CUDA setup, no HuggingFace inference endpoint. The install-to-first-sound path is under five minutes.
For the last three years, "good TTS" has meant "send text to a hosted API." ElevenLabs charges per character. OpenAI's `tts-1` is cheap but still a network round-trip. Amazon Polly, Google Cloud TTS, Azure — all cloud, all metered, all leaking your text to a third party. The self-hosted alternatives (Coqui, Piper, Bark, XTTS) either sounded robotic, needed a GPU to be responsive, or had licenses that made lawyers nervous.
Kokoro's contribution isn't a novel architecture — it's that the model is small enough, fast enough, and permissively-licensed enough that "just run it locally" is now the default answer for a large class of TTS use cases. Piper is faster but noticeably more synthetic. Bark sounds great but wants a GPU and takes 30+ seconds per clip. XTTS v2 is high quality but Coqui's non-commercial license kills it for products. Kokoro sits in the previously-empty quadrant: quality close to the commercial APIs, CPU-friendly, Apache 2.0.
The HN thread has the usual mix of skepticism and pleasant surprise. Multiple commenters report generating usable audiobook chapters overnight on Mac Minis. One thread benchmarks it at ~0.3x real-time on a Raspberry Pi 5, which is slow but not absurd — meaning offline voice for hobbyist hardware is now realistic. The main complaint is prosody: Kokoro handles declarative sentences well but flattens questions and struggles with long dependency chains. This is a known StyleTTS 2 limitation, not a Kokoro-specific bug.
The economics are the part worth internalizing. ElevenLabs' cheapest paid tier is $5/month for ~30k characters. A modest app that reads a couple of paragraphs per user per day burns through that in a week. At the API's per-character rate for overage, a mid-sized product easily runs four or five figures a month. Kokoro turns that recurring cost into a one-time integration effort and some CPU cycles on hardware you already own. For a startup, that's the difference between TTS being a feature and TTS being a line item you have to defend to the CFO.
If you're currently paying an API for anything that sounds like a robot reading a menu — button labels, error messages, article-to-audio, meditation prompts, IVR — Kokoro is worth a weekend prototype. The integration surface is small: a Python service behind a queue, or `kokoro-onnx` linked directly if you're already in a Python backend. The Node ecosystem has an `onnxruntime-node` binding, so a JS-only backend is workable too, though the tokenizer/phonemizer step still nudges most people to Python.
Where you still want a hosted API: multi-speaker conversational audio, real-time voice cloning, streaming latency under 200ms, or anything where legal wants a vendor SLA on the audio. ElevenLabs and OpenAI still win on expressive range and emotional nuance for long-form narration. But those are a shrinking share of what shipping products actually need. Most TTS in the wild is functional, not artistic — and Kokoro handles functional cleanly.
One underrated angle: privacy. If you're building anything in health, legal, education, or enterprise, "we send user text to a third-party TTS vendor" is a data-flow diagram you'd rather not have to draw. Local inference removes the box entirely. That alone justifies the switch for a lot of B2B products.
The broader pattern here is the one that's been playing out with Whisper, Llama, and now TTS: models keep getting small enough that the default deployment target shifts from "someone else's GPU" to "the machine the code is already running on." Kokoro isn't the endgame — someone will ship a 40M-param model in six months that sounds identical — but it's the point at which the CPU-only path stops being a compromise. If you last evaluated self-hosted TTS in 2024 and concluded it wasn't ready, that conclusion is now out of date.
Fun... This is something I actually care about...I used to keep a version of whisperx around, because I think it's important to have not just transcription, but also timing and speaker identification (e.g. for subtitles)... It depends on pyannote, though, which has some wierd licensing (and is
Kokoro voices were the non-human actors directed by Opus, featured in the sound performance "God Bless the United States of Aliens". A theatrical adaptation of a liturgical texts, a surveilled mass ceremony at a protesting Christian church, being exhibited at the 61st Venice Biennale until
Love this model. I’m GPU poor and have had FOMO that I haven’t played with local models at all. About a month ago I setup Kokoro on my GTX1650 to do TTS for an article reader. A simple WebUI lets me paste a URL or a chunk of copy pasted text. Python cleans it up and sends to Kokoro for TTS and it’s
This repo is a good starting point for comparing TTS models https://github.com/5uck1ess/tts-benchKokoro is a really good model, considered it’s released 1.5 years ago. It’s punching above its weight https://5uck1ess.github.io/tts-bench/scores.html
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I have used Kokoro fairly extensively for an accessibility product. I have loved working with it (especially because I don't have an NVidia GPU like many TTS of similar quality require).I particularly appreciate the fact that it lets you manually add IPA pronunciation guides. There have been so