Hi — we're on the Ship plan (20-session cap) and seeing a pod-sizing / autoscaler issue that's killing sessions well under our plan cap. Project:

commandiq

(subdomain

commandiq-6ek744bb

) Agent:

CA_YHsMYA66ykvG

Pod:

deployment-p-6c3dvi560ji-ca-yhsmya66ykvg-699d9fcc59-tblcq

Timestamp of incident: 2026-04-22 130931 UTC (epoch 1776877771) What we ran: 5 concurrent agent sessions, each ~10 min, started within seconds of each other. Our per-session memory overhead is small (~30-40 MB). What we observed in our own agent logs: - All 5 sessions were dispatched to the same single pod (only one hostname in the log throughout) - Pid=1 supervisor logged

process memory usage is high

at 530 MB (warnMB=500) - ~2 seconds later, all 5 sessions reported

room_disconnected

simultaneously (session durations 131-137s) - No "registered worker" / second hostname appeared — i.e. a second pod was never provisioned What we expected: With a 20-session cap, we assumed LiveKit's scheduler would start spreading sessions across multiple pods before single-pod memory hit the SDK's warning threshold. Questions: 1. Is the scheduler supposed to provision additional pods before a single pod hits the memory-warning threshold? If yes, why didn't it here? 2. What's the documented "sessions-per-pod" target on Ship-tier pods? Is there a way for us to see or influence this? 3. Are Ship pods significantly larger than Build pods memory-wise, or is the plan cap raised without a proportional pod-size increase? Happy to share full agent logs, Playwright reproduction, or hop on a call. Our 3-concurrent runs are clean; 5-concurrent is 0/5 because of this pod-packing behavior.

Hi chris, ⚠️ This channel will be deleted soon ⚠️ Please use our new community at https://community.livekit.io for technical discussions and to post technical questions. The Slack community is not going away, but we are migrating technical questions to our new forum. Please see full details here.