September 15, 2026

How to Dictate Prompts to Coding Agents on Linux

A coding agent does about as well as the brief you hand it, and typing a proper brief is the slowest part of the loop. Here's how on-device voice to text fits into a terminal agent workflow on Linux: why pasting into a TUI is harder than it looks, the honest state of Wayland support, and which Whisper model to run for long prompts.

If you drive an agent from a terminal, you already know the shape of the problem. A good task description names the files that matter, the constraint you actually care about, what “done” looks like, and what the agent should leave alone. That is four or five sentences before you have said anything about the bug itself.

Typing all of that, every time, is tedious enough that most people stop doing it. They send “fix the login bug” and get back a confident change to the wrong file. Then they spend ten minutes explaining what they meant, which is longer than the brief would have taken in the first place.

The brief is the bottleneck, not the model

Agent quality has improved faster than anyone's typing speed. The models read a whole repository now; the limiting factor is how much of your intent makes it into the prompt box. Talking is faster than typing for anyone who isn't a competitive typist, and it's a lot faster for the kind of rambling, qualified, “but be careful about X” context that makes an agent run land.

Spoken briefs also tend to be better, not just longer. When you talk you naturally explain why, mention the thing you tried yesterday, and add the constraint you'd have skipped while typing because your hands were already tired.

Cloud dictation undoes the reason you ran the agent locally

Here's the catch, and it's the reason a lot of developers never bothered with dictation. If your agent works against a private repository, client code, or anything under NDA, you were deliberate about keeping that code on your own machine. Routing every spoken instruction through a speech vendor puts the same material on someone else's server by a different wire, and the prompts you dictate often describe the system in more detail than the diff does.

Cloud speech-to-text is a fine trade for a grocery list. It's a strange trade when the whole point of the setup was local control. (We wrote a longer piece on where dictation audio actually goes if you want the app-by-app breakdown.)

The other advantage of local transcription is boring and comes up more often than the privacy one: it works on a plane, on hotel wifi, and while your VPN is having a bad day.

Pasting into a terminal is where most tools fall over

This is the part nobody warns you about. There are two ways to get text into a focused window on Linux: synthesize the keystrokes one character at a time, or put the text on the clipboard and send a single paste keystroke.

Character synthesis is what most DIY dictation scripts do, because xdotool type and wtype are right there. It's fine in a browser text field. It is genuinely bad in a terminal UI, because every character forces a re-render of the whole interface. A 200-word prompt is roughly 1,200 keystrokes, and a full-screen agent interface running inside tmux can freeze for several seconds in the middle of one, which is a memorable way to lose a dictation you just spent 40 seconds on.

Wspr does the other thing, on every platform. It saves whatever is on your clipboard, writes the transcript to both CLIPBOARD and PRIMARY, sends one Shift+Insert, then puts your original clipboard back. One keystroke and one re-render, whether you dictated eight words or eight hundred. Rapid-fire dictations don't clobber the clipboard either: only the most recent paste is allowed to restore it, so firing off three prompts in a row leaves your clipboard exactly as you found it instead of holding a stale transcript.

The honest state of Wayland

Linux dictation writeups usually get vague right here, so: the keystroke above has to come from somewhere, and which backend sends it depends on your session.

The middle row is newer than most comparison articles think. Wspr used to force everything through XWayland, which meant a “Control input devices” permission prompt on every single launch. Since version 5.1.2 it holds one RemoteDesktop portal session for the life of the process and injects through libei, so the compositor remembers the grant: you see a single “Started Remote Desktop” notice per session and nothing afterwards. Details are in the changelog.

The global hotkey goes through the same portal family on Wayland. Registering it the X11 way (grabbing the key) is blocked by GNOME's compositor by design, which would leave you with a dictation hotkey that only fires while a Wspr window is focused. Instead the hotkey is registered with the GlobalShortcuts portal, so it works from whatever you're actually looking at. The side effect worth knowing: your desktop owns that key binding, so you rebind it in your desktop's own settings (on GNOME, under Settings then Apps) rather than inside Wspr.

