developers
Why a meeting bot needs a whole browser to take notes
There is a participant in your Zoom call named "Jack's Notetaker." It has no camera. It never speaks.
What it actually is: a headless Chrome instance running in a container on somebody's cluster, which opened your meeting URL and clicked Join.
That is the whole trick. Recall.ai, who sell this as infrastructure, describe the join step plainly: on Zoom a bot joins "using the platform's Meeting SDK as a headless client or through browser automation," while "Google Meet has no dedicated bot API, so bots typically join through browser automation," and on Teams bots join through the Teams SDK "or browser automation when the SDK doesn't expose the needed data." Slack Huddles need browser automation plus a third-party SDK.
So: a real browser, driven by a script, pretending to be a person. If you are evaluating whether to build on Recall.ai, MeetingBaaS or Skribby, or roll your own, that sentence explains most of what you are about to pay for and most of what is about to go wrong.
The pipeline, hop by hop
Every hop below is a place where cost enters, latency enters, or accuracy leaks.
| Hop | What actually runs | Where it breaks |
|---|---|---|
| Dispatch | Your scheduler decides a bot is needed | Calendar drift, meeting moved, link changed |
| Container spin-up | A fresh container per meeting | Cold start against a hard 10:00 start time |
| Browser boot | Headless Chrome, audio stack, virtual devices | Chrome update changes a flag |
| Join | Navigate to URL, fill name, click Join | Waiting rooms, host admission, admin policies that block bots |
| Capture | Media and signaling channels, same as a normal client | Reconnects, tab crashes, silent stream death |
| ASR | Audio to a transcription service | Cost per hour, latency, code-switching |
| Diarize | Split the audio into speakers | See below |
| Attribute | Map speakers to human names | See below, twice |
Recall is candid that the operational half is the hard half: "Running a single bot is simple; running thousands simultaneously is an infrastructure problem," requiring "container orchestration, autoscaling, monitoring, and session lifecycle management." They are describing their own moat accurately.
Note what is not on that list. Nothing about intelligence. The expensive part is the transport.
Diarization is the load-bearing weakness
Here is where most write-ups get sloppy, including the ones that say bots always receive a single mixed stream. They do not always. Recall's own capability matrix lists per-participant audio streams as available on Zoom, Google Meet and Microsoft Teams, and unavailable on Slack and Webex, and the same page claims bots can deliver "100% perfect diarization."
When that privileged path is available, it mostly works. The problem is what the path costs you and what it still cannot know.
First, the privileged path is conditional. Per-participant audio on Google Meet means the Meet Media API, which is still in Developer Preview, gated behind the Workspace Developer Preview Program, and capped: Google's docs say "there exists a cap on the number of Virtual Audio Streams and Virtual Video Streams a client can open," after which Meet servers send only the participants "deemed most relevant." Fireflies, who ship on it, put a number on that cap: the SDK "captures audio and video from up to three active participants at a time — this is a Google API limitation." The same page notes the SDK "currently doesn't support chat messages or captions." Three streams and no chat is not a general solution to meetings.
When you fall off that path — no approval yet, a platform without the API, a meeting the SDK refuses — you land on browser automation, and what leaves a browser tab is a mix. Speaker separation then becomes inference from voice characteristics, and inference degrades in exactly the conditions real meetings have: more participants, accents, people talking over each other, one attendee on a phone speaker.
Second, and this is the part no model release fixes: a stream is a connection, not a person. Perfect per-connection separation still gives you one label for a conference room with six people around a single laptop. A commenter on the Hyprnote Launch HN thread put the case exactly:
When holding meetings in a hybrid fashion where some people are remote and others are in the office with a shared mic...it's a total dealbreaker for us
The information required to split that room is not in the signal. You can throw a better model at it and get a better guess. It stays a guess.
Third, identity is unstable even when separation succeeds. A developer working against Meet's bot APIs reported that email = null (always null) and that static_participant_id "changes every meeting — it is not a stable identifier," concluding: "We cannot tell which transcript segment belongs to which person." A perfectly separated stream labelled speaker_7f3a is not attribution.
The measured numbers match the theory. A comparison across 20 meetings found "Otter and Fireflies were both around 88-90% accuracy in clean 1-on-1 calls but dropped to maybe 75% in group calls with 5+ people." Two people on the Hyprnote thread hit the floor case on the same day. One: "I just tried it in a 30-minute meeting with 20 people and it put the entire conversation under a single speaker, in a single paragraph." Another: "I just tried this for a standup meeting, and the inability to tell who said what is a show stopper."
Why this matters more than the accuracy number suggests
Word error rate degrades gracefully. Attribution error does not.
A transcript that misspells a product name is annoying. A transcript that assigns the wrong name to a sentence produces a summary that says "Sarah agreed to ship by Friday" when Sarah never spoke — and that document does not stay in your app. Someone forwards it. From r/sales:
those AI summaries confidently invent action items nobody agreed to... Then someone forwards it as the record and now you are on the hook for a commitment that never happened.
And on HN:
The worst is when someone uses these, blindly trusts the output, and then sends out an email after the meeting with a list of hallucinations that everyone supposedly "agreed to."
A summary with confident wrong attribution is worse than no summary. No summary leaves people relying on memory, which they know is fallible. A wrong summary carries the authority of a record.
Worth noting what developers on that same thread asked for and did not get: "The ability to receive live transcripts from a webhook, including speaker diarization metadata would be super useful," and a headless mode that would "write transcript to stdout with some light speaker diarization markup." Those are the two requests. They come up constantly.
Per-platform ugliness
Zoom is the least bad, because the Meeting SDK exists and a headless client is a supported shape. You still need raw data access approval.
Google Meet has no bot API at all, so the mainstream approach is browser automation against a UI Google keeps changing. Recall lists exactly this among the per-platform quirks you inherit if you build it yourself: "Google Meet's changing interface elements that bots must track." Your join flow is a selector, and selectors rot.
Teams gives you an SDK, an approval process people route around, and breakout rooms — which Recall also names as a quirk. A breakout room is a different media session. A bot in the main room hears nothing.
Slack and Webex have no per-participant audio streams at all, per Recall's matrix. On those platforms you are back to inference regardless of how much you spend.
What it costs, and what you are paying for
Prices verified 24 August 2026.
| Provider | Transport | Transcription | Minimum |
|---|---|---|---|
| Recall.ai | $0.50/recording hr | +$0.15/hr built-in | None |
| Skribby | $0.35/hr | +$0.39/hr to $1.36/hr by model | "No contracts, no minimums" |
| MeetingBaaS | 1.00 token/hr raw | +0.25 token/hr standard | Tokens $0.35–$0.50; plans $99–$299/mo |
One correction to the folklore. Developers spent 2025 citing a $1,000/month floor — one builder on HN in June 2025: "It's surprisingly hard to get transcripts and recordings out of Zoom, Teams and Google Meet meetings. The only API that had the features I needed (Recall.ai), charges $1000 / month minimum, so I decided to build my own." Another builder hit the same number, and pricing plus enterprise-gated calendar sync was a recurring complaint.
That floor is gone. Recall announced in March 2026 that it cut PAYG from $0.70 to $0.50 per recording hour, that "we no longer charge a monthly platform fee," and that the Calendar API is now included free. Credit where due. If you bounced off this category eighteen months ago on price, the price changed.
What has not changed is the shape of the bill. Look at Skribby's split: $0.35/hour buys "meeting bot deployment, raw audio recording, and live webhook notifications," and transcription starts at $0.39/hour on top. The container and the browser cost about as much as the speech recognition. Recall's pricing page notes that participant count does not affect the rate — you are billed for wall-clock hours a browser stayed connected. You are renting a seat in a call for a robot.
The other architecture
Every problem above traces to one decision: the notetaker is a guest, so it hears the room the way a guest hears it.
Change that and the problems do not get solved so much as cease to exist. If the meeting platform transcribes each microphone on the machine it came from, speaker attribution is not inference. The speaker is the connection the words arrived on. That is what Team Meet does — a track each, transcribed per-speaker, so the name on a line is a fact about routing rather than a guess about timbre. Two people sharing a laptop are still one connection, and we say so instead of inventing a split.
Downstream, a lot of infrastructure stops being necessary. No container per meeting. No headless Chrome. No audio pipeline, no waiting room, no selector that breaks when someone ships a redesign. An agent needs a socket and a key:
import { WebSocket } from 'ws';
const ws = new WebSocket('wss://teammeet.io');
ws.on('open', () => ws.send(JSON.stringify({
type: 'agent-hello',
key: process.env.TEAMMEET_KEY,
meeting: 'abc-defg-hij',
})));
ws.on('message', raw => {
const m = JSON.parse(raw);
if (m.type === 'transcript') {
// m.line.speaker is a name, not a guess
console.log(`${m.line.speaker}: ${m.line.text}`);
}
});The key is one call:
curl -X POST https://teammeet.io/api/keys \
-H 'content-type: application/json' \
-d '{"name":"Notetaker"}'No account, no card, no monthly minimum. Details at teammeet.io/developers.
Now the honest part, because this piece is worth nothing if I bury it.
This only works for meetings held on Team Meet. A protocol-native agent cannot join someone else's Zoom call. There is no per-participant socket to connect to, because Zoom did not build one for you. If your product's job is to sit in whatever meeting your customers already run — sales calls into a prospect's Teams tenant, interviews on a client's Meet link — you need a bot, you need per-platform integrations, and you should buy them rather than build them. Recall at $0.50 an hour with no floor is a reasonable purchase for that job.
The choice is not which vendor. It is whether you need to be a guest at all. If your meetings can live on one platform, the guest architecture and everything it drags behind it is a cost you were never obliged to pay.