Dictating into Claude Code from Windows

Typing is not the bottleneck when you are writing code. It is the bottleneck when you are writing instructions about code.

A prompt to a coding agent is a paragraph of context: what the file does, what is wrong with it, what you tried, what you want instead, and what it must not touch. I can say that paragraph in about the time it takes to think it. Typing the same paragraph takes several times longer, and something worse happens along the way. I shorten it. I drop the constraint about not touching the other file because typing it felt like effort, and then I spend ten minutes undoing a change I could have prevented with eleven spoken words.

That is the actual return on dictation for agent work. Not speed, though it is faster. The return is that you stop truncating your own instructions, because saying the extra sentence costs you nothing.

Everything else about dictating into a terminal is a preference. This part is not.

The dictation tool must not take keyboard focus.

Claude Code runs in a terminal. If pressing your dictation shortcut pops up a window that grabs focus, the terminal loses it, and now the text is typed into the wrong place, or into nothing, or the terminal's own input state is confused when focus comes back. A lot of dictation tools are built around a panel you talk into, then copy from. That is fine for writing an email and useless here.

What you want is a tool that stays entirely out of the input path: a shortcut you press while the terminal still has focus, a recording indicator that is deliberately not focusable, and text delivered as if you had typed it. When Quickword's recording pill was built, not-focusable was the load-bearing property, not a detail. It is the difference between dictating into your session and dictating next to it.

If you are evaluating something else, that is the first thing to test. Open a terminal, start a session, hold your shortcut, and watch whether the cursor stays in the terminal.

Both, and for different sentences.

Push to talk, where you hold a modifier while you speak, is right for short instructions. Hold, say "run the tests and show me only the failures", release. Nothing to remember to turn off, and no risk of leaving the microphone open while you swear at the output.

The toggle is right for the long ones. If I am describing a whole refactor, a hold that lasts forty seconds is genuinely uncomfortable, and if you have any wrist trouble at all it is worse than typing. Tap once to start, talk, tap once to stop.

My bindings, which are the ones Quickword now defaults to, came from what I already had in muscle memory from the app I was replacing. Ctrl and Shift held is push to talk. Ctrl Shift Z is the hands-free toggle. Nothing else changed, so my hands did not have to relearn anything on the day I switched.

One warning, learned the annoying way. If you are trialling a new dictation app alongside your old one, quit the old one first. Two apps registered on the same shortcut both fire, and you get two recordings, one of which arrives late and pastes over your prompt.

I expected to need a hosted speech engine for technical vocabulary. Mostly I do not.

Prompts to a coding agent are full sentences of ordinary English with a handful of proper nouns in them: file names, library names, the name of your own project. General speech models handle the sentences well. What they get wrong is the proper nouns, every time, and no amount of enunciating fixes it.

The fix is a word list. Add the names you say all day, and they come out spelled the way you spell them instead of phonetically. It takes about ten minutes to seed and then it stops being a problem. Once the vocabulary is handled, a local model running on your own machine is close enough to a paid cloud service that I stopped noticing the difference during normal work.

Where hosted engines still pull ahead is noise, unusual accents and unfamiliar words that are not in your list. Being able to switch is worth having. Being forced to upload every clip to get any transcription at all is not.

Two things, honestly.

You still have to read the output. Dictation makes it fast to send a long instruction, and a long instruction produces a large diff. If you speak four sentences of specification in twenty seconds and then spend four minutes reviewing what came back, you have moved the work, not removed it. That is usually a good trade, and it is a trade.

And you cannot dictate a code snippet. Punctuation-heavy text, exact identifiers and anything where whitespace matters are all faster to type. I paste code and I speak about code. Trying to dictate a regular expression is a party trick, not a workflow.

There is also a social limit that nobody mentions in these posts. Dictation requires being able to talk out loud, and in an open office or a shared room that is either awkward or impossible. It is a great tool for people who work alone, which is not everyone.

If you want to try this on Windows: install a dictation tool that types at the cursor rather than into its own window, pick a local model, grant microphone access, set push to talk to a modifier pair you can hold comfortably, set a separate toggle key for long dictations, and add your project's proper nouns to the word list before you judge the accuracy.

That is the whole setup. It took me longer to write this paragraph than to do it.

I built Quickword because I wanted that setup to work identically on my PC and my MacBook, offline, without paying a subscription for a job my own hardware can do. It is free and it is early. If you dictate into agents on Windows, it was built for exactly what you are doing.