Hey y'all. When performing a phone call, I've noticed that sometimes, the session will randomly seize up, taking upwards of 20s to start replying to me again. Wondering if I'm just doing something very dumb, or if there's some reason for this? In this session (

019d0dea-311c-7000-b767-f7fc9076cece

), you can see that roughly 3:25 in the user stops speaking, but there is no model output until almost 3:46. Would really appreciate any help you can offer! https://cdn.discordapp.com/attachments/1484728584584036362/1484728584802406561/Screenshot_2026-03-20_at_18.39.16.png?ex=69bf48bf&is=69bdf73f&hm=27c4fb3be7682826ac89cf3f081e1b4aadcef548991bb3be87ccb627683223aa&

The latency spike is likely due to relying on transcriber end-of-turn (EOT) detection when LiveKit smart endpointing is disabled, which can cause long waits. To reduce this delay, enable smart endpointing with LiveKit in your configuration:

json
{
  "startSpeakingPlan": {
    "smartEndpointingPlan": {
      "provider": "livekit",
      "waitFunction": "2000 / (1 + exp(-10 * (x - 0.5)))"
    },
    "waitSeconds": 0.4
  }
}

This setup enables fast, accurate endpointing and should resolve the random latency spikes. For more details, see the [Voice pipeline configuration documentation](https://docs.vapi.ai/customization/voice-pipeline-configuration). Source: - [Voice pipeline configuration](https://docs.vapi.ai/customization/voice-pipeline-configuration)

Hey disclaimer I'm just a fellow builder and VAPI may have better input - but from the SS you shared it looks like there is periodic audio coming through which will cause the start speaking 'counter' to reset. If the audio isn't from the customer, it's likely noise or other artifacts coming through - you could try: - Background denoising enabled (Could reduce transcription quality) - Increase confidence threshold Just snippets I've found from building myself, not looking to sell services but feel free to ask Q's

Hi, Thanks for the detailed report — I looked into call

019d0dea

and found what's causing the delay. The ~20 second pause (actually ~31 seconds in this case) is caused by your primary model returning empty responses several times before finally succeeding. Your fallback model never kicks in during this because the responses technically come back as valid — just with no content — so the system keeps retrying the primary instead of escalating to the fallback. This is a platform-side limitation rather than anything you're doing wrong. Workaround in the meantime: if reliability is critical, try swapping GPT-4o as your primary model. It's more consistent and should avoid the empty response issue. We're aware of this and working on improving how empty responses are handled. Let me know if you have any other questions!

Thanks a lot Shaunak! That makes sense. Appreciate the quick turnaround 🙂

No worries! If you face any further issues, feel free to create a new ticket.