Why Dictation Apps Eat Your First Word

Press the hotkey. Start talking. Watch the transcript begin at your second word — sometimes your third. "Refactor the retry logic" comes out as "the retry logic." "Don't merge that yet" comes out as "merge that yet," which is a genuinely dangerous sentence to have typed on your behalf. This failure is easy to reproduce across cold-start microphone pipelines, from OS built-ins to dedicated dictation tools.

People describe it different ways — "it clips the start," "I have to pause before speaking," "the first word is always missing" — but it's one phenomenon, and once you've been bitten you develop the workaround everybody develops: press the key, wait a beat, then talk. Which means you're now performing a small superstitious ritual dozens of times a day to compensate for your tool, and the tool has trained you instead of the other way around.

I did that ritual for months in other tools. Building Keebye, killing it was one of the first things on the list, because the fix turned out to require an uncomfortable tradeoff most apps won't make — and I want to talk about the tradeoff as plainly as the fix.

Why does the first word get cut off?

This is a category-level problem, not one vendor's sloppiness, and the physics of it are simple: microphones are not instant.

When a dictation app starts a recording the naive way — press hotkey, then open the microphone — a whole chain has to run before the first sample of your speech is captured. The OS audio session has to initialize. The input device has to wake up, which for some hardware means literal warm-up time. The stream format gets negotiated, buffers get allocated, and the first buffers that arrive are often garbage that gets discarded. Depending on the machine and the device, that chain takes somewhere between "a beat" and a couple of seconds.

Meanwhile, you — a human being with an already-formed thought — start speaking at the instant your finger hits the key. Usually a hair before the instant, actually: the intention to press and the intention to speak leave your brain together, and speech onset routinely beats the app's readiness. Everything you said before the stream went live never existed as far as the app is concerned. The model can't transcribe audio that was never captured. Hence: "the retry logic."

Why do apps start the mic on demand instead of keeping it ready? Mostly good citizenship. Holding a microphone open costs a little power, and — much more importantly — it lights up the OS microphone indicator, which users understandably read as "this app is listening to me." Opening the mic only on demand keeps the indicator honest and the app looking polite. The cost is cold-start risk at the beginning of a recording.

The fix: a mic that's already listening when you press the key

Keebye attacks this from both ends, and the two mechanisms are worth separating because they solve two different halves of the problem.

The warm mic. After your first recording of a session, Keebye keeps the audio input stream open. That means the cold-start chain — session init, device wake-up, stream negotiation — has already happened before a later dictation while that stream remains healthy. The stream is live before your finger moves.

The pre-roll. A warm stream fixes the app's lateness, but not yours — remember, your speech onset can beat your keypress. So Keebye keeps a rolling 500-millisecond buffer of the most recent audio (8,000 samples at 16 kHz, in a ring). When you press the hotkey, that half-second of just-before audio is flushed into the front of the utterance. Audio that began inside that buffer is available to the transcriber instead of being discarded before the keypress.

The combined result: on repeat dictations, the warm stream and 500 ms pre-roll cover the common case where speech begins just before or with the keypress. The ritual pause becomes unnecessary inside that boundary. It cannot recover a word spoken more than half a second before recording starts, and the first dictation of a session still pays normal stream-start latency.

The tradeoff, stated plainly

Here's the part I refuse to bury, because it's the honest price of the design: since the audio stream stays open between dictations, macOS shows the microphone as active even when you're not dictating. The orange dot is on. If you look at Control Center, Keebye is listed as using the mic, right then, while you're doing nothing.

What's actually happening during that time: the audio flows into the 500 ms ring buffer and is continuously discarded. Nothing is transcribed. Nothing is stored. Nothing leaves the buffer until you press the key — and everything older than half a second is gone forever, overwritten by the ring. But I'm not going to pretend the indicator is lying, because it isn't: the stream is open, and "always-listening-capable" is a fair description of the architecture, even though nothing listens in any meaningful sense until you ask.

I made this tradeoff deliberately, with eyes open, and here's the reasoning. Opening the mic on demand introduces cold-start risk each time: clipped words, wrong sentences, the trained pause. The warm-stream design has a cost that lands on your comfort with an orange dot, backed by an architecture you can reason about: text-only local history (which we've written up in your dictation should never just vanish), on-device transcription, no audio ever stored, half a second of ring memory. I'll take the dot. If you won't — that's a legitimate position, and it might genuinely make a different tool the right choice for you; our Keebye vs Superwhisper and Keebye vs Wispr Flow pages are written to help with exactly that call.

Two boundaries, so nobody's surprised

The very first dictation of a session still has normal stream-start latency. The warm mic is warm because a recording already happened; the first one still pays the setup cost. Later dictations benefit while the stream remains open.

Pre-roll is 500 milliseconds, and 500 milliseconds is a beat, not a sentence. The buffer covers the natural case — a word begun slightly before the keypress. If you deliver a full sentence and then remember to press the key, the earlier words are gone, by design: the ring only ever holds half a second, precisely so that the app isn't retaining meaningful audio while idle. A longer pre-roll would catch more of your absent-minded starts and keep more of your ambient audio in memory. Half a second is where I drew that line.

Why half a second matters more than it sounds

A clipped first word looks like a small bug. In the parallel-lane workflow Keebye was built for — voice as the control channel for several AI agents and several human conversations at once, the workday described in two kids, three startups, one voice — dictation happens dozens of times a day, in bursts, mid-context-switch. A tool that demands a ritual pause taxes every burst and, worse, occasionally inverts your meaning and submits it. "Merge that yet" was funny exactly once.

Reliability in this category isn't one big feature. It is the accumulation of smaller safeguards: pre-roll for the opening audio, history behind the transcript, and a recoverable insertion path. This post is about the first of those; the history post covers the second.

Keebye is in early access for macOS. Start your free trial below, say “Don't merge that yet” on a repeat dictation, and check whether the first word survives. That's the whole test.