Voice coding: how developers dictate to Claude Code, Cursor, and Copilot

You hold the hotkey, talk for four minutes about the bug you just found, let go — and nothing appears. The recording is gone, along with the only version of that thought you had.

That’s one of the failures developers report about /voice in Claude Code, and it isn’t the only one. Public reports and the discussion on Anthropic’s issue tracker describe the same short list: recordings that drop, no project dictionary — so internal service names, library acronyms, and package names come back misspelled every single time — and English-only input. It’s a good demo. Heavy users hit the wall in about a week.

So: what breaks, why, and what it takes to build the version that doesn’t.

Why prompts are the ideal dictation workload

A prompt to a coding agent is long, structured, and disposable. You write 200 words describing what you want, the agent does something with it, and nobody reads that paragraph again. Compare it to the code itself — short, dense, precise, and permanent.

Dictation wins where text is verbose and thrown away. That’s the whole reason this niche appeared at all. The highest-value thing to speak in a developer’s day isn’t code. It’s the paragraph of intent that sits above the code.

There’s a second-order effect too. Because you’re talking rather than typing, you say more. Constraints you’d have skipped — “don’t touch the migration files,” “the flaky test in the auth suite is known, ignore it” — make it into the prompt, and the agent’s first attempt lands closer.

Our research team frames the shift as moving from treating speech as dictation to treating it as executable command input. The text isn’t the deliverable. The action is. That reframe is also what the emerging patterns for driving a coding agent with voice keep circling back to, and it’s the same instinct behind writing better prompts for Claude in the first place.

What breaks when you point generic speech-to-text at a terminal

Four failures. Every one of them shows up in the first ten minutes.

Identifiers become English

bolt.module.paportal comes back as “bolt module pa portal.” axios becomes “axe eos.” A general transcription model is doing precisely what it was built to do — writing down the most probable sequence of English words. Package names, version strings, issue IDs, and internal service names are, statistically, not English words.

It’s an entity accuracy problem rather than a word accuracy problem, and it’s the one that makes people quit. Aggregate accuracy looks fine while every proper noun in the prompt is wrong.

Syntax becomes prose

The Copilot CLI thread named this one cleanly: “if colon newline indent a equals 42” dictated verbatim is not working code. Speech has no indentation, no brackets, and no way to signal that you’ve moved from describing something to specifying it.

You can teach users to speak a punctuation grammar. Physicians already do it, and it works — but it’s a training burden most developer tools can’t impose.

Filler survives

Coding agents follow instructions literally. That’s the point of them. It’s also why a raw transcript is a hazard: a false start becomes an instruction.

Say “let’s use Postgres — no, wait, use SQLite” into a verbatim transcriber and the agent receives both. Add the ums, the restarts, and the half-sentence you abandoned mid-thought, and you’ve handed a literal-minded system a document that contradicts itself.

No context

The same words mean different things depending on where they land. “Fix the failing test in the user service” is a command in a terminal, a description of finished work in a commit message, and a request to a teammate in a Slack thread. Same audio, three correct outputs, and an endpoint that sees only the audio can’t pick between them.

What it takes to build the version that works

Each failure above has a fix, and they sit at different layers. Getting the order right matters more than any single parameter, and the full feature set a shipping dictation feature carries runs wider than the four fixes below.

Get the identifiers right before cleanup

This one is first because nothing downstream can repair it. A word that was never heard can’t be recovered by any amount of post-processing.

Two controls do the work, and they do different jobs. Contextual prompting describes the setting and the vocabulary the model should expect to hear — something like “a software engineer dictating a bug report; expect package names, version numbers, and issue IDs.” Keyterms prompting carries the terms you already know will appear: your library names, your service names, your internal acronyms. If you’re building dictation into a developer tool, you know that list at build time and can extend it per project.

The keyterm prompting docs cover the mechanics. One tradeoff that isn’t obvious from them: explicit language selection is ignored when a custom prompt is set. For an English-speaking developer audience that costs you nothing. If your users dictate across the flagship model’s other supported languages, you’re choosing between pinning the language and prompt-driven jargon handling, and you should make that choice deliberately rather than discover it in a bug report.

Underneath all of it, the model matters more than the parameters do. This runs on Universal-3.5 Pro — the same flagship behind our pre-recorded and streaming endpoints, not a smaller variant tuned for latency — which is the difference between a package name landing and a package name becoming two English words.

Shape the output for where it lands

Cleanup handles filler and false starts. A rewrite instruction handles everything past that — plain English, per request, so the same hotkey behaves differently depending on where the text is going.

