barge_confirm_ms and server_vad are and picks
up when they aren’t behaving.
The stereo recording is your ground truth
Before you touch a knob, get the recording. Every call is captured as a stereo WAV — caller on the left channel, agent on the right — which makes barge-in failures visible at a glance: open the two channels side by side and you can see exactly where they overlap and for how long.Pull the recording for the call_sid
Every call keys off its
call_sid. Find the failing call in your reports view
and open its recording from the call’s detail page. See
Call traces for locating a call
by call_sid, DID, or time window.Read the two channels against each other
- Agent (right) keeps going while caller (left) is loud → the interrupt never fired, or fired but the provider couldn’t cancel. Go to the symptom table and the provider scorecard.
- Agent (right) cuts out right when its own audio is loudest, no caller speech on the left → a self-trigger. Jump to no-AEC self-trigger.
- Agent cuts on a short “mhm” on the left → a backchannel got treated as an
interruption; raise
response_min_speech_ms.
Confirm on a live call with monitor
Reproduce with a supervisor monitor session so you hear both legs in real
time while you change a knob. Monitor is listen-only and does not alter the
call — see Supervise a call.
There is no shipped per-turn barge-event telemetry stream or dashboard today.
Barge-in is diagnosed from the stereo recording, a live monitor session, and the
knobs below — not from a “barge timeline” chart. A turn-level event feed is on
the roadmap; don’t wait for it to debug a call.
Symptom, cause, fix
| Symptom | Likely cause | Fix |
|---|---|---|
| Agent talks straight over the caller, never yields | Provider can’t be cancelled mid-flight (HTTP LLM, or a vendor bridge with no interrupt event) | Check the scorecard; move to a streaming/realtime provider or fix the vendor adapter |
| Agent yields on a phone call but not in the browser (or vice-versa) | The interrupt fires on one transport leg but the provider path differs | The VAD is per-transport-agnostic; the difference is the provider — confirm the same agent/provider on both legs |
| Agent cuts itself off mid-word, no caller speech present | Its own TTS leaks back through a no-AEC phone mic and self-triggers | Raise margin_while_tts to match margin on PSTN (default on phone) — see below |
| Agent replies mid-sentence, chopping the caller | silence_duration_ms too low — end-of-turn fires on inter-word pauses | Raise silence_duration_ms toward 500–800 ms |
| Short “mhm”/“ok”/“right” cancels the agent | response_min_speech_ms (the over-agent floor) too low | Raise response_min_speech_ms (default 600); the backchannel then self-drops |
| A genuine one-word answer (“yes”, a digit) gets ignored | answer_min_speech_ms too high in the answering window | Lower answer_min_speech_ms (default 150) so terse replies still commit |
| Barge “feels laggy” even on a good provider | barge_confirm_ms hold window is the floor of interrupt latency | Lower barge_confirm_ms, or set 0 only on echo-cancelled transports |
| Barge silences the audio but the LLM still “runs” (and bills) | HTTP / non-streaming LLM completes server-side regardless | Expected — use a streaming or realtime model for a true mid-flight cancel |
| Clicks/line noise trigger false interrupts | min_speech_ms / threshold too permissive | Raise min_speech_ms; raise threshold on noisy trunks |
The four knobs you’ll actually reach for
These are the levers behind almost every barge-in fix. They live underturn_detection (and turn_detection.params) in the agent config; full schema
in Runtime configuration.
| Knob | Governs | Turn it when |
|---|---|---|
silence_duration_ms | Trailing silence before end-of-turn fires (when the agent may reply) | Agent replies mid-sentence → raise; agent feels sluggish → lower |
min_speech_ms | Shortest burst that counts as speech at all (noise/click filter) | Line noise causes false triggers → raise |
barge_confirm_ms | The hold-and-confirm window — how long over-talk must sustain before the interrupt actually fires | Backchannels cancel the agent → raise; interrupt feels laggy → lower (or 0 on echo-cancelled legs) |
margin_while_tts (the TTS guard) | How hard the mic gate clamps while the agent is speaking | PSTN self-trigger → raise to match margin; browser wants a snappier cut → lower |
min_speech_ms floor is position-dependent under the hood: over the agent it
is response_min_speech_ms (higher, to reject backchannels); in the answering
window it is answer_min_speech_ms (lower, so a one-word reply still counts).
Debug the two windows independently — a symptom in “agent won’t stop for me” is a
different knob than “agent ignored my quick yes.”
Provider cancel scorecard
The on-device VAD always detects the interruption. Whether the agent’s audio actually stops depends on whether the downstream provider can be cancelled mid-flight. A “timeout-only” provider is not a bug you can tune away — the runtime silences local playback immediately, but the provider keeps generating (and billing) until it finishes on its own.| Provider path | Mid-flight cancel | On barge |
|---|---|---|
OpenAI Realtime (server_vad or local VAD) | Clean | Runtime sends the truncate/interrupt; the session stops generating |
| Gemini Live | Clean | Provider interrupt sent; generation halts |
| Streaming TTS — ElevenLabs, Deepgram | Clean | Outbound audio buffer flushed within a frame; playback halts at once |
| Streaming ASR — Deepgram | Clean | Cancel propagates; the partial transcript is discarded |
| HTTP / non-streaming LLM — OpenAI HTTP, Anthropic, Gemini text, Ollama | Timeout-only | Playback silenced locally; the request runs to completion server-side and is still billed |
| External vendor bridge — LiveKit, Vapi, Twilio | Depends on the vendor’s own interrupt event | Only as clean as that vendor’s adapter — see below |
No-AEC SIP legs self-trigger
The most confusing barge-in bug: the agent interrupts itself, with no caller speech anywhere on the recording. This is a telephony-only failure mode. There is no acoustic echo cancellation in the media path. On the browser path that’s fine — the browser cancels echo before the audio ever reaches us. On a PSTN/SIP leg there is no such thing: the agent’s own TTS travels down the line, bounces off the far-end handset or hybrid, and comes back up the caller’s mic. To the VAD that returning audio looks exactly like the caller speaking over the agent — so it fires a barge and cancels the agent mid-word. The runtime guards against this with the TTS guard: while the agent is speaking it raises the during-speech mic gate (margin_while_tts) so quiet
echo can’t cross the speech threshold. On phone calls the runtime clamps
margin_while_tts up to match the quiet-line gate margin, so the agent’s own
voice can never cancel the agent.
Confirm it's a self-trigger, not a real barge
On the stereo recording, the agent (right) drops out while it is loudest and the
caller (left) is silent or only carries a faint echo of the agent. That’s a
self-trigger.
Check the transport
Self-trigger only happens on no-AEC legs — SIP/RTP PSTN trunks. If the leg is a
browser (WebTransport) or WebRTC-terminated leg, echo is cancelled upstream and
this isn’t your cause; look elsewhere.
Raise the TTS guard on PSTN
Ensure
margin_while_tts is clamped to margin on the phone leg (the default).
If you lowered it for a snappier browser cut and that same agent also takes phone
calls, the phone leg is now under-guarded — restore the clamp for PSTN.A decision path
Does the recording show real caller speech over the agent?
No, and the agent still cut → a self-trigger; go to
no-AEC self-trigger. Yes → continue.
Did the agent stop when the caller spoke?
No → the interrupt wasn’t actioned. Check the
provider scorecard: an HTTP LLM or a vendor bridge
can’t be cancelled mid-flight regardless of your knobs.
Did it stop, but too eagerly or too late?
Too eagerly on a short sound → raise
response_min_speech_ms /
min_speech_ms. Too late → lower barge_confirm_ms. Replies chopping
mid-sentence → raise silence_duration_ms.Still stuck?
It’s likely not barge-in at all — a one-way-audio or high-latency problem can
look like “the agent won’t respond.” Cross-check
Latency breakdown and the
Barge-in not working
troubleshooting guide.
Related
Turn detection & barge-in
The config reference for every knob referenced here.
Barge-in not working
Step-by-step fixes when the agent won’t yield to the caller.
Call traces
Find a call by
call_sid, open its recording, and monitor it live.Latency breakdown
Rule out latency masquerading as a barge-in failure.