Talk to your terminal
Dictating prompts to a CLI agent beats typing them.
Most of my work with a command-line agent is writing prompts. Claude Code and Codex do best when I can provide as much information as possible. They excel at determining what I want from the latent constructs in the text I provide. Detailed prompts of this kind easily run three hundred words long (and longer), and typing three hundred words for every prompt, all day, is a kind of energy-sapping drudgery. The rational response is to shorten the prompt, which also degrades the answer and the work being done.
Earlier this year, I discovered just how good the speech-to-text technology is and created setups for my desktop machine which runs on Linux and my Macbook Pro. I stopped typing most of my prompts and started dictating them. I tap a hotkey and talk at the terminal through my mic for as long as the thought takes. Another tap ends the recording, and about a second later the cleaned-up text is sitting at my cursor. Accordingly, my prompts got longer and the answers and outputs got better, because a language model is very good at pulling intent out of even meandering speech. It needs volume and specifics, and speaking is the cheapest way to supply both. I still type anything that must be exact, such as slash commands, file paths, flag names, and model IDs, but almost everything else I say out loud.
This configuration has been especially useful for work that benefits from repeated explanation and close supervision. I use it to iterate on my own writing, draft emails, develop prose from rough ideas, and produce detailed feedback on student assignments, particularly writing assignments. In that setting, the limiting factor is often not what I have to say, but how much of it I am willing to type. Thorough feedback requires explanation: identifying the problem, showing why it matters, suggesting a revision, and sometimes distinguishing between several possible ways forward.
The advantage is not simply that speaking is faster. It also makes it easier to think through a response in full. I can talk through an argument, qualify a judgment, add examples, and revise my own assessment as I go. I then clean it up through edits, mostly typed but also some spoken. For student advising, this has been a big improvement. I can give more specific and more useful feedback. I have not subjected this to an A/B test, but my impression, and I am open about this with my students, is that the feedback is much better than what they are used to receiving.
Typing, however, is not obsolete. It remains better for anything that must be exact. The most effective workflow combines the two. As I will explain below, there is some modification of your voice as it is produced as text, especially if you want it to be clean. This post documents the improvement in the underlying technology, then the setup I run on Linux and macOS. Both configurations are public, hyperwhspr for Linux and macwhspr for the Mac. Speech-to-text is useful for all sorts of cases, but my reflections from here on are based primarily on my experiences from interacting with Agentic AI.
Speech recognition is good now
For a long time, dictation software produced enough errors that correcting the transcript took longer than typing it would have. In 2011, Microsoft researchers cut the word error rate on conversational telephone speech from 27.4 percent to 18.5 percent by swapping Gaussian mixture models for deep networks (Seide, Li, and Yu 2011). A system that still got nearly one word in five wrong counted as the breakthrough of its day. By 2016 the same benchmark was at 5.8 percent, alongside a measured 5.9 percent for professional human transcribers (Xiong et al. 2016). A year later it was 5.1 percent (Xiong et al. 2017).
OpenAI’s Whisper made high-quality speech recognition widely accessible. Trained on 680,000 hours of audio, it transcribed LibriSpeech at 2.7 percent error zero-shot and held up on accents and noise where earlier models collapsed (Radford et al. 2022). In 2023 it went behind an API at $0.006 USD per minute (OpenAI 2023), which is 36 cents per hour of speech. The 2025 generation, gpt-4o-transcribe, beats Whisper across the FLEURS language benchmark by OpenAI's own evaluation (OpenAI 2025). These figures come from different test sets. They are not directly comparable, but together they illustrate the broader improvement in accuracy, quality, and cost.
Once transcription accuracy became good enough, the remaining irritation was the pause after speaking. The 2026 releases address this, with streaming models that transcribe while you talk instead of after you finish. ElevenLabs claims under 150 milliseconds for Scribe v2 Realtime (ElevenLabs 2025), and OpenAI's gpt-realtime-whisper streams over a WebSocket at $0.017 per minute (OpenAI docs). I switched both of my machines to it this week, with notable improvements.
The setup
The pipeline is the same on both machines. A hotkey starts recording. Audio streams to the transcription model while I speak. A second tap commits the buffer, and the final transcript comes back in about a second. A small LLM then repairs the transcript, and the result is pasted at my cursor in whatever window has focus, which is usually a terminal and occasionally a draft like this one.
hyperwhspr, for Linux
On Linux the recorder is hyprwhspr, and scdenney/hyperwhspr is the reproducible configuration pattern I run under Omarchy/Hyprland. It holds the streaming backend config, the cleanup hook with its constrained prompt, the vocabulary file, the systemd service with its Wayland fixes, and the calibration command that uses the cleanup log to make new vocabulary rules. The README keeps a dated known-issues table, including this week's switch to the streaming model and other notes added by AI agents or by me.
macwhspr, for the Mac
There is no hyprwhspr on macOS, so scdenney/macwhspr is the whole setup in one small repo. An idempotent installer copies everything into place. A small Python daemon records audio with SoX and streams it to the transcription service. Pressing and releasing the Globe key (my hotkey of choice) starts or stops recording, with Karabiner and Hammerspoon handling the keyboard shortcut and a small on-screen status indicator. launchd keeps the daemon running in the background, and if a transcript ends up in the wrong window, Ctrl-Cmd-V opens a list of the last twenty recordings so it can be recovered and then pasted where you want. The repository contains the complete setup. Aside from the platform-specific content, the transcription, cleanup, calibration, and logging pipeline is the same as on Linux.
The cleanup stage is an underrated part of this setup that I did not quite appreciate until setting it all up. The transcription model returns raw text with filler words, false starts, and little punctuation. A tightly constrained GPT-4.1 mini prompt restores punctuation, paragraph breaks, and consistent formatting, but it is explicitly told not to change the meaning or answering the content. If I dictate a question, I get back a well-formatted question, not an answer. Every raw and cleaned transcript pair is logged, and a calibration command uses those logs to update a vocabulary file with preferred spellings, names, romanizations, and other recurring corrections — this is how you can customize your use. Over time, the system gradually adapts to the way I speak.
Below is a recording loop example from my Linux machine. Hotkeys start the recording, the pill streams the live transcript while I speak, and a second pushing of the hotkeys send the cleaned-up text to the Claude Code prompt.
Latency differences
Until this week both machines uploaded the finished recording after I stopped talking, which meant the wait grew with the length of the dictation. The streaming backend does the work during the speech itself.
I measured both backends on identical audio, synthetic speech streamed at real-time pace over the same network. On a 6.5 second clip, batch took 1.7 seconds after stop and streaming took 0.9. On 94 seconds of audio, batch took 5.9 seconds and streaming took 0.9 again. Across the lengths I tested, the streaming wait was effectively flat at about a second. My most recent log has a 128 second dictation, a spoken complaint about a LaTeX table layout in a manuscript — a commonly written and voiced / yelled complaint, I am sure. The transcription wait alone was five seconds. Under the streaming backend, a dictation of that length now finishes in about one second. For a workflow built on dozens of dictations a day, that dead time adds up. The newer model is much better, in other words.
Each cell in that chart is a single run, though the production logs agree with the pattern. Streaming costs $0.017 USD per minute against $0.006 for batch, so a two-minute dictation costs about three cents. The realtime model accepts no vocabulary prompt, so domain terms ride on the cleanup stage instead. A WebSocket connection has more failure modes than a file upload, and both repos keep the batch path one config line away. The last caveat is that the audio leaves the machine. If that is unacceptable, hyprwhspr supports a local ONNX backend, at the cost of about 5.7 GB of VRAM and maintaining the model yourself. I found the local option usable, but not good enough to justify those additional demands.
What a month of this costs
The question of cost comes up whenever I describe this setup, so before writing this post I pulled thirty days of logs from both machines. Between June 13 and July 13 I dictated 662 times across the two machines, which comes to 7.7 hours of speech and 54,796 words. The transcription bill for the month was $2.77 USD, and the cleanup model added another $0.27, so the total was $3.04, or about five and a half cents per thousand words. The whole window ran on the older batch backend, and at streaming prices (my latest setup) it would come to about $8.11. For me, the difference is negligible. The deciding factor is the latency.
Make the switch
Typing still has an imporant role, just to be clear. It is better for writing commands, file paths, quotations, citations, identifiers, and anything else that must be exact. It also remains an important part of writing itself. I am not about to dictate an entire scientific manuscript. Drafting, revising, and polishing still belong at the keyboard — at least for me, for now.
But typing should not be the only way you work with AI agents. Restricting yourself to the keyboard either limits the context you provide or makes providing that context unnecessarily slow and tiring. The better workflow is hybrid. Explain the problem out loud, let the transcription and cleanup stages produce a first draft, then edit it if needed, adding the precise commands, paths, or other details that only typing can reliably supply.
Speech recognition is accurate, inexpensive, and nearly immediate. Talking to an agent is no longer a novelty or an accessibility matter. It is a practical way to give these systems that are coming to dominate our computational and other kinds of pipelines the detailed instructions they require. If you do substantial work with agents and still type every prompt from beginning to end, you are imposing a bottleneck the technology has largely removed.