openWakeWord vs an online wake word generator: two paths to a custom model
openWakeWord is the default answer when Home Assistant users want custom wake words, and for good reason: it's free, open source, and ships with a set of official pretrained models. I've used it, and parts of my own product exist because of its limitations.
Because people ask me to compare it with Voicute — the online generator I built — here is an honest breakdown: what openWakeWord's training path actually involves, where it struggles, and what a hosted generator changes. (microWakeWord, the ESP32-side cousin of openWakeWord, gets its own post.)
First, the right mental model
These are not two versions of the same thing. openWakeWord is a pipeline you operate: open-source training notebooks, open weights, open runtime, and you own every step. Voicute is a hosted workflow that operates the pipeline for you — type a phrase, get a model. The training platform is closed source; the inference engine and the exported models are open.
If your decision criterion is "must the training code be open?", this comparison is over — pick openWakeWord and be done. The comparison below is for everyone else.
What custom training on openWakeWord looks like
For the official pretrained models, openWakeWord is excellent — download, load, done. The story changes when your phrase isn't one of them:
- Generate synthetic positive samples with the Piper sample generator (free, open TTS)
- Assemble negative datasets: background audio, speech, music
- Run the training notebook (Colab or local Python)
- Export ONNX/tflite, test on the real device, and usually iterate
One structural fact explains most of the pain: the speech embedding backbone is frozen. Custom models are small classifiers on top of a fixed feature space. When your phrase lives in a badly-covered region of that space, no amount of training steps pulls recall up — I've measured swings from roughly 25% to 90% between two words trained with the identical recipe. Lowering the threshold to recover recall buys you false wakes.
Also note the language situation: the official pretrained models are English. The training notebook can synthesize samples in other languages via Piper voices, but you own the entire validation burden — nobody has tuned that path for you.
What the hosted generator does differently
Same goal, different allocation of work:
| openWakeWord | Voicute | |
|---|---|---|
| Code | fully open (training + runtime) | training closed; engine + models open (GitHub) |
| Sample TTS | Piper (free) | commercial neural TTS |
| Architecture | frozen embedding + small classifier head | from-scratch TCN per model |
| Real recordings | DIY — record, re-run notebook, repeat | upload in browser, retrain is one click |
| Multi-keyword | one model per word, stacked at runtime | 2–10 words in one model (~128 KB, <5 ms) |
| Languages | English pretrained; others DIY | Chinese, English, German, French, Japanese workflows |
| Output | ONNX / tflite | ONNX + TFLite, standard formats |
| Time to first model | hours–days, notebook fluency required | minutes to a testable model |
Three of these deserve a paragraph each.
No frozen embedding. Because Voicute trains from scratch per model, the network can shape its feature space around your specific phrase instead of drawing a boundary inside a fixed one. That's the direct answer to the "word-picking" problem above — not magic, just not inheriting someone else's frozen features.
Commercial TTS + real recordings. Piper is impressive for a fully open pipeline, but synthetic samples are the only positive evidence an openWakeWord model ever sees, and Piper's prosody/accent range is narrow. Voicute starts from commercial-grade neural TTS — closer to natural speech, fewer retrain cycles — and, more importantly, treats real recordings as a first-class step: when recall disappoints on real hardware, you record a small varied set of the actual phrase, upload it, and retrain. A small varied set beats hundreds of duplicate takes. All of this is possible in openWakeWord's world too; it's just you, scripts, and an afternoon each time.
Multi-keyword in one model. openWakeWord trains one model per word, and your runtime stacks them. A wake word plus four commands means five models to tune and serve. Voicute trains 2–10 keywords into a single model with one inference pass — ~128 KB and under 5 ms on an ESP32-S3.
When openWakeWord is still the right call
- Your phrase is close to an official pretrained model — free, proven, done.
- You need the training pipeline itself open and auditable end to end.
- You're researching, not shipping, and the notebook loop is part of the fun.
When the generator earns its keep
- The phrase is non-English, or English-but-picky (the 25%-recall kind).
- Recall must be stable without per-device threshold tuning.
- You need wake word + commands in one small model.
- The person doing this is a firmware engineer with a deadline, not an ML hobbyist.
That's the whole trade: open pipeline you operate vs hosted workflow that operates it for you, with different TTS, different model architecture, and a real-recording loop measured in minutes. If runtime openness matters to you, note that Voicute's engine and models are on GitHub — measure recall yourself rather than trusting any "90%+" claim, mine included.
Disclaimer: I'm the creator of Voicute. openWakeWord is referenced fairly as far as I can — it's a genuinely good project; if I've mischaracterized anything, tell me and I'll correct it..
Top comments (0)