Thanks — I hear you: you see “current” and “draining” versions but new sessions sometimes land on the older (draining) agent. Here’s how to check which version is handling sessions and what to look for. How to check agent versions • Run

lk agent versions

to list deployed versions with timestamps and statuses (current, draining). • Tail runtime logs with

lk agent logs

and look for the string "draining worker" to confirm drain started and which instances are draining. • Use the Agent Console to inspect real‑time sessions (audio/events/metadata) and correlate session start times with deployment timestamps. Why new sessions might hit a draining instance • If drain hasn’t actually started yet (deployment still rolling), old instances can still receive new sessions. • A routing cutover delay or session‑affinity/dispatch configuration can cause new sessions to land on older instances. • Misconfigured agent names or dispatch rules can route sessions incorrectly. Quick troubleshooting steps 1. Confirm deployment finished and the old instance shows “draining” in

lk agent versions

. 2. Tail logs (

lk agent logs

) during session creation and verify new sessions are assigned to the new version and that you see "draining worker" entries on old instances. 3. Check dispatch configuration and any session affinity settings that might bind clients to specific agents. 4. Use Agent Console to map session start timestamps to the version timestamps from

lk agent versions

. If you want, share: • The output of

lk agent versions

• A snippet of relevant

lk agent logs

around a new session start • Any dispatch/agent name config With those I can help pinpoint whether the deployment hasn’t fully rolled or if routing/config needs adjustment. Sources: Deployment reliability on LiveKit Cloud | LiveKit | Deployment reliability on LiveKit Cloud | LiveKit | Where to find your Agent Logs | LiveKit | Agent dispatch | LiveKit Documentation | Debug voice agents in real time with Agent Console | LiveKit, with interactive elements