Why we built Wrenscribe

Most of what gets typed on our machine now goes to a coding agent. Claude Code in one terminal, Codex in another. Prompts to an agent run long, and they are the kind of thing you would rather say than type: a paragraph of context, with a correction halfway through it and a file path at the end.

Dictation should be the obvious answer. On a Mac it nearly is. On a Linux laptop running GNOME on Wayland, it was not.

What we found

The app with the best cleanup had no Linux version at all. The ones that did run on Linux sent our audio to a server, or capped free use at a couple of thousand words a month. The local, open source option came closest, but on GNOME it needed shortcuts bound by hand and a separate tool to type the text, and it switched off its overlay because the overlay stole focus.

Nothing was local, at home on GNOME and as good at cleanup as the cloud apps, all at once. That gap is the reason Wrenscribe exists.

What we wanted

Hold a key, talk, let go, and have finished text appear in whichever window had focus. Without the ums. With “Tuesday, no, Wednesday” already resolved to Wednesday. Written for where it was going, so a prompt for Claude Code does not come out sounding like a Discord message.

And all of it on the laptop. Speech is more personal than typing. You think out loud, and you say names and details you would never paste into a web form. Sending that to someone else's server to get punctuation back is a bad trade when the laptop has a capable CPU and a graphics card sitting idle most of the day.

How it came together

The first decisions were written down on October 27. Before any app code, we ran small experiments on the parts most likely to sink the project. Could GNOME's shortcut portal do hold-to-talk at all? (Yes, if you watch closely for the release.) Which speech model was accurate enough on a CPU? Which chip should run the cleanup model? And how do you paste into another app on Wayland without asking for access to every input device?

The answers became the app. Parakeet TDT 0.6B transcribes on the CPU, measured at 31 times faster than real time. Gemma 4 E2B does the cleanup on the graphics card through llama.cpp. A small GNOME Shell extension draws the pill and does the paste. The first full version was running the next day, and the current window followed the day after that.

Measured before it ships

Every dictation is logged stage by stage. When one comes out wrong, Report a problem records what should have come out, and the bad case becomes a test. A set of 34 recorded clips scores every change: on those, speech recognition sits at a 6.11% word error rate and the cleanup passes 129 of 130 checks.

Names get the same treatment. A product name only joins the built-in vocabulary after the speech model has been caught getting it wrong, which is its own story: teaching a speech model to spell Claude Code.

What comes next

Linux first, because that is where it was missing. Other Linux desktops after GNOME, then macOS and Windows. The core of the app is already separated from the Linux parts so those ports have somewhere to start.

It stays local on every one of them. If that sounds like the dictation app you have been waiting for, join the waitlist.