Voice control for coding agents on Mac: what actually works

By Meffysto · updated October 4, 2026

Voice for writing code: no thanks, you type more precisely than you speak. Voice for directing five agents that write code: different story. It all comes down to one word, targeting. Here's what works, in what order to set it up, and where it stops being worth it.

The win isn't typing speed

With five sessions open, half your gestures exist only to point at things: find the right window, click into it, check it has focus, and only then type. One sentence removes that whole step. "Send Merlin goal one" carries both the target and the content.

It's the same reason a command palette feels good, except voice also works when your hands are holding a coffee or your eyes are on another screen. It doesn't replace the keyboard. It replaces the mouse hunting for a window.

1. Recognition has to be local, and fast

Two criteria, in this order.

Latency first. Past half a second between the end of your sentence and the action, you stop using voice: you hesitate, repeat yourself, and end up clicking. Small speech models running on Apple silicon now get down to a few hundred, even a few dozen, milliseconds. Fauconnier runs Parakeet locally, around 135 ms on an Apple silicon Mac.

Location second. A developer's mic picks up private repo names, internal paths, client names. Transcription belongs on the machine. That's also what makes it work offline, on a train or anywhere else.

Feed it your vocabulary: your agents' names, worktree, tmux, your repo names. An engine that knows which words to expect makes far fewer mistakes than a generic one.

2. A name per agent, not a number

Nobody says "send to session 3". People say "send to Merlin". Naming agents isn't a gimmick: it's what makes voice addressing workable, and it's also how you'll still know who's who an hour later.

Two things to check when comparing tools. The name you gave must be the only source of truth: a tool that renames agents after the CLI running them breaks voice commands at the first duplicate. And an ambiguous name must trigger nothing. If "Mer" could mean Merlin or Mercury, the right move is to send nothing and ask. Typing into the wrong terminal is worse than doing nothing.

In Fauconnier, name matching ignores case and accents, accepts a prefix as long as it's unique, and you can add a lasting alias: "call this window the payment flow". The original name still works; you just have two.

3. Several commands in one sentence

Nobody speaks in atomic commands. People say "open a claude agent on the site and a codex on the API", or "tidy the windows, then tell me what Chase found". Two requirements:

• commands run in the order you said them, not in parallel and not backwards;
• self-correction is understood: "actually, start with…" reorders instead of piling up.

This is the hardest part to get right and the easiest to test. Splitting a sentence is a pure function: you can feed it hundreds of real sentences and check the output. If a vendor can't tell you how they measure it, they probably don't.

4. Spoken feedback, or the loop stays open

Speak to start things but read to find out how they went, and half the gain is gone. "Tell me what Chase found" should produce an answer you hear. There are two ways to produce it.

Locally: Apple's on-device model summarises what the session just printed. Zero tokens, zero network, and it works even when your quotas are spent.
With a remote model: better on long text, but you pay and you wait.

For "where is it at?", local is enough and wins. Keep remote models for questions that really need reasoning.

5. The keys, and a mic that stays off

One setup detail decides everything else: which key opens the mic. When a terminal has focus, a bare key (Space, a letter) goes to the terminal, as it should. Only modifier keys get through. Fauconnier defaults to three right-hand modifiers: right ⌥ for commands, right ⌘ for dictation, right ⌃ for conversation. The mic lives while you hold the key, or toggles on each press, depending on the setting.

Wake-word listening exists too, for talking without touching the keyboard, but it's off by default. Always-on listening should be something you arm, never a default.

6. What should stay on the keyboard

To be honest about the limits: voice is bad for dictating a code snippet, entering an exact path, picking from a long list, working in an open-plan office, or working at night next to someone asleep. It's also bad at answering a menu. A menu wants a key, not a sentence.

A serious voice tool therefore offers the same vocabulary on the keyboard: a command palette, a text field, and ideally a command-line tool for anything you want to script. In Fauconnier that's ⌘K, the command bar and fauconnierctl, all generated from the same verb table as voice. Add a command once and it exists everywhere.

Where to start

Don't start by doing everything by voice. Start with one sentence you'd say twenty times a day, typically "where are we at?" or "where's Merlin at?". Once it's a reflex, add dispatch by name, then handoffs. Within a week you'll know whether voice saves you time or costs you some. Both answers happen.

Frequently asked questions

Does my voice go to the cloud?

Not for commands and dictation: speech recognition runs on the Mac, and summaries come from Apple's on-device model. What you then ask an agent goes to that agent's AI provider, exactly as if you'd typed it.

Does it understand languages other than English?

Fauconnier understands English and French. Agents receive your instruction as you said it.

Which key opens the mic?

By default right ⌥ for a command, right ⌘ to dictate into the targeted agent, right ⌃ for conversation. They're modifiers because a bare key would go to whichever terminal has focus.

Can I do everything without talking?

Yes. Anything you can say you can also type in ⌘K or the command bar, or script with fauconnierctl. The mic only turns on when you ask.

Read next

• Running several coding agents at once
• Claude Code from your iPhone
• CNVS alternative