I'm experiencing an issue where the AI assistant repeats the same response multiple times with noticeable lag, rather than speaking it once cleanly. Call ID:

019c8103-23ca-7772-adff-d52c83f04da3

Timestamp: ~0:42–0:52 into the call What happened: The AI was confirming a reservation date (February 26, 2026 at 8 PM) and got stuck repeating "February 2026" several times with lag over a ~10 second window before the conversation could move forward. (please listen to audio to understand). What I believe is the cause: Looking at the call logs, three new turns were triggered in rapid succession within ~2 seconds (at 39.9s, 40.9s, and 41.8s) as Deepgram partial transcripts arrived before the final transcript. Each turn independently triggered an LLM call and queued a separate TTS request — all generating essentially the same response. This resulted in 4 TTS chunks being queued and played back-to-back, creating the repetitive, laggy output the caller heard. It appears there's no deduplication or cancellation of overlapping turns when a new turn starts before the previous one has finished speaking.

Hi, Sorry for the inconvenience, we’re currently working on a permanent fix. In the meantime, you can apply the following **workaround**: Switch your endpointing to LiveKit smart endpointing in the assistant’s `startSpeakingPlan`:

{
  "startSpeakingPlan": {
    "smartEndpointingPlan": {
      "provider": "livekit"
    }
  }
}

This should help improve turn detection while we resolve the issue. Best regards, Oshi Raghav Customer Support Vapi

I have tried livekit and getting high endpoint delays because of it, even after configuring to aggressive setting, so I would like to keep using the default

startSpeakingPlan

. Could you please update me when the permanent fix has been merged 🙏

Hi, If the previous option is not working for you, you can try the following alternative approaches in the meantime. Option 1: Use Transcription Heuristic Endpointing This method is much faster (~100–150ms) because it skips the ML model entirely and uses simple transcription rules.

{
  "startSpeakingPlan": {
    "waitSeconds": 0.1,
    "smartEndpointingPlan": null,
    "transcriptionEndpointingPlan": {
      "onPunctuationSeconds": 0.05,
      "onNoPunctuationSeconds": 0.3,
      "onNumberSeconds": 0.2
    }
  }
}

What this configuration does: •

onPunctuationSeconds: 0.05

Responds in ~50ms when punctuation is detected (., !, ?) •

onNoPunctuationSeconds: 0.3

Responds in ~300ms if no punctuation is detected (instead of the default ~1.5s) •

onNumberSeconds: 0.2

Responds ~200ms after numbers are spoken This approach helps avoid: • The repetition bug caused by endpointing race conditions • Higher delays introduced by the LiveKit ML endpointing model Tuning Tips • If the assistant interrupts users mid-sentence, increase

onNoPunctuationSeconds

(try ~0.5). • If responses are still too slow, you can reduce

onPunctuationSeconds

further (minimum ~0.05). ---- Option 2 Custom Endpointing Rules For more control, you can define **custom endpointing rules**:

{
  "startSpeakingPlan": {
    "customEndpointingRules": [
      {
        "type": "customer",
        "regex": ".*[.!?]$",
        "timeoutSeconds": 0.1
      },
      {
        "type": "customer",
        "regex": "^(yes|no|okay|sure|yeah|nah|correct|right)$",
        "timeoutSeconds": 0.05
      }
    ]
  }
}

This allows very fast responses for short answers while keeping longer timeouts for open-ended speech. Please try these approaches and let us know if the behavior improves.