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. Users of every dictation tool ever shipped — Wispr Flow, Superwhisper, the OS built-ins, going back years — know this one.

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 of that politeness is your first word, every time.

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 never tears the audio input stream down. It stays open, permanently. That means the entire cold-start chain — session init, device wake-up, stream negotiation — has already happened by the time you press the hotkey for your second dictation and every one after it. There is nothing left to spin up. 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 tends to 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. The word you started a beat before pressing the key is in the transcript, because the app was capturing it before you asked.

The combined result: on repeat dictations, the first word is simply never clipped. Not "rarely." The stream was already open and the buffer reaches back before the keypress; there is no gap for the word to fall into. The ritual pause dies. You press and talk the way you always naturally wanted to — often in the wrong order, and it works anyway.

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. The indicator-friendly design — open the mic on demand — has a cost that lands on every single dictation: 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; there's no way around the first one paying the setup cost. In practice this means dictation number one after launching the app behaves like every other tool, and dictations two through two hundred don't.

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's the accumulation of small guarantees: the first word arrives, the text doesn't vanish, the insert lands. This post is about the first of those; the history post covers the second.

Keebye is in early access for macOS. Press the key and talk immediately — in that order, the other order, or both at once. That's the whole test.