The transcript never touches a disk.

Most "AI meeting" tools ship audio to a cloud transcriber and keep the transcript on a server. That's a fine architecture for a note-taking product where the user actually wants the transcript searchable. It's a terrible architecture for the kind of product MeetPing is, where the only output we care about is a popover that opens on a keyword. The audio doesn't need to leave your machine. So it doesn't.

The model lives in the .app bundle (Parakeet TDT v3, CoreML). The decoder runs against the Apple Neural Engine — an on-die accelerator that's both faster than the CPU for this workload and dramatically lower-power. The first partial transcript lands in about 1.4 seconds of wall-clock time on M1+, none of which depends on a network.

Verifying it yourself

You don't have to take our word for it. Three ways to confirm: point Little Snitch at the MeetPing process and watch nothing connect; switch to airplane mode mid-meeting and confirm pings keep firing; or check Activity Monitor's network column for the MeetPing PID and watch it stay at zero. The Parakeet model is read off disk once at startup and never read again.

What about IT?

v0.1 has no backend, no telemetry endpoint, no auto-update key other than the EdDSA-signed Sparkle appcast at meetping.app/appcast.xml, which is a static file. Most security teams approve MeetPing in one round of review; the privacy posture is documented entitlement-by-entitlement on /privacy. Hardened Runtime is on. Sandbox is off in v0.1 because Core Audio Taps and the FluidAudio BNNS dylib loader require it.

What the v0.2 remote-alerts channel will mean

v0.2 will introduce an opt-in remote-alert channel (Telegram, Pushover, Slack DM, or ntfy.sh — driven by what users actually ask for). When that ships, it will only fire on a keyword hit, it will only contain the keyword and a timestamp (never transcript text or audio), and the toggle will be visibly outlined in Settings. Until then: zero outbound calls, end of story.