How to dictate prompts into ChatGPT, Claude, Cursor and Claude Code on a Mac

Speaking a prompt helps when the idea is clear in your head but slow to type. You can describe the context, the exception and the thing that keeps going wrong in one continuous thought. The useful part is the extra detail. A long recording alone does not make a good prompt.

This guide covers two things. First, the voice options already built into ChatGPT, Claude, Cursor, Claude Code and macOS, and when a separate dictation app is worth it. Second, a way of speaking a prompt in four parts, then checking it before you send it. That last step catches the small transcription mistakes that can change the whole request.

The built-in voice options, compared

Most of these tools now have some voice input of their own. They differ in where they work and where your audio goes. Here is what each vendor's own documentation says, checked on 27 September 2026.

Claude Code: /voice

Claude Code has its own dictation for prompts. Type /voice to turn it on. By default you hold Space to talk and release to stop, and a tap mode is also available. According to Anthropic's voice dictation documentation, it works in the Claude Code CLI, agent view and the VS Code extension, but not in cloud or SSH sessions. The same page says your recorded audio streams to Anthropic's servers for transcription and is not processed locally. It needs a Claude.ai login rather than an API key, supports 20 languages, and uses your project and branch names as recognition hints. If you spend most of your day in Claude Code and that processing suits you, it is the most integrated option there.

The Claude app for Mac

The Claude desktop app can take dictation through quick entry. Once you turn it on, you press Caps Lock to start and press it again to finish. Anthropic's quick entry article says the feature is off by default because it takes over Caps Lock, and that dictation needs macOS 14 or later. The text goes to Claude. It is not a way to type into other apps, and the article does not say where the audio is transcribed.

ChatGPT

ChatGPT has a dictation microphone in the message box. The OpenAI voice dictation FAQ says the recorded audio is sent to OpenAI's models to be transcribed, that you can edit the text before sending, and that the audio is kept for as long as the chat stays in your history. A data controls setting decides whether your recordings may be used to improve its models.

Cursor

Cursor added built-in speech-to-text for controlling its Agent in the Cursor 2.0 changelog. The Cursor 3.1 changelog says you press and hold Ctrl+M to speak in the Agents Window. Neither changelog says where the audio is processed, so check Cursor's current documentation if that matters for your work.

macOS Dictation

Apple's Dictation works in any text field, so it works in all of the apps above. You turn it on in System Settings under Keyboard, then Dictation. Apple's Dictation guide says you can dictate text of any length without a timeout, and that it stops after 30 seconds without speech. The text under Dictation in Keyboard settings tells you whether your Mac processes it on the device. It types what you said, including fillers and restarts, and costs nothing.

A system-wide push-to-talk app

A dictation app sits outside the assistant. Rambleproof, which we make, is one of them: in any app, you hold a shortcut, speak and release, and cleaned text is pasted at your cursor. The same shortcut and the same dictionary work wherever you type, so you do not have to learn a different voice feature in each tool. In Local mode, transcription and cleanup run on your Mac and work offline after setup. Cloud processing is an optional Pro choice that uses your own OpenAI, OpenRouter or Gemini key.

Some apps, including many browser-based and Electron editors, do not let Rambleproof read the field back to confirm a paste. If text does not appear, the dictation is still in its local History, and a shortcut (Control + Command + V by default) pastes the last one again. Rambleproof needs an Apple silicon Mac with macOS 15 or later, and English is the language we test and recommend.

Scroll the table sideways to see all columns.

Which one to use

If you mostly use one assistant and its own voice input works for you, use it. There is nothing to install. A separate app earns its place when you move between several assistants and editors in a day, want one dictionary for the names and terms you use, want filler and restarts cleaned up before the text lands, or want speech processed on your Mac. Whichever you pick, the prompt is only as good as what you say and check. The rest of this guide is about that.

Start with a place where you can review the text

Click into the prompt field or a plain-text note. If a particular app submits on Return, or you are unsure how it handles pasted paragraphs, use the note first. Speak a short harmless sentence, check where it lands, and move it into the assistant yourself. Establish that ordinary input path before dictating a detailed request.

With Rambleproof, finish the one-time setup before you start: activate the app with an account or license key, let it download its models, and grant the microphone and Accessibility permissions. Then click into the prompt field, hold the shortcut, speak and release. The download page lists the current requirements.

Dictation entering text is separate from an assistant acting on that text. A local dictation route does not make the destination AI service local. Once you submit a prompt to a cloud assistant, that service's own data policies apply. Leave sensitive material out unless your chosen tools and workplace policy permit it.

Use four parts, in this order

1. Say the outcome first

