Why your Mac dictation app types words you never said (and what we found in 35 days of audio)

Short answer: In 35 days of our own recordings, Sorimac's V2.1 model produced 412 voice-assistant commands nobody spoke, and 27 were typed into an app; the Qwen3 model produced none. More than half sat on 0.13 seconds of sound or less, such as clicks, and the V2.1 training data had no real-world silence. A detection rule we are testing, not in a release yet, would stop 291 of the 412 before dictation opens.

Ten times over 35 days, our test Mac typed "Cancel the ticket I booked this week." into whatever app was open. Nobody had said anything. There was no ticket.

It was not the first ghost. Months earlier, an early build typed "Amen" by itself in a quiet room at dawn. With an always-listening dictation app, those ghosts are more than an annoyance. They land wherever your cursor is, and if auto-enter is on, they get sent.

We build Sorimac, a dictation app for Mac that runs speech recognition on the device. Because the app can keep recordings locally (an opt-in setting, off by default, and the audio never leaves the machine), we had 35 days of our own audio to go through. This post is what we found when we traced these invented sentences back to their source.

How often it happened

Over 35 days of stored recordings, the app produced 412 transcripts that were voice-assistant style commands nobody spoke. They showed up on 24 different days.

Two things stood out right away. Every single case came from one model, V2.1, an optional engine we fine-tuned from Qwen3-ASR for Korean. And none of the 412 were mixed into real speech. Each one was a complete, standalone command sentence.

The same few sentences kept coming back. "Cancel the ticket I booked this week." appeared 167 times. "Cancel the pension booking I made this week." 78 times. "Who is the main actor in this movie?" 45 times. (The originals are Korean; a "pension" is a Korean holiday rental.)

What sound triggers it

Sorimac's voice detector works in blocks of 0.064 seconds. We counted how many blocks in each of the 412 cases actually had sound in them.

More than half had less than 0.13 seconds of sound. You cannot physically say a twenty-character sentence in that time. These were clicks, taps and bumps, and the model wrote a full command on top of them.

That matched a separate look at a single day of our usage. Dictation opened 1,321 times that day, and 1,102 of those (83%) were thrown away. When we plotted the discarded ones, almost all were impulse sounds of 0.06 seconds or less: keyboard, mouse clicks, the mic brushing against clothing. The detector in the released app opens on a single loud block.

Why the model invents sentences

We went back to the V2.1 training set, 96,270 samples, and grouped it.

The interesting part: "Cancel the ticket I booked this week." is not in the training data. The model did not memorize it. It assembled it. The habit of opening with "this week" comes from the voice-assistant group, where 1,461 sentences start that way. The words "booking", "pension", "ticket", "movie" come from the unstructured command group, which has 1,421 mentions of movies and 754 of pensions, while the voice-assistant group has zero of either.

Then the no-speech samples. Only 2% of training data, and every one of them was either digital silence (all zeros) or low white noise. Not one keyboard click, breath or desk tap. The model never learned that a sharp click deserves an empty transcript. Given a click, it did what it had seen most: wrote a typical command.

Same audio, two models

To check that this is a model property and not an accident of the app's code path, we re-ran 120 of the stored clips (all 27 that were typed, plus 93 random discarded ones) through both models with the current code.

Qwen3 produces short junk like "Ah." on these clips (73 times), which the filters remove easily. It never produced an invented sentence. (Two V2.1 outputs were mixed with log text and could not be read, hence 118.)

Why text filters kept leaking

Before this investigation, the app already had four defenses: a self-consistency check (decode the same audio several times and discard if results scatter), a speech-rate cap, a filter for the "booked this week" sentence pattern, and a repeat memory for short strings.

They caught 385 of the 412. They also had a structural hole. On the re-run, only 15 of the 46 invented sentences matched what was logged at the time. The other 31 had turned into different sentences. The same sound that once became "Cancel the ticket I booked this week." now became "Tell me where the ticket machine is in this cinema." 21 times. A small change in the input conditions and the model's favorite sentence moves somewhere else. Filtering by text means chasing it forever.

The self-consistency check had its own blind spot: a favorite sentence comes out identical every time, so it looks consistent.

What we are testing

The fix that addresses the cause sits at the door, before any model sees the audio. The voice detection rule we are testing takes a loud block as a candidate only, and opens dictation when 3 voiced blocks gather within 6 blocks (0.38 seconds). A click goes back to the noise floor right away. Speech, even quiet speech, keeps sound above the floor between syllables.

We replayed all 9,349 stored recordings from 35 days through the real detector:

"Three in a row" looked better on noise but blocked 3.1% of real speech, because speech drops out for about 0.06 seconds between syllables. We dropped it. Most of the 46 typed utterances the new rule blocks were themselves invented commands sitting on one or two impulse blocks.

Against the 412 invented sentences, the new rule stops 291 (71%) before dictation even opens, including 15 of the 27 that were typed. The cost: dictation opens 0.13 seconds after the first sound. Sorimac keeps a pre-roll buffer, so the start of your sentence still reaches the model.

The rule is still in testing and is not in a release yet.

What is still open

The remaining 29% are breaths and longer noises above 0.2 seconds. A detection rule cannot stop those. The real fix is training data that contains real-world silence. From our own recordings there are 1,961 clips (65 minutes over 34 days) that the new rule blocks and that contain two or fewer voiced blocks, so no speech could be in them. They stay on this Mac. Whether they go into the next training run is not decided.

There are limits to all of this. We classified "invented commands" with a word list we wrote, so other kinds of hallucination are missing and some real speech could be mixed in. We looked at waveforms and transcripts, but did not listen to every clip. It is one speaker, one microphone, one room. We have no data from other users' Macs, because Sorimac does not collect usage data.

If you see ghost text with your own dictation app, a practical check: note whether it happens after a click or tap rather than after silence, and try the app's other speech model if it has one. In our case the difference between models was 39% against 0%.

FAQ

Why does a dictation app type words nobody said?

In our case, clicks, taps and bumps opened dictation, and the V2.1 model wrote a typical voice-assistant command on top of them. More than half of the 412 cases had less than 0.13 seconds of sound. Its training data had no-speech samples that were only digital silence or low white noise, never a keyboard click.

Does every speech model do this?

Not equally. On the same 120 stored clips, V2.1 produced invented commands in 46 of 118 (39%), and Qwen3 in none. Qwen3 produced short junk like "Ah." instead, which the filters remove easily.

Why not just filter the invented sentences out?

The existing filters caught 385 of the 412, but the favorite sentence moves. On the re-run, 31 of the 46 invented sentences had turned into different sentences, so filtering by text means chasing them.

Is the new detection rule in Sorimac now?

No. It is still in testing and not in a release yet. In a replay of 9,349 stored recordings, it blocked 60% of discarded utterances and 1.3% of typed ones, and it opens dictation 0.13 seconds after the first sound.