Prompting an AI assistant well usually means more than a single question. A good prompt often includes constraints, an example of the format you want back, context the assistant would otherwise have to guess at, or all three at once. Typing all of that, one keystroke at a time, happens dozens of times a day for anyone who prompts regularly — and it adds up the same way any other repeated typing does. This page is about replacing the typing with speech, not the prompting itself: the app has no idea what a good prompt is, and never touches the wording once it lands.
Extract the list of constraints from this document and put them in a numbered list, preserving the original wording exactly.
Starting with the assistant already open
The easiest flow is the one you are probably already in: the assistant is open in a browser tab or an IDE, and you have decided what to ask. You do not need to move the cursor to the chat box or type anything to prepare — the app does all of that the moment you press the hotkey.
Your cursor should already be in the chat box when you hold the key. Most assistants put focus there automatically when the page loads, and when you start a new conversation, the focus returns to the chat box after each message. If you have been reading somewhere else on the page — scrolling back through earlier messages, looking at the assistant's previous response — click the chat box once to move focus there, then hold your hotkey. The words land wherever the cursor is focused at the moment you press the key, which means if the chat box has focus, the prompt lands there.
The actual prompt: press, speak, release
Hold your hotkey — the default is ⌥ Space, Option and Space pressed together — speak the prompt exactly as you want it read, and let go when you have finished speaking.
- 09:154.1sExtract the list of constraints from this document and put them in a numbered list, preserving the original wording exactly.Claude
- 10:405.8sSummarize the three options above into a table with cost and effort as columns.ChatGPT
- 15:033.2sExplain why this is failing and what to do about it.Cursor
The prompt lands in the chat box as exactly as you said it, character by character, including filler words if any ("um", "uh") — those come through unless you have turned filler removal on in the app settings, which is off by default. Once the text is in the box, it is yours to edit, refine, or send as-is.
Reading it back before sending
This is the single most important habit to build from the first prompt: read what landed before you hit send. A misheard word in a prompt does not just produce a typo the way it would in an email — it can send the assistant down an entirely wrong line of reasoning. Fixing that after the assistant has already started working is harder than the ten seconds a read-back takes, and it only happens if you notice it after the fact. A read-back costs nothing and catches mistakes before they matter.
The words sit in the chat box, editable, readable, and pausable for as long as you need before the assistant sees them. This is an advantage over a tool that pipes speech directly to the assistant as it is being spoken — in a text box, you can review, modify, and decide whether to send.
Why the prompt is written to history before it goes anywhere else
- 1Key downthe target is chosen here
- 2You speaklevel meter, over your work
- 3Key up
- 4Written to historybefore the engine is asked
- 5Engineon your Mac
- 6Typedabout half a second
A chat interface that reloads mid-message, a browser tab that loses focus, or a network hiccup in the assistant's own connection are ordinary hazards of browser-based work, and any of them can interrupt a prompt that's mid-dictation. The safety net is that the words are already written to local history the moment you release the key — before this app's own engine is even asked to transcribe them. That means a lost connection to the assistant, a closed tab, or a crashed page costs a copy-and-paste from history, not the prompt itself.
Nothing about this is uploaded — no audio, no transcript, the app works with no internet at all, though the assistant on the other end still needs its own connection to answer.
Following up in the thread with a second prompt
A conversation with an assistant is often a series of short prompts more than one long one, and each follow-up works the same way: hold the hotkey, speak, release, and the words land in the conversation thread wherever the cursor already is. The difference is that the second prompt is shorter (usually a clarification or a "try again with this angle instead") and sometimes you are editing or quoting something from the assistant's previous response before sending your own.
The same principle applies: the words land first, the assistant sees them second, and you decide what to send before they ever see it.
Multi-constraint prompts — say them as one continuous thought
The best prompts are the ones where you pile three or four separate requirements into one message instead of sending them as four separate ones. Something like: "Rewrite this paragraph to use active voice, cut it to under fifty words, and remove any jargon a new reader would not know." That is three things stacked together, and it dictates faster than typing it — the thought comes out whole, in one breath, and the assistant has all the context at once instead of in sequence.
A common mistake is starting to dictate, pausing to think about what constraint comes next, then picking up the dictation again. The app does not stitch pauses together by default; what you get is what you said, including silence. If you need to think, let go of the key, think, press the key again and dictate the next sentence. Two dictations in a row are quicker than a long pause in the middle of one.
Prompting across different assistants in the same window
A common pattern: trying the same prompt in multiple assistants to compare answers. You open one assistant, dictate a prompt, read the answer, then open a different one. The prompt is still in your local history, so you can paste it into the next assistant's chat box rather than dictating it again — which is faster if you do not want to change it, and slower if you are going to adjust it slightly for the second assistant anyway. Your choice each time.
The app works the same way in any text field, so switching assistants costs nothing beyond moving to the next window. There is no assistant-specific setup, no integration to configure, and no difference in how the prompt gets typed depending on which assistant is about to read it.
Including context in the prompt — pasted content and dictated explanation
A prompt is often mostly context and only briefly a question — pasting in a code snippet, a stack trace, or a paragraph from a document before asking what to do about it. The context usually comes from a file or a previous message, already sitting somewhere you can reach. What you are adding is the explanation of what to do with it.
If you are dictating that explanation instead of typing it, the workflow is: paste the context first (the code, the error, the document excerpt), press enter if you want space between the context and the question, then hold the hotkey and dictate the question. The result is a prompt with the full context, your exact wording, and no keystroke-for-keystroke typing between the two.
Custom vocabulary and project-specific terms
If you work with jargon or specific terms — a product name, an internal acronym, a library name — the app has a dictionary you can fill in. You type the entries yourself; nothing is inferred from what you dictate, and nothing carries to another machine. The dictionary is used twice: as a hint before recognition and as a filter after, so it helps the engine understand what you are saying and also corrects common misheard variations after the fact.
That means a prompt about "our Shapekit API integration" comes out as you said it if you have registered "Shapekit" and "API" in the dictionary, and comes out as the engine heard it if you did not. For anyone prompting an assistant about internal systems, filling in the dictionary on the first day is worth the five minutes it takes.
Why shorter prompts sometimes get ignored by the assistant
A one-line question is so quick to type by hand that dictation barely changes the arithmetic; the prompts that actually save time are the longer ones — multiple constraints stacked together, a worked example showing the format, a block of context copied in from somewhere else. If you find yourself dictating a lot of very short prompts, the payoff is smaller than for longer ones, which is worth knowing before assuming dictation is the answer to every prompt.
When to dictate and when to stick with typing
Prompts that are mostly code or syntax sometimes actually type faster than they dictate, because speaking a line of code like const handler = (event) => { ... } means the engine hears something it is not trained on, and it needs a dictionary entry for every symbol and every operator, which is more work than typing it. Prose prompts — "adjust the tone of this to sound more formal" — dictate faster. Mixed prompts, with both code and explanation, are worth trying either way and sticking with whichever is faster for your specific assistant and your specific code.
The choice is yours each time: if a prompt feels like it will type faster than it will dictate, type it. The same hotkey works for all the prompts that benefit from dictation, and you do not have to be consistent. Switch between the two within the same conversation thread without any penalty.
Reading back the prompt one more time
It is worth restating: the moment between dictating a prompt and sending it is the moment to read it back. A misunderstood word, a dropped constraint, a phrase that came out differently than intended — all of these are visible in the text box and editable in ten seconds, before the assistant has a chance to misinterpret them. A prompt that does not read quite right can be edited right there, or deleted and dictated fresh. The habit of read-and-check costs nothing and saves the back-and-forth that comes from sending a prompt the assistant misunderstood.
What happens to your prompts
Every dictated prompt is written to local history the instant you release the key, kept on the machine you dictated it on, and never uploaded anywhere. This is useful for the privacy angle, but it also means you can search your past prompts locally and regenerate a question you have already asked without having to remember exactly how you phrased it the first time.
A prompt dictated at your desk does not automatically appear on your laptop if you dictate from both machines — each installation has its own history, which is worth knowing before assuming a saved prompt will simply follow across devices. Each machine is independent.
Adjusting a prompt after the assistant has already started
Sometimes an assistant starts working on a prompt and you realize mid-answer that you meant something slightly different. The assistant is working on the version that landed in the chat box, not a version you can edit in real-time — but you can let the assistant finish, then send a follow-up correction in the next message. You can also paste the original prompt from history, edit it, and send it as a new prompt to compare answers.
This is another situation where the read-back before sending is the safety: if you catch the mistake before you press send, it never reaches the assistant in the first place.
Building the habit
The first few prompts often feel awkward because dictating feels less natural than typing for something that is already well-formed in your mind. The habit builds somewhere around the fifth or sixth prompt, when the flow becomes invisible and you stop thinking about how the words are getting from your head to the chat box. The general page on dictating long documents covers the same transition for other kinds of writing, and the time investment is the same: a few tries until it is automatic.
Why this fits alongside other uses of the same hotkey
Developers use the same hotkey to dictate prompts to coding assistants and also to dictate PR descriptions, commit messages, and code comments — all within the same workflow. The accessibility pages show how the same mechanism helps anyone reduce typing, regardless of the destination. You are not learning one thing just for prompting; you are learning one mechanism that works everywhere text can be entered.
Who should try this
Anyone prompting an AI assistant several times a day, working on a Mac, and willing to build a small habit around it. The thirty-day trial is long enough for that habit to form and for real prompts to accumulate in history — worth trying against a real week of work rather than a demo.
If you are new to dictation entirely, start there to understand how the mechanism works before applying it to prompting specifically. If prompting is already a big part of your day, try the accessibility tools comparison to see whether a full voice control setup is what you actually need, or just a hotkey for typing.