The Dictation App That Works When the Internet Doesn't

Some complaints only show up when things break, which is why they're easy to underweight until they happen to you: cloud dictation dies with the network. A provider outage, and your dictation key does nothing. Hotel wifi that drops every ninety seconds, and half your sentences vanish into a spinner. A plane. A train tunnel. A VPN that decided to renegotiate at exactly the wrong moment. Users of cloud-dependent dictation tools — and that's most of the category — run into some version of this, because it's not a defect of any one product. It's what depending on a round trip means.

The cruelty of it is what fails. If your note-taking app goes down, you open a text file. If your dictation goes down, you lose an input method — the thing you'd built muscle memory around, mid-sentence, usually while your hands were busy with something else. That was the whole reason you were dictating.

And underneath the loud complaint sits a quieter one that surfaces in every privacy thread about this category: your voice audio is leaving your machine at all. Every recording of you thinking out loud — client names, unreleased features, the security issue you're describing to a teammate — travels to someone else's infrastructure to become text. Even people who've made peace with that trade get worn down by its logistics: sessions that expire, accounts that need re-authentication, permissions that need re-granting after an update. Every one of those is another way a working setup stops working, and none of them are under your control.

I built Keebye's answer to this before I articulated it as a feature, because my own requirement was blunt: it had to work with the Wi-Fi off. Here's what that actually looks like, and what it costs.

Why cloud dictation fails to zero

The category-level mechanics are worth spelling out, because they explain why this complaint never fully goes away no matter how good the products get.

A cloud dictation loop has a minimum of four links: capture audio on your machine, ship it to a server, run inference there, ship text back. Every link is a dependency — your network, their network, their auth layer, their capacity, their uptime. The chain is usually fine. But when any link breaks, the whole loop breaks, and it breaks to zero. Not "slower," not "less accurate" — nothing arrives at your cursor. Degradation would be tolerable; dictation degrades to silence.

The providers know this, and the serious ones engineer hard against it. But no amount of engineering on their side fixes the links they don't own: the hotel router, the flight, your corporate VPN, the backbone incident between you and them. A tool whose availability is the product of five systems' availability will always have days when the math comes up short.

What happens when there's no cloud to fall back from?

Keebye's architecture answers the question by removing it. Speech-to-text runs fully on-device — ONNX models, local inference, on your Mac's own silicon. There are zero network calls in the dictation path. Not "we minimize them," not "we batch them" — zero. There's no telemetry either. None. When you hold the key and speak, no packet leaves the machine on your behalf.

I want to underline the architectural point, because it's the difference between this and an "offline mode." An offline mode is a fallback: the normal path goes to the cloud, and when the cloud is unreachable, a degraded local path takes over — if the app notices in time, if the local path is maintained, if the handoff works mid-sentence. Keebye has no such handoff because it has no cloud path to hand off from. Local inference isn't the backup plan; it's the only plan. An outage upstream cannot break it for the same reason a power cut in another country can't turn off your desk lamp. Immunity by construction, not by fallback.

This is also where the quieter complaint gets answered without a settings page. Your audio never leaves the machine — not encrypted-in-transit, not anonymized, just never sent, because there's nothing to send it to. If you turn on dictation history, what's stored is text only, in a local SQLite database on your own disk. (That history is its own quality-of-life story — the recurring "where did my dictation go?" complaint — which we covered in your dictation should never just vanish.) And the account-and-session fragility disappears with the accounts: there's no cloud session to expire in the dictation path, so there's no re-authentication standing between you and a working hotkey.

The one time you do need the internet

Required honesty, stated plainly: the models have to get onto your machine somehow. On first run, Keebye downloads its speech model — roughly 700 MB for the English engine, and about 1.3 GB if you enable the multilingual engine. That's a real download, once per engine, and you need internet for it.

After that, you're done. The models live on disk and everything runs against them locally, forever, network or no network. But if that first run happens on the plane, you're out of luck until you land — do the setup before you travel, not during. I'd rather you hear that from me than discover it over the Atlantic.

The accuracy question, answered honestly

The download is the small caveat. Here's the bigger one, because on-device tools love to skip it.

The largest cloud models can be more accurate than an on-device model. A model that fills a server rack has capacity a 700 MB file doesn't, and pretending otherwise would insult your intelligence. What I'll say — and what I believe from living with both — is that the gap has narrowed a great deal, and more importantly, the failure modes differ in kind. An on-device model's worst day is a mis-heard word you correct. A cloud model's worst day is zero output, because its accuracy is multiplied by its availability, and availability is the term that goes to zero on the train. Which failure mode you'd rather own depends on your day; mine has too many trains in it.

It's macOS-only today, and it's early access. No Windows build, and the rough edges early access implies. If your setup is Windows-first, the honest answer is that Keebye can't help you yet.

If you're weighing this against a tool you already use, the comparison pages are the fair-minded version of this argument — Keebye vs Superwhisper covers the local-vs-cloud question directly, since Superwhisper is itself part of the local-first camp and the differences are elsewhere.

Availability is a feature

The dictation category has spent years competing on accuracy percentages, and accuracy matters. But the complaint that actually drives people to switch tools is rarely "it misheard me once." It's "it stopped working, again, and I don't know why, and the fix involved logging in to something." Availability — boring, unglamorous availability — is the feature you only notice as its absence.

The way to make an input method as reliable as a keyboard is to give it the same dependency list as a keyboard: the machine in front of you, and nothing else. That's the whole design.

Keebye is in early access for macOS. When you get access, do the first-run download while you still have internet — you'll need it exactly once — and then try the thing no cloud tool can demo: turn the Wi-Fi off and keep talking.