Who Said What: Why MinuteAI Ships Speaker Diarization as a Download, Not a Bundle

A Transcript Isn’t the Same as Minutes

Transcribe a one-hour meeting with four people and you get a wall of text. Somewhere in it is who agreed to what, who raised the objection nobody addressed, and who owns the follow-up — but none of that is visible until you know which lines belong to which speaker. Turning a transcript into usable meeting notes depends on an attribution step most transcription tools treat as an afterthought: speaker diarization, the process of figuring out who said what and when.

We’ve written about MinuteAI’s on-device transcription pipeline and its Chrome Extension that never lets a bot join the call. Speaker diarization is the piece that turns the resulting transcript from a block of text into something structured — and it’s also the piece that broke MinuteAI’s usual pattern of just running everything on-device without a second thought.

The Problem With Doing This On-Device

Whisper-based transcription — what MinuteAI already runs through Core ML — is a manageable model to keep resident in a native macOS or iOS app. Speaker diarization is a different animal. MinuteAI’s diarization is built on pyannote.audio, the open-source library that’s become close to a de facto standard for the task, and pyannote.audio runs on PyTorch. Neither of those ship as a lightweight CoreML model you can drop into an app bundle; the runtime dependencies alone — Python, PyTorch, and pyannote’s own dependency tree including scikit-learn and networkx — pack out to roughly 743MB extracted.

Bundling that into every install would mean every MinuteAI user pays a several-hundred-megabyte tax for a feature most of them may never turn on. So MinuteAI doesn’t bundle it. Diarization ships as a separate, optional download: a self-contained Python 3.13 runtime with PyTorch 2.10 and pyannote.audio 4.0.4 pre-installed, packaged to about 234MB compressed, fetched from a GitHub Releases artifact only when a user enables diarization in Settings. Everyone else’s install stays exactly as small as it was.

A Subprocess, Not a Bridge

The architecture that makes this work keeps the Python runtime at arm’s length from the rest of the app. Rather than embedding a Python interpreter into the SwiftUI binary through some kind of bridge library, MinuteAI’s Swift code spawns the downloaded runtime as a subprocess and talks to it over that boundary — a python-runtime-manager component handles the download and lifecycle, a subprocess runner resolves which Python binary to call, and a diarization engine loads the model and runs inference through that subprocess. If diarization is never enabled, none of that code path executes and none of that runtime ever gets downloaded. It’s the same instinct behind the model-manager design in MinuteAI’s core transcription pipeline — lazy loading, nothing resident until it’s actually needed — applied to a dependency an order of magnitude heavier than a CoreML model.

That separation also means the diarization runtime versions independently of the app itself. It has its own release history, separate from MinuteAI’s own version numbers, so the model and its dependencies can be updated without forcing an app release, and the app can ship without ever touching the diarization stack.

What Attribution Actually Requires

The model behind diarization — pyannote/speaker-diarization-community-1 — comes with its own licensing chain worth being explicit about, because it’s a genuine build-process constraint, not a footnote. It’s distributed under CC-BY-4.0, which requires attribution to its authors (Hervé Bredin and collaborators), and pulling it from Hugging Face in the first place requires an access token tied to accepting that model’s terms — a step every build of the runtime has to complete before the model can be packaged into a release, even though the resulting artifact ends up as a public download. pyannote.audio itself is MIT-licensed and the Python runtime is PSF-licensed; three different licenses stacked into one download, each with its own obligations.

The engineering wasn’t frictionless, either, and it’s worth naming plainly rather than glossing over: pyannote 4.x changed its output API mid-stream, wrapping results in a DiarizeOutput object instead of returning the Annotation directly, which broke existing integration code until it was fixed. And validating that the whole pipeline actually detects speech required generating real speech with macOS’s own text-to-speech rather than synthetic test tones — the model doesn’t reliably register synthetic audio as speech at all. Small details, but the kind that separate a diarization feature that ships from one that looks finished in a demo.

Where the Market Is Actually Moving

The decision to keep diarization off a server isn’t happening in isolation. Most cloud-based meeting note-takers still run diarization exactly where you’d expect — inside the same infrastructure that already receives the uploaded audio, computing speaker embeddings and storing them alongside the transcript. But the center of gravity is visibly shifting: pyannote.ai, the commercial venture built around the same pyannote.audio library MinuteAI depends on, has partnered with Argmax specifically to bring its most accurate diarization models on-device — the company that helped define cloud diarization as an API-first category is now investing in running the same models locally. And it isn’t the only signal: a growing set of meeting tools are marketing “100% local” diarization as an explicit differentiator against the upload-and-process norm, positioning on-device speaker attribution as a distinct, privacy-driven segment rather than a niche experiment.

MinuteAI’s downloadable-runtime approach is a specific, sometimes awkward answer to a real constraint — a heavyweight ML dependency that doesn’t fit the rest of an on-device app’s footprint — but it lands in the same place that segment is heading: audio and speaker data that never leave the machine it was recorded on, transcription included.

Where This Fits

Transcription decides what was said. The Chrome Extension decides how the audio gets captured without a bot in the room. Diarization decides who said it. Three different engineering problems, each solved with the same non-negotiable running underneath: nothing about a conversation — its content, its capture, or who was speaking — has to leave the device it happened on.

---

MinuteAI is available on the App Store for macOS and iOS, or you can learn more at getminute.app. Questions about how it fits your workflow? Reach out at hello@aitytech.com.