The case for push-to-talk.

The ambiguity problem

Tap-to-toggle has a fatal flaw the first time you forget you turned it on. You walk away from your laptop. You return to find three pages of your kid asking what's for dinner pasted into a Slack thread. The app did exactly what you told it to. You just told it the wrong thing.

Hold-to-talk closes that loophole the way a walkie-talkie does. The microphone is on for as long as your finger says it is, and not one second longer. There's no internal state to misremember.

Latency is honest

When you hold a key, you can feel the start. There's no “is it listening?” moment, no listening indicator to glance at. You press, you speak, you release, the words appear. Three actions, no inference.

Tap-to-toggle, by contrast, asks you to trust an invisible mode. The good apps cover this with audio cues and lock-screen badges. The great ones make those cues so loud that they cost more attention than the press itself.

But what about accessibility?

This is the strongest argument against hold-to-talk, and we take it seriously. Some users can't comfortably hold a modifier for the length of a dictated paragraph. So we ship a toggle mode too. The default is hold; the option is one settings page away.

What we won't do is make tap-to-toggle the default. Defaults shape behaviour, and the default behaviour we want is: you are always in control of when the mic is on.

The deeper bet

Voice input wants to be ambient. It wants to be ready, listening, waiting for a wake word. That's a great pattern for a kitchen speaker. It's a terrible pattern for the device you're actively typing on.

Hold-to-talk says: voice is a tool you pick up when you need it, then put down. Like a pencil. We think that's the right relationship between you and your keyboard.

“I tried four dictation apps before settling on Speechcap. The thing I didn't expect to care about was the hotkey model. Now it's the thing I miss the most when I'm using anything else.”