Where your meeting audio actually goes

“Can this tool be trusted” is the wrong first question, because the answer is a promise and promises are not checkable. There is a better one: which machine does the audio have to reach for the product to work at all? That is architecture, not policy. It cannot be revised in a blog post, it is the same for every customer, and you can watch it happen in a browser’s network panel in about two minutes.

Three designs cover almost everything in this category.

Three places the audio can be

Design Where the audio must travel What you can see from inside the call
A bot joins the call The platform streams the meeting to the vendor. Transcription happens there A named participant in the attendee list that somebody had to admit
A desktop app captures your device The microphone and system audio are taken locally, then usually sent onward to the vendor Nothing. There is no participant, and often no announcement unless the person makes one
A page captures the tab Nowhere, if the model runs in the page. The audio never becomes a request Nothing, for the same reason as the row above

Note what the third column does not tell you. Rows two and three look identical from inside the meeting, and they are opposites on the question this page is about. Anyone choosing a tool on “no bot in my call” alone is choosing on the column that does not answer it — and anyone in a meeting who assumes no bot means no recording is making the same mistake in reverse.

Local capture is not local processing

This is the sentence the whole page exists for. “Records on your device” describes where the microphone is. It says nothing about where the audio goes next, and the two are marketed as if they were one thing.

Two vendors are unusually clear about it, to their credit, and both are quoted here because they said it themselves. OpenAI’s help centre, describing the Meetings plugin in its macOS app, says it “uses microphone and system audio from your Mac and streams it to OpenAI to generate meeting notes”, and that once the notes are ready “the audio is deleted from your Mac and OpenAI’s servers”. Read.ai, describing its desktop and mobile mode, says it “is capturing audio locally on the user’s device” and that the mode exists because “local-device capture works in situations where an agent cannot or should not join” — it is a statement about joining, not about uploading.

So the useful question about a desktop note taker is not whether it joins. It is whether a transcript shows up in a web account you can open from another computer. If it does, the audio or its transcript left the machine, whatever the capture was called.

How to check it yourself

This is the part that cannot be argued with, and it works on any of the three designs, including ours.

  1. Open the browser’s developer tools and go to the network panel before you start. Leave it open.
  2. Record a minute of anything, then stop and let the tool transcribe.
  3. Sort the request list by size, largest first, and look at the direction. Weights coming down once is a download. Megabytes going up while you speak is an upload, whatever it is labelled.
  4. Check the websocket and media entries too, because a continuous stream does not appear as one large request.
  5. Then turn off the network and try to transcribe. Anything that still works was never leaving.

A tool that transcribes locally makes no request while it transcribes. One that does not, does. No amount of wording on a marketing page changes which of those you are looking at.

Every host this application can contact

Which is why the list is published rather than summarised. This is the same table that is on the privacy page, where the application’s own test suite fails the build if a request appears that is not on it.

HostWhenWhat is in the request
huggingface.co and its CDN The first time you transcribe with a given model, and never again Nothing of yours. It is a download — the weights come to you
The site itself The page, the WebAssembly runtime, and a page-view count Nothing of yours
auth.opennotetaker.app The account page, and while signed in A sign-in method and a credit balance. No transcripts
gateway.opennotetaker.app Only when you press a button that shows a price The text that button names, and nothing else

There are only three buttons in the fourth row — AI-written minutes, a question across your library, and translating a finished transcript — and they send the transcript you already have on screen. Never audio: the request bodies have no field for it, and the application shows you the exact body before it sends anything.

What the architecture does not fix

Four things, and none of them are small.

The other half of the architecture question is the licence, which is a different axis and is checked separately in what is actually open source in this category. A tool can be MIT-licensed and still upload every minute of audio; a closed one can keep it local.

Record a meeting · What leaves your device · Read the source

The two vendor descriptions quoted above were read on 1 October 2026 from OpenAI’s and Read.ai’s own public help centres, and are quoted for what they say about where audio travels — nothing here is a claim about what any product does beyond its own documentation. Our own host table is the one on the privacy page. The check in the middle of this page is the point: do not take this page’s word for any of it.