16 August 2026
There's no single number, because the limit isn't set by the app — it's set by whether the call routes media directly between participants (mesh) or through a server (SFU), and by whose CPU and upload speed pays for it. A mesh call is usually fine at four and struggling by nine. An SFU-based call can hold fifty or more, but the bottleneck moves from your upload to your download and your machine's ability to decode and render that many streams at once.
Every video call has to move a camera and microphone feed from each person to every other person. The two dominant ways to do that produce very different ceilings, and most people never see the difference because they only ever join calls, they don't build them.
In a mesh call, every participant's device connects directly to every other participant's device — no server sits in the middle relaying video. In a server-relayed call (an SFU, or Selective Forwarding Unit), each device sends one upload stream to a server, and the server copies and forwards it to everyone else. Same call, same faces on screen, completely different math underneath.
In a mesh call with N people, each device has to maintain N-1 direct connections. That means encoding and sending N-1 upload streams and decoding N-1 incoming ones — simultaneously, with no server to absorb the fan-out.
At four people, that's 3 up and 3 down. A modest laptop on home wifi handles that without much strain: maybe 1-1.5 Mbps per 480p stream, so 4-5 Mbps total upload, well inside most home connections. At nine people, it's 8 up and 8 down. Now you're pushing 8-12 Mbps of upload from a single machine while decoding eight incoming video feeds on the CPU, and most residential upload speeds — often capped at 5-20 Mbps even where download is fast — simply can't sustain it. The first symptom is usually one or two participants freezing or dropping to audio-only, not everyone degrading evenly, because the weakest uplink in the mesh determines what everyone else sees of that person.
This is also why a mesh call that was fine yesterday breaks today with the same headcount: it's sensitive to whichever single participant has the worst connection, since their upload has to reach everyone directly.
An SFU fixes the upload problem by having each participant send exactly one stream — to the server, not to everyone. The server then duplicates and forwards it to whoever needs it, often at different resolutions per recipient (simulcast), so a phone on a slow connection doesn't get the same bitrate as a laptop on fiber.
This is why platforms built on an SFU can hold thirty, fifty, or more participants without every device needing a 20 Mbps uplink. But the ceiling doesn't disappear — it moves. Your upload is now flat regardless of group size, but your download and decode load still scale with N. A device rendering forty live video tiles is decoding forty streams and compositing forty frames into a layout, and that's a CPU and GPU cost that has nothing to do with network speed. This is why large SFU calls switch to speaker-view or paginated grids well before the participant count gets absurd — usually somewhere between 25 and 49 visible tiles, depending on the client — and why turning video off for most participants is the actual fix once a call gets large, not a bandwidth upgrade.
For a mesh architecture, plan on real trouble starting somewhere between 6 and 10 participants, with 4-5 as the comfortable zone on typical home connections. For an SFU architecture, the network ceiling is much higher — into the hundreds for audio and dozens for full-grid video — but the rendering ceiling on the client kicks in well before that, which is why most tools quietly cap visible video tiles rather than the meeting itself.
Beyond that, the tools that claim to hold hundreds or thousands of people are usually doing something structurally different: most attendees are receive-only, sending no upload stream at all, which is a webinar, not a meeting. That distinction matters more than the headline number. A 500-person 'meeting' where 495 people never unmute and never send video is a broadcast wearing a meeting's name.
AVAY runs on a server-relayed model in the browser, so the upload-side math that breaks mesh calls at eight or nine people doesn't apply — a participant sends one stream regardless of group size. It's built and tuned for meeting-sized groups where everyone is expected to be present and speaking, not for webinar-scale broadcast to a mostly silent audience, so if the goal is a one-to-many stream to hundreds of receive-only viewers, that's a different tool than the problem AVAY is solving.
One thing worth knowing regardless of platform: the AI participant that transcribes and answers questions in an AVAY call doesn't add a video stream to the call itself, so it doesn't count against the same rendering ceiling that live video tiles do.
| Upload cost per participant | Where the ceiling actually sits | Typical practical limit | |
|---|---|---|---|
| Mesh (peer-to-peer) | Scales with N-1: full stream sent to every other peer | Weakest participant's uplink, plus local encode/decode load | 4-6 comfortable, 8-9 typically breaks |
| SFU (server relay) | Flat: one upload stream regardless of group size | Download bandwidth and client-side decode/render CPU | 20-50+ before UI switches to speaker view or paginates |
| MCU (server mixes into one stream) | Flat, and download is also flat — server sends one composited feed | Server-side compute; client work stays low even at scale | Very large, but layout and speaker prominence are fixed server-side |
All three use server-relayed architectures, and their published limits (often 100-1,000 depending on plan and whether it's a meeting or webinar mode) reflect licensing and product tiers more than a hard technical wall. The real-world limit most people hit first is the client rendering dozens of live video tiles at once, which is why these platforms switch to speaker view, grid pagination, or 'view more' well before the account limit is reached.
Audio streams run at a tiny fraction of video's bitrate — a compressed voice stream is typically under 50 kbps versus 500 kbps to 2.5 Mbps for a video stream at reasonable quality. A connection that can't sustain nine simultaneous video streams can usually sustain nine audio streams without noticing, which is why calls often degrade to voice-only rather than dropping entirely.
On a mesh call, yes, up to a point — more upload bandwidth directly raises the number of simultaneous streams your device can push. On an SFU call, faster internet mostly helps your download side; your CPU's ability to decode and render many tiles at once becomes the limiting factor before bandwidth does, so a faster connection on an old or thermally-throttled laptop won't fix a call that's stuttering because of rendering load.
It depends on the platform, but a well-built AI participant typically joins as a listener rather than a full video peer, so it doesn't add an encode/decode video stream that counts against the rendering ceiling. It still consumes a participant slot on platforms that count by connection, but the video-quality math that breaks mesh calls at high counts isn't affected by its presence.
There's no fixed number of people a video call can hold — there's a mesh ceiling around 6-9 set by upload bandwidth, and a server-relayed ceiling set by how many video tiles a device can decode and render, and the fix for each is different.
Meetings that take their own notes, in the browser: avay.ai.