We are in build plan. We are developing our outbou...
# ask-ai
r
We are in build plan. We are developing our outbound calling agent and deployed to LK cloud. But It stops accepting call dispatches by going to sleeping state after some inactive period and the only way to recover is to delete the agent and redeploy — it then works for a while before going sleeping state again. Is there a workaround beyond redeploy?
✅ 1
t
Thanks for reaching out, Hariram. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I hear you: your outbound calling agent on LiveKit Cloud goes to a sleeping state after inactivity and only recovers when you delete and redeploy. That’s frustrating; let’s look at options. Short answer: • On LiveKit Cloud, agents on build/free tiers can scale to zero (go “sleep”) after idle periods. The reliable way to prevent this is to keep agents warm — which is supported on paid plans. • There isn’t a documented configuration that prevents scale-to-zero on build plans. Workarounds you can try now: • Keep the agent warm with periodic keep-alive traffic (a lightweight request or call heartbeat) at an interval shorter than the idle timeout so the instance never scales to zero. • If possible, schedule a small background job or cron that makes an authenticated API/connection attempt to the agent regularly. • Upgrade to a paid plan so agents remain warm and avoid cold starts/sleeping. If you want, tell me: • which plan you’re on (build/free vs. paid), and • whether you can run a periodic keep-alive from your infra; I’ll help pick the easiest keep-alive approach and give concrete steps. Sources: Deployment reliability on LiveKit Cloud | LiveKit, with interactive elements
r
But it used to restart when a new call has been dispatched when it was in sleeping state. Why it is not working now? Any idea on this? community issue link: https://community.livekit.io/t/livekit-agent-dispatch-issue-hosted-on-livekit-cloud/811/7
t
Thanks — I hear you: you expect agents to auto‑wake on a new call (as they used to), but now they stay sleeping and only recover after redeploy. Let’s narrow this down. What changed and why this can happen • LiveKit Cloud’s scaling behavior changed: older behavior could wake a sleeping agent on dispatch, but current build/free plan behavior can let agents scale to zero and not reliably auto‑wake on incoming dispatches. Paid plans keep agents warm so they reliably accept dispatches. • That community thread matches this behavior: auto‑wake on dispatch is no longer reliable on sleeping instances in the cloud plan you’re on. Quick checks for me to help further 1. Which LiveKit Cloud plan are you on (build/free or paid)? 2. Did anything change recently in how you dispatch calls (different API/headers, auth tokens, or dispatching endpoint)? 3. Can you add a periodic keep‑alive (a lightweight authenticated request) from your infra to the agent to prevent it scaling to zero? Practical next steps you can try now • Implement a periodic keep‑alive ping (simple authenticated HTTP/WebSocket connect) at an interval shorter than the idle timeout to keep the agent warm. • If keep‑alives aren’t possible, consider upgrading to a paid plan so agents remain warm and reliably accept dispatches. If you share your plan and whether you can run keep‑alives, I’ll provide a concrete keep‑alive example and suggested interval. , with interactive elements
r
Can you please provide me some details on the idle time for the agent deployed to LK cloud in build plan?
t
Thanks — I hear you want the exact idle time for agents on the LiveKit Cloud Build plan. Short answer: • There is no documented fixed idle timeout for general agent instances on the Build plan. Instead, Build plan agents are subject to auto-scaling to zero (cold starts) after inactivity, which effectively puts them to sleep and prevents reliable auto‑wake on dispatch. • The only explicit
idle_timeout
documented (60 seconds) applies to LemonSlice avatar sessions, not standard outbound calling agents. What you can do: • Keep the agent warm with periodic authenticated keep‑alive pings (a lightweight HTTP/WebSocket connect) at an interval shorter than your observed sleep period. • Or upgrade to a paid plan — paid plans keep agents warm and avoid cold starts. If you’d like, tell me which plan you’re on and how long the agent stays responsive after activity; I’ll recommend a concrete keep‑alive interval and an example ping. Sources: LemonSlice virtual avatar integration guide | LiveKit Documentation | Understand and Improve Agent Latency | LiveKit | Understand and Improve Agent Latency | LiveKit | Towards a future-aligned pricing model | LiveKit | Towards a future-aligned pricing model | LiveKit, with interactive elements
r
Is there any release or announcement link regarding the auto‑wake on dispatch is no longer reliable on sleeping instances in the cloud build plan?
t
Thanks — I hear you: you want an official release or announcement saying auto‑wake on dispatch was changed for Build plan agents. Short answer: • There is no specific release note or announcement that says auto‑wake on dispatch was intentionally disabled. • The behavior you’re seeing matches the documented platform design: Build plan agents can scale to zero (cold start) after inactivity, and cold starts can prevent reliable auto‑wake on dispatch. Paid plans keep agents warm and avoid this. Relevant links: • Deployment reliability / scaling to zero: https://livekit.com/blog/deployment-reliability-cloud • Agent platform / plan differences: https://livekit.com/products/agent-platform If you want, tell me which plan you’re on and how long agents stay responsive after activity — I’ll recommend a concrete keep‑alive interval and give a short example you can implement. Sources: Deployment reliability on LiveKit Cloud | LiveKit | LiveKit Platform | Build, run, and observe voice AI agents | LiveKit, with interactive elements