Thanks — I’ll respond to your request for production-ready CPU and RAM sizing for a LiveKit agent running in Docker. Recommended baseline • CPU: 4 vCPUs (use compute-optimized instances like AWS c5/c6i rather than burstable types) • RAM: 4 GB How to scale from the baseline • Expect ~100 MB RAM per concurrent conversation; increase RAM proportionally to expected concurrency. • A single worker with the baseline config typically handles ~5–10 concurrent conversations; add more workers behind a load balancer for higher concurrency. • If your agent performs local model inference (turn detection, STT/TTS), increase CPU and RAM to reduce latency (consider 6–8 vCPUs and 8+ GB RAM for heavier workloads). Operational advice • Pre-download models during your Docker build to reduce startup latency. • Monitor CPU usage, memory, STT→response latency, and connection counts; adjust instance size or worker count based on those metrics. • Prefer multiple smaller workers over one very large instance to improve isolation and restart behavior. If you tell me your expected concurrent sessions, whether you run STT/TTS locally, and your cloud provider, I’ll give a concrete instance type and Docker resource limits (CPU/memory) to use. Sources: Troubleshooting Latency and Timeout Errors with Turn Detection on AWS | LiveKit turn detector plugin | LiveKit docs | examples/drive-thru | livekit/livekit_composite | DeepWiki | examples/survey | livekit/livekit_composite | DeepWiki | Self-hosting the Ingress Service | LiveKit docs