Marcus didn't think voice-to-text was worth his time. He typed fast. Then the work's shape changed. Three years ago, Marcus wrote specifications in Notion. Now he's dictating them to Claude, watching the model interpret intent and build.
The moment cloud tools fail
Marcus tried Wispr Flow first. It's capped the free tier at around 600 words per month. By paragraph three of a design doc, he's done. He could pay $14 per month to lift the cap, but he won't. Not because of the price. Because he's explaining code architecture, database decisions, authentication strategies, failover logic, and he's not sending that audio to a cloud service that records it and stores it on their servers.
This is where the conversation splits. There's voice-to-text for transcribing lectures, voice memos, interview recordings, places where the content is sharable by nature. Then there's voice-to-text for developers explaining intent to LLMs while keeping code IP private. They're not the same problem. They don't have the same constraints.
A developer explaining system design to Claude doesn't want that conversation recorded. A developer dictating a PR description in a public GitHub repo might be fine with cloud transcription, but the same developer dictating architectural decisions in a private design doc isn't. The tool needs to understand that distinction. Or, more simply: don't put the burden on the developer to decide. Keep it local.
Local transcription changes the economics
Recitey runs Whisper locally on your device. It's not in the cloud. It doesn't require an API call per transcription. The audio doesn't leave your machine. There's no word counter because there's no backend tracking usage. No billing event. No infrastructure cost to pass on. The free tier and the paid tier have the same dictation, the difference is the optional rewrite that polishes your rough draft into publication-ready prose.
That's structural, not just faster. Marcus can dictate a 2,000-word design doc without pause. No cap. No sync to the cloud. No moment of loss when he hits a limit and has to switch tools. Local transcription's fast, under 200ms per phrase on a decent machine. Fast enough that there's no latency frustration. When he needs prose polish (turning rough voice-draft into publication-ready copy), that's cloud-based, paid, optional. The transcription itself, the part that replaces typing, costs nothing and travels nowhere.
What you accept in the trade-off
Local Whisper's accurate: 96.3% on LibriSpeech, the open benchmark. But it's not perfect. Proper nouns slip through. Acronyms get mangled. Code terms need review. You can't mumble into the microphone and expect the system to parse it the way a human listener would. You can't dictate slurred speech or ambient noise and have Whisper handle it gracefully. The speech needs to be reasonably clear.
This is a real constraint. If you're explaining intent in quiet moments, at your desk or in a focus room, it's fine. If you're trying to dictate while driving or in a noisy office, local Whisper won't handle it as well as cloud-based transcription trained on messier audio. You trade robustness for privacy and cost.
For Marcus's workflow, design doc at 11pm, code IP non-negotiable, word limits a frustration, these trade-offs are acceptable. He's working in quiet. He's explaining to himself and to an LLM, not transcribing for publication. Cursor's tab-complete polishes the prose as he pastes voice output into code. A design doc read by a team that knows the system forgives occasional mishearing. The rough draft's fine. The clarity comes from the second pass, not the first voice recording.
The real shift
Voice-to-text didn't become faster. The work became more words. Three years ago, Marcus wrote specs in prose. Now he writes specs by explaining intent to Claude. Explaining a complex system takes more words than describing it in bullet points. The same with PR descriptions: "why did you make this change" requires more prose than a one-liner. Slack threads explaining the context of a bug investigation run longer. Incident postmortems require structured narrative.
Explaining intent to an LLM is a different task than transcribing a lecture. It's closer to thinking out loud. Voice is the faster channel for thinking out loud. Typing forces you to edit as you go. Speaking lets you think at speed, and then edit the rough draft. For intent-writing, speaking is faster than typing.
But only if the tool doesn't trap you in a word budget. And only if you don't have to send your code architecture to a cloud service to get the dictation working.
When the bottleneck's intent-writing, not transcription accuracy, local makes sense.