Live dictation without a streaming model: how Parakeet gets sentence boundaries right

Text that appears while you are still talking sounds like a job for a streaming model, one that listens and writes at the same time. Hebrish has one: Shakshuka, a fine-tune of NVIDIA's Nemotron streaming model. Yet the apps recommend Sabich, a Parakeet model that only transcribes finished audio. This post explains why, and the work at the joins that made Parakeet good at live dictation, sentence boundaries above all.

Streaming was tried first

Desktop 0.7.0 (2026-10-22) made Shakshuka the default for dictation. Daniel dictated with it the same day and found it jarring: text arrived two or three words at a time, and when he paused to think, the last words didn't come out until he spoke again. The cause was in how streaming text grows. It grows in word pieces, so the app held each word back until the next one started, and a pause meant nothing arrived to release it. Desktop 0.7.1, the same evening, moved the recommendation back to Sabich. Shakshuka is still in the desktop app and its pacing was retuned, but for dictation Parakeet read better.

Parakeet, in pieces

Parakeet needs the audio before it can write, so the apps cut a take into pieces at your pauses and transcribe each piece as soon as it is cut. A pause of 0.6 seconds or more is a candidate cut, and one of a second or more cuts straight away. Each piece is then transcribed with Parakeet's full accuracy, and the text lands a moment after you stop to breathe.

The catch is that Parakeet writes every piece it is given as a complete sentence: capital letter at the start, full stop at the end. Stop to think in the middle of a sentence, and you got "kind of Dumping" or "the hardest part is. Is the room noise?" Daniel's own dictation history from desktop 0.7.3 to 0.7.5 had about 1.2 capitalised function words a minute after a word with no punctuation: 134 in 110 minutes of audio.

The fix: let the model hear the sentence carry on

Two changes, both in the apps, with no change to the model.

• A held full stop (desktop 0.7.1). The full stop at the end of a piece is held back until the next piece arrives. If the next piece clearly continues the sentence, the stop is dropped.
• Context at the joins (desktop 0.7.6, Android 0.8.2, 2026-10-23). Each piece is transcribed together with the last 3 seconds of the piece before it, and only the words after that point are kept. The model hears the sentence going on, so it writes the first word in the case it has mid-sentence. And it decides for itself whether the previous piece ended a sentence, now that it has heard what followed.

What it measured

On 108 clips from the benchmark test set, each with one pause inside a sentence (0.7 to 2.0 seconds) and four clips to a take, 19.3 minutes of audio in all:

• Capitals in the middle of sentences: 73 before, 30 after.
• Full stops in the middle of sentences: 27 before, 10 after.
• Word error rate: 6.38% before, 6.07% after. Transcribing the whole take at once, with no live text at all, scored 11.63% on the same clips.
• The cost: about 21% more decoding time, and more missed full stops (12 to 19). With the extra context, the model sometimes runs two sentences together across a 1 to 2 second gap.

In real use the change shows too, though less sharply. A rough count over Daniel's desktop dictation history (capitalised common words such as "the", "so" or "it" after a word with no punctuation) gives 1.34 a minute on desktop 0.7.5 (110 minutes) and 1.03 a minute across 0.7.6 to 1.005 (426 minutes). The count also catches some capitals that are correct, so it only shows the direction of the change.

The latest fix: whole words at the joins

Reviewing a first export of Daniel's Android history turned up one more seam problem. The first word after a pause sometimes lost its start: "ividual" for "individual", "chnically" for "technically". Nine of the ten cases were in takes that had been cut into pieces. The model times each word piece to an 80-millisecond step, so the start of that first word could be timed just before the end of the context and was dropped with it. Android 1.005 and Desktop 1.006 move the cut back to the start of the word. On 59 test-set clips joined in pairs, one word was clipped before the change and none after.

Why this matters

A streaming model trades some accuracy and some readability for text that appears word by word. With pause-based pieces, a held full stop and context at each join, Parakeet keeps its offline accuracy and still gives live text, with sentence boundaries close to those of a single long transcription. It runs on a phone's processor too: on Daniel's OnePlus, the Android history shows Sabich transcribing in about a tenth of real time, with half a second from Stop to text in the typical take. Shakshuka stays available for anyone who prefers text word by word. Its accuracy as a streaming model hasn't been measured on the test set yet, so this post makes no comparison of the two on accuracy.