Begin with the result you need: “Draft an email asking the supplier to confirm the revised delivery date.” This gives the rest of the explanation a destination. Avoid starting with a minute of background and only revealing the task at the end.

For a coding task, the outcome might be “Find why the Save button stays disabled after the form becomes valid.” For a writing task, it might be “Turn these notes into a one-page decision memo for the operations team.” These are useful requests because someone can later check whether the response did the job.

2. Explain only the relevant context

Describe what prompted the request and what the assistant can inspect. Keep a sentence when it changes the answer. Drop it when it only repeats how frustrated or busy you feel.

For example: “The supplier first promised Thursday. They now say the parts will arrive Monday, but our installer is booked for Friday. We can move the appointment once without paying another fee.” That context explains why confirmation matters without dictating the entire email word for word.

3. State the constraints plainly

Say the things the response must preserve: dates, amounts, names, tone and actions that need your approval. Put a negative constraint in its own sentence if it matters: “Do not promise a new installation date.” It is easier to spot a missing “not” in that sentence than in the middle of a long aside.

When using an assistant that can take actions, distinguish research, drafting and execution. “Prepare the change and show me the preview” is a different request from “Publish it.” The prompt should say which outcome you intend.

4. Describe the output

Finish with a shape: “Give me a short subject line and two paragraphs.” Or: “Explain the cause, propose the smallest useful fix and list what you verified.” This helps you assess the answer without asking for an elaborate format that the task does not need.

You do not have to speak the labels “outcome, context, constraints, output” every time. They are a mental checklist. Pause briefly between the parts and keep moving.

A worked example

Here is an intentionally messy spoken request:

Help me write to the supplier. The components were meant to arrive Thursday and now it's Monday, I mean next Monday, and the installer is coming Friday. We can move that appointment once without another fee. Ask them to confirm Monday in writing and tell us if anything is still missing. Don't promise them a new install date. Keep it polite and fairly short, subject line and two paragraphs.

After dictation, review the prompt as text. You might make one targeted edit: replace “next Monday” with the exact calendar date. Then send it. You do not need to turn a clear spoken explanation into formal prompt language.

This example illustrates how to frame the request. It is not a promise that any dictation tool will produce a specific transcript or that any assistant will follow every instruction.

Use your voice for explanation and your keyboard for exact strings

Names and identifiers deserve a separate pass. You may naturally say “the customer I D field” while the code uses customer_id, customerId or a label you have not opened yet. Copying the exact identifier is often easier than explaining every character aloud.

A good coding prompt can therefore mix the two input methods:

Investigate why saving a valid form leaves the button disabled. I have selected the component below. Check how validation and loading state interact. Preserve the current request format. Show the cause and a proposed fix before changing unrelated screens.

Paste the exact component path, error message or relevant snippet afterward. This separates your explanation from evidence the assistant should inspect. It also avoids presenting an approximate spoken filename as an exact match.

For recurring names, a personal dictionary can help. Start with the few terms you actually use. If a spelling keeps failing, check the app's supported correction or alias feature. Do not assume a saved term guarantees that every similar sound will be interpreted correctly.

Check five things before sending

Read the final text once for these details:

1. Names and exact strings. Are people, product names, filenames and URLs correct?
2. Numbers and dates. Did “fifteen” become “fifty”? Is “next Friday” ambiguous?
3. Negation. Did “do not change the public API” survive?
4. Scope. Is the assistant being asked to explain, draft, edit or execute?
5. The final correction. If you changed your mind while speaking, does the text express the final instruction?

Correct the prompt, not just the assistant's eventual answer. A response can be perfectly reasonable for a mistranscribed request.

Troubleshoot the right stage

If words are missing, check microphone selection and the recording indicator. If a name is repeatedly wrong, inspect the recognized text and dictionary options. If correct text appears in the wrong place, check the selected field and insertion behavior. If the prompt is accurate but the answer is unhelpful, adjust the task or supply the missing context. These are different problems.

For an unfamiliar app or terminal, test harmless prose in a scratch document first. Avoid dictating a command into a place where an accidental newline could execute it. This is a practical input check, not evidence that a specific terminal is unsupported.

You can compare input tools using a small set of your own tasks rather than a polished demo. Our dictation evaluation guide explains a repeatable test. If the problem is Apple's built-in input, start with Mac dictation troubleshooting.

Try it on the next request you were going to type

Pick something you understand well: an email, a planning question or a bug explanation. Say the outcome, relevant context, constraints and output. Read the resulting prompt and fix the important details. Judge the workflow by the effort needed to reach a useful request, not by how many words you managed to speak.

If you want that workflow through a hold-to-talk shortcut on a supported Mac, try Rambleproof. Check the current plans and limits and complete the one-time setup first. For the processing choices, read local versus cloud dictation.