Build plan deployed agent stays Sleeping after successful CreateDispatch

I’m trying to understand expected behavior for LiveKit Cloud deployed agents on the Build plan when the agent is in the Sleeping state.

I’m aware of the documented cold-start behavior. The quotas/limits docs say Build-plan projects may shut down deployed agents after active sessions end, and that the agent should automatically start again when a new session begins. The docs mention this can add up to 10-20 seconds before the agent joins the room.

What I’m seeing is different: once the agent is Sleeping, I have not been able to get it to wake from CreateDispatch.

Flow:

  1. A backend service calls AgentDispatchService/CreateDispatch using the official Python SDK.
  2. The request includes:
    • agent_name
    • room
    • JSON metadata
  3. The project setting “Automatically create rooms on participant join” is enabled.
  4. CreateDispatch succeeds immediately and returns a dispatch ID.
  5. The room exists and can be probed.
  6. The backend polls ListParticipants for 120 seconds.
  7. The room remains empty for the entire 120 seconds.
  8. No agent participant ever joins.
  9. No SIP participant is created; this failure happens before telephony.
  10. The deployed agent remains in Sleeping state.

I also tested a no-phone diagnostic dispatch using heartbeat-style metadata. Same result:

  • CreateDispatch succeeds
  • Room exists
  • Participants stay at 0 for 60 seconds
  • Agent remains Sleeping

When I try to fetch agent deploy logs after this, the CLI returns:

failed to get logs: The agent has shut down due to inactivity. It will automatically start again when a new session begins.

That message suggests a new session should wake the agent, but in practice CreateDispatch appears to create the dispatch/room without waking the deployed agent.

Earlier, before enabling auto-create rooms, CreateDispatch returned not_found: requested room does not exist. Enabling auto-create fixed that part: dispatch now succeeds on the first attempt. But it exposed this second problem, where successful dispatch does not wake the Sleeping agent.

Questions:

  • On the Build plan, should CreateDispatch reliably wake a Sleeping deployed Cloud agent?
  • Is there another documented API or workflow required to wake a Sleeping agent before dispatch?
  • Is this expected Build-plan behavior, or should the agent join after the documented 10-20 second cold start?
  • Are there project settings, quotas, or deployment states that can cause dispatches to be accepted but never assigned to a worker?
  • Is the only reliable solution to upgrade to Ship for cold start prevention?

I can share project ID, agent ID, dispatch IDs, room names, and UTC timestamps privately with LiveKit staff if useful.

What is your agent id?

Just looking at your list of sessions, I notice that all sessions since 30th May have had an agent join, I wonder if you changed anything (I notice there was also an agent redeployment over the weekend.)

We had an exchange in DMs but for anyone reading this … I didn’t do anything different but my agent dispatch is now successfully waking a sleeping agent so far many times. So we must assume that Livekit addressed this issue behind the scenes which is awesome!

Thanks for the update, I do still need to follow up with the team to see what as I know this wasn’t an isolated report