Our July 2026 Performance Test: What We Found and Fixed

Every month we run a multi-day performance test on Cosmos: real machines, four browsers plus our desktop apps, and a fleet of 150 bots simulating a busy distributed company. We described the full method in how we keep Cosmos light at any call size. This post is what the July 2026 run found.

The short version: the baseline stayed light, the plateau held, and our repetition tests caught memory leaks in a handful of everyday actions, from status switching to noise cancellation. All of them are fixed. Here are the numbers.

The baseline: Cosmos alone

Before testing calls, we measure the cost of simply being present in your virtual office: connected, visible to your team, ready to talk, with nobody actually talking.

On the Windows desktop app in July:

• Call view, listening: around 1.5% CPU, 0% GPU, roughly 910 MB of memory
• Call view, mic and camera on: around 3% CPU, 17% GPU, roughly 940 MB
• Map view, listening: around 2% CPU, 10% GPU, roughly 560 MB

In the browser the story is similar. Edge on Windows idled at about 5% CPU in call view and 12% in map view. Chrome on a Mac read about 15% CPU in call view listening, 22% in map view, and 16% with mic and camera on, with roughly 520 MB of memory throughout.

A note on Mac numbers throughout this post: macOS reports CPU as a percentage of a single thread, not of the whole machine. A reading of 30% there means a third of one thread on a many-threaded machine, so the machine-wide usage is far lower than the raw figure suggests.

For context on where those numbers sit, we benchmarked Cosmos against Google Meet, Zoom, Microsoft Teams, Webex and Zoho Meeting earlier this year: the same five-person call, all cameras on, on the same machine.

The plateau: 20 people vs 90 people

Cosmos's gallery view shows 24 videos at once, so our architecture makes a specific promise: resource usage climbs up to 24 participants and then flattens, no matter how large the call gets. Every monthly run has to prove that promise again.

In July we put a 20-person call and a 90-person call side by side on the same machines. On the Windows desktop app in map view, listening:

Four and a half times the participants, and the machine barely notices. That is the plateau doing its job, and it is why we say the numbers hold at any call size beyond 24: past that point, your machine is rendering the same 24 videos regardless of who else is in the room.

What we found: memory that did not come back down

Snapshots were the easy part. The harder question is what happens over hours of use, so we repeat everyday actions 5, 10 and 30 times and watch whether memory returns to its baseline. In July, in several actions, it did not:

• switching status between Focus and Available
• switching camera devices
• starting a screenshare, and watching someone else's
• toggling noise cancellation
• broadcasting
• switching pages in gallery view

Noise cancellation on the Mac app shows the shape of the problem. Picture a session idling at 1.39 GB of memory. Before the fix, five toggles added roughly 0.25 GB, taking it to about 1.64 GB; ten toggles added 0.68 GB, pushing it past the 2 GB mark, and none of it was released afterwards. Nobody toggles noise cancellation ten times in a row, but a leak like this grows quietly across a working week of normal use.

Call page switching showed the same shape. In a 60-person call on the Mac app, the session sat at roughly 1.3 GB; five page flips took it to 1.46 GB and ten took it to 1.62 GB, with none of it coming back.

None of these would have shown up in a quick smoke test. All of them showed up within hours of the repetition protocol, which is the entire argument for having one.

What we fixed

Every leak on that list was fixed during the same test cycle, and each fix was verified by re-running the identical scenario on multiple machines with the bot fleet.

The noise cancellation re-test tells the story in one line: that same session now ends exactly where it began. Ten toggles, and memory still reads 1.39 GB; the line is flat. Call page switching is the same picture: flip through as many pages as you like and memory holds at 1.3 GB. The other leaks were confirmed fixed the same way: repeat the action, watch the line stay flat.

The run surfaced functionality and UI issues too, and those were fixed alongside:

• a camera feed appearing stuck when switching to a second camera before its permission was granted
• broadcasters not seeing their own video in the popout or in chat view
• the input volume slider not working on Firefox
• polish on whispering, broadcast and meeting room toast positions

This is the loop working as designed: the test exposes the issue, the fix lands, the same test proves the fix, and next month's run makes sure it stays fixed.

Everything else we checked

The rest of the July run came back clean. Across Windows and macOS, the desktop apps and Chrome, Edge, Firefox and Brave, we repeated the full battery: mic and camera toggles, microphone device switching, joining and leaving calls, breakout rooms, codec changes and Bluetooth music mode. Memory returned to baseline after each.

We also ran the toughest scenario in the book: bot calls joining from 15 regions on slow machines with low bandwidth, cameras on and moving through the space, with over a dozen speaking at once. Even under that load, resource usage stayed in the same range as our ordinary tests: the extreme case cost your machine no more than the everyday one.

What this means for you

Every fix from the July run is already live. You did not have to update anything or ask for it; your Cosmos simply got lighter.

So leave Cosmos open from your first coffee to the end of the day, sit in a 90-person all-hands, toggle whatever you like, and your machine will barely notice. Performance and reliability are not launch-week claims for us; they are re-proven every month.