DEV Community: Al Amin

Local Whisper vs. Cloud Dictation: Privacy, Latency and Accuracy Tradeoffs (Plus a Private Setup)

Al Amin — Sun, 18 Oct 2026 05:01:35 +0000

"Just run Whisper locally" is good advice that skips a lot of detail. Local speech-to-text is genuinely useful, but it is not automatically faster, more accurate, or even fully private, depending on what else sits in your pipeline.

This post breaks the decision into three questions (what leaves the machine, where latency comes from, and how accurate it is for your voice) and ends with a setup where nothing leaves your computer. I use InsertKit as the dictation front end because it supports local Whisper, bring-your-own-key cloud providers, and custom OpenAI-compatible endpoints in one place. The tradeoffs apply to any stack.

1. Privacy: map the data flow first

A modern dictation pipeline usually has two stages:

mic audio -> [speech-to-text] -> raw transcript -> [LLM formatting] -> text at cursor

Each stage can be local or remote, and people often secure one and forget the other.

Speech-to-text. With a cloud engine, your audio is uploaded and processed by that provider. With a local Whisper model, audio stays on your machine.
Formatting. Clean-up (removing filler words, fixing punctuation, adapting tone) is usually done by a chat model. If that model is in the cloud, your transcript leaves the machine even when the audio did not.
Side channels. Sync features count too. In InsertKit, snippets, clipboard history, custom vocabulary, and API keys sync to your account. If your vocabulary list contains an unreleased product codename, that word list is synced, even if every audio clip stays local.

What InsertKit stores is worth knowing precisely: cloud voice history in Settings → Usage covers the last 30 days and is text only, no audio, with a Clear button. Local voice history stays on the device, and setting its maximum to 0 disables it.

So "private" is not a property of a model. It is a property of the whole path.

2. Latency: where the milliseconds actually go

Local is not always faster. Rough breakdown:

Cloud: upload time + queueing + inference on fast hardware + download. On a good connection, short utterances can come back very quickly, because providers run large models on serious GPUs.

Local: zero network, but inference runs on your CPU or GPU. A small model on a modern laptop is responsive. A large model on an older CPU can take noticeably longer than the time you spent talking.

Two details that matter in practice:

Model loading. Expect the first transcription after loading a large model to be slower than the ones that follow.
Long dictation. If the tool waits until you finish a three-minute ramble before transcribing, you wait for all of it at the end. InsertKit splits long speech into chunks at natural pauses and transcribes them while you keep talking, which hides much of that delay locally and in the cloud.

3. Accuracy: benchmark your own voice

Published word error rates come from benchmark datasets, not from your accent, your mic, or your jargon. Ten minutes of testing beats any leaderboard.

Here is a quick, tool-agnostic way to compare Whisper model sizes with whisper.cpp:

git clone https://github.com/ggml-org/whisper.cpp
cd whisper.cpp
cmake -B build
cmake --build build -j --config Release

for m in base small medium; do
  sh ./models/download-ggml-model.sh $m
done

# Convert a 60-second recording of you reading real work text to 16 kHz mono WAV
ffmpeg -i sample.m4a -ar 16000 -ac 1 -c:a pcm_s16le sample.wav

for m in base small medium; do
  /usr/bin/time -p ./build/bin/whisper-cli -m models/ggml-$m.bin -f sample.wav -otxt -of out-$m
done

Then score each output against what you actually said:

# pip install jiwer
from jiwer import wer

ref = open("reference.txt").read()
for m in ["base", "small", "medium"]:
    hyp = open(f"out-{m}.txt").read()
    print(m, "WER:", round(wer(ref, hyp), 3))

Use real material: a commit message, a ticket description, a paragraph full of service names. Generic sentences flatter every model.

A few patterns you will likely see:

Bigger models handle accents and noise better, at the cost of speed and memory.
Jargon fails across all sizes. That is a vocabulary problem, not a model-size problem.
Whisper can hallucinate on silence or noise, producing text nobody said. Trimming silence and using a decent mic reduce it.

For jargon, a correction layer helps more than a bigger model. InsertKit's Custom Vocabulary has word hints plus "heard as → write as" corrections, like post gres → Postgres, and corrections run before and after formatting so the LLM cannot undo them.

The decision, simplified

Audio must never leave the machine: local Whisper.
Speed on modest hardware: cloud, or a small local model.
Accuracy on difficult audio: a large local model with a GPU, or a strong cloud engine.
Zero setup: a hosted engine that needs no key.
Air-gapped or offline work: local Whisper plus a local LLM, or formatting turned off.

