Local vs Cloud Dictation App: Two Questions, Not One

Local vs cloud is two questions: where does audio go, and what does cleanup receive? An airplane-mode test, seven questions for any vendor, ListenIn's answers.

You are picking a dictation app for a Mac you also use for work, and every product page says “local” or “private”. Local instead of cloud for which stage, recognition or cleanup? The word is doing two different jobs, and the page rarely says which one.

A dictation app is two stages, not one

Every modern dictation app does two things in sequence:

  1. Speech → text. A recognizer turns audio into a raw transcript. This is the stage people mean when they say “the model”.
  2. Text → clean text. A language model removes the “um”s and false starts, repairs sound-alike errors, adds punctuation, maybe restructures. Without it you get what macOS built-in dictation gives you: every word, literally.

“Local” can describe either stage. One app runs recognition on your Mac and sends the transcript to a cloud model for cleanup. Another sends audio to a cloud recognizer and skips cleanup entirely. Both call themselves private. So the question is never “is it local?” It is two questions.

Question 1: does audio leave the machine?

Audio is the sensitive artifact. It carries your voice, the room, whoever was talking next to you, and everything you said before you cancelled. Text can be read before it goes anywhere; audio can’t.

The airplane-mode test. Turn off Wi-Fi, click into a text field, dictate a sentence. Three outcomes:

  • Nothing appears, or an error asks for a connection: recognition is cloud.
  • Raw text appears with the ums and false starts left in, maybe with a cleanup-failed notice: recognition is on-device, cleanup is cloud. (Apple’s recognizer already adds punctuation, so punctuation is not the tell.)
  • Clean text appears: both stages run on your Mac. Confirm it on the vendor’s data page anyway.

The test has a limit. It proves the recognizer can work offline, not that it never uses the network when one is available. Apple’s own engine, for example, may use device or service-side processing depending on macOS version and language unless the app forbids it. For the online path you have to read the vendor’s data-flow document, and if there isn’t one, that is your answer.

ListenIn’s answer: recognition runs through Apple’s speech engine with on-device processing forced on, on both the modern engine (macOS 26) and the classic fallback (macOS 14–15). The classic engine is not permitted to use Apple’s speech service. Audio never reaches ListenIn’s cleanup service in any mode. The security page lists what each mode sends, and audio is not in any row.

Question 2: what does the cleanup stage receive, and where does it go?

This is the question most privacy pages skip, because the honest answer is “text goes to a language model, and here is whose.”

Ask three things:

  • What is in the request? Only the transcript, or also context: your dictionary, nearby text, a screenshot of the window? Each extra input helps cleanup and widens what leaves.
  • Whose server? The vendor’s own endpoint, which forwards to a model provider, or a provider you pick directly?
  • Can it be nobody’s? Is there a route where cleanup runs on the Mac too?

ListenIn’s built-in cleanup request carries the recognized text and your cleanup settings, and optionally your personal-dictionary terms, a tone hint, and recent text context. It carries a random device ID for quota and an optional Pro license key. It carries no account name or email, because there is no account. So that your corrections keep working, it may also carry word-level pairs such as “gethub → GitHub”: single words, never sentences, never past transcripts. No screen image. ListenIn’s server keeps no transcript database; text is forwarded to the configured model provider under that provider’s API terms, and the privacy page names which providers.

Cleanup does not add content or answer what you dictated; set Cleanup strength to Verbatim (punctuation only) if you want it to touch as little as possible.

Two routes skip ListenIn’s server entirely:

  • Your own key. Add a provider under Settings → Models and text goes straight from your Mac to it. If your company already has an approved endpoint, point ListenIn there and ListenIn’s service is out of the path.
  • Local Ollama. Pick an on-device model under Settings → Models and turn on Offline Mode. Cleanup runs on your Mac. Combined with forced on-device recognition, nothing leaves: not audio, not text. The Ollama setup post covers the steps.

Seven questions to ask any vendor

Paste these into the support form. A vendor who has thought about the problem answers all seven in a paragraph.

#QuestionWhat a clear answer looks like
1Does raw audio ever leave the Mac? Under which conditions?”Never”, or a named list of exceptions
2What text leaves, in which modes?A per-mode table
3Does the app capture the screen or read other windows?”No”, plus what the Accessibility permission is actually used for
4How long is anything kept server-side?”No transcript store”, or a stated period
5Is audio or text used to train models?Separate answers for the vendor and for its model provider
6Is an account required, and what identifies me?”No account; a random device ID”, or the account fields
7What happens with no network?Which stage keeps working, and what you get

ListenIn’s seven, one line each:

  1. Audio: never leaves the Mac. Both recognition engines are forced on-device.
  2. Text: recognized text plus the optional context above, only when cleanup runs.
  3. Screen: no. Accessibility is used for the trigger key, the paste, and re-reading the field it just pasted into, for up to a few minutes, so your corrections can be learned. That read stays on the Mac; only word-level pairs go up with the next cleanup.
  4. Retention: no transcript database; the server keeps anonymous word-count totals for quota and request metadata without content. History and dictionary stay on the Mac.
  5. Training: ListenIn never uses audio for training and never receives it. Text goes to the provider under its API terms, or to nobody with Ollama.
  6. Account: none. A random device ID keys the free quota.
  7. Offline: recognition still works. The raw transcript still lands when cleanup is unavailable, and Offline Mode with a local model keeps cleanup working too.

”Fails without a language pack” is evidence, not a bug

The trade-off ListenIn accepts: on macOS 14–15, Apple’s classic recognizer needs the dictation language downloaded to the Mac. If it isn’t, ListenIn does not quietly route the audio to Apple’s servers to compensate. It fails, and the HUD tells you to download the language in System Settings › Keyboard › Dictation Languages.

That is inconvenient the first time. It is also the only behavior consistent with “audio never leaves the Mac”. An app that promises on-device recognition and never fails offline either ships the language models it needs or has a fallback it isn’t describing. If you hit it, the fix takes a minute.

Which route for confidential work

Whether you may dictate customer names, source code, or contract terms is your organization’s call, not a vendor’s. What you can do is pick the route whose data flow matches the policy you already have:

  • Built-in cleanup (default, no setup): audio stays on the Mac; text goes to ListenIn’s service and on to a model provider. Suitable for the same material you would paste into a web chat assistant.
  • Your own key: text goes only to the provider your organization already approved. ListenIn’s service never sees it.
  • Local Ollama + Offline Mode: nothing leaves. The route for material that shouldn’t touch any third party, at the cost of running a model on your own hardware.

Traditional Chinese writers ask about script: Chinese script set to Always Traditional is a cleanup setting. It travels with the recognized text and does not change the audio boundary above; all three routes hold for Traditional.

One boundary applies on every route: password fields and apps with secure input on get a copy card instead of a paste. The HUD says “Can’t paste into a password field · click to copy” or “Another app has secure input on · click to copy”, Everywhere else ListenIn pastes, then checks that the text landed; if it can see that it didn’t, it shows the same copy card. If you dictate into a terminal, the secure-input post explains when the card appears and what to do.

If anything here disagrees with what the app does, that is a bug. The FAQ has the short version of these answers, and questions go to support.

Try it on your own Mac

Free tier, no account. Audio never leaves your Mac.

Download for Mac

← All posts