← All articles

Inside Our Monthly Performance Test: How We Keep Cosmos Light at Any Call Size

29 Jul 20268 min readCommunication

We hold a fairly blunt belief at Cosmos: it does not matter how good your software is. If it has bad performance, it should not exist, because nobody can actually use it.

That belief is why we run a multi-day testing marathon every single month. This post explains exactly how we do it: the setup, the bot fleet, the toughest calls we simulate, and how we hunt memory leaks.

Why performance is make-or-break for a virtual office

A meeting tool has to behave for 45 minutes. A virtual office has to behave for eight hours, every working day, alongside everything else on your machine.

Our customers keep Cosmos open all day; it is where their team sits. If our software chokes their laptop, they cannot design, code, render or take a sales call. That is unacceptable, and it is why we treat resource usage as a product feature rather than an engineering afterthought.

So we set ourselves a standing target: always sit at the low end of CPU, GPU and memory usage, and prove it on a schedule. We run a full performance test every month, or after every two ships, whichever comes first.

The setup (the nerdy bit)

Each run covers the real spread of devices our users work on:

  • Desktop platforms: Windows and macOS
  • Desktop app: the Cosmos app, tested on both platforms
  • Browsers: Chrome, Edge, Firefox and Brave
  • Mobile: Android and iOS

Testing one platform tells you very little. The same build can idle quietly on Windows and lean hard on a MacBook, and a browser tab behaves nothing like the desktop app. We capture every combination, every run.

Cosmos performance test matrix: Windows and macOS, the desktop app on both, Chrome, Edge, Firefox and Brave, plus Android and iOS

How we replaced human testers with 150 bots

We used to run these tests with people. Rounding up enough humans for a large call, coordinating them, then doing it all again after every fix made the iterations painfully slow, and slow iterations mean shallow testing.

So we built our own bot fleet, in a repo we call HK50, to replicate how real users behave in Cosmos. Each run, the bots:

  • join from 15 regions around the world, with 10 bots per region and 150 in total, so network conditions vary the way they do in a genuinely distributed team
  • run on slow machines with low bandwidth, because your users are not all on new MacBooks with fibre
  • stream video and audio into the call, so the media pipeline does real encode and decode work rather than idling behind blank tiles
  • move through the space, jumping in and out of conversations, because spatial movement is how Cosmos works. A bot sat still in one room would be testing a different product

The result is a repeatable, on-demand simulation of a busy distributed company. We can find an issue, ship a fix and re-run the identical scenario the same day. Human testing never gave us that iteration speed.

We test the toughest call possible

Most large calls follow a predictable pattern. An all-hands with 90 people typically has four or five hosts speaking, and everyone else raises a hand and waits their turn.

We test something far harder: a big call where around 16 people are speaking at once, everyone has their camera on, and the whole room is moving through the space, joining and leaving mid-flow. It is a situation that almost never occurs in real usage, and that is exactly why we test it. If Cosmos stays light under a load no real meeting will ever produce, everyday usage has headroom to spare.

Then we ask one question of that extreme call: what is the least resource usage we can possibly achieve?

What we actually measure

Every run works through the same chunks, in order:

  1. Someone using Cosmos alone
  2. A 2-person call
  3. A 20-person call
  4. A 90-person call
  5. A 150-person call

For each chunk we capture CPU, GPU and memory, in both map view (moving around the space) and call view (the meeting itself), in listening mode and with mic and camera on. We record it all on the same machines we have used in previous runs, so numbers are comparable across months.

The Reality test: the 24-video plateau

Cosmos's gallery view shows 24 videos at once; anyone beyond that sits on the next page. So resource usage should climb incrementally up to 24 participants and then plateau, regardless of call size.

We call this the Reality test, and CPU, GPU and memory are its fundamental metrics. A 150-person call should cost your laptop the same as a 24-person call across all three. If any of the lines keeps climbing past 24, something is subscribing to media it should not be, and we go digging. It is also why a 150-person all-hands on Cosmos does not need a special machine.

