The recogniser is the free part

Every developer who has looked at a paid dictation app has had the same thought, and it is a correct thought: the hard bit is already open source and costs nothing. openai/whisper is MIT licensed. So is ggml-org/whisper.cpp, which its README calls a "plain C/C++ implementation without dependencies" and an "Apple Silicon first-class citizen — optimized via ARM NEON, Accelerate framework, Metal and Core ML". Both were checked on 4 September 2026. You can transcribe a file on your Mac tonight for nothing.

So this page does not argue that you cannot build it. You can. It argues about what is left over once the recogniser works, because that leftover is the entire product, and the honest version of this comparison is an estimate of a weekend against $19.

What you get for free, stated properly

The command line is genuinely simple. The whisper README's own example is whisper audio.flac audio.mp3 audio.wav --model turbo, and adding --language Japanese --task translate gets you an English translation of Japanese audio. That is a lot of capability for one line.

You choose the trade-off. The README publishes a table of model sizes against approximate memory and relative speed, so you can pick the point on that curve that suits your machine rather than accepting somebody else's default. This app makes that choice for you and does not expose it.

It is not restricted to dictation. A CLI transcribes the two-hour interview recording, the podcast, the voice memo from last March. It emits timestamps and subtitle formats. This app does none of that: it dictates live and has no way to open an audio file you already have. If transcribing existing recordings is on your list at all, look at MacWhisper, which is built for it.

It runs everywhere. whisper.cpp's README lists macOS on Intel and Arm, Linux, Windows, iOS, Android, WebAssembly, Raspberry Pi and Docker. We ship macOS 13 or later and nothing else.

Nothing renews and nobody can change the terms. MIT is MIT. That is a real argument and it is the strongest one on this page for the DIY side.

Both projects are being worked on. whisper.cpp's most recent tagged release is v1.9.3, dated 20 August 2026; openai/whisper's most recent tag is v20250625, dated 26 June 2025, and its repository received commits as recently as 31 August 2026. Check both yourself — they move.

Now build the other 90%

Here is what stands between "transcription works" and "I dictate sixty times a day without thinking about it". None of these are hypothetical; they are the list any working dictation tool has had to solve.

Bind a key and record while it is held. Not press-to-start and press-to-stop, which loses you the ergonomic advantage entirely — held. Something has to own that binding globally, which on a Mac means an event tap and the accessibility permission that goes with it. Hammerspoon is the usual answer, MIT licensed with a 1.1.1 release dated 26 February 2026, and it is a good one.

Capture audio at the right rate and stop cleanly. Start the recorder on key-down, stop it on key-up, and handle the case where the key came up before the recorder was actually running, which is most dictations under a second.

Do not pay the startup cost per press. Loading a model on every keypress is the difference between a tool you use and a tool you abandon. Something has to stay resident, which means you are now writing a daemon rather than a script, with everything that implies about restarting it, logging it and noticing when it has quietly died.

Get the text into the application you were in. This is the part everybody underestimates. There are two mechanisms on macOS, neither works everywhere, and the fallback involves the clipboard — which means you are now responsible for putting back what was in the clipboard afterwards, and for the race between your paste and the application reading it.

Know which application you were in. By the time the transcript exists, two or three seconds have passed and the front window may not be the one you were talking into. A notification, a build finishing, a chat message stealing focus. If the destination is decided at the end, you will eventually paste a private sentence into the wrong window, and you will only need that to happen once.

Show something while you talk. Without feedback you cannot tell a muted microphone from a silent one, and you will discover the difference after a forty-second dictation.

Keep the transcripts. Somewhere searchable, so that a paste that went astray is a recoverable annoyance instead of a lost paragraph.

Keep it working. This is the invisible line item. A macOS update changes a permission prompt; a Python version moves and the environment breaks; a dependency stops publishing wheels for your platform. The whisper README already mentions needing Rust "if tiktoken does not provide a pre-built wheel for your platform", which is exactly the kind of Tuesday morning this route hands you.

The table

Six clear rows to the script, and the first one is free. Everything on our side is plumbing — and plumbing is what a dictation tool is, once the recogniser is a commodity.

The two rows that are not just convenience

Most of that list is work you could get through. Two of the rows are design decisions rather than features, and they are the ones a script written in an evening tends not to have.

The first is the order of operations.

A script that transcribes and then types has one failure mode with no recovery: the transcription succeeded, the insertion did not, and nothing kept a copy. You said the sentence, it went nowhere, and you have to reconstruct it. Doing it the other way round means writing to durable storage before the risky part, which is a decision you have to make on purpose on day one, because retrofitting it means rearranging everything.

The second is when the destination is chosen. Deciding at key-down means the text lands where you were talking, whatever the window manager did in the meantime. Deciding at insertion time — which is what a script does if nobody thought about it — means the text lands wherever you happen to be looking three seconds later.

Neither of these is difficult. Both are invisible until the day they matter, which is precisely why they get left out.

What a fortnight of the real thing looks like

Count the rows. That is a light day, and every one of them is a moment where the question is not "how good is the model" but "did it land in the right place, was the clipboard still mine afterwards, and is it recorded somewhere if it did not". The recogniser's quality is table stakes and it is free. The difference between the tools in this category is entirely the other thing.