And the limit, stated plainly: a compositor with neither the RemoteDesktop portal nor XWayland has nothing for Wspr to paste through. If you run a minimal Sway or Hyprland session with XWayland stripped out, this isn't your tool yet.

Which model to run for long prompts

Dictation for agent prompts is a different workload from dictating a chat message. The clips are longer, 30 to 90 seconds is typical, and they're full of file paths, library names, and identifiers that a small model will cheerfully mangle.

Large v3 Turbo is the model to pick for this. It's a 1.6 GB separate download under Settings then Models, and it reaches Large v3 accuracy at roughly Small's speed. Measured warm on an RTX 4060 Ti with Vulkan, a 45-second recording transcribes in 1.16 s, against 3.40 s for Large v3 and 1.93 s for Medium. Small (460 MB) remains the recommended default and it's perfectly good for short commands, but for a technical brief the accuracy of a Large-class model saves you the cleanup pass. Custom vocabulary hints handle the project names no Whisper model has ever heard.

The workflow, which is deliberately boring

1. Focus the terminal your agent is running in.
2. Hold your hotkey and talk. Brief it the way you'd brief a colleague: goal, the files involved, the constraint, what done means.
3. Release. Transcription runs on your GPU and the text arrives at your cursor.
4. Send it.

Notice what isn't in that list: a step where you go back and repair the transcript. That's the part people expect from dictation and the reason they gave up on it, and two things remove it here.

Custom vocabulary hints teach Wspr the words a general-purpose model has no reason to know. Your repo names, your service names, the internal library nobody outside your stack has heard of, the colleague whose name Whisper insists is a verb. They come back spelled the way your codebase spells them, which is exactly the class of error that used to make dictated prompts more expensive than typed ones. Pair that with a Large-class model on a decent microphone and the raw transcript is usually already correct.

The second thing is the transcribe and rewrite hotkey, a separate binding that does both in one action. The rewrite pass drops the filler, the “um, so, basically” and the sentence you started over halfway through, and hands your agent a brief that reads like you wrote it on purpose. It's worth knowing where that text goes: rewrite is the one step that leaves your machine, through your own API key. For this workflow that's usually a non-issue, since the prompt was on its way to a hosted model anyway, and it stays off until you turn it on.

One practical safeguard for this workflow: if a paste lands in the wrong window because you clicked away a second too early, the optional paste last transcription shortcut re-inserts your most recent transcript into whatever is focused now. You'll find it under Settings then General, and Shift+Alt+V is a reasonable choice. If your compositor wants to own the key itself, bind it to wspr --paste-last instead.

Recordings as context, not just prompts

The same local engine does file transcription, which turns out to pair well with agents. Drop in the recording of the call where the requirements were actually decided, or the voice memo where you thought out loud on the drive home, and hand the transcript to your agent as context instead of retyping the gist from memory. Whisper covers 99 languages with automatic detection, so a meeting that drifted between two of them still comes out readable.

What leaves your machine

For transcription, nothing. The model sits on your disk, whisper.cpp runs it on your GPU with CPU fallback when there isn't one, and the temporary audio file is deleted the moment transcription finishes. No account, no telemetry, no crash reporting.

The one exception is worth naming because vague privacy claims deserve suspicion: optional AI rewrite. If you turn it on, the text (never the audio) goes to OpenAI, Anthropic, or Gemini using your own API key, straight from your machine to the provider you picked. Leave it off and nothing touches a network. The full detail is in the privacy policy.

Try it on your own desktop first

Linux input handling is too fragmented for anyone to promise your exact compositor will behave, so don't take our word for it. Wspr ships as an AppImage and a .deb for x86_64, and the free download includes 50 live transcriptions and 5 file transcriptions with no account and no card, which is plenty to find out whether the paste lands where you want it. Pro is $14.99, once, and it unlocks unlimited live and file transcription, custom rewrite styles, and unlimited history.

If you want the wider Linux picture rather than the agent-specific slice, that lives in Voice-to-Text for Linux in 2026.