Many developers end up hybrid: local for anything touching client code or internal docs, cloud for low-stakes chat.

A fully private dictation setup

Here is the setup where audio and text both stay on your machine. Local Whisper is a desktop feature in InsertKit (Windows, macOS, Linux).

Step 1: Local speech-to-text

In the Speech Engine panel, choose Local Offline (Whisper) and download a model inside the app. Sizes go from Tiny (~75 MB) and Base (~140 MB) through Small (~460 MB) and Medium (~1.5 GB) to Large v3 (~3 GB). Use your benchmark results to pick. Small is a sensible starting point on most laptops.

Step 2: A local LLM for formatting

Run a local OpenAI-compatible server. With Ollama:

ollama pull llama3.2
curl http://localhost:11434/v1/models

LM Studio exposes a similar server, by default at http://localhost:1234/v1.

In InsertKit, open Settings → API Keys and add a Custom OpenAI-compatible provider: a name, the base URL (for example http://localhost:11434/v1), a key if your server needs one, and the models (auto-fetched or entered by hand). Then choose that model for Smart Formatting.

Smaller local models format well enough for clean-up. If output gets too creative, add a short custom instruction under Use my own instructions, such as "Fix punctuation and remove filler words. Do not add or change content."

Step 3: Decide what happens when formatting is unavailable

Enable Keep working offline so the raw transcript is pasted if the formatter cannot be reached. Or skip formatting for sensitive sessions and rely on vocabulary corrections.

Step 4: Verify, do not assume

Turn off Wi-Fi (or run nmcli networking off on Linux) and dictate a paragraph into your editor. If text still appears and is formatted, both stages are local. Turn the network back on afterwards, because account sync needs it.

Linux note

Check Settings → General → Linux Dependencies. Typing and pasting rely on tools such as xdotool and wtype, and on Wayland the tips point to wtype or ydotool.

Where cloud still wins

To be fair to cloud dictation:

No local resources. Large models do not eat your RAM or battery during a long build.
Consistent quality on weak hardware.
Language coverage. InsertKit's voice typing covers 100+ languages with auto-detect. If you dictate in more than one, benchmark each on your local model before committing to it.
Mobile. InsertKit's Android app uses hosted or BYOK engines; there is no on-device Whisper there.

If you use the cloud, at least choose deliberately. InsertKit Free needs no key and has a daily limit, Premium uses credits, and BYOK covers providers such as OpenAI, Groq, Deepgram, AssemblyAI, and ElevenLabs.

Wrapping up

Local Whisper is a strong default for private work, but privacy depends on the full path, latency depends on your hardware, and accuracy depends on your own voice. Benchmark with real text, add vocabulary corrections for your stack, and verify your setup with the network off.

If you want to try this exact setup, the desktop builds are at insertkit.com/download.

Dictating Code Comments and Commit Messages: A Practical Hands-Free Setup

Al Amin — Sat, 17 Oct 2026 05:18:32 +0000

I do not want to dictate code. Brackets, indentation, and symbol-heavy syntax are a bad fit for speech, and autocomplete already does a lot of that work.

The prose around code is a different story. Comments that explain why, commit messages that someone will read during a painful git bisect, PR descriptions, review replies. That text is often the part we rush, because typing a careful paragraph after an hour of debugging feels like a chore. Saying it out loud is easier, and it usually comes out clearer.

Here is how I set that up with InsertKit, a desktop app (Windows, macOS, Linux) that combines voice typing, text snippets, and clipboard history.

The basic loop

Put your cursor where the text should go: a comment line, the commit message buffer, a PR description box.
Press the voice shortcut (Right Alt by default) and talk.
Stop talking. After a short silence (5 seconds by default, configurable), recording stops and the text is inserted at the cursor.

It works system-wide, so the same shortcut works in your editor, a terminal, the browser, or a chat app. Long explanations are fine too: speech is split into chunks at natural pauses and processed while you keep talking.

Let the Code profile handle formatting

Raw transcripts are messy. With Smart Formatting turned on, InsertKit cleans filler words and punctuation and adapts the style to the app in focus. When the active window is VS Code, Cursor, IntelliJ, Sublime, vim, or a terminal, it uses the Code profile.

Two things happen in that profile:

Output reads like a comment or docstring, not a chatty paragraph.
Spoken identifiers become camelCase or snake_case. Say "this wraps fetch user profile and retries on a timeout" and you get a comment that refers to fetchUserProfile instead of four loose words.

It will not always guess the convention you want, so glance at identifiers before you move on. If you want a specific house style, there is a Use my own instructions option for a custom formatting prompt. Keep in mind it changes formatting generally, not only in your editor.

If the formatter is unreachable, the raw transcript is pasted anyway, so nothing you said gets lost.

Snippets for the boilerplate around the prose

Voice handles the thinking. Snippets handle the structure that should look the same every time. A few I use:

/todo for a TODO tag with my name and today's date, using built-in variables:

TODO({{myName}}, {{date}}):

Type /todo, then press the voice shortcut and say what needs doing.

/pr for a PR description skeleton:

## What changed

## Why

## How to test

## Notes for reviewers

Drop it in, then dictate each section. "Why" is where speaking pays off most.

/commit as a dynamic snippet. On desktop, a snippet can have form fields. I use a Dropdown called type (feat, fix, refactor, docs, chore, test) and a Text field called scope:

{{type}}({{scope}}):

Type /commit in the commit buffer, pick the type, enter the scope, press Enter, then dictate the subject and body.

If you forget a trigger, typing / opens a small autocomplete popup at the cursor with matching snippets.

Press F4 before snippets bite you

Here is the gotcha nobody mentions. Snippets fire the moment the end of what you typed matches a trigger, without waiting for Space. That is great in a chat box and dangerous in code. If you have a /pr snippet and you type a path like /proc/... or a URL segment starting with /pr, it will expand.

Two fixes:

Pick triggers that rarely appear in code or paths. /prdesc is safer than /pr.
Press F4 (Fn + F4 on Mac) to turn the whole snippet system off while you are writing code, and press it again when you switch to prose. A small toast confirms "Snippets disabled" or "Snippets enabled". You can change the key in Settings.

Some apps also use / for their own commands. Under Settings → Snippets → Trigger Prefixes, you can enable a different prefix character for those cases.

Teach it your jargon

Speech engines are trained on everyday speech, not on your stack. Custom Vocabulary fixes that in two ways:

Add word: hint terms like Kubernetes, PostgreSQL, gRPC, or your internal service names.
Add correction: "When heard as" → "Write as". For example "post gres" → "Postgres", "next js" → "Next.js", or "k eights" → "k8s".

Corrections run before and after AI formatting, so the formatter cannot "fix" your spelling back. Vocabulary syncs to your account, so it follows you to another machine.

Picking an engine: hosted, BYOK, or fully local

You can start with InsertKit Free, which needs no API key and has a daily limit. For more control there are a few options worth knowing.

Bring your own key. Settings → API Keys accepts keys for providers such as OpenAI, Groq, OpenRouter, Deepgram, AssemblyAI, and ElevenLabs for transcription, plus chat providers for formatting. Adding a key assigns sensible defaults. A Groq key, for example, sets whisper-large-v3 for speech.

Local Offline (Whisper). On desktop you can download a Whisper model inside the app, from Tiny (~75 MB) up to Large v3 (~3 GB). With this engine selected, audio is transcribed on your machine and does not leave it. Start with Small or Base on a laptop and move up if accuracy is not good enough for your accent and vocabulary.

Custom OpenAI-compatible endpoint. Formatting uses a chat model, and by default that may be a cloud model. If you want the text to stay local too, add a custom provider pointing at a local server such as Ollama or LM Studio: set a name, the base URL, a key if needed, and fetch or enter the model list. Pair that with Local Offline Whisper and the whole pipeline runs on your machine.

If your team has rules about what can leave your machine, that is the setup to look at. Or turn Smart Formatting off and rely on vocabulary corrections alone.

Linux notes

On Linux, check Settings → General → Linux Dependencies. InsertKit relies on tools such as xdotool, wtype, and maim to type and paste. On Wayland, the tips point to wtype or ydotool.

A couple of extras

Voice Assistant: say "hey ik draft a short changelog entry for a fix to session expiry handling" and a draft is typed at the cursor. Treat it like a junior's first draft.
Clipboard history: Ctrl + Shift + Z opens a small popup with recent copies, snippets, and favorites. Handy for juggling an error message, a ticket ID, and a stack trace line while writing a commit.

What does not work well

Open-plan offices. Dictation is awkward with people around.
Dictating code itself. Stick to prose.
Skipping review. Read every comment before you commit it.

If you want to try this workflow, the desktop builds are at insertkit.com/download. My suggestion: set up /todo, /commit, and a few vocabulary corrections, then dictate every commit body for a week and see if your history reads better.