← Resources

Push-to-talk vs always-on dictation

Short answer: push-to-talk means you hold a key while you talk and release when you are done, so the microphone is open only for that span; always-on dictation keeps the microphone listening until you switch it off, and wake-word assistants listen for a trigger phrase. The difference is who controls the capture boundary, and that one choice shapes privacy, cleanup cost and which work each model suits. Parakeety chose push-to-talk on purpose, as one expression of the broader picture of Mac dictation that stays on-device. Here is the even-handed version of where each interaction model wins.

Three interaction models at a glance

The label "dictation" hides three quite different ways of getting your voice into text. They differ less in the speech model and more in who decides when the microphone is listening.

ModelHow you start and stopCapture boundaryBest for
Push-to-talkHold a key, talk, releaseExactly the held spanDeliberate dictation while you keep working at the keyboard
Toggle / always-onSwitch on, talk freely, switch offEverything until you remember to stopLong hands-free sessions where reaching for a key is the friction
Wake wordSay a trigger phrase to beginWhatever follows the trigger, plus a listening bufferFully hands-free, voice-first control

Control over the capture boundary

The capture boundary is the single most useful lens here. With push-to-talk, the boundary is the key: the microphone opens when you press and closes when you let go. There is no ambiguity about what was recorded, because it maps exactly to the span you were holding. You decide, by hand, what counts as dictation and what does not.

Always-on dictation moves that boundary out of your hands. You switch it on, then the microphone stays open until you remember to switch it off. In practice the session often runs longer than the speech you meant to capture: the sentence you said to a colleague, the phone that rang, the thinking-out-loud you would not have typed. A wake word tightens the start by waiting for a trigger, but it still has to be listening before the trigger in order to hear it, so the microphone is effectively open the whole time.

None of this makes always-on wrong. It makes the boundary looser, and looser is exactly what you want when the goal is to keep talking without touching the machine.

Privacy implications of an open microphone

An open microphone is a privacy question even before you ask where the audio goes. With push-to-talk, the answer to "what could this have heard" is bounded: only what you held the key for. With always-on or wake-word listening, the honest answer is wider, because the microphone was live around everything else too.

The second layer is the network. If dictation transcribes in the cloud, an always-on microphone is also a continuous outbound path, and the privacy posture then rests on what the vendor promises to do with that stream. If dictation runs on-device, the audio stays on the machine regardless of model, but the capture window is still the wider one. The architectural point, that audio never leaving the device is a different shape of guarantee from a promise about audio that has left, is the same distinction we unpack in the piece on architectural versus contractual privacy.

Parakeety stacks both narrow choices: push-to-talk for the capture boundary, and on-device transcription so the audio never leaves the Mac in the first place. The only outbound traffic is a one-time speech-model download and periodic license checks, never your audio.

Error and cleanup cost

Every interaction model produces a different kind of mess to clean up. Push-to-talk fails closed: if you do not hold the key, nothing is captured, so the failure mode is a missing sentence you simply say again. There is rarely stray text to delete, because the microphone was shut the rest of the time.

Always-on fails open. The classic cost is the session you left running: a paragraph of off-topic speech transcribed into the document, the half of a meeting that landed in your notes, the "are you free for lunch" sitting in the middle of a client email. Cleaning that up is editing work, and it is the tax you pay for not having to reach for a key. Wake-word systems add their own failure: a false trigger that starts a capture you did not intend, or a missed trigger that drops the one you did.

For work where the transcript is the deliverable, the cleanup cost usually favors push-to-talk. The boundary that feels like friction in casual use is the same boundary that keeps the document clean.

Microphone conflict behavior

On a Mac the microphone is a shared resource. An always-on dictation tool holds it for the length of the session, which can collide with a video call, a recording app or another tool that wants the same input. A wake-word listener wants the microphone open more or less permanently, which is the heaviest claim on a shared device.

Push-to-talk holds the microphone only while the key is down, so it stays out of the way of everything else for the rest of the time. You can dictate a note between calls without a tool having quietly held the input the whole morning. It is a small thing day to day, but it is the difference between a dictation tool that shares the machine and one that occupies it.

