hi vapi support! i'm trying to figure out why we are experiencing a few different issues on our long (30-45 minute) expert interview calls: 1) long assistant silences of up to ~30 seconds or more before answering 2) audio cutting in and out on the recording after about the ~15 minute mark representative call id: 019c5090-5290-799f-9ac2-9e2cc71f598b - at 2:17:12 ish the caller is done talking. - at 2:17:22 i see an Azure OpenAI HTTP request (not sure why Azure, we don't use that) - model output begins at 2:17:24.001 ("That...") - cartesia voice request at 02:17:24.614 - cartesia "first audio received" at 02:17:24.817 - azure openai http response at 2:17:25.617 consisting of "That makes sense. Given that desire to avoid lock‐in, how consciously do you design your architecture to keep the option open to switch providers? What abstractions or safeguards do you put in place to make a change feasible if you ever needed to move off Exa?" so that message, i interpret, as being what our assistant wants to ask, and it seems like we're calling cartesia to do so. but its not until the 2:18:05.5~ point that there's anything actually audible on the recording and its our agent asking, "What would you want to do differently in the product once you can reliably detect agent traffic?" which is a completely different question. it was in listening closer to the actual recording that i noticed how bad it sounds—the audio from the interviewee is cutting out so much that it's hard to really make sense of what's being said. i looked across a bunch of our other calls and it's the same way, they always get choppy after the ~10-15 minute mark. i've been thinking that our issues are related to 1) our large system prompt OR 2) our TTS provider, but it seems like the LLM is generating the response pretty quickly even on these later turns (fast enough for our purposes at least) and it seems like vapi is 'generating' audio in some sense (because right after the cartesia "audio is received" there's even a bunch of deepgram logs recording that the agent's lines are being transcribed). so i'm not sure what's going on. if there's something i should modify in our assistant settings, what might that be? and if there isn't, what would be the best way to mitigate? i've been experimenting with 1) using handoffs upon x duration of agent silence to move the convo to a new assistant, and 2) completely stopping the call upon x duration of silence and just generating a new assistant that has the previous partial transcript in context so the user can pick up their interview where they left off. better solutions?

because once the time increase the info LLM needs to process increases, that cause high latency issue and more hallucination This is nothing to do with Vapi

Hi from what you’ve shared, this looks much more like a long-session media/stream stability issue than an LLM latency problem. When calls run past 10–15 minutes, WebRTC or audio sockets can degrade, partially reconnect, or desync, which leads to delayed playback, mismatched TTS, and choppy recordings even though the model and TTS are responding on time. The fact that Cartesia and Deepgram are still firing normally suggests generation is working, but delivery to the call stream isn’t staying stable. I’d focus first on checking for silent reconnects, buffer overflows, keepalive timeouts, or stream resets in your logs, and also verify your max call duration, idle timeouts, and whether your ASR/TTS sessions are being recycled mid-call. Handoffs can help as a workaround, but stabilizing the underlying media session will give you much better reliability long-term. Could you share your current call timeout limits, TTS/ASR providers, and whether you see any reconnect or transport warnings around the 10–15 minute mark? @jan

thanks! here's what we're seeing on the log: config: - silenceTimeoutSeconds: 120 - maxDurationSeconds: 3620 - webhook timeoutSeconds: 20 - TTS: Cartesia (sonic-3), fallback 11labs - ASR: Deepgram (nova-3), fallback OpenAI what we see in timeline: - 10–25 min window: - one hang event at +12:43 - one endpointing timeout warning at +15:15 - no websocket connect/disconnect/status-change events in this window - Full call: - websocket connect at start and disconnect at teardown only - hang events cluster later (~34m+) - endpointing timeout warnings cluster heavily in ~30–45m - two conversation-update webhook timeouts around +41:00 (20s timeout exceeded) fyi these calls are all web calls just through a Vapi widget on our site (https://docs.vapi.ai/assistants/examples/voice-widget)

Thanks, this helps a lot, your config is solid, and the pattern points to long-session stream degradation, not an LLM issue. The endpointing timeouts and late webhook delays show the audio pipeline is slowly falling behind after ~20–30 minutes, which causes desync, silence, and choppy playback even though TTS/ASR are still running. This is more common in browser-based widget calls where WebRTC sessions degrade over time. The most reliable fix is to proactively refresh or hand off the session around 20–25 minutes, tune endpointing to be more aggressive later in calls, and test periodic ASR/TTS re-initialization to prevent buildup. We’ve helped teams stabilize long interviews using this segmented approach while preserving full context. If you’d like, I can walk you through the exact setup privately and help you implement this cleanly. @jan