I spent a week trying to replace my keyboard with my voice, went through four applications, and finished the week with none of them installed. That sounds like a failure, and for the first three days I thought it was — specifically, I thought it was the software's failure. It wasn't. Or at least, not entirely.
The reason this is worth 2,000 words rather than a shrug is what happened when I stopped switching tools and started measuring the input. The number I found explained failures I had already blamed on four different vendors, and it generalizes to every AI tool you will ever evaluate. If you take one thing from this: before you conclude a model is bad at your task, verify that the model actually received your task.
The setup: what I actually wanted
Most of building with an AI agent is writing prose. You describe a feature, you explain the constraint, you write the paragraph of context the model needs. That's talking with extra steps, and talking is roughly three times faster than typing. The prize is real.
My requirements were unglamorous: it had to work in any app (terminal, editor, the agent's chat pane), it had to handle my accent in English, and — the hard one — it had to handle Arabic, because half my work is in Arabic. That last requirement is where every tool in this story went to die, and it is the requirement most reviews never test, because most reviewers dictate in American English into a native English model.
App one: the cloud tool that stopped hearing me
Wispr Flow was the incumbent and, for English, genuinely good — the cleanup layer that strips filler words and fixes punctuation is the real product, and it earns its price when it works. Then it stopped capturing speech inside one specific Electron app I live in all day. Not an error, not a crash: the hotkey fired and nothing arrived.
I did the obvious paranoid test — a second account, fresh quota — and got the identical failure. That's a useful result, because it rules out the vendor's servers and your subscription in one move. Same machine, different account, same silence means the problem is local: a permission, an OS-level accessibility grant, an app version. Worth knowing before you write an angry support ticket.
It also killed a theory I want to state clearly because I see people spend money on it: paying for a higher dictation tier does not buy you better recognition. Those plans sell word quota, not accuracy. If the free tier mishears you, the paid tier will mishear you identically, just for longer.
App two: the one that answered in the wrong alphabet
Next I tried a well-regarded local-first alternative. Its setup wizard hung, which I pushed through, and then it did the single strangest thing of the week: fed Arabic speech, its default model returned Cyrillic characters. Not wrong Arabic — Russian letters.
That's not a bug so much as a signature. Its default engine was a speech model family optimized for a specific set of languages, and handed audio outside that set it did what a confident model does with unfamiliar input: produced fluent output in the nearest thing it knew. The lesson is that a bundled "default model" is a product decision, not a neutral choice, and if your language isn't on its list you get confident nonsense rather than an error. I looked for a Whisper-family model in its library, didn't find one, and uninstalled.
App three: the cloud one with the honest logs
Third was a newer, nicely built menu-bar app, properly signed and notarized, that I had genuinely high hopes for. It also turned out to be a cloud service wearing a local coat — and its logs told on it: repeated 15-second timeouts and plain internal_error responses.
Two things worth stealing from this one. First: read the log file before you form an opinion. Ninety seconds in a log told me more than an hour of retrying. Second: for dictation specifically, "cloud" is a functional property, not a philosophical one. Every sentence is a network round trip, so your typing speed is now bounded by your latency to someone else's data center, and their bad afternoon is your broken workflow.
App four: fully local, and the moment things got interesting
The fourth was a fully local transcriber running a Whisper-family model on-device — about 1.5 GB of weights, no network at all, one-time price rather than a subscription. Philosophically exactly what I wanted.
Its results, in Arabic, were garbage. And this is where I finally stopped installing things and started measuring.
The measurement that explained everything
I recorded a single reference sentence — an ordinary work sentence, the kind I'd actually dictate — and instead of feeding it straight to a model, I looked at the audio itself. The mean level was about −35 dB.
That is very quiet. And a Whisper-family model handed audio that quiet doesn't return an error or an empty string. It hallucinates — it produced a translator credit line, a piece of boilerplate that appears in subtitle files all over its training data and nowhere in my recording. That output is the model's tell for "I could not hear speech," and if you don't know that, it reads as the model being catastrophically stupid.
A hallucinated transcript is not always a bad model. Very often it is a bad microphone level, and the model politely inventing something rather than admitting it heard nothing.
Normalizing that same recording to around −18 dB with loudnorm immediately recovered real words. One more finding worth saving you the experiment: crude gain (volume=15dB) made things worse than doing nothing, because it clipped the peaks flat. Normalize, don't amplify.
Two corrections fell out of this that I want on the record, because they were my own errors, not any vendor's:
- My first test script started its timer before the audio device finished opening, so the first two seconds of every sentence were never recorded. Every model looked like it was failing at the start of the sentence. Nothing was failing; nothing was captured. If you script your own capture, wait for the device — mine needs roughly 2.5 seconds — before you tell yourself to speak.
- I assumed a custom vocabulary prompt (product names, jargon) might bias the model badly. I tested it. It only helped: with the prompt in place, the credit-line hallucination never appeared once.
What was left after the noise: a real model limit
So I fixed the level, kept the prompt, and re-ran the local model on clean audio. Result: the everyday, internationally common words came out perfectly, every time. The dialect-specific phrases — the way people actually speak where I live, as opposed to broadcast-standard Arabic — failed, every time, in every configuration I tried.
That consistency is the finding. Once input quality is controlled, a stable failure is a genuine model limitation, and no amount of settings-fiddling will move it. The turbo-class distilled model I was running trades accuracy for speed, and dialect is exactly the first thing that trade gives up.
For contrast I sent the identical audio file to a current general-purpose multimodal model — not a dedicated dictation product, just an API call — and it returned the sentence correctly, dialect words included, in a few seconds. Same audio, same conditions, different result. The bottleneck was never the app. It was which model the app would let me point at.
So what am I using now? Nothing.
Honest ending: I removed all four. I built a small script that recorded, normalized, and sent audio to the model that actually worked — and I removed that too, because a workflow that requires me to run a terminal command, wait, speak, and paste is not dictation. It's a chore with extra steps.
One design lesson stuck harder than any of the technical ones. A version of my script that ran from a clickable icon worked perfectly and I still couldn't use it, because it gave no visible signal for when to start talking — so I spoke early, every time, and lost the first words. Any voice tool without an unmistakable "go now" cue fails in practice regardless of how correct its internals are. The apps that got this right beat the ones that were technically better and silent about it.
The transferable checklist
None of this is really about dictation. It's about how to evaluate an AI tool honestly on your own input:
- Measure the input before judging the output. One level check would have saved me most of a week.
- Learn each model family's failure signature. Whisper hallucinates boilerplate on silence; other families answer in the wrong language. Recognizing the tell tells you the cause.
- Use one fixed reference sample across every tool. Comparing different recordings compares your recordings, not the tools.
- Separate the app from the model. "This app is bad at my language" often means "this app ships one model and won't let me change it."
- Test your own language and accent before paying. "Supports 100+ languages" is a compatibility claim, not a quality claim. The free tier exists precisely so you can check.
- Read the logs. They're faster than your intuition and they don't have feelings about the tool you just chose.
If you dictate in clean English, most of this doesn't apply to you and the category is genuinely excellent — Wispr Flow's cleanup layer in particular is the thing to try first, and its free tier will tell you within ten minutes whether talking-instead-of-typing suits your brain. If you work in a language or dialect off the main highway, budget a real afternoon for testing, measure your levels first, and don't buy a subscription hoping accuracy is what's behind the paywall. It isn't.
Sources
All levels, timings, and failure messages in this post are from my own testing on my own machine, in August 2026 — measured, not estimated. Tool pricing and plan details referenced:
- Wispr Flow — product and pricing (affiliate link; plans meter words per week, not accuracy)
- wisprflow.ai — platform and language support claims
- Previous review on this site: Wispr Flow, Honestly — still accurate on English; this post is the update