I have a lot of failed calls, and I noticed for ea...
# ask-ai
f
I have a lot of failed calls, and I noticed for each failed call, there still is an openai request. Is this the prewarm function? Does it send only to llm to create a cache session, or to the tts? If I don't use prewarm, are there any downsides besides a slightly higher delay before the first answer?
✅ 1
t
Thanks for reaching out, Alexandru. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — this is a great question. I’ll respond to each part you asked about. Acknowledging your point: you’ve seen failed calls where an OpenAI request still happens, and you’re wondering whether that comes from the prewarm function and whether prewarm targets LLM or TTS, plus what happens if you don’t prewarm. Quick answers • Prewarm does NOT send requests to OpenAI (LLM) or to TTS providers. • Prewarm is used to load heavyweight local models (for example, VAD) into the process memory so they’re ready when a session starts. • If you don’t prewarm, the main downside is a higher first-interaction latency while the model loads. It does not change LLM/TTS API usage by itself. Why you’re seeing OpenAI requests on failed calls • Those OpenAI requests are not from prewarm. They’re likely caused by LLM initialization or an early LLM call that runs when the agent/session starts (for example in
on_enter
,
entrypoint
, or as part of session setup). • If the session fails after the LLM is already initialized or an initial prompt was sent, you’ll still see outbound OpenAI requests even though the call ultimately failed. What prewarm actually does • Runs once per process before agent sessions begin and loads local models (e.g., VAD) into
proc.userdata
for reuse across sessions. • Improves readiness for audio processing and turn-taking by avoiding cold-start model load on the first audio. • Does not initialize LLM sessions, cache LLM responses, pre-load TTS services, or make outbound API calls to OpenAI/third parties. Practical recommendations • Keep VAD and other heavy local models in prewarm to avoid cold-start latency for the first user turn. • If you want to avoid unnecessary OpenAI requests on failed calls, review where the LLM or any outbound calls are triggered: ◦ Move LLM initialization or the first API request to a point after the call/room join is verified (i.e., only initialize the LLM when you’re certain the call will proceed). ◦ Ensure `on_enter`/`entrypoint` logic does not unconditionally call LLM/TTS before the connection is confirmed. • If you need, I can help you identify likely spots in your session code (e.g.,
on_enter
,
entrypoint
, or early tool calls) that commonly trigger LLM requests and suggest how to condition them. If you want, share a short snippet of where you initialize the LLM or your session entry logic and I’ll point out where to gate that initialization so failed calls don’t trigger API calls. Sources: Server options | LiveKit Documentation | LLM Metrics | LiveKit Documentation | LLM-Powered Content Filter | LiveKit Documentation | LLM Output Replacement | LiveKit Documentation | Pipeline Translator Agent | LiveKit Documentation, with interactive elements