Build plan shows 5 concurrent agent sessions, but only 1 live call works at a time

Agents
1

Hi,

I’m using LiveKit Cloud Agents on the free Build plan.

My project quota page shows:

  • Concurrent agent sessions: 5
  • Agents deployed on LiveKit Cloud: 1

But in practice only one live call works at a time.

What I’m seeing:

  • The first room works normally
  • The second room can still get a token, connect to LiveKit, and publish local mic
  • But the second room never receives agent boot events or avatar tracks
  • It eventually times out because the agent/avatar never joins that room

This only happens when another live call is already active.

In agent status I also see replicas shown as 1 / 1 / 1, so I’m not sure whether the deployment is actually able to run concurrent jobs even though the quota says 5 concurrent agent sessions.

Is 2 concurrent sessions supposed to work on Build in this situation, or is there another deployment/runtime limit I’m missing?

2

Useful hypothesis, but not yet proven:

  • The failure is likely in LiveKit Cloud runtime dispatch/scaling or Hedra concurrency, not in Wix/token/frontend.
  • However, “replicas 1/1/1 means only 1 concurrent session is possible” is not confirmed by official docs.
  • Official docs describe a worker-pool/job-subprocess model, and Build quota still shows 5 concurrent agent sessions.
  • So the real question is why a second room can connect and publish mic, but still never gets agent boot/avatar attached while another call is active.
3

If I look at your session history, it looks like all sessions in the last 48 hours (approx) have had 3 participants, the agent, the user, and the avatar.

So, perhaps you resolved this issue?

I didn’t look too deeply, but I also noticed you have two unnamed agents, one self-hosted and one hosted in LiveKit cloud. I’m unsure if that’s deliberate, but it’s uncommon as with automatic agent dispatch you can’t be sure which agent will take the session, Agent dispatch | LiveKit Documentation, so you would need to make sure these two agents are functionally identical to get consistent behaviour.

4

No, unfortunately.

We only tried self-hosting because we could not get it working with LiveKit Cloud hosting no matter what we tried. Even before setting up the self-hosted agent, we were unable to run more than one session at the same time.

5

Typically, a symptom like that is caused by reusing a room name rather than assigning a unique room to each call.

6

Hi LiveKit team,

We are writing from HeyGIA to look into a capacity issue on our plan (Scale). Our understanding is that we should have 500 channels (concurrent sessions), but in practice we are only able to sustain ~200 concurrent before seeing memory/CPU saturation on our workers, and we’ve already hit egress quota errors (TwirpError resource_exhausted) during load testing.

We’d appreciate your help with the following:

  1. Confirm whether 500 is the correct figure for our plan, and whether the ceiling we’re seeing (~200-250 actual) matches what you observe on LiveKit’s side for active rooms/sessions.
  2. Recommendations for memory/CPU sizing per worker, given the measured consumption (~500-680MB per active call, details below).
  3. Whether we need to expand the plan or a specific quota (e.g., concurrent egress) to sustain 500 real channels, or whether something is misconfigured or misbilled on our end.

We know most of this runs on LiveKit Cloud’s managed infrastructure without direct visibility into per-node CPU/RAM, which is why we’d rather review it together with you. We’re standing by, and happy to set up a call if that’s useful.

Additionally, I’ve attached the technical appendix of what we’ve reviewed with our technical team.

Technical appendix

  • Workers running on SDK defaults: src/server.py:374,2383-2384 doesn’t configure any resource or concurrency parameters (no job_memory_warn_mb, job_memory_limit_mb, num_idle_processes). Logs confirm this: memory_warn_mb: 500 / memory_limit_mb: 0, the SDK’s default values.
  • Constant memory pressure, not just during tests: last 10 days in CloudWatch: 3,721 “process memory usage is high” warnings, spread across several days (07/31 through today). Even normal calls already run at or above 500MB.
  • Load test peak (250 simultaneous calls, 07/31): 695 processes crossed 500MB within 15 minutes (peak 602MB) → estimated aggregate footprint of ~150GB of RAM for active call processes alone.
  • CPU saturation only under high load: 0 “process unresponsive” events in normal traffic (10 days); 418+153 events during the 200-250 concurrent test — this appears to be specific to high concurrency, not a baseline issue.
  • Additional dead weight: torch 2.12 in a CPU-only deployment pulls in ~2GB of unnecessary CUDA wheels that inflate baseline memory (evaluating a CPU-only wheel is still pending on our side).
  • Important note: we found a reporting bug in our dialer that undercounts sessions actually open on LiveKit (orphaned sessions that never close). This means the real ceiling we’re hitting today could be 300-400 actual sessions, not 200 — worth keeping in mind before simply asking for “more capacity.”
  • Cross-referenced source: consistent with plan-load-test-2026-07-31-200-slots.md (heygiaapidialerengine, 07/31).

What we’d propose asking for concretely: (1) raising the “concurrent egress sessions” quota, and (2) guidance on memory/CPU sizing per worker (~600MB/active call).

7

@jorge.melo I see you have a support ticket in the system and I also responded to your outage alert earlier.

It gets a bit difficult to coordinate support when you keep replying in different places.

You should have received a reply to your original email on August 10th to reply if the matter was urgent - I don’t see any response from yourself to that email, which is probably why the issue was not prioritized.

I apologise for the confusion.

It appears as though you have exceeded your concurrent egress and concurrent inference connection limits. Please see here, and request more:

https://cloud.livekit.io/projects/p_/settings