Anyone else experience this? The call just drops at random points. I've tested a lot of different configurations, models, and voice providers.. but it seems to all have the same effect.

Thanks for sharing your experience. To help diagnose the dropped calls, could you check your Vapi dashboard's call logs and let me know if there are any specific error messages or "endedReason" codes listed for the failed calls? This information will help pinpoint the cause and guide the next steps. Sources: - [Call ended reasons documentation](https://docs.vapi.ai/calls/call-ended-reason) - [Debugging guide](https://docs.vapi.ai/debugging)

🤷‍♂️ https://cdn.discordapp.com/attachments/1486774238802346135/1486775153609277552/image.png?ex=69c6bac3&is=69c56943&hm=efd0c7858554baa28cd8b3802ce55763db34c81e1486a79402a2d41010ec8fc1&

That’s painful, if it’s happening across setups it’s likely infra not the models, I’d check timeouts, webhook delays or Twilio/SIP stability since call logs usually show where it’s breaking, are the drops random or around the same point each call @Scimon

im not connected to anything external except a GoHighLevel CRM Tool. this is purely in the assistant testing UI. It drops in random places every time. never the same place. @User

Got it, if it’s dropping inside the testing UI with no external deps, that rules out Twilio/SIP and points more to session handling or streaming interruptions. I’d focus on checking response time limits, token/stream cutoffs, and whether the model is hitting silent errors mid-response. Next step I’d run controlled short vs long prompts and watch exactly when it breaks. Are you seeing any errors or just clean drops with no logs? @Scimon

Where would I find the errors? I have a log screenshot above .. not sure where else to look to debug. @Matt Attached is a screenshot of my entire config. Also my prompt is pretty darn long, not sure if that matters.. but that's how it is 😅 https://cdn.discordapp.com/attachments/1486774238802346135/1486825025779798146/image.png?ex=69c6e936&is=69c597b6&hm=13d5c760c89b67d84986d91481691501aaf56922988acab7753be928e099441d&

Yeah I can’t fully read the screenshot, but based on what you said this feels like prompt/stream instability more than config. Long prompts can silently hit token or streaming limits and cause clean drops with no obvious errors. I’d start by cutting the prompt in half, test stability, then gradually add sections back to find the breaking point. If you want, I can jump in with you and help isolate it properly step by step. @Scimon

that would be awesome, @Matt thank you. I just checked a char count on my prompt and it's 4495 char long... lol.. do you know if there is any specific limit?

4.5k chars isn’t too big on its own, but combined it can hit ~8k–16k tokens and cause drops, long prompts can also make the testing UI unstable when streaming so I’d break it into smaller chunks and test step by step, happy to help you privately and pinpoint exactly where it’s breaking @Scimon

Got time for a google meet right now? or soon? @Matt ?

Yeah I can jump on, but it’s pretty late here right now, tomorrow would be better. Just send me a private message and we’ll lock in a time that works. @Scimon

FR Sent @Matt

Were you able to get it sorted or you need my suggestion?

What's your suggestion? @✞ρєη¢ℓσηє

did you add an end call phrase? @Matt

We are experiencing the same issue. We are using Openrouter or OpenAI, but both seem to have issues. Other applications don't have this, so it seems a VAPI problem. pipeline-error-openrouter-llm-failed { "level": 50, "body": "Model sequence failed - all attempts exhausted", "provider": "openrouter", "model": "openai/gpt-5.2-chat", "error": { "message": "providerfault-model-no-response" } }

please provide a call id so we can review the logs. thanks

thanks for the call id. we reviewed the logs and can see what is happening. the call is dropping because openRouter is hanging on LLM requests and there was no fallback model designated. the prompt size is pretty large (~44k tokens) which may be related to the requests timing out. there are also several requests earlier in the call that the system was able to recover from briefly, so that is suggesting that there's something flaky with the connection to openRouter. in all of your tests, were you only using openRouter models? if thats the case, you might want to try using our default openAI models as a test. also consider using a fallback model so if the main one times out, the fallback model can resume the call. the main blocker here is openRouter models timing out causing the call to end.