full-terabyte-95216
03/20/2026, 6:53 PMtall-airline-16756
03/20/2026, 6:53 PMtall-airline-16756
03/20/2026, 6:53 PMon_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