Where always-on and wake-word win

The honest case for the looser models is accessibility and genuine hands-free use. If holding a key is painful or impossible, push-to-talk is the wrong design, and an always-on or voice-control model is the one that actually works. That is the world of hands-free computer control, where speaking to start and stop, and driving the cursor by voice, is the entire point. We cover that category, and where it diverges from plain dictation, in the comparison with Talon Voice.

Always-on also suits long, uninterrupted sessions in a quiet room: drafting at length where reaching for a key on every paragraph is the friction, not the open microphone. And for people managing strain or recovering from an injury, reducing the keypresses themselves can be the goal, which is part of the wider case for voice as relief from typing. The right model follows the constraint you are actually under.

Which model suits which work

  • Push-to-talk. You type most of the day, dictation is an extra input, and the transcript is real work: clinical notes, code review comments, client emails, drafts. You want a clean capture boundary and a closed microphone the rest of the time.
  • Always-on / toggle. Long hands-free drafting in a quiet space, or any case where reaching for a key on every utterance is the main friction and stray capture is easy to tolerate.
  • Wake word. Voice-first control where you are not at the keyboard at all, and starting by speaking a trigger is the natural entry point.

Apple Dictation sits closer to the always-on end, with sessions that can end on a pause and a shortcut to toggle listening. How that compares to a held-key loop, and why the cut-offs frustrate longer dictation, is the subject of the Apple Dictation comparison.

Why Parakeety chose push-to-talk

Parakeety is push-to-talk by design: hold the section key, talk, release, and the words paste at the cursor in whichever app you were in. The choice is deliberate. A held key gives an exact capture boundary, keeps the microphone closed the rest of the time, leaves the microphone free for calls and recordings, and removes the cleanup cost of an open session. It pairs naturally with on-device transcription on the Apple Neural Engine, where you want the capture window to be a thing you choose rather than a thing left running.

That said, push-to-talk is not the universal answer. For hands-free accessibility it is the wrong model, and we say so plainly. The point is to match the interaction to the work, not to claim one model wins every time.

FAQ

What is push-to-talk dictation?
Push-to-talk dictation means you hold a key while you speak, then release it when you are done. The microphone is open only for that span, and the text pastes at the cursor. It mirrors the radio convention of holding a button to transmit. Parakeety works this way: hold the section key, talk, release, and the transcript lands in whatever app you were typing into. The opposite model is always-on dictation, where the microphone listens continuously until you switch it off.
Is always-on dictation a privacy risk?
It depends on where the audio goes. Always-on dictation keeps the microphone open, so the boundary of what gets captured is looser than with push-to-talk. If the app transcribes in the cloud, that open microphone is also a continuous network path. If it transcribes on-device, the audio stays on the machine but the capture window is still wider than a held key. Push-to-talk narrows capture to the moment you choose, which is why it is the easier model to reason about for confidential work.
Which is better for hands-free dictation on a Mac?
Always-on or wake-word models are better when you cannot hold a key, for example because of a motor impairment or because your hands are occupied. Hands-free voice control systems are built for exactly that. Push-to-talk needs one free finger on a key, so it suits people who type most of the day and want dictation as an extra input rather than a full replacement for the keyboard. The right answer follows the constraint, not the other way around.
Why did Parakeety choose push-to-talk?
Push-to-talk gives you an exact capture boundary and keeps the microphone closed the rest of the time, which suits dictation that is real work rather than casual one-liners. It removes the cleanup cost of an open microphone catching half a conversation, and it pairs naturally with on-device transcription where you want the capture window to be deliberate. Parakeety runs Parakeet TDT v3 on the Apple Neural Engine for $30 once, and the held-key loop is the core of how it is designed.

Try it

Parakeety is a Mac menu-bar app. Hold the section key, talk, release; your words paste at the cursor in whichever app you were typing into. The microphone is open only while you hold the key, and audio never leaves the machine. There is a free 7-day trial with no card required. After that it is $30 once.

Try Parakeety free →