Voxor
Download 
Try saying this out loud:
git commit dash m quote fix auth flow quote
In an email, a dictation tool is rewarded for making speech look polished. It might capitalize the first word, add a period, and turn the quotes curly. In a terminal, those small improvements can turn a valid command into the wrong one.
The output we want is plain:
git commit -m "fix auth flow"No final period. No typographic quotes. No helpful rewrite of “auth” to “authentication.” And, most importantly, no automatic press of Enter.
A larger technical vocabulary will not solve this on its own. The destination changes the job.
A dash has consequences here
Prose can tolerate small variations. A sentence with one extra space still means the same thing. In a shell, one character can select another flag, point to a different path, or make the command fail.
The text also switches roles constantly during a developer’s day. A long prompt inside Cursor wants readable prose. A comment in VS Code wants punctuation and line breaks. A variable name wants exact casing. The terminal at the bottom of the same window wants literal symbols.
Looking only at the spoken words is not enough. “Go to source” could belong in
a message to a colleague, or it could mean cd src. Voxor has to consider the
app, the focused control, and sometimes the characters around the cursor before
deciding how much cleanup is safe.
When that context is uncertain, leaving the transcript alone is better than confidently inventing a command.
Spoken symbols need to stay boring
There is no universal way to say code punctuation. People say “dash,” “hyphen,”
and “minus.” They say “slash” for /, except when they do not say it at all and
expect a path to appear. Naming styles add another layer: account_id,
accountId, and account-id sound almost identical when spoken.
The tempting response is a large voice grammar that promises to understand everything. Those grammars are impressive in a demo and exhausting in daily use. Every hidden rule is another thing to remember.
We prefer a small set of literal phrases that behave consistently. “Dash dash
force” can become --force. “Dot dot slash source” can become ../src.
“Snake case account id” can become account_id. If you say “new line,” it
should insert a line break rather than the words.
Predictability wins here. A short phrase you can remember is more useful than a clever interpretation you have to check every time.
Quotes deserve suspicion
Quotes are where ordinary writing software causes a surprising amount of damage. Curly quotes look right in an article and are often invalid in code. Straight quotes are only the beginning: single and double quotes behave differently in a shell, escaping varies by language, and a variable may expand inside one form but not the other.
Voxor can insert the characters you ask for. It should not pretend to understand the full quoting intent of a complex command from tone of voice alone. Existing delimiters should stay in place, newly dictated delimiters should be explicit, and the result should remain visible before anything executes.
That last boundary is non-negotiable for us. Dictating a command and running a command are separate actions. Speech can put editable text at the prompt. You decide when it is ready.
Cleanup has to know when to stop
The cleanup that makes Voxor pleasant for messages can be risky around code. A model may replace a short technical word with a longer, more formal one. It may smooth away a repeated phrase that was intentional. It may turn a spoken path into a sentence because the sentence looks more fluent.
Some details deserve extra protection: numbers, URLs, paths, flags, and words you spelled out. If one of those changes during cleanup, the app should notice. Basic checks catch a surprising number of mistakes. Quotes and brackets can be counted. A suspiciously shortened result can fall back to the transcript. A path that loses a separator should not be inserted as if nothing happened.
These checks do not prove a command is correct. They catch the kinds of damage that a language model can make while producing perfectly readable text.
Why the words appear after you finish speaking
Partial transcription is especially awkward at a prompt. Halfway through the
utterance, “dash” is still a word. A moment later it may be part of --force.
A package name may remain ambiguous until the next two words arrive.
Voxor can stream audio while you speak without placing every provisional guess under the cursor. Once you release the key, it has the complete utterance, can apply the terminal rules, run the basic checks, and insert one stable result.
That short pause is less distracting than watching a command repeatedly rewrite itself. It also makes the boundary before execution much clearer.
Test the failures that can ruin an afternoon
Generic speech benchmarks do not tell us enough about developer dictation. A transcript can contain almost every spoken word and still corrupt the one flag that matters.
Our useful test cases look more mundane: a path with mixed case, two hyphens in a flag, a port number, nested quotes, a comment beside executable code. We keep long dictated prompts too, because an over-eager cleanup pass may summarize them. When a real correction reveals a recurring failure, the sanitized version belongs in the regression suite.
Voice is already a good fit for code reviews, commit messages, comments, prompts, and plenty of shell work. The difficult part is not recognizing technical words. It is knowing when punctuation is style and when punctuation is an instruction.
Related reading: Voxor for developers, works with Cursor, and works with VS Code.