Cloud transcription was a hardware workaround. The hardware caught up.

On-device transcription used to be the option you tolerated for privacy and paid for in accuracy. In 2026 that trade is gone: the model that transcribes your calls on a MacBook is a server-class speech model, running on silicon Apple has been shipping since 2020, faster than the conversation happens. This is the engineering story of how that happened, because the privacy argument for local processing only lands once you believe the quality argument is settled.

Why transcription moved to the cloud in the first place

Speech recognition was one of the first workloads to centralize, and the reason was never your data. It was arithmetic. A good speech model in 2015 needed more compute than a laptop had, so vendors put the model on GPUs in a datacenter and had your device ship audio to it. Siri worked this way. Every dictation feature worked this way. When AI meeting notetakers arrived, they inherited the architecture without re-examining it: capture audio, upload it, transcribe it server-side, store the result.

The pattern hardened into an assumption. By the time OpenAI released Whisper in September 2022, an open-source model you could genuinely run yourself, most of the industry kept uploading anyway, because the pipeline, the pricing and the product were already built around servers holding your conversations.

What changed on the silicon side

Two curves crossed. Consumer chips gained dedicated machine-learning hardware, and speech models got dramatically more efficient per parameter.

Apple has shipped a 16-core Neural Engine in every M-series Mac since the M1 in 2020, alongside a GPU and unified memory that CPU, GPU and Neural Engine all address directly. For speech models this matters more than raw speed: audio features move between the encoder and decoder without being copied across a bus, which is where inference pipelines on conventional hardware lose their time.

The software path matured too. CoreML compiles a neural network into something the Neural Engine executes natively, and by 2025 the conversion tooling was good enough that models trained on NVIDIA hardware in PyTorch could run on a Mac's ML accelerator without a specialist team doing the port.

The model that made it concrete: Parakeet

Whisper proved local transcription was possible. NVIDIA's Parakeet made it comfortable.

Parakeet TDT v3 is a 600-million-parameter speech model covering 25 European languages, German included. Two design choices make it fit a laptop where larger models struggle. The encoder is a FastConformer, a convolution-augmented transformer tuned for long audio at low compute. And the decoder uses token-and-duration transduction: instead of stepping through the audio one frame at a time, it predicts each token together with how long that token lasts, then skips the frames in between. Fewer decoding steps, same words.

Fazit runs exactly this model through CoreML, via the open-source FluidAudio runtime. The adapter is one file, FluidRecognizer.swift, and the model weights download once on first launch from Apple and Hugging Face CDNs. That download is the only network call in the product, and it fetches weights to your machine rather than sending anything from it.

What on-device makes possible that cloud cannot offer

Here is the part that matters beyond benchmarks. A cloud transcription pipeline has a structural requirement: the audio must survive long enough to be uploaded, queued and processed. That means a file, or a stream that lands in one. Every cloud notetaker, whatever its retention policy says, first creates a copy of your conversation on infrastructure you do not control. The policy governs the copy. The architecture guarantees it exists.

When the model runs on the same machine that captured the audio, that requirement disappears, and you can make a stronger choice: never let the audio become a file at all.

Fazit's capture path is a fixed-capacity ring buffer of PCM samples in RAM, defined in AudioRingBuffer.swift. Audio enters at 16 kHz mono, the live transcriber consumes it incrementally during the call, and when the session ends the buffer is zeroed and released. There is no code path from that buffer to a file: no AVAudioFile, no write(to:), no upload. At the 45-minute buffer ceiling the whole thing is about 170 MB of memory, and then it is gone. The result is audio_retained: false as an architectural fact you can check, not a settings toggle you have to trust. The security page documents each invariant with the code path that enforces it.

The last cloud argument was summarization. That one fell too.

For a while the honest objection was that even if transcription ran locally, turning a transcript into a usable note needed a frontier model, so the text went to the cloud anyway. That objection had a shorter shelf life than expected.

A 3B-parameter local model, running under Ollama, writes a faithful structured meeting note from a transcript. Extraction is not creative writing: the model's job is to find the decisions, numbers and follow-ups already in the text, and small models do that reliably when the prompt is disciplined. Fazit talks to Ollama at 127.0.0.1:11434, the loopback interface, so during a session the transcript's entire journey is from one process on your Mac to another. The finished note lands as Markdown in your Obsidian vault, which is the files-not-rows argument in practice.

Why this lands hardest in regulated work

If you are a consultant under an NDA, an accountant under IRC § 7216, or a European professional watching the EU AI Act's main obligations apply from August 2026, the on-device shift changes the shape of your compliance question. A cloud notetaker makes you a data controller with a processor chain to govern: DPAs, subprocessor lists, transfer mechanisms, deletion requests. Local processing removes the chain rather than papering it. Client audio that never leaves your machine involves no third party to contract with, no transfer to assess, and no vendor retention policy to monitor for silent edits.

That reasoning is developed properly in on-device vs. cloud AI notetakers; this post is the technical floor under it. The claim "your audio never leaves the device" is only as good as the hardware's ability to do the work locally, and that ability is now boring, settled fact.

Frequently asked questions

Is on-device transcription as accurate as cloud transcription?

For meeting speech in the 25 European languages Parakeet TDT v3 covers, the gap that once justified uploading audio is gone. The model families are the same ones cloud vendors run server-side; the difference is where the inference happens, not what the model can do. Heavy accents, crosstalk and bad microphones degrade both the same way.

What Mac do you need to run transcription locally?

Any Apple Silicon Mac (M1 or later) on macOS 14.4 or newer. The 14.4 floor comes from the Core Audio process-tap API Fazit uses to capture call audio from Zoom, Google Meet, Microsoft Teams or any other app without a bot joining the meeting.

Doesn't the model download count as sending data somewhere?

No. The one-time download on first launch fetches model weights to your machine from Apple and Hugging Face CDNs. Traffic flows toward your Mac. No audio, transcript or note content travels the other way, and you can verify that with any network monitor.

Can the summary step run locally too?

Yes. Fazit generates notes through a local model served by Ollama on 127.0.0.1:11434. The transcript never leaves the loopback interface, and if Ollama is not running the raw dialogue is still written to your vault, so a call is never lost to a missing model.