Line chart of CPU and GPU usage alone, in a 20-person call and in a 90-person call on the same Windows machine, flattening past the 24-video gallery limit

Hunting memory leaks

Light usage in a snapshot is not enough. A virtual office runs all day, so we test what happens to memory over time: does it get released, or does it quietly pile up?

We attack this from two angles. First, we keep Cosmos running for long stretches during the test, tracking resource usage over time the way a normal workday would. Second, we use repetition: take a base reading for an everyday action, then repeat that action 5, 10 and 30 times, reading memory at each stage.

The actions are deliberately ordinary, because ordinary actions are what users do hundreds of times a day:

  • turning your mic on and off
  • turning your camera on and off
  • switching to a different microphone or camera
  • changing your status between Focus and Available
  • starting a screenshare, stopping it, or watching someone else's
  • turning noise cancellation on and off
  • joining and leaving calls

If memory grows and does not come back down, we mark it, reproduce it on other machines and platforms to confirm it, fix it, and then run the whole sequence again.

And yes, we find leaks. That is the entire purpose of the exercise. A team that claims its long-running app has never leaked memory is a team that has never looked.

Keeping ourselves honest

Two habits stop this from becoming a vanity exercise.

We benchmark against Google Meet. For call view, we run the same scenarios side by side and compare resource usage. Comparing against yourself is comfortable; comparing against one of the most widely used meeting tools in the world is not.

Every run is compared with the last one. New features such as screenshare modes, noise cancellation and device handling get audited for both correct functionality and resource cost. A fix only counts if the next run's numbers are lower, and the long-term trend has to point one way: down.

Find, fix, re-test, repeat

Each run produces a huge volume of readings and logs from our own test machines and bots. We use modern AI models to help trace where a performance issue starts, which turns days of manual log-reading into hours and leaves more time for the fixes themselves.

Then we iterate: find issues, fix them, test again. It is a brutal multi-day process, deliberately so. The discipline is the feature.

How far the numbers have come

We have been running versions of this process for years, on the same machines, so we can see the whole arc. In the early days, a 10-person call on Cosmos could spin up your laptop fans. Today a 150-person call runs smoothly on an ordinary laptop.

Three of our long-serving test machines tell the story between March 2025 and July 2026:

  • On the Windows desktop app, a 90-person call cost around 17% CPU in March 2025. In July 2026, the same call on the same machine cost around 5%.
  • On a deliberately low-end Windows laptop with 4 GB of RAM, running Cosmos in Edge, a mid-sized call cost around 71% CPU in March 2025. In July 2026 it was around 40%.
  • On a Mac in the browser, the same scenario went from around 50% CPU to around 23%.

Same machines, sixteen months, and the CPU cost of a call dropped to a half or a third of what it was. None of that came from one clever rewrite; it is the compound interest of monthly test-fix-retest cycles.

The March 2025 sheet also records the kind of thing this process exists to catch: a burst of animated emoji reactions pushed memory to 4.2 GB, never gave it back, and crashed the weakest machine in the fleet outright. Found, fixed, verified the next run. We wrote about an earlier chapter of this work in how Cosmos delivers high-performance virtual spaces.

Line chart of the CPU cost of a large call on the same Windows machine falling from 17% in March 2025 to 10% in February 2026 and 5% in July 2026

What this means for you

Focus on your work and collaborate with your team; keeping resource usage low is our job, and we do it so you never have to think about it. You open Cosmos in the morning, your team is there, and your machine stays yours: fans silent, battery intact, every other tool running at full speed.

You get everything Cosmos offers, from spatial conversations to 150-person all-hands, without your machine paying for it. Performance is not a feature we advertise; it is a promise we keep on schedule, every month. That is what it takes to build a virtual office you can live in all day.

Get started

Ready to try Cosmos Video?

See how a persistent virtual office changes the way your team works. Free for up to 4 concurrent users — no credit card, no time limits.

Tags

  • performance testing
  • virtual office performance
  • video call cpu usage
  • memory leak testing

Stay in the loop

Get the latest articles in your inbox. No spam, unsubscribe anytime.