How we measure

We take 902 to 2,936 short recordings in each of five languages, play every one of them to each speech model, and compare what the model typed with what was actually said. Accuracy is the share of words it got right. Speed is how long you wait for the text. Wispr Flow gets the exact same recordings, played into it through a virtual microphone, because it has no other way in.

Two public speech datasets that come with a written transcript of every recording. LibriSpeech is English audiobook speech and comes in a clean set and a harder, noisier set. FLEURS is read sentences in many languages, from which we use Spanish, Danish and Hungarian.

Each language is scored on 902 to 2,936 recordings. Before scoring starts, every run plays 3 extra recordings so the model is loaded and warm; those 3 never count towards accuracy, speed or the sample total. The transcripts are read speech, not someone thinking aloud, so every product looks a little better here than it will at your desk.

For every recording we line up the words the model produced against the words in the transcript and count three kinds of mistake: a wrong word, a missing word, and an extra word. Accuracy is the share of words with no mistake, so 96% means four words in a hundred were wrong, missing or invented.

We add up the mistakes from every recording and divide by the total number of words once, instead of averaging per-recording or per-language scores. A row's overall figure is built the same way across the languages it measured, so a weak language cannot hide behind a strong one.

Before comparing, both texts are lower-cased, stripped of punctuation and squeezed to single spaces, and anything in brackets such as [laughter] is removed. That is the whole of the cleanup, and it has one consequence worth knowing: punctuation is not scored, so a model can score high here and still miss every comma.

Speed is milliseconds of waiting for every second of audio you dictate. A figure of 100 ms/s means a ten-second sentence took about one second to come back. It is a ratio, so it is fair across short and long recordings; hover a cell on the benchmarks page for the actual wait per recording.

For a model running inside Codictate, the wait is the whole transcription, from the moment the audio is handed over to the moment the text comes back. Wispr Flow is different in two ways. It transcribes while you are still speaking, so what we can see is only the wait after you stop. And its audio travels to a server and back, so the network is part of its number.

The exact statement we publish with every speed table: Response times are not measured the same way for both products: Codictate is timed at the direct adapter call boundary, Wispr Flow is timed from the UI-observed paste. Compare speeds within a column freely. Treat a gap of less than two to one between the two products as noise.

Speed figures from runs before 4 September 2026 are not shown. In those runs some of our own test setup's work, such as switching the audio device back, was timed along with the product and added between 81 and 380 ms to a clip. Since then a run has to prove its clock was clean before its speed is published.

A comparison only means something if both products heard the same recordings. Every run writes down the exact list of audio files it scored and a short checksum of that list. Before a head-to-head is published, Wispr Flow's checksum has to match every Codictate model's checksum for that language, and the total word counts have to match to the word. They do, for all five languages.

This matters because an earlier version of the test identified recordings by sentence number, and FLEURS records the same sentence by several speakers. A run that believed it had covered 400 Danish recordings had in fact heard 264 distinct files. Runs are now identified by file, and that mistake cannot recur.

Wispr Flow has no API, no file input and no scriptable start or stop. It listens to a microphone and pastes text into whichever window is focused. So the test rig uses it exactly the way a person would, one recording at a time.

A virtual microphone. The recording is played through a loopback audio driver (BlackHole) that feeds whatever is played straight back in as microphone input, and Wispr Flow is set to listen to it. No speakers, no room, no background noise, for either product.

Real-time playback. Each recording plays at normal speed, because Wispr Flow starts working while you are still talking and a sped-up recording would change what it hears.

A real keyboard shortcut.The rig presses Wispr Flow's dictation shortcut with the same key event a keyboard would send, half a second before the audio starts and half a second after it ends, so no words are cut off.

A text box to paste into. The rig keeps a focused text field, clears it before every recording, and watches it after the shortcut is released until the text has stopped changing, because Wispr Flow revises what it has pasted for a moment after it appears.

The rig is open source and produced every Wispr Flow figure on this site: github.com/EmilLykke/dictation-benchmark.

Disk is the size of the model download. RAM is the most memory the model used while running, averaged across its languages. The language columns are word accuracy for that language. Speed is the wait described above, and lower is better. A dash means there is no figure, never a zero, and hovering it says why.

Every run executes on an Apple M4 Max with 36 GB of RAM, running macOS 26.6.2, with nothing else demanding running. Other hardware will give other speeds, but the order of the models holds.

Every run keeps the results file it was scored from, listed with its dataset, sample count and hardware on the benchmarks page. The Codictate side of the test ships in the app's own repository; the Wispr Flow rig is linked above. If you run either, we would like to see the numbers.