The problem
A general speech-to-text model is trained on ordinary speech, so it leans toward ordinary words. When you say something it has rarely heard, it substitutes the nearest common word it knows. "Confluence" comes out as "confidence." "Firebase" comes out as "rebase." The transcript reads fluently and is quietly wrong, which is the worst kind of wrong, because nothing looks off until you reread it.
These are the exact words a technical writer cares about most: product names, libraries, acronyms, and the identifiers in your own codebase. Evoglyph corrects them in the acoustic layer, grounded in what you actually said, rather than leaving it to a language model to guess later from context.
A second model, listening again
Right after the main speech model (NVIDIA Parakeet) produces its transcript, Evoglyph runs the same audio through a second, independent acoustic model: a CTC keyword-spotter. Its one job is to check whether any term from your vocabulary is a better acoustic match for what you said than the word the main model chose. This is not a find-and-replace over the text, and it is not a language model rewriting your words. It is a second opinion on the sound itself.
The keyword-spotter runs with a context bias toward your terms, which makes a listed word roughly twenty times more likely to win when it genuinely matches the audio (about twelve times once your list passes ten terms). Everything after that first pass is plain arithmetic over the scores the model produced, so adding more vocabulary does not add more listening passes. If anything goes wrong at any point, the pipeline falls back to the raw transcript untouched.
Two parts make this work, and it is worth keeping them separate. The model is an openly licensed keyword-spotter from NVIDIA (about 103 MB, CC-BY-4.0). The scoring layer around it, the part that decides which candidates are trustworthy, composes your vocabulary, and splices the accepted corrections back into the transcript, is Evoglyph's own.
Where your vocabulary comes from
Your vocabulary is assembled from several sources every time you dictate, in priority order, so the terms most relevant to what you are doing right now win first:
- Cursor context. The name-shaped words just before your cursor (up to a couple dozen of them), so a term you were just typing is ready when you speak it.
- Project scan. Names pulled from your current project: README, manifest, and directory names.
- Workspace. Terms drawn from the broader workspace you are in.
- Your curated list. The vocabulary you add by hand. This is the only tier that supports phonetic aliases, so you can teach Evoglyph that "laura" should become "LoRA."
Corrections from every source are gathered and applied in a single position-aware pass. When a term appears more than once, only the specific spot the audio supports is changed, not every copy of the word. The assembled vocabulary is cached and only rebuilt when your terms change, so the common case adds no measurable overhead. To manage your curated list and see tips on what to add, see Custom vocabulary.
The guardrails
A booster that is too eager is worse than none at all, because it starts rewriting common words into your rare ones. Evoglyph gates every replacement behind two checks.
First, a confidence floor scaled to word length. A correction only lands if the keyword-spotter is confident enough, and the bar is higher for short words, which collide with far more things:
| Word length | Minimum confidence to replace |
|---|---|
| 1 to 4 characters | 0.92 |
| 5 to 6 characters | 0.88 |
| 7 characters or more | 0.82 |
Terms shorter than three characters are skipped entirely. These floors were raised over time in response to real collisions seen in use (the kind where "rebase" turned into "Firebase," or "confidence" into "Confluence"), and they keep being tuned as new ones turn up.
Second, a common-word guard. If the main model heard one of the ten thousand most frequent English words, the booster leaves it alone, on the reasonable assumption that it heard right. The one exception is a word you have explicitly taught as an alias. This guard only covers that top-ten-thousand list, so short developer words outside it, like "grep," lean on the confidence floors alone.
What it can't fix: homophones
Vocabulary boosting is acoustic. It fixes words the main model got wrong as sound. It cannot fix words the model heard perfectly well as sound but that are wrong in meaning, like "their" versus "there" or "one" versus "won." Those are acoustically identical, so no amount of listening again resolves them; only the surrounding sentence does.
That job belongs to homophone correction, which runs later, inside the cleanup model, and disambiguates from context. The two systems are deliberate counterparts: vocabulary boosting works on the audio before any language model, homophone correction works on the meaning inside it.
Privacy and licensing
Vocabulary boosting runs entirely on your Mac, on the CPU and the Neural Engine, alongside the rest of the pipeline. Your vocabulary, your cursor context, and your audio never leave the device. On any error, the feature fails safe to the raw transcript rather than blocking your dictation.
The keyword-spotting model is openly licensed by NVIDIA under CC-BY-4.0 (open weights, with attribution). The scoring and guardrail layer built around it is Evoglyph's own, proprietary code. For the full account of what stays local and every network call the app makes, see Where your audio goes.