Skip to main content
Barge-in is the ability for a user to interrupt the AI while it is speaking. The server handles detection and confirmation automatically; the client’s job is just to react to the status messages it sends and clear playback promptly.

​
How it works

  1. User starts speaking while the agent is talking. The server’s VAD fires and opens a tentative barge-in: it stops sending new audio for the in-flight response, but does not cancel it, and sends status: listening. It does not send interrupted yet, so keep playing the audio you already have. Most short sounds over an agent are not interruptions: a cough, a click, a “mhm”, or the agent’s own voice leaking back through the microphone (worst in the first second of a call, before the browser’s echo canceller has adapted).
  2. Playback stops once the interruption is real. The server sends status: interrupted as soon as either:
    • the user has kept talking for 400 ms, or
    • their utterance is confirmed once it ends: it is long enough (MinWordsToInterrupt, relaxed for a single word when the GateTurn barge-in classifier scored the audio as a real interruption), is not noise, and is not an echo of the agent’s own voice.
    Stop playback and clear your queues on interrupted. A confirmed barge-in also cancels the response, truncates the assistant’s context to what the user actually heard, sends transcript_truncated with that text, and continues with a transcript for what they said.
  3. A false alarm never interrupts anything. If the utterance turns out to be noise, a backchannel or an echo, the server sends a status naming what is true now (speaking if the response is still playing or resumes, thinking if it was still being generated), and any held audio continues under the same generation. Because the client was never told to stop, the response simply plays on.

​
GateTurn is confirm-only

Earlier revisions of this pipeline let the fast classifier both confirm and resolve a tentative barge-in (i.e., proactively declare “false alarm, keep talking”). That resolve path was removed: on real call traffic, genuine interruption attempts scored in the same confidence band as backchannels often enough that the resolve path was vetoing real barge-ins, making the bot impossible to interrupt. GateTurn today only ever fast-tracks a confirm. It never resolves a tentative barge-in back down — that decision stays entirely with the pre-existing STT-based heuristics described in step 2 above, which is exactly how barge-in worked before GateTurn was introduced. A wrong confirm just costs one redundant interrupt (STT would likely have confirmed it a few hundred ms later anyway); a wrong resolve would cost the user their ability to interrupt at all, which is why the two paths aren’t symmetric. There is no separate “resolve” or “dismiss” message on the wire: a dismissed tentative barge-in is an ordinary status message (speaking or thinking).

​
Implementation

​
Best practices

  • Clear audio queues and viseme timelines on status: interrupted, and only then. Stopping on listening would let every cough cut the agent off.
  • A fast 50ms volume fade-out sounds less jarring than a hard cut.
  • Treat “a new audio message arrives” as “we’re speaking again”, whatever UI state you are showing.
  • Don’t rely on MinWordsToInterrupt-style precision from the client: single-word interjections (“stop”, “no”, “wait”) are still respected server-side if sustained, but very short noise and backchannels never reach you as an interrupt.