Blog · 2026-09-12

Bot-free is not the same as local

Every meeting notetaker now says some version of the same thing: no bot, private, local-first, on-device. The words are used interchangeably in marketing and they do not mean the same thing. One of them describes what other people in the call can see. The other describes where your conversation ends up. This post is about telling them apart, including a test you can run in two minutes.

Two different claims

• Bot-free is a claim about visibility. Nothing extra shows up in the attendee list. The tool records the audio already playing on your machine instead of sending a participant into the meeting.
• Local (or on-device) is a claim about data flow. Recording, transcription and note generation all happen on your machine, and nothing is uploaded.

Most products advertising the first do not do the second. They capture locally and then upload the file for transcription, summarization, or both. If your concern is that a vendor ends up with a copy of the call, the missing bot changes nothing at all. It only changes whether the people on the call find out.

That last part is worth sitting with. Removing the bot without moving the processing does not make a tool more private. It makes the same data transfer less visible to everyone except you.

Three places audio can leave

Any tool in this category has three stages. Ask about each one separately, because the answers are usually different:

1. Capture. A bot in the call, or a recorder on your device? Only the bot hands the vendor your audio at this stage.
2. Transcription. Speech recognition on your machine, or an upload to an API? This is where nearly every “local” tool actually uploads.
3. Summarization. A model on your machine, or a frontier model in someone’s cloud? A transcript is not a harmless byproduct. It carries the same content as the recording, in a form that is easier to search, store and leak.

In practice the common shape is: stage one local, stages two and three remote. The reverse essentially never happens.

The two-minute test

Product pages are weak evidence. This is better, and it takes about as long as reading one:

1. Start a recording.
2. Turn off Wi-Fi and unplug the ethernet cable.
3. Talk for a minute.
4. Stop the recording and wait.

If a full transcript and a set of notes appear, both stages run on the machine. If the transcript is empty, a spinner hangs, or the entry sits at “processing” until the network comes back, the work is being done somewhere else. No marketing copy survives this test.

There is a second test that costs even less. Open the privacy policy and search for “sub-processor”. A product that genuinely processes on your device has no transcription vendor and no model provider to list, because there are none.

Why the distinction has teeth

If audio reaches a vendor, a set of questions comes with it, and none of them are answered by a promise not to look:

• Disclosure. If you work under an NDA, a client engagement, or a DPA, a new vendor in the chain is something you may have to name.
• Retention. “Deleted after transcription” is a policy, not a property of the system. Policies change with ownership, pricing and pressure.
• Breach. A copy that exists can be exposed. A copy that was never made cannot.
• Training. Opt-out defaults are a setting. Settings get reset, and terms get revised.

On-device processing does not answer these questions well. It removes them.

What actually runs on a Mac today

The reason this is worth arguing about now, and was not worth arguing about three years ago, is that the local option stopped being the worse option:

• Speech recognition. macOS ships an on-device engine that is fast and cheap for roughly ten languages. Everything beyond that is covered by Whisper large-v3-turbo running locally on Apple Silicon, about 1.6 GB downloaded once and then fully offline.
• Summarization. Turning a transcript into topics, decisions and action items is a narrow task. It does not need a frontier model, and an on-device one handles it.

The limiting factor is no longer quality. It is memory, which is why tools in this shape require Apple Silicon.

What you give up

A comparison with only one side is not worth reading, so here is the honest list. Processing on one machine means:

• No sync and no team library. The notes are on the Mac that recorded them. If your team needs one searchable archive of every call, a hosted product is the right answer, and Otter, Fireflies, Fathom and tl;dv are built for exactly that.
• No phone, no Windows. If half your meetings happen away from a Mac, an on-device Mac tool covers half your meetings.
• Hardware requirements. Running the models locally costs memory that a cloud product does not ask you for.
• One writing style. An on-device model is good at this task. A large cloud model is better at prose. If you rewrite the notes anyway, that difference is small; if you forward them untouched, it is not.

The case for on-device is not that it wins every comparison. It is that for conversations that cannot be uploaded, the other options are not options.

The short version

• Bot-free is about visibility. Local is about data flow.
• Check capture, transcription and summarization separately. Usually only capture is local.
• The offline test settles it in two minutes, more reliably than any product page.
• On Apple Silicon the whole chain can run with no network, including keeping each side of the call on its own track.
• If you need a shared archive across a team and across devices, a hosted tool is the better fit. Pick the constraint you actually have.