Setup Vapi web SDK, browser-based GPT-4o (also tried GPT-4.1, same behaviour), 6 tools, typical request triggers a 4–5 tool chain backchannelingEnabled: false, waitSeconds: 0.4, smartEndpointingEnabled: false, idleMessages: [], all tool messages: [], endCallMessage: "" Behaviour 15–25s of silence between user finishing and the first tool dispatching. Assistant says nothing, no tool fires. Generic filler replacing our required task narration. The system prompt mandates verb-first narration before every tool call (e.g. "Pulling your latest YouTube video", "Opening Creation Agent", "Adding that as a source") AND explicitly bans generic filler ("Just a sec", "Hold on", "Give me a moment", "This'll just take a sec"). The model does the opposite: it ignores the required narration entirely and emits the banned filler before every tool call. The prompt has hard rules, a verbatim banned-phrase list, and 7 worked examples. The model follows them for its final confirmation sentence but ignores them entirely for inter-tool narration. **Tried: **two model families, multiple prompt rewrites, all speaking/message-plan tighteners above, per-tool messages: []. **Hypothesis: **the model emits a full spoken turn AND a tool call in the same response, and Vapi plays speech then dispatches the tool serially. If so, prompt rules can't fix it — the model defaults to short generic filler because narrating the actual action burns more airtime than Vapi-side filler would. Questions Per-tool messages: [{ type: "request-start", content: "…" }] — does this replace the LLM's spoken turn before the tool, or play in addition? Any way to mark a tool as "silent dispatch" so the model fires it with no spoken turn? Is streaming tool dispatch supported — can a tool fire on the first tool_call delta token, before the text turn finishes? Canonical Vapi pattern for multi-step chains where each step should narrate its specific action? Happy to share call logs and assistant config.

Hi, Thanks for the detailed write-up - this is really helpful context. Before we dig in, could you share a couple of call IDs where you experienced both issues (the 15–25s silence gap and the generic filler)? That will let us trace exactly what's happening in the pipeline. Happy to also review your assistant config if you want to share it. Best, Vapi Support

Sure: we have now fixed the filler issue but still experiencing really delayed start when a user clicks to chat with the voice agent Assistant ID: e8004612-509c-42cf-80e9-601835e6512a Call ID showing filler + cold start issue: 019e6920-1ee1-7000-a6af-235013a20b89

Hi, Thanks for sharing those details and the call ID. We've looked into call

019e6920-1ee1-7000-a6af-235013a20b89

- here's what we found: This specific call actually performs well. The time from you finishing speaking to tool dispatch was about 1 second, not 15–25 seconds. So this call likely shows the filler issue (which you've since fixed) rather than the cold start delay. Could you share a call ID where you experienced the actual 15–25 second delay? That will let us trace the real bottleneck. Regarding your architecture questions: For the multi-step tool chain narration issue, we'd recommend trying per-tool

request-start

messages as your next step:

{
  "messages": [
    {
      "type": "request-start",
      "content": "Pulling your latest YouTube video"
    }
  ]
}

This lets you pre-script the exact narration per tool, bypassing whatever the LLM would generate. Set a different

request-start

message for each tool so each step narrates its specific action. Best, Vapi Support

hey shaunak - we're mostly sorted now. The only thing we'd love to improve is the start up - which usually takes 7/8 seconds from someone clicking to speak with out agent to our agent greeting them - anyway to improve this?

Hi, Glad to hear things are mostly sorted! For the 7-8 second startup time, a few things that can help: 1. Use

firstMessage

instead of letting the LLM generate the greeting. If your assistant has a static greeting, hardcode it in the

firstMessage

field. This plays immediately without waiting for an LLM round trip. 2. Check your transcriber settings. If

smartEndpointingEnabled

is off and

waitSeconds

is 0.4, that's fine. But make sure there's no unnecessary delay before the assistant starts speaking. 3. Reduce system prompt size. A very long system prompt increases the LLM's time-to-first-token on the initial turn. If yours is large, consider trimming it or moving reference data into tools/knowledge base. 4. Pre-warm with `firstMessage`**.** The fastest possible startup is a hardcoded

firstMessage

that plays instantly while the LLM loads in the background. The user hears the greeting immediately and by the time they respond, the LLM is ready. Could you share a call ID showing the 7-8 second startup so we can check where exactly the time is being spent? Best, Vapi Support