Last year I had a call with a large enterprise customer about integrating analytics into my SaaS. I'd sent the invite myself. We said hello in Google Meet, and a few seconds later a notification came up: my cloud note taker was knocking to be let in.

The man on the other side stopped smiling. "Sorry, we can't continue in this format. Guest apps and recording bots are prohibited by our security policy."

So I spent the first five minutes of an important call hunting for the button that kicks my own bot out of my own meeting, apologising, and trying to get the temperature back. To them I was the guy who had quietly brought a stranger into a confidential conversation.

That's the version everybody notices. The quieter one happens on every call where the bot does get in: "Notetaker" sits in the participant list, and people edit what they were about to say.

Both come straight from how most meeting note takers are built. So it's worth knowing the architecture before you pick one, because the architecture decides where your audio ends up.

Twenty seconds of the alternative, no sound: setup, the live transcript running over the desktop, then the summary being written when the call ends.

Watch it run0:20 · no sound
Nothing joined the meeting to produce any of this. The transcript panel is an application on the desktop, alongside the call.

How the common design works

The dominant pattern is a bot participant. You connect your calendar, the service reads your invites, and a headless client joins each meeting as a guest. It gets the same stream everyone else does, sends it to the vendor's servers, transcribes it there, and writes a summary.

This design is popular for good reasons. Nothing to install, works the same on every platform, and it captures the call even when you're away from your desk.

Four consequences come with it, and they're structural:

Everyone can see it. The bot is a participant. On sales calls that changes the temperature of the conversation. In interviews, candidates notice. Some people say less, and what you get are the notes of a more careful meeting.

Your host may not allow it. Plenty of companies restrict guest joins, block unknown apps at the tenant level, or require approval for recording tools. If you're the outside party, you often can't bring your own bot into someone else's meeting at all. The softer version of the same problem: the bot lands in the waiting room, and you break off mid-sentence to ask whether someone could please let your robot in.

The audio leaves your machine. Not the transcript, the raw audio, of every call, to a third party's infrastructure. Whatever the retention policy says today, that's a copy of your conversations sitting somewhere you don't administer. I've spent twenty years writing software and running the servers it lands on, which is probably why this one bothers me more than it bothers most people: I know how little you can tell from the outside about how that data is stored, or whether it trains something.

Consent gets complicated. In two-party consent jurisdictions, recording without everyone agreeing is a legal problem rather than an etiquette one. A visible bot at least makes the recording obvious, which is genuinely better than hiding it. It also means you've announced it to the room whether you wanted to or not.

The other design

Capture the audio locally, on the machine that's already in the call.

The application takes the system audio output and your microphone input directly, the same way a screen recorder does. Nothing joins, because there's no additional participant. The meeting sees exactly the people who were invited. Transcription runs through a speech-to-text provider you connect yourself, with your own API key, and both the transcript and the summary land on your disk.

Transcript with each line labelled either MIC or LOOPBACK
Each line is labelled by where it came from: MIC is you, LOOPBACK is the system audio of everyone else. Two streams captured on the machine.

The practical differences follow from that:

  • Nothing appears in the participant list, because nothing joined.
  • It works on calls you were invited to but don't control, including ones where guest apps are blocked.
  • Audio goes to the transcription provider you chose, on your account, under your agreement with them.
  • Recordings and transcripts stay on your device by default.

What your own key actually buys

It's easy to read "you supply your own API keys" as a cost the vendor pushed onto you. Look at what it changes, though, because this is the part that does the privacy work. Not the policy page.

With a proxied service your audio goes to the vendor, and the vendor forwards it to whichever model provider they contracted with. You're trusting two companies instead of one, and you have a relationship with neither the processing nor the retention. What their servers keep, for how long, who inside the company can read it, what happens to it in an acquisition: all outside your control, and mostly outside your visibility.

With your own keys that middle link doesn't exist. Outrun has no server in the path, so there's no copy of your calls on our infrastructure and no account of ours holding your transcripts. We couldn't read your conversations if we wanted to. That's architecture, not a promise. It still holds if we get acquired tomorrow, or breached: there's nothing in our possession to take.

The tradeoff, stated plainly: your audio does still reach a transcription provider, and your text does reach a model provider. Something has to do the work. The difference is that it happens on your account, under your agreement, with retention settings you control and logs in your dashboard. You're one party away from your own data instead of two, and that party is one you picked and can audit.

There's a second effect people miss. Because the keys are yours, so is the model choice. Proxied services have a margin to protect, which pushes them toward cheaper, smaller models: you pay a flat subscription and get whatever is economical for them that quarter. On your own key you can point Outrun at a flagship model and pay its actual price, with nothing added on top.

What this costs you

The local design is worse in several concrete ways, and you should know them before you switch.

Setup isn't zero. You have to create accounts with a transcription provider and an AI provider, generate keys, and paste them in. Budget fifteen to twenty minutes, once. A cloud service with a calendar integration is genuinely faster to start using: two clicks and you're running.

You pay the providers directly. The app can be free while the intelligence isn't. A full cycle of prep, live call, and analysis afterwards runs somewhere around fifty cents to two dollars depending on the model you pick. Usually cheaper than a per-seat subscription, but it's metered, and it's a bill from someone else.

No bot means no absentee capture. If you're not on the call, nothing gets recorded. A calendar bot will happily attend a meeting you skipped. A local recorder can't.

Your notes are on one machine. Local-first means local. No cross-device sync and no shared team workspace unless you export and send it yourself.

Which one you actually want

If your calls are internal, your company already administers the vendor, and convenience is the priority, the bot design is fine and you should use it. Being recorded by a tool your own IT department approved is a very different situation from routing your conversations through a service you signed up for personally.

The local design earns its friction in a narrower set of cases:

  • You're the outside party, and you can't install anything in the host's meeting.
  • The content is sensitive enough that "where does the audio live" is a question you have to be able to answer.
  • You're in a regulated environment where sending customer audio to an unapproved processor is a compliance event.
  • You just don't want a visible recorder changing how people talk to you.

If none of those apply, the extra setup buys you very little. If two or more do, it stops being a preference.

Trying the local approach

Outrun's note taker is free and stays free: realtime transcript on any call, a summary once the call ends, and exports. You bring your own transcription and AI keys, which is exactly why the audio never touches our servers. There's no account of ours for it to sit in.

The summary gets written from the transcript once the call ends, and it's deliberately conservative about what it claims:

Call notes with sections for what the call was about and who took part
It states the length of the capture up front, and says nobody was named on the call instead of inventing participants.
A key details section listing specific technical facts from the call
Key details stay concrete: the numbers, names and decisions that were actually said out loud.

Read the API keys guide first. It walks you through creating both keys with screenshots, about fifteen minutes, once, and that's the whole setup. If you'd rather not connect anything yourself, one of the cloud services will serve you better, and that's a reasonable answer.

If it isn't, download it and record one call. You'll know within a single meeting whether the tradeoff fits how you work.

If you later want more than notes

The same keys unlock everything else, so nothing has to be reconfigured if you decide to go further.

The paid tiers turn the recorder into something that works during the conversation instead of after it. A copilot that reads the room live and hands you the next question or the number while you're still talking. A prep agent that assembles a brief on the company and the people before you dial. Practice runs built from the places you were weak on the last call. On the Pro layer, private mode and live translation. There are two tracks, one for job seekers and one for closing deals, because those funnels genuinely differ. The pricing page has what each includes.

None of that changes the architecture above. The live features run on the same bring-your-own-key model, on the same machine, with the same absence of our servers in the path.