My voice agent is taking ages to respond. I've gone through logs and can't really identify why. Call ID: 019d1b5e-866a-7000-9d4a-1c0e5ae97942 Call ID: 019d1b5c-d61f-7001-8178-721e253216ca This one had very long response time for the first 2 turns "019d1b61-76bd-7000-a56c-92c3f9cefbad"

Slow response times in voice agents are usually a layered problem I've debugged a few of these and it's rarely just one thing. Often it comes down to where latency is accumulating: STT processing, LLM first-token time, or TTS buffering, and the culprit isn't always obvious from surface-level logs. Happy to take a look at what you're seeing if you want to share more about your stack or pipeline setup. @Hugo

same with this one doesn't respond at first then does: 019d1b61-76bd-7000-a56c-92c3f9cefbad

That pattern latency hitting hardest on the first couple of turns then smoothing out is a pretty classic cold start signature. I've seen this with Vapi specifically where the assistant or model context is being initialized on the first interaction rather than pre-warmed. Worth checking if there's any session or context setup happening lazily on turn 1 and 2 that could be front-loaded instead.

Hi, Thank you for your patience while we investigated the latency issue. We identified the root cause, your custom LLM is currently hosted on Render (

custom-llm-6sfm.onrender.com

), and the service appears to cold-start after being idle. In the affected call flow, the first turn took approximately 10.3 seconds, almost entirely spent waiting for the LLM server to wake up and respond. Once the service was warm, turns 3 and onward dropped to under 1.5 seconds, which confirms this is a cold-start behavior rather than a Vapi-side latency issue. To improve this, we recommend one of the following approaches: Option 1: Upgrade Render to an always-on paid plan Option 2: Add a keep-alive ping You can set up a cron job or external uptime monitor to hit the LLM endpoint every 5–10 minutes, which keeps the Render instance warm and avoids first-turn latency spikes. Option 3: Move to always-on infrastructure If low latency is critical, consider hosting the custom LLM on infrastructure that does not sleep, such as a VPS, container service, or dedicated compute environment. One additional note: I also noticed your n8n webhook is hosted on Render (

n8n-ra2x.onrender.com

), which carries the same cold-start risk if it is triggered during an active conversation. It may be worth applying the same keep-alive or always-on strategy there as well.