Fastest Mac Dictation App? WhisperBud vs Wispr Flow

We build WhisperBud, so read this with that in mind. But every number below comes from a benchmark we ran ourselves and are publishing in full, including the run where our own app lost to an older version of itself. If you only came for the numbers, the table below has them. If you want to know why an app that never touches a server keeps beating one that runs on real cloud infrastructure, keep reading, that part is the more interesting one.

WhisperBud vs Wispr Flow, benchmarked

Do not take our word for any of this. The method is written out in full below, so you can run the same test yourself, on your Mac and your voice, and check the numbers.

Both numbers are release-to-paste: the time from letting go of the hotkey to the finished text landing in the target app. Lower is better everywhere in this table.

At the median, WhisperBud is 2.8x faster (898ms ÷ 319ms). At the 95th percentile, it's 2.4x faster (1,809ms ÷ 749ms). We're calling out both numbers on purpose: the gap is smaller at p95 than at p50, and we'd rather you see the honest spread than a single flattering multiplier.

One more data point worth keeping around: WhisperBud itself used to be slower. Our previous release, v2.4.1, measured a 1,365ms median and a 2,039ms p95 on the same kind of test, slower than Wispr Flow is today. The rest of this post is mostly about how we closed that gap and then some.

How we measured it

Benchmarks are easy to rig by accident, so here's exactly what we did. If you want to poke holes in it, this section has everything you need to try.

And the honest caveats, because a benchmark without them isn't worth publishing:

Nothing leaves the Mac

The simplest reason WhisperBud is fast is the one that's easy to state and easy to underestimate: there's no network in the critical path. A cloud dictation app has to upload your audio, wait for a server to transcribe and format it, and download the result, twice per dictation, before it's even started the work a local app is already halfway through. WhisperBud's speech recognition and formatting both run on the Mac's own GPU, so the round trip simply doesn't exist. That alone doesn't explain a 2.8x gap, but it's the floor everything else is built on.

The speech engine: Parakeet on MLX

WhisperBud's speech recognition is NVIDIA's Parakeet TDT 0.6B model, running on the Mac's GPU through Apple's MLX framework. We publish our own pre-quantized 8-bit weights, 933MB instead of the original 2,472MB, so the Mac loads a model that's already the right size instead of quantizing it fresh on every launch. That one change took model load time from 1.71 seconds down to 0.05 seconds. Once loaded, it's fast at the actual job too: on real speech, it transcribes a 15-second clip in about 0.3 seconds.

The router: why most dictations skip the LLM

This is the biggest single win, and the least obvious one. Most dictations don't need a language model at all. We measured 265 real dictations from actual use and found that 78% carried no semantic cue whatsoever: no self-correction, no spoken list, no grammar error to fix. Nothing for a language model to meaningfully do.

Those dictations take what we call the fast path: a 7MB punctuation-and-capitalization model running on the CPU, in 6.6ms, plus a set of deterministic formatting rules. Only the harder 22%, things like "no wait, make it Wednesday," spoken lists, symbols, or long paragraphs, get routed to the 1.5B language model. For the typical dictation, formatting time dropped from roughly 500ms to roughly 10ms.

The part that surprised us: we went back and compared the rule-based fast path against what the language model would have produced on that same 78% of dictations. The outputs matched byte-for-byte 40% of the time. Where they differed, the language model was usually paraphrasing the user, rewording things the user never said, which its own prompt explicitly tells it not to do. The fast path wasn't just faster. On the dictations it handles, it was also more faithful to what people actually said.

Work done while you're still speaking

For the 22% of dictations that do need the language model, WhisperBud gets a head start. Screen context is captured the moment you press the hotkey, seconds before there's any transcript to work with, and it's pre-loaded into the language model's cache while you're still talking. By the time your transcript is ready, that groundwork is already done. It shaves 213 to 341ms off the critical path, only on the dictations that reach the language model, but that's exactly where every millisecond is being fought for.

Ideas we killed with data

Just as important as what shipped is what didn't. All three of these looked good on paper. None of them survived contact with a stopwatch.

We're including this section because a benchmark that only shows wins is marketing, not engineering. These three ideas were plausible enough that we built and measured them before saying no.

What this means for you

If you dictate a lot, the 2.8x number is the headline, but the router is the part worth remembering: most of your dictations were never going to need a language model in the first place, and the fastest way to handle them is to notice that and get out of the way. That's also, on our data, the more faithful way to handle them.

None of this replaces the privacy and pricing comparison. We've covered that ground separately in WhisperBud vs Wispr Flow vs Superwhisper, and if privacy specifically is what brought you here, our Wispr Flow alternative piece goes deeper on that. This post is only about speed, and on speed, on-device won.

Benchmark run by the WhisperBud team, not an independent lab: WhisperBud v2.7.0 vs Wispr Flow 1.5.1095, macOS Samantha TTS audio, one MacBook Pro (M1 Pro, 16GB), release-to-paste timing via clipboard watch, July 2026. Full methodology in the section above. Figures will differ on other machines, networks, and accents.