If you want the shortest answer, it is this: offline dictation usually feels faster because there are fewer steps between “I stopped speaking” and “the text appeared.” Cloud dictation can still be the right choice, but it pays a network and upload cost that local workflows do not.
TL;DR
- On-device dictation removes the upload and remote-processing path from the loop.
- Cloud tools can still be excellent when you want shared history, server-side automation, or aggressive rewrite workflows.
- Apple’s current Mac guidance makes it clear that Dictation behavior varies by setup; Keyboard settings tell you whether general text Dictation is processed on-device or sent to Siri servers.
- Voice Control also supports offline use after its one-time download.
- For daily Mac dictation, the real question is not only accuracy. It is workflow latency: how long you wait after each utterance, all day.
- Accuracy is shaped as much by input conditioning and speaking habits as by model size.
The latency question that actually matters
Model quality and feature lists are the wrong axis for a tool you trigger two hundred times a day. The question that predicts how the tool feels is narrower:
How many steps happen after I stop talking?
Where the delay comes from
This section describes mechanism, not measurement. The point is to name the steps, so you know what to time on your own machine rather than which number to trust from a marketing page.
In an on-device workflow, the path is usually:
- capture audio locally,
- process or stream chunks locally,
- finalize the unfinished tail,
- insert text.
Cloud dictation adds a network path on top of that:
- capture audio locally,
- open a connection (DNS resolution, TLS handshake, sometimes authentication),
- upload the audio,
- wait for remote inference,
- download the result,
- sometimes pass the text through another rewrite or formatting layer.
Two properties of that second list are worth understanding, because they behave differently.
Connection setup is roughly fixed per request. DNS, TLS, and authentication cost about the same whether you dictated two words or two minutes. That cost is amortized over a long recording and is not amortized at all over a five-second note. So the shorter your typical utterance, the larger the share of the wait that has nothing to do with recognizing speech. Persistent connections and streaming protocols reduce this, which is exactly why implementation details matter more than the “cloud versus local” label.
Transfer time scales with audio length. Recognition quality generally favors lightly compressed or uncompressed audio, so the payload for a long session is not small. On a stable connection this is invisible. On hotel or café Wi-Fi it is the variable that moves.
Local does not mean instant magic. There is still work happening after you stop speaking. But it does mean you remove the entire upload-and-return loop, and with it the part of the delay that depends on a network you do not control.
You can see the shape of this yourself in the interactive demo, which lets you vary utterance length and network conditions: /blog/latency-demo.
Windowing: why long sessions do not have to get slower
A naive local implementation waits for you to stop, then transcribes the whole recording. That has the same scaling problem as an upload: half an hour of audio is half an hour of audio.
Streaming implementations avoid it by decoding as you speak, in bounded batches. When you stop, only the last incomplete batch still needs finishing.
Voice Type works this way, with a batch target of 29 seconds, clamped to a range of 15 to 29. The batches are not fixed-length windows: the batcher accumulates whole speech regions and will not cut one in half at a boundary, so an incoming phrase that would cross the target starts the next batch instead. The practical consequence is that the wait after you stop is bounded by the batch target rather than by the session length. A two-minute dictation and a thirty-minute dictation end with the same amount of work left to do.
That is an architectural property, not a benchmark. How long that final pass actually takes depends on your Mac, and it is worth timing on yours.
Cloud dictation: more moving parts, but sometimes the right trade
Each extra step in the cloud path can be worth it if the product is doing something valuable:
- team history,
- account-level sync,
- server-side prompt or template pipelines,
- meeting or file processing at larger scale,
- post-processing that improves rough spoken input.
The point is not “cloud bad.” The point is that cloud has more things that can become the bottleneck.
Where Apple fits in
Apple’s own stack now sits in the middle of this conversation.
The current support pages make two things clear:
- general text Dictation may be processed on-device or sent to Siri servers depending on your setup,
- Voice Control requires a one-time download, then can be used without internet.
So “Mac dictation” is not one fixed architecture. It depends on:
- your hardware,
- your language and region,
- the feature you are using,
- whether you are using Dictation or Voice Control.
That is one reason generic comparison posts age badly: they talk about “Mac dictation” as if it were a single, static product.
Why daily users notice the difference more than casual users
If you dictate one paragraph a week, the difference between local and cloud might not matter much.
If you dictate dozens or hundreds of times a day, small delays compound:
- waiting for the connection,
- waiting for upload completion,
- waiting for a response,
- waiting for a second pass that “polishes” the text.
That is where on-device workflows gain ground. The absolute delay is not always dramatic. The repetition is what makes it expensive. Consistency matters more than a best case: a workflow that is predictable on bad Wi-Fi beats one that is faster on good Wi-Fi and unusable on bad.
Accuracy is not only a model problem
Model size is the number every product page leads with, and it is one input among several. In real use, accuracy is shaped by:
- microphone quality,
- room noise,
- echo,
- input gain,
- speech segmentation,
- vocabulary mismatch,
- and whether the workflow lets you keep going without breaking concentration.
That is why a “we use the largest model” claim does not tell you how the app will actually feel in Slack, Gmail, or Linear.
Conditioning the input before recognition
Speech models are trained on audio with particular characteristics. The closer your input sits to that distribution, the less the model has to guess. Three adjustments do most of the work:
- Normalize loudness to a consistent target, so words land at similar levels whether you leaned in or sat back.
- Filter low-frequency rumble with a light high-pass. Desk thumps, HVAC, and building noise carry energy that is not speech.
- Use noise-aware voice activity detection, so silence and background are not handed to the recognizer as if they were words.
Voice Type applies all three before recognition. The shipping defaults for live dictation are a loudness target of minus 16 LUFS and a 50 Hz high-pass, both visible and adjustable in the app's audio settings. The reasoning is that improving the signal is more honest than patching the output: heavy prompt-based “fixes” can make a transcript look confident while drifting away from what was said.
Related reading on the specific components: voice activity detection and resampling to 16 kHz.
Two stages, in this order. The loudness target is not one number, it depends on which path the audio took. Sources: WhisperState+FileTranscription.swift, WhisperState.swift.
Punctuation and sentence breaks
Punctuation is the thing you notice only when it goes wrong. A missing period. A doubled space. A proper noun that splits a sentence.
Most of it comes down to segmentation, which is why input conditioning and speaking habits affect it directly. Loudness swings can read as sentence boundaries. Room noise blurs the pauses the model uses to commit a sentence.
Habits that help on any microphone:
- Pause a fraction longer at full stops. Half a beat is enough to give a clean boundary signal.
- Say list punctuation when precision matters. For tight lists or code, saying “comma” out loud removes the guesswork.
- Keep your level steady. Speak closer to the microphone rather than louder; a cleaner signal beats a hotter one.
- Add custom words. Product names and jargon that are not in a general dictionary become anchors once you register them, which cuts edits in long notes.
- Keep noise suppression gentle if your tool exposes it. Aggressive gating clips consonants, and clipped consonants cost you more than the noise did.
A quick way to test any dictation setup on your own machine: read this line into a blank document without saying the word “period.”
Aeloria and Kyran left Eldmere at dawn. They crossed the Kintara ridge before the fog rolled in. Skystack Nova ships next week.
It mixes invented proper nouns with ordinary sentence structure, so you can see how a tool handles both unknown vocabulary and sentence breaks in one pass. Run it once at a normal distance and once with the microphone closer, and compare.
Privacy is a structural difference, not a feature
With on-device dictation, audio does not leave the machine, so there is no retention policy to read and no vendor to trust with the recording. With cloud dictation, audio leaves the machine by design, and the privacy question becomes a question about a specific vendor’s handling.
Voice Type keeps dictation local. The optional LLM rewrite is the exception, and it is opt-in: text goes directly from your Mac to the provider whose key you supplied, not through our servers. Details are on the trust center and the privacy policy.
Where Voice Type fits
Voice Type is built around the repeated-use case: hold the hotkey, speak, release, get text back locally, with the rolling-window behaviour described above.
That is a different job than tools that focus on:
- file transcription,
- meeting recording,
- cloud rewriting,
- or shared server-side history.
If you want to compare categories rather than slogans, these pages are more useful:
When cloud still wins
Cloud is still the better fit when you need:
- shared transcripts across a team,
- server-side storage and search,
- automatic post-processing for long-form dictated drafts,
- workflows that depend on centralization rather than privacy,
- managed infrastructure instead of local compute.
The honest conclusion is not “local beats cloud.” It is:
Local wins when your bottleneck is interaction speed. Cloud wins when your bottleneck is collaboration, server-side processing, or centralized workflow.
Which should you choose?
Use this rule:
| If you care most about... | Better fit | | --- | --- | | Fast repeated dictation into Mac apps | On-device | | Local privacy model | On-device | | Shared history and server-side automation | Cloud | | File uploads and transcript management | Cloud or file-transcription tools | | Accessibility-style voice control | Apple Voice Control |
Practical next steps
If you are still deciding, do this:
- Use Apple Dictation for a few days with your real microphone and real apps.
- Notice the delay after short utterances, not just long recordings.
- Repeat the same test on an unreliable network, because that is where the two architectures separate.
- If the built-in tool is enough, keep it.
- If you keep thinking about the workflow instead of the writing, try a dedicated local app.
Start here if you want the local Mac path:
Sources
- Apple Support: Dictate messages and documents on Mac
- Apple Support: If Dictation on Mac doesn’t work as expected
- Apple Support: Get started with Voice Control on Mac
- OpenAI research: Whisper overview
- Paper: Robust Speech Recognition via Large-Scale Weak Supervision