Why's it take ~6-8s to make a connection and have ...
# ask-ai
n
Why's it take ~6-8s to make a connection and have the agent join the room? How do you optimize this for fast connections?
✅ 1
t
Thanks for reaching out, William. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I hear you: you’re seeing ~6–8s before an agent is connected and joined, and you want to make that faster. Below I’ll explain the common causes and then give concrete ways to reduce the delay so connections feel near-instant. Why it can take 6–8s • Agent cold starts on the free Build plan can add several seconds when a new agent is spun up. • Explicit
CreateRoom()
calls add cross-region synchronization overhead, which increases room creation/join latency. • Network distance between the user, agent, and any AI services (STT/LLM/TTS) increases round-trip time and processing time. • Autoscaling or resource provisioning during sudden bursts causes extra delay if capacity needs to be created. • Sequential test/ramp behaviors (e.g., creating rooms only after the previous agent joined) can make joins appear slower during load testing. Actions to optimize and speed up joins 1. Avoid explicit room creation where possible ◦ Let rooms be auto-created when the participant joins with a valid token. This removes cross-region
CreateRoom()
synchronization delays. 1. Use instant-connect (capture & buffer) on the client ◦ Start capturing and buffering user audio immediately so the user experience isn’t blocked while the agent finishes joining. This reduces perceived latency and is supported in JS, Swift, Android, and Flutter SDKs. 1. Prevent cold starts (upgrade plan or keep workers warm) ◦ Cold-start delays are common on the free Build plan. Upgrading to a paid plan or keeping agent workers warm reduces spin-up latency. 1. Place agent workers near AI services and users ◦ Deploy agents in the same region as your LLM/STT/TTS providers and as close to your users as practical to reduce network RTT. 1. Run multiple agent workers / ensure HA for agents ◦ Have multiple workers with the same
agent_name
so dispatch can pick an already-ready worker instead of waiting for one to start. This avoids dispatch failures and long waits. 1. Use dedicated resources and monitor utilization ◦ Run agents on dedicated servers (avoid other heavy workloads) and instrument resource usage to ensure CPU/memory/network aren’t bottlenecks. 1. Test with realistic ramp-up and autoscaling in mind ◦ Avoid huge instant bursts in load tests. Ramp up gradually so autoscaling can keep up and you measure realistic join times. 1. Monitor and inspect join metrics ◦ Use Agent Observability and your monitoring tools to track where time is spent (room creation, token exchange, signaling, STT/LLM/TTS calls). Target the largest contributors first. If you’d like, I can help further — tell me: • Are you using explicit
CreateRoom()
or relying on auto-create? • Which SDK/platform is your client (JS, Android, iOS, Flutter)? • Are your agent processes running in the same region as your AI services? With those answers I’ll recommend the highest-impact changes for your setup. Sources: Understand and Improve Agent Latency | LiveKit | CreateRoom() is taking too long | LiveKit | How to load test voice agents and get meaningful results | LiveKit | Agent speech and audio | LiveKit Documentation | examples/drive-thru | livekit/livekit_composite | DeepWiki, with interactive elements