When building it is the right call

This is not a page arguing nobody should. Build it if any of these are true.

You want to understand it. There is no substitute for having written the event tap yourself, and you will make better decisions about every tool in this category afterwards.

You need something we do not do. A different language mix, a specific model, batch transcription of a folder, an output format nobody sells, a pipeline that feeds something else. A script has no opinions and we have several.

You are not on a Mac. Then this is not a comparison, it is your only option — although if you are on a Mac and want the machine driven by voice rather than merely typed into, Talon is a mature system that already exists and is free to download.

You enjoy it. Genuinely the best reason. A tool you built and understand is worth more to you than a tool you bought, and the maintenance is a hobby rather than a tax.

If none of those are true — if what you want is to press a key and have the words appear, starting this afternoon — then the weekend is not an investment, it is the price, and it is a higher price than $19.

The hosted shortcut, and why it is a different trade

There is a third route people take: skip the local model and call a hosted transcription API from the script. It is less to install and the accuracy question goes away.

It also changes the product you are building. OpenAI's own file transcription guide documents an upload endpoint with a 25 MB file limit — you are sending audio to a server, which means a per-use cost, a network dependency, and a page of questions about what is retained that you now have to answer for yourself rather than read on somebody's privacy page.

For dictating a commit message that may be entirely fine. For dictating anything under an NDA it is the decision the whole local category exists to avoid, and it is worth making deliberately rather than because it was the shortest path in the script.

The maintenance ledger

The number nobody estimates before they start, so it is worth writing down.

A hand-built dictation setup has four moving parts that update independently: the recogniser, whatever runtime it needs, the thing that binds your key, and macOS. Each of them is fine on its own. The failures come from the joins, and they arrive at the worst possible moment — which is not "when I have a free evening" but "the morning I am dictating replies before a meeting".

The failures have a shape. A macOS update resets an accessibility permission, so the key stops firing and nothing tells you why. A Python version moves underneath the environment and a dependency stops resolving. A model file lands somewhere else after a reinstall. The resident process you wrote to avoid per-press startup cost dies quietly on Thursday and you notice on Monday.

None of these are hard to fix. They are each twenty minutes, they happen a few times a year, and the cost is not the twenty minutes — it is that your dictation tool is unreliable in a way you cannot predict, which is the property that stops you trusting it, which is what stops you using it. A tool you reach for sixty times a day only earns that by being boring.

Set against $19, the arithmetic is not really about money. It is about who owns the Saturday.

What accuracy actually depends on

A note that applies to both sides of this page, because it is the most common mistake in the whole category.

People building the DIY version tend to spend their effort on model choice — which size, which quantisation, which fork. That is the axis with the least headroom in it. Between a mid-sized model and a large one, on clear speech into a decent microphone, the difference on ordinary prose is small enough that you will not reliably notice it without measuring.

What you will notice: a laptop microphone in a room with other people in it, a fan running, and a habit of trailing off at the end of sentences. Fixing those costs less than either option on this page and improves both by more than any model change. If you are going to spend money before you spend a weekend, spend it on the microphone.

The second thing that matters more than the model is what happens in the two seconds after the words exist — the routing, the fallback, the clipboard, the saved copy. That is the part this page has been about throughout, and it is the part a benchmark never measures.

What we are actually selling

Not a recogniser. The engine is the commodity part of this product, exactly as it is the commodity part of your script, and pretending otherwise would be transparent nonsense to the audience for this page.

What $19 buys is the decisions: the key that works while held, the destination locked when the key goes down, insertion through the accessibility path with a paste as the fallback and your clipboard put back afterwards, the transcript written down before the engine is consulted, a searchable local history, a pill with a level meter so you can see you are being heard, and the fact that when macOS 27 changes something underneath all of that, fixing it is our morning rather than yours.

Nothing is uploaded — no audio, no transcripts. The model weights are fetched once from a public model host and after that it works with the network off. The price is $19 once for three Macs, updates included, and nothing renews. The trial is thirty days of the whole app, no card, no account, which is the honest way to run this comparison: build your script, run the trial alongside it, and see which one you reach for.

If you build it, build it in this order

Free advice for the people who are going to do it anyway, arranged so that the expensive discoveries happen early rather than in week three.

Get the resident process working before anything else, so you are measuring real latency rather than model load time. Then decide your destination at key-down and carry it through, because retrofitting that means rewriting the routing. Then write the transcript to a file before you attempt to insert it. Then do the insertion, with the clipboard save and restore, and test it in the ugliest application you use — a terminal, an Electron app, a web form — rather than in TextEdit, which works with anything.

Do the visual feedback last. It feels cosmetic and it is the thing that makes the tool usable, so leaving it late means you get an honest look at how much work the whole thing really was.

If you would rather buy than build, but not from us

Fair, and the category is not short of options. superwhisper is a local-first Mac app with a wider feature set, MacWhisper is the one to look at if transcribing files matters as much as dictating, Murmur is free and open source if you want somebody else's script rather than your own, and VoiceInk is a larger paid Mac app in the same neighbourhood. If what you want is a model that also thinks about your words rather than transcribing them, that is a different tool entirely.