Hi, I am seeing big delay times when doing calls in Squad mode. When Squad decided to transfer to the new assistant, I am seeing big delay between "Handoff Initiated" tool call result and the first AI message (note AI is configured to

"firstMessageMode": "assistant-speaks-first-with-model-generated-message"

). For example, in this call (

019c4180-244c-7773-8839-d5d85635976d

): * Handoff initiated (message 7) is at 13.3s. * AI message (message 8) is then at 15.6s, with 2.3 seconds delay that should include calling AI with a transcript history without any transcriptions because AI is configured to speak first. * It should not be the LLM latency because further messages like message 10 has only 0.5s delay (running on the same assistant and responding to the user) and that includes transcript

Hi — thanks for sharing the call ID. We reviewed the logs for call 019c4180-244c-7773-8839-d5d85635976d and identified two factors contributing to the perceived 2.3s delay: 1. Measurement artifact The timestamps in the

messages

array reflect when messages are committed to the buffer (after TTS generation), not when audio actually reaches the user. Based on wall-clock timing, the real handoff-to-audio latency is closer to ~800ms, not 2.3s. 2. Pipeline reconstruction overhead During squad handoffs, all 13 stream components are rebuilt — including the STT transcriber. Even though your Interaction assistant uses:

firstMessageMode: assistant-speaks-first-with-model-generated-message

the platform currently initializes STT during the swap. That adds roughly ~400ms of overhead on the first post-handoff turn. This does not impact subsequent turns. Your configuration looks correct. The ~0.5s latency you’re seeing on later turns confirms the pipeline is performing normally once warm. One additional recommendation: If minimizing first-turn latency is critical, consider using a static firstMessageMode for the first handoff. Using model-generated first messages on a cold start will always introduce some additional latency due to LLM invocation. Let us know if you'd like us to review another call or test an alternative configuration.

Thank you so much for looking into it, that makes sense. I have looked into using firstMessageMode and it did work well, shaving off 1 second roughly. I have a new call that I have questions for if thats okay -

019c5bcb-4dff-744e-8484-89c1320a9b34

. What I am trying to do is try make it as fast as possible, and on analysing the logs I am confused with the following. 1. The delay between user stops speaking and AI responds with audio is roughly the same with every non-thinking model I have tried (gpt-4.1-mini, gpt-4o-mini, gpt-4.1, gemini 2.5 flash) . I would of expected smaller models to respond faster, but they all have the same TTFT. For example, in the shared called id the before transfer its using gpt 4.1 (with 700ms latency as advertised by Vapi's dashboard) actually responds in ~420ms and after the transfer its using gpt-4o-mini (with 390ms latency as advertised by Vapi's dashboard) actually responds in ~450ms. Why does it happen and are there models that you could recommend that even has smaller response times? 2. Related to previous one, I have noticed that the latency times for the same model vary depending on the provider used. I noticed that when Azure is used, its slower by ~50ms. For example, in turn 3 and turn 4 same gpt 4o mini was used, by turn 3 used Azure and took 485ms compared to turn 4 used OpenAI and took 413ms. Is it possible to select OpenAI provider to be used? 3. The latency per turn shown on call logs is not the same as in the audio in the call. For example, in the supplied call id, the #4 turn takes 948ms but if you look at the screenshot, it takes ~1.5s. Where is the 0.5s latency coming from?