Why do agents on free plans tend to go to sleep and then not wake back up when requested by name for dispatch?

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.

lol bot agents, not humans. my mobile client connecting to the agent. this is a lot of questions, it's clearly lk putting the container to sleep and not waking it back up, but its causing issues because non-prod is not on a paid plan but we still need it for testing.

Thanks — that helps a lot. You’re seeing bot agent containers on the free plan sleep and then fail to wake when your mobile client dispatches them by name. You’re right: free-tier agent containers can go to sleep and that can prevent them from accepting dispatches until they’re woken (or kept warm). Here’s what’s happening and what you can do right away. Why this happens • Free “Build” plan containers may sleep after inactivity to conserve resources. A sleeping container cannot accept incoming dispatch requests, so a named dispatch from your mobile client either times out or fails until the container wakes. • Paid plans include “always warm” containers that avoid these cold starts, so paid environments reliably accept dispatch requests immediately. Immediate workarounds for testing (no plan change) • Keep agents warm during test windows by sending periodic pings or health-check requests so containers don’t drop into sleep. • Before running tests, proactively “pre-warm” the agent by triggering a lightweight request (for example, an authenticated heartbeat or a small status API call) a minute or two before you need the agent to accept sessions. • If possible, avoid relying on name-based real-time dispatch for critical test flows; instead, use a polling or retry strategy in the mobile client so it retries until the agent wakes. Recommended long-term solutions • Move non-prod testing to a paid plan tier that provides always-warm containers to eliminate cold-start wake failures. This is the most reliable way to match production behavior for integration and QA testing. • Add a brief retry/backoff flow in the client when dispatch fails due to agent unavailability, and log the failure reason and timestamps so you can correlate with container sleep events. If you want, I can: • Suggest a minimal heartbeat/ping pattern you can implement from your mobile client to keep an agent warm during tests. • Outline a simple retry/backoff sequence for dispatch attempts and what client-side logs to capture to diagnose wake problems. Which would you prefer — a sample heartbeat pattern, a retry strategy, or both? Sources: Pricing | LiveKit | LiveKit Platform | Build, run, and observe voice AI agents | LiveKit | Agent dispatch | LiveKit Documentation | Deploy and scale agents on LiveKit Cloud | LiveKit, with interactive elements