Three issues: 1. Average turn latency is 2,596ms. 2. At the very beginning of the call, the assistant talks over me when I'm talking. 3. Partway through, a tool call is completed but the assistant gives an "Are you still there" message, and only after the caller responds does the AI continue the flow. * Call ID = 019c509a-78c3-7eea-86f3-6e855e9afa0a * LLM = 5.2-Instant (via OpenAI key) * TTS = Inworld 1.5 Max * STT = Deepgram Nova 3 Med * Inbound phone via Twilio * Calling in from a cellphone We've been trying to go-live for several weeks but we keep running into inconsistent behavior. In some calls, the timing between turns is extremely long (4-5 seconds), using a mix of different OpenAI LLM/TTS/STT. We would appreciate it if someone cloud please take a look. https://cdn.discordapp.com/attachments/1471405965319344303/1471405965562740776/2026-02-11_23-11-53.jpg?ex=698ed117&is=698d7f97&hm=e4c437e2dbf1373ef80672f468ffd1759c12087ea8d0149c626106412b1414bd&

It looks like most of the delay is coming from LLM + TTS latency and endpointing timing, which can also cause early barge-in and “Are you still there” misfires. When endpointing fires too early or late, it interrupts turn alignment and creates overlap. I’d recommend tuning silence thresholds, barge-in sensitivity, and testing with a lower-latency TTS/streaming config first. Also, inconsistent 4–5s delays usually point to buffering or transport jitter between Twilio and your media pipeline. Are you currently using streaming responses for both LLM and TTS, or full-response mode? @manos

@James Christopher Where can we see if we're using streaming responses? I don't think we have the settings exposed to control that. The frustrating part is that sometimes it's "ok" (but still a tad bit slower than we'd like) and sometimes it's very slow. An interesting experiment was we created an outbound caller agent that called the inbound voice assistant. Hilarity ensued as somehow they ended up talking constantly over each other, each with 2-4 second gaps/silence; it's just compounding the turn latency between the two AIs. VAPI's test suite isn't much better. We're honestly starting to look at different platforms, although I suspect part of it is just not enough capacity of the LLMs themselves...

Yeah, that behavior actually makes sense given how the pipeline works. In Vapi, “streaming” isn’t always a visible toggle, it mostly depends on how your LLM and TTS are configured under the hood. If the system is waiting for the full LLM response before sending it to TTS, you’ll get exactly those random 2–5 second gaps, especially when traffic or load fluctuates. The AI-to-AI test stacking delays is a classic sign that endpointing, buffering, and playback are all compounding each other. In most cases, the fix isn’t switching platforms, it’s making sure you’re using true token streaming → immediate TTS playback, tightening your silence/barge-in thresholds, and reducing unnecessary hops between Twilio, STT, LLM, and TTS. Once those are aligned, latency usually becomes much more stable. If you’d like, I can review your current agent and transport setup and help you tune it for real-time performance. Are you running this over WebSocket with streaming TTS enabled, or are you still on a more buffered setup? @manos