Your Dictation Should Never Just Vanish

Ninety seconds of exactly-how-I-meant-it — a full PR description, a careful reply to a client — and then something small goes wrong at the moment of insertion. The target window wasn't focused. The paste didn't take. The app hiccuped. And the text is just gone. Not saved somewhere. Not sitting in a buffer. Gone. Ask around and you'll hear this story from users of every dictation tool — Wispr Flow, Superwhisper, the OS built-ins, all of them — because almost nothing in this category keeps what you said.

What follows is a specific, disproportionate kind of anger, and I think it's justified. The seconds lost aren't the point. The point is that you did the work — you composed the thought, you said it well, the machine even transcribed it correctly — and the tool destroyed the result over a delivery problem. The second take is never as good as the first. Anyone who has re-dictated a paragraph from memory knows you don't reproduce it; you produce a flatter cousin of it.

I've lost dictations this way myself, in other tools, before Keebye existed. It's one of the small emergencies the app was built around.

Why does dictated text just disappear?

This isn't one vendor's bug. It's a category-level design decision, and it's worth understanding why the category made it.

A dictation app is a pipe, not an editor. Speech goes in one end; text comes out the other, into someone else's window — a terminal, a Slack box, a Google Doc. There is no document of its own, which is exactly what makes these tools invisible and fast. But it means the transcript often exists for precisely one moment: the insert. And the insert is the single most fragile step in the whole pipeline. It depends on which window has focus at the millisecond of delivery, on the clipboard not being raced by another app, on accessibility permissions being in the mood, on the target application accepting synthetic input at all. When any of that fails, a pure pipe has nothing behind it. The water is on the floor.

There's also a principled reason tools have been shy about keeping copies: a log of everything you've dictated is sensitive. Your dictations are your messages, your prompts, your half-formed decisions. A vendor that stores them — especially anywhere near a cloud — has created a liability, and the easy way to avoid the liability is to keep nothing. Users inherit that caution as ephemerality: the safest dictation, from the vendor's perspective, is the one that never existed.

I understand the logic. I just think it optimizes for the wrong party. The failure mode of keeping local history is a file on your own disk. The failure mode of keeping nothing is your work evaporating because a window lost focus.

What Keebye keeps, and where

So Keebye keeps a history, on by default, and here is precisely what that means — no more, no less.

Every completed dictation is written to a local SQLite database on your Mac (rusqlite, WAL mode, for those who care about the plumbing). The file lives in the app-support directory — com.keebye.app/keebye.db — and it never leaves the machine. There is no sync, no upload, no account it's attached to. It's a file, on your disk, owned by you.

Recovery is designed around the two ways you actually lose text. The common case — the insert just failed, one second ago — has the fastest path: the tray menu has a Copy Last Dictation item. Click it, your most recent dictation is on the clipboard, paste it where it was supposed to go, move on. The rarer case — "I dictated something on Tuesday and I need it back" — goes through Dictation History…, a window with the full list: searchable, with per-entry delete and a clear-all for when you want the slate wiped.

Retention is 30 days, enforced automatically. The prune runs when the database opens and again after every insert, so the window is genuinely 30 days, not "30 days, approximately, whenever we get around to it." And if you want the old ephemeral behavior — some people should, and I'll get to who — history is a setting (history_enabled), and turning it off means nothing gets written at all.

Text only. Never audio.

The part I care most about is what the history isn't. It is text only. Keebye's history schema has no audio column — not an audio-retention setting defaulted to off, no column. The recordings themselves are never stored. That's structural, by design: a transcript of "reply to Andrei that the migration slips a week" is sensitive enough; the sound of your voice saying it, timestamped, is a different order of artifact, and I didn't want the app to be capable of accumulating it.

One more nuance that matters more than its word count: if you dictate into a secure field — a password-style input — history does not record it. The one place where even a text trail is wrong is the one place we don't keep one.

This is the same posture as the rest of the app — the speech-to-text runs on-device, which we've written about in the context of dictating in your own language — but history is where the posture gets tested, because history is the only place Keebye persists your words at all. Local, text-only, self-deleting felt like the shape that earns the default-on.

The honest limits

Honesty section, as always.

You can't re-listen. Text-only cuts both ways. If the transcription was wrong — the model misheard a name, mangled a number — the history faithfully preserves the wrong text, and the audio that could settle the dispute is gone by design. For most recovery cases this doesn't matter; the failure was the insert, not the transcript. But if you wanted dictation history as a voice-memo archive, this isn't that, on purpose.

Thirty days is thirty days. The history is a safety net, not an archive. If a dictation matters beyond a month, its home is the document you dictated it into, not the app's database. The prune doesn't ask.

Local-only means local-only. Your history doesn't follow you across machines. The dictation you did on the desktop isn't recoverable from the laptop. I'm presenting this as a privacy feature, and it is one — nothing syncs because nothing is transmitted — but I won't pretend it isn't also a limitation. It's both. You should know which one it is for you before you rely on it.

And the boundary case: if you're the person whose threat model says no trail at all, turn history off. It's one setting, and the app respects it completely. Default-on is the right call for most users, who'd rather have last Tuesday's paragraph back; it shouldn't be a trap for the rest.

Work shouldn't have a single point of failure

The deeper reason this feature exists: I run my day as parallel lanes — agents building in some windows, humans waiting in others — and voice is the channel that feeds all of them. That workflow is the whole premise of driving Claude Code with your voice. A channel that occasionally destroys its own payload isn't a channel you build a workday on. Every other tool in a developer's life has an undo, a log, a reflog, a trash can. Dictation somehow shipped for years without one.

If you're weighing tools in this category, our comparisons are honest about where others shine too: Keebye vs Superwhisper and Keebye vs Wispr Flow. And vanishing text has a sibling complaint — the first word of your dictation getting eaten before the mic wakes up — which we've written up in why dictation apps eat your first word.

Keebye — in early access for macOS — was built so you can dictate something long, deliberately click into the wrong window first, and watch it not matter.