Speech recognition is a solved-enough problem that you can download a model and get a good transcript. The part that generates the awkward bug reports is the last hop: putting that sentence into an application you do not control, on three operating systems, without losing anything.
Two imperfect options
There are essentially two ways to put text into someone else's window, and both have real drawbacks.
| Clipboard paste | Simulated typing | |
|---|---|---|
| Speed | Instant regardless of length | About 30 ms per character |
| Fidelity | Exact | Depends on keyboard layout handling |
| Cost | Touches the clipboard, which is shared state | Slow, and visibly types |
| Fails on | Apps that ignore paste, some remote sessions | Rarely, which is why it is the fallback |
Neither wins outright, so the default mode picks per application: simulated typing for terminals, editors and remote sessions; clipboard paste everywhere else. Terminals get typing because paste behaviour in a terminal is its own adventure, and a stray bracketed-paste sequence is worse than waiting.
The clipboard is not yours
Using the clipboard to deliver text means borrowing something the user is also using. Getting this wrong — destroying whatever someone had copied — is the kind of bug that loses trust permanently, because the thing you destroyed is invisible until they need it.
So the sequence backs up the existing contents, uses the clipboard, and restores. Two details matter more than the happy path:
- If you copied something new between the paste and the restore, the restore is skipped. Putting the old value back would be worse than leaving your newer one alone.
- Concurrent dictations are serialised, so two pastes cannot interleave and restore each other's backup.
Reading a selection is worse
Command mode needs the text you have selected, which means reading out of an application rather than writing into one. On Windows the accessibility APIs can often supply it directly, within a strict time budget. Everywhere else — and in any app that does not expose its text, which includes editors built on web technology — the fallback is to simulate a copy.
That fallback has a subtlety worth stealing. It clears the clipboard before copying. Without that step, an application that ignores the copy leaves the previous contents sitting there, and the app cannot tell the difference between "your selection" and "something you copied an hour ago" — so it silently rewrites the wrong text. Clearing first turns a silent wrong answer into an honest empty one.
The wall you cannot climb
On Windows, a normal-privilege process cannot send input to a window running as administrator. This is a deliberate OS security boundary, and it is the correct behaviour — an app that could type into elevated windows could type into anything.
What makes it nasty is that the injection call can report success while nothing arrives. The text is simply dropped. Detecting the case up front and offering to restart elevated is the only honest handling; silently doing nothing looks exactly like a broken app.
The pattern
Most of this work is not clever. It is noticing the places where a failure looks like success — a dropped keystroke that reports OK, a stale clipboard that reads like a fresh selection, a dead audio stream that reports healthy — and making them fail loudly instead. That is most of what separates a dictation tool that works on your machine from one that works on everyone's.