A terminal wants a terse imperative. A commit message wants a subject line and a body. A pull request description wants prose with the “why” intact. Same audio, three instructions, three shapes of finished text. Wire that stage up through an LLM Gateway and keep the verbatim transcript alongside the rewritten version, so your product never has to guess which one it’s holding — and so a “show original” toggle is a display decision rather than a second API call.

The boundary is worth stating plainly, because it’s the thing developers most often assume works the other way. The rewrite polishes; it does not correct. Hand it “axe eos” and you get “Axe EOS,” confidently capitalized and still wrong. Fixing that belongs upstream, in the prompt and the keyterms. It’s the same reason a rewrite stage is a formatting layer and not an accuracy layer.

Feed it context

This is the highest-impact and least-obvious part of the build, and almost nobody does it.

Send what’s around the cursor. Send the selection. Send what app or field the user is dictating into. Our own dictation experiments got materially better the moment surrounding text became part of the request — not because the model got smarter, but because “the failing test” stopped being ambiguous once the request carried the file the user was staring at.

The pattern generalizes: whatever your editor knows and the user hasn’t said out loud, the request should carry.

Make the hotkey feel instant

Dictation is a UI-blocking interaction. The user has stopped talking and is looking at the cursor. There’s no background job here and no spinner you get away with.

Three things carry most of the weight. Push-to-talk, so the clip boundaries are set by the user rather than guessed by a silence detector — the push-to-talk dictation tutorial covers capture and encoding. Connection pre-warming, so the first request of a session isn’t the slow one. And keeping the number of sequential inference calls down, because a transcript hop and a rewrite hop compound, and the second one usually crosses the public internet to a different provider.

For scoping: the Sync API is the shape that fits here — bounded audio that’s already complete, one request, one finished result, no partial hypotheses to render and revise on screen.

One reliability argument that shows up on laptops: a single request survives a network change. Your user closes the lid, walks to a meeting, reopens on cellular, and holds the hotkey. A WebSocket held open across that handoff is dead. A POST goes out over whatever interface exists now.

Where this goes

The version of this that gets interesting isn’t dictation into an agent. It’s dictation as command input — where “run the tests and fix whatever breaks” is a spoken instruction the agent executes, not a string it writes down.

That’s a much shorter utterance doing much more work, and it puts the whole burden on the layer between the microphone and the agent. Get the identifiers wrong and the agent edits the wrong file. Leave the false start in and it does two contradictory things. Drop the context and it asks which test you meant.

Which is the part most teams skip, because it doesn’t look like the hard part. Transcription is a solved-looking problem right up until the words are bolt.module.paportal.

Frequently asked questions

Does Claude Code accept voice input?

Yes. Claude Code includes a built-in /voice dictation command, so you can speak a prompt instead of typing it. Developers report real limits on it — dropped recordings, no project dictionary for internal names and library acronyms, and English-only input — which is why many teams bind a system-wide dictation hotkey instead and let it type into the terminal like any other app.

Is there a voice plugin for Claude Code?

The supported path is the /voice command that ships with Claude Code rather than a separate plugin. Because coding agents read from the terminal or editor like any other text field, the common approach is an app-agnostic dictation utility bound to a global hotkey — the same setup works in Cursor, in Copilot CLI, and in your commit messages. Superwhisper and the leading dictation apps take that shape.

How do you enable voice mode in Claude Code?

Run the /voice command inside a Claude Code session and speak your prompt. Availability and setup steps vary by platform and version, so check Anthropic’s current documentation rather than an older walkthrough. If you need a custom dictionary or non-English input, a separate dictation layer calling a speech-to-text API gives you both.

Why is voice input not working in VS Code, on Mac, or under WSL?

Most voice input failures are permission or audio-routing problems rather than model problems. On macOS, the app that owns the hotkey needs microphone and accessibility permissions granted separately, and a fresh grant usually needs a restart before dictation types into another window. Under WSL there’s no audio device inside the Linux environment by default, so capture has to happen in a Windows-side app that types into the terminal. In VS Code, confirm a terminal panel has keyboard focus when text is inserted.

What’s the best speech-to-text setup for dictating prompts to an AI coding agent?

The setup that works has four parts: push-to-talk capture so the user sets the clip boundaries, a transcription prompt plus keyterms carrying your package and service names, a rewrite instruction that shapes the output for its destination, and the surrounding editor text sent along as context. Get the first one right before the others, because nothing downstream recovers a word that was never heard.

How do I stop dictated prompts from mangling package and identifier names?

Bias the transcription itself, before any cleanup runs. Pass a prompt describing the setting — a developer dictating a bug report, expecting package names and version numbers — and pass your known identifiers as keyterms. Post-processing can’t recover a term that was never heard, so a rewrite instruction listing your library names does nothing for this.