The AI agent stopped responding in middle of call. I see these logs

17 April 2026, 16:47
{"message": "closing agent session due to participant disconnect (disable via `RoomInputOptions.close_on_disconnect=False`)", "level": "INFO", "name": "livekit.agents", "room": "371007ad-95f9-4120-9faf-47f658ebd83e", "participant": "user-user-test-1@ext.vanilabs.ai", "reason": "CLIENT_INITIATED", "pid": 22055, "job_id": "AJ_DwaC5dp5kFx7", "room_id": "RM_Y4srKDfHRz3b", "timestamp": "2026-04-17T11:17:44.684968+00:00"}
0ad8c18e5324489abae198320919cb09
insurance-worker
17 April 2026, 16:47
{"message": "STT metrics", "level": "INFO", "name": "livekit.agents", "model_name": "saarika:v2.5", "model_provider": "Sarvam", "audio_duration": 2.04, "pid": 22055, "job_id": "AJ_DwaC5dp5kFx7", "room_id": "RM_Y4srKDfHRz3b", "timestamp": "2026-04-17T11:17:41.415766+00:00"}
0ad8c18e5324489abae198320919cb09
insurance-worker
17 April 2026, 16:47
{"message": "EOU metrics", "level": "INFO", "name": "livekit.agents", "model_name": "unknown", "model_provider": "stt", "end_of_utterance_delay": 0.55, "transcription_delay": 0.0, "pid": 22055, "job_id": "AJ_DwaC5dp5kFx7", "room_id": "RM_Y4srKDfHRz3b", "timestamp": "2026-04-17T11:17:40.303519+00:00"}
0ad8c18e5324489abae198320919cb09
insurance-worker
17 April 2026, 16:47
{"message": "LLM metrics", "level": "INFO", "name": "livekit.agents", "model_name": "gpt-5.2", "model_provider": "api.openai.com", "ttft": 0.8, "prompt_tokens": 0, "prompt_cached_tokens": 0, "completion_tokens": 0, "tokens_per_second": 0.0, "pid": 22055, "job_id": "AJ_DwaC5dp5kFx7", "room_id": "RM_Y4srKDfHRz3b", "timestamp": "2026-04-17T11:17:14.197786+00:00"}
0ad8c18e5324489abae198320919cb09
insurance-worker
17 April 2026, 16:47
{"message": "STT metrics", "level": "INFO", "name": "livekit.agents", "model_name": "saarika:v2.5", "model_provider": "Sarvam", "audio_duration": 3.64, "pid": 22055, "job_id": "AJ_DwaC5dp5kFx7", "room_id": "RM_Y4srKDfHRz3b", "timestamp": "2026-04-17T11:17:14.189969+00:00"}
0ad8c18e5324489abae198320919cb09
insurance-worker
17 April 2026, 16:47
{"message": "EOU metrics", "level": "INFO", "name": "livekit.agents", "model_name": "unknown", "model_provider": "stt", "end_of_utterance_delay": 0.55, "transcription_delay": 0.0, "pid": 22055, "job_id": "AJ_DwaC5dp5kFx7", "room_id": "RM_Y4srKDfHRz3b", "timestamp": "2026-04-17T11:17:13.052918+00:00"}
0ad8c18e5324489abae198320919cb09
insurance-worker
17 April 2026, 16:47
{"message": "STT metrics", "level": "INFO", "name": "livekit.agents", "model_name": "saarika:v2.5", "model_provider": "Sarvam", "audio_duration": 1.52, "pid": 22055, "job_id": "AJ_DwaC5dp5kFx7", "room_id": "RM_Y4srKDfHRz3b", "timestamp": "2026-04-17T11:17:09.138377+00:00"}
0ad8c18e5324489abae198320919cb09
insurance-worker
17 April 2026, 16:47
{"message": "EOU metrics", "level": "INFO", "name": "livekit.agents", "model_name": "unknown", "model_provider": "stt", "end_of_utterance_delay": 0.5, "transcription_delay": 0.0, "pid": 22055, "job_id": "AJ_DwaC5dp5kFx7", "room_id": "RM_Y4srKDfHRz3b", "timestamp": "2026-04-17T11:17:08.394835+00:00"}
0ad8c18e5324489abae198320919cb09
insurance-worker
17 April 2026, 16:47
{"message": "STT metrics", "level": "INFO", "name": "livekit.agents", "model_name": "saarika:v2.5", "model_provider": "Sarvam", "audio_duration": 4.56, "pid": 22055, "job_id": "AJ_DwaC5dp5kFx7", "room_id": "RM_Y4srKDfHRz3b", "timestamp": "2026-04-17T11:17:07.892134+00:00"}
0ad8c18e5324489abae198320919cb09
insurance-worker
17 April 2026, 16:46
{"message": "STT metrics", "level": "INFO", "name": "livekit.agents", "model_name": "saarika:v2.5", "model_provider": "Sarvam", "audio_duration": 1.27, "pid": 22055, "job_id": "AJ_DwaC5dp5kFx7", "room_id": "RM_Y4srKDfHRz3b", "timestamp": "2026-04-17T11:16:38.816578+00:00"}
0ad8c18e5324489abae198320919cb09
insurance-worker
17 April 2026, 16:46
{"message": "TTS metrics", "level": "INFO", "name": "livekit.agents", "model_name": "chirp_3", "model_provider": "Google Cloud Platform", "ttfb": 0.15450423897709697, "audio_duration": 34.96, "pid": 22055, "job_id": "AJ_DwaC5dp5kFx7", "room_id": "RM_Y4srKDfHRz3b", "timestamp": "2026-04-17T11:16:24.600258+00:00"}

When I look at timestamp, there was an LLM event but no TTS event so LLM generated a response but TTS did not speak

Thanks for reaching out, Abhishek. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

The participant did not leave. The disconnection happened multiple seconds after bot stopped responding

Thanks — that helps. I’m following up about why the agent stopped responding even though the participant stayed connected. Quick diagnosis • The log shows a session close with reason

CLIENT_INITIATED

, but that can happen for reasons other than the participant intentionally leaving (e.g., a session timer, programmatic shutdown, or an internal error). When the session begins closing it can halt TTS before audio plays, which explains an LLM metric without downstream TTS metrics. To help narrow this down, please answer: 1. Which SDK are you using (Node.js or Python)? 2. Do you have any custom shutdown/timer logic, retries, or job timeouts in your agent code? 3. Can you paste (or share) any log lines immediately before and after the LLM metrics timestamp (around 2026-04-17T111714 and up to 111745)? Look for errors, shutdown calls, or SIGTERM messages. 4. Do you see any TTS-related error logs (failed synth, TTS provider errors) or network errors around that time? What I’ll do next • Once you share the SDK and the surrounding logs, I’ll point to the exact places to check and provide a short code snippet to either: ◦ keep the session open to finish TTS, or ◦ perform a draining shutdown so TTS completes before closure. If you prefer, paste the additional logs here and I’ll review them. Sources: Agent session | LiveKit Documentation | Job lifecycle | LiveKit Documentation | Deployment reliability on LiveKit Cloud | LiveKit | Build a salary negotiation coach with a LemonSlice avatar | LiveKit | Build a salary negotiation coach with a LemonSlice avatar | LiveKit, with interactive elements

There are no logs between that LLM and EOU log. Those were continuous logs. Why there was so long diff between the 2? No error, no logs in that duration

Thanks — I hear your frustration. You're asking why there’s a long silent gap after the LLM log with no TTS or error logs. Possible causes to investigate • The agent may have been waiting on TTS synthesis or an external TTS provider call that hung or timed out without emitting an error. • The agent could have been stuck in a background task (e.g., waiting for a resource, lock, or network I/O) so no pipeline logs were produced while LLM → TTS handoff awaited completion. • A programmatic shutdown/drain signal or internal flag (e.g.,

self._draining = True

from a SIGTERM or shutdown call) might have been set without logging details, preventing TTS from starting. • The LLM response could have been partial/streamed and the agent was waiting for completion or post-processing before invoking TTS. Quick checks I recommend right now 1. Confirm SDK (Node.js or Python). 2. Search logs for any process-level signals or shutdown calls (SIGTERM, ctx.shutdown, session.shutdown, aclose) within ~1 minute after 111714. 3. Check TTS provider logs/requests around that time — does the TTS service receive a request? Any slow/failed HTTP calls? 4. Check for thread/blocking issues: are there any long GC pauses, blocked worker threads, or thread pool exhaustion metrics? 5. Inspect agent-side timeouts (LLM/TTS request timeouts, overall job timeout, session timers) and any retry/backoff logic that could pause the pipeline silently. If you want, share: • SDK (Node or Python), and any shutdown/timer code or job timeout values. • TTS provider logs or HTTP traces for that job_id (AJ_DwaC5dp5kFx7). • Any process-level logs (SIGTERM, resource warnings, GC pauses) within the minute after 111714. Tell me which of those you can pull and I’ll point exactly where to look and what snippet to add to capture the blocked/timeout event. , with interactive elements

node sdk - 2.17.0, no shutdown logic. No sigterm logs

Thanks — I see you’re on the Node SDK v2.17.0 with no shutdown logic and no SIGTERM logs. I’ll explain why a long silent gap can happen and give focused diagnostic steps you can run now. Why you might see an LLM log then a long gap with no TTS/error logs • TTS request hung or timed out: the agent may have sent a TTS request to the provider and the provider or network stalled without returning an error or timing out the request in your app-level logs. • Blocking or waiting in the agent process: the handoff from LLM → TTS may have blocked on IO, a locked resource, or a worker thread (so no new logs appeared while waiting). • LLM completion was partial/streamed and the agent waited for final output or post-processing before invoking TTS. • Silent internal state change: an internal drain flag or job-state transition (not logged at your level) could have prevented TTS from starting even though the LLM step completed. • TTS metrics not emitted: TTS may have run but its metrics/log emission failed (e.g., log flush issue), leaving only the earlier LLM entry. Practical diagnostics to run now (ordered — do the first items and report results) 1. Enable verbose SDK and network logging for a short window around reproductions: ◦ Set LiveKit agent logger to debug (capture timestamps for each pipeline stage). ◦ Capture outgoing HTTP requests/responses to your TTS provider (headers, request IDs, timestamps). 1. Search provider logs for job_id AJ_DwaC5dp5kFx7 — confirm whether a TTS request was received and its timing. If the provider never received a request, the handoff stalled before network call. 2. Add short instrumentation around the LLM→TTS handoff in your agent code: ◦ Log when LLM result is enqueued for TTS, when the TTS request is sent, and when TTS response completes/fails. ◦ Example pattern: ▪︎ "LLM->TTS enqueue at ts" ▪︎ "TTS request sent at ts (request id: ...)" ▪︎ "TTS response at ts status: ..." 1. Reproduce and capture process-level traces during the gap: ◦ Enable async/worker stack traces or a short pprof/CPU profile to detect blocking (if Node: inspect event loop lag, blocked timers, or worker thread exhaustion). ◦ Log event loop lag (e.g., using node's async_hooks or perf_hooks) to detect long blocking operations. 1. Verify timeouts: ◦ Confirm SDK-level and provider-level timeouts for LLM → TTS calls. If none set, add conservative timeouts so hangs produce errors you can log. 1. If reproducible, run with close-on-disconnect disabled and use draining to avoid session state changes interfering: ◦ Set

RoomInputOptions.closeOnDisconnect = false

or ensure you call `await ctx.waitForPlayout()`/`session.shutdown({ drain: true })` to let TTS finish. (This won’t fix the root cause but prevents session closure from masking the issue.) 1. Check logs around resource limits: ◦ Worker pool exhaustion, memory pressure, or GC pauses can cause large gaps without explicit errors. What I can do next for you • If you paste the small added logs you get from step 3 around the LLM→TTS handoff, I’ll interpret them and point to the exact failure mode. • If you can share whether the TTS provider shows any incoming request for job_id AJ_DwaC5dp5kFx7, tell me the timestamps and I’ll help map where the pipeline stalled. Would you like the minimal debug-snippet to add to your Node agent for the LLM→TTS handoff and event-loop lag measurement? , with interactive elements