In general, it seems to be a long-lasting problem that sometimes the assistant goes silent and never speaks, even if the human tries to wake it up. The case for our current issue is the next: 1. The assistant starts speaking at the start of the call 2. Human interrupts it and says something 3. Assistant goes silent and never responds again Providing 2 call IDs for you to look at: 019cb582-91a2-7333-945d-12dda90a0678 019cb8a9-d0e2-700b-97b9-a2275a642aaa

Thank you for sharing the call IDs and a clear description of the issue. Based on the documentation, assistant silence after interruption can often be related to the voice pipeline's "stop speaking plan" or interruption handling settings (such as

backoffSeconds

,

numWords

, or

voiceSeconds

)—incorrect values may cause the assistant to not recover after being interrupted. Could you confirm if there have been any recent changes to your assistant's voice pipeline configuration, especially around interruption or endpointing settings? This will help narrow down whether the issue is configuration-related or something else. For further troubleshooting, reviewing the detailed call logs in the [Vapi dashboard](https://dashboard.vapi.ai/) for these call IDs may also provide more insight into where the conversation flow is breaking down. Let me know about any recent configuration changes! Sources: - [Debugging voice agents](https://docs.vapi.ai/debugging) - [Voice pipeline configuration](https://docs.vapi.ai/customization/voice-pipeline-configuration)

For this specific Assistant, we only have: "firstMessageInterruptionsEnabled": true We did not set any specific StartSpeakingPlan The whole Assistant settings can be found by CallID

Thanks for sharing the call details. It looks like the silence happens when the human interrupts the assistant mid-speech, which aligns with the firstMessageInterruptionsEnabled behavior. To help pinpoint the root cause, could you confirm if any custom StartSpeakingPlan or turn-based settings were applied at the assistant or workflow level? @Dmytro

Hi, This is a known issue, our team is working on it. Recommended workaround: Allow VAD to bootstrap timeouts in

EndpointingBuffer

even during interrupted first messages. A FIX ticket will be created to implement this improvement. Best regards, Oshi Raghav Customer Support Team | Vapi

Hey, thanks for your reply! Could you please give more details on your recommendation: 'Allow VAD to bootstrap timeouts in EndpointingBuffer even during interrupted first messages.' Could you give an example of a config we should try to use?

I’m extremely sorry for the confusion. Please ignore the previous message. Allow me some time to look into your issue more carefully, and I will get back to you with an update shortly. Thank you for your patience.

Hey again, any news?

Hi, Apologies for the delay. We are still looking into the issue and will share an update with you as soon as possible. Thank you for your patience and cooperation, we truly appreciate it. Warm regards, Oshi Raghav Customer Support Team Vapi

Hey, this is completely unrelated to the issue... Please read my very first message in this thread. Regarding the Assistant setting We use a webhook to populate the Assistant into the call, and in the call log, it is clearly seen that the Assistant was successfully resolved.

Hi, Sorry for the delay, and thank you for your patience. It looks like the call record was purged from our logs, so I’m unable to review that specific interaction from our side. Could you please share the most recent call ID where the assistant stopped in the middle of the conversation? Once we have a fresh call reference, I’ll make this a priority check and investigate why the assistant stopped unexpectedly. Thank you, and we’ll be happy to help further. https://cdn.discordapp.com/attachments/1479054874418090076/1489560968920039476/image.png?ex=69d0dd41&is=69cf8bc1&hm=085d8fcde79f95d002d1d5e1be294cd1f9f541b6113e74f662697dcb93765354&