Voice dictation for Cursor

Cursor changed how a lot of developers spend their day. The editor is still an editor, but a large share of the work has shifted into a conversation — describing what you want, refining it, reviewing what came back, asking for the next change. That conversation is typed. And typed conversation, it turns out, is exactly the part of the job where voice helps most.

This post is about using voice dictation inside Cursor. Not for writing code character by character — that is still a keyboard job — but for the prompts, the chat, and the prose that now fill so much of an editing session.

Where the typing actually goes in Cursor

If you watch yourself work in Cursor for an hour, the keystrokes split into two very different piles.

One pile is code: identifiers, brackets, operators, indentation. Dense, precise, punctuation-heavy. This belongs to the keyboard. Nobody wants to say "open brace" out loud.

The other pile is language. It is the prompt in the chat panel. It is the follow-up — "that is close, but keep the existing error handling and only change the retry logic." It is the inline instruction you give for a specific edit. It is the explanation you write so the assistant has enough context. This pile is plain English, sometimes several sentences at a time, and it is growing.

That second pile is what voice is for. It is prose. You already know how to speak prose.

Why prompts are better spoken

A typed prompt tends to be short because typing has a cost and you are economizing without realizing it. You write "add caching here" and hit enter. The assistant guesses at the rest, guesses wrong, and you spend two more rounds correcting it.

A spoken prompt comes out differently. When you say it, you naturally include the context: "Add caching to this function. It is called on every render, the data only changes when the user switches projects, so cache on the project ID and invalidate when that changes." That is the same thought, but complete. You said it because speaking it cost you nothing — no extra typing, no fatigue. And a complete prompt gets a better first answer, which means fewer rounds and less total time.

This is the quiet advantage. Voice does not just move text faster. It changes what you are willing to say, and in an AI-assisted editor that directly affects the quality of what comes back. We wrote more about that effect in why voice changes the prompts you write.

How a system-wide dictation tool fits Cursor

Here is the part worth being precise about. A good dictation tool does not need a Cursor plugin, a Cursor extension, or any Cursor-specific integration at all. Cursor has a text cursor, like every other application. A system-wide dictation tool simply inserts text wherever that cursor is.

That means it works in every text field Cursor has — and Cursor has many:

the AI chat panel
the inline prompt for a targeted edit
the editor itself, for comments and docstrings
the integrated terminal
commit message fields in the source control view
the search box, settings fields, anywhere else you can put a caret

You do not configure any of this. The tool does not know it is "in Cursor." It just types where you are typing.

That is how Lispr works. It is a small macOS app — about 4 MB — that sits in the menu bar with no window. You hold the right Option key, speak, and release. The transcribed text appears at the cursor in whatever app has focus. In Cursor that might be the chat panel one minute and the integrated terminal the next, and Lispr does not care which; both are just places a cursor blinks. There is nothing to install into the editor and nothing to keep updated when Cursor updates.

A practical workflow

Here is a routine that works well after a day or two of getting used to it.

Open the chat or inline prompt as usual. Click into the field with the mouse or a shortcut, exactly as you do now.
Hold the right Option key and describe the change. Speak it the way you would explain it to a colleague sitting next to you. Include the context, the constraint, the thing not to break. Release the key.
Read it before sending. Spoken text benefits from a quick glance. Fix a word if needed, then send.
Type the code edits yourself. When you are adjusting the result by hand, that is keyboard work. Voice does not enter into it.
Dictate the commit message at the end. When the change is done, hold the key and say a full, descriptive commit message instead of a terse one. It lands in the same source control field.

Notice that you never decided "now I am in voice mode." You held a key when you had a sentence to say, and released it when you were done. The rest of the time your hands are on the keyboard writing code. The two modes interleave without ceremony.

What to expect

The first prompts you dictate will feel slightly unfamiliar — talking to an editor is a new habit. Within a day that fades. What stays is two things. First, your prompts get longer and more specific, because the cost of detail dropped to nearly zero. Second, you stop noticing the seam. Code is typed, language is spoken, and you move between them the way you already move between keyboard and trackpad.

Cursor moved a lot of the developer's day into a conversation. Voice simply lets you have that conversation the way humans have always had conversations — by talking. The editor does not need to know you are doing it.

If you work in the terminal as well, the same approach applies to agent tools there — see voice dictation for Claude Code. And if you are weighing voice against the keyboard in general, voice typing vs typing covers the trade-offs.