Barge-in during call opening: how often callers speak before the agent does

What the thread asks, and what call data can answer

The r/VoiceAutomationAI thread describes an outbound voice agent whose callee keeps saying hello before the agent speaks and then talks over its reply, and asks how to close that opening gap. The same problem shows up when a call must open with a recording or consent notice: callers who talk early trigger barge-in and cut the notice off, while a notice nobody can interrupt can cost hang-ups in the first seconds.

APIFleet's call traces can measure part of both questions: whether caller speech started before the assistant's first audio, and how long that first audio took on each stack.

They cannot show how often a caller talks over a notice while it is still playing, or whether a protected notice changes early hang-ups, so this page does not claim either. APIFleet publishes this answer from calls on its own platform, including developer test and demo calls, and reports aggregates only: no recordings, transcripts or caller details.

How often callers spoke before the first assistant audio

For each phone call we took the first assistant session and asked whether the pipeline's own speech detector fired before APIFleet's server received the first audio of the assistant's first segment, or while that segment was still arriving. OpenAI Realtime reports its voice-activity start, Gemini 3.1 Flash Live mostly a local voice-activity detector, and cascading calls use Deepgram's SpeechStarted event, a voice-activity signal that is separate from transcription and can fire on line noise and, once the assistant is talking, on its own echo, so a stricter cascading row counts only transcribed words.

Outbound and inbound calls give different answers in every pipeline, so each pooled phone row depends heavily on how many of its calls were outbound. In 35 of the 37 outbound cascading calls where the person answering spoke first (phone, 15 to 18 August 2026), the assistant's first audio was a model reply rather than a scripted opening: there was no opening to cut off, and the assistant replied to what the person said first. The OpenAI Realtime and Gemini traces do not record whether an opening was configured, so the same split is not available for them.

Inbound early speech was concentrated: all 50 cascading and all 7 OpenAI Realtime calls in the before column came from two assistants per pipeline, and the assistant-level 95% intervals for those shares, over 352 and 65 calls, run from 0% to 31.4% and from 0% to 23.9%. Gemini's inbound zero covers 91 calls from 5 to 9 September 2026, including 38 after 5 September, the day APIFleet's own Gemini voice-activity detector shipped, so it describes a five-day period, not the model in general.

Why talk-over during the opening itself is hard to measure

The during column counts only speech that began while APIFleet's server was still receiving the first segment, and on the phone the caller keeps hearing that audio after the server has all of it. How long the server-side window stays open depends on the stack: across 404 cascading phone calls from 15 August to 24 September 2026 its median was 1 ms, because Piper, which carried two thirds of those calls, returns each text chunk as one finished audio file.

So the low phone values in that column, at most 6.2% in any row of the table, do not show that callers rarely talk over openings, and the column should be read within a row rather than across rows. Browser test sessions cannot fill the gap: for assistants with a greeting, the test client holds back microphone audio until the greeting starts playing, unless a start timeout or an error releases it first, and in the current code until it has finished.

gpt-live-1 records no caller speech-start event, so it has no values in the table. Its model-spoken openings do record whether a caller transcript arrived before the opening audio began, which happened in 47 of 368 phone attempts (12.8%) between 11 September and 29 October 2026.

How long callers waited for the first audio, by stack

This wait runs from the start of the assistant session on APIFleet's server to the moment the server received the first audio of a scripted or model-spoken opening, so carrier answer time, network delay and the phone's playback buffer come on top. Calls whose first audio was a reply to the caller are left out, and for OpenAI Realtime and Gemini so is every call with caller speech detected before the first audio, so those rows cover only openings that began before any detected caller speech.

Medians differ by seconds between stacks: 549 ms over 269 calls for the one large Piper deployment, against 3,775 ms over 309 calls for gpt-live-1's model-spoken opening, whose separately computed stage medians were 1,606 ms to start the session and 2,054 ms more to produce audio. In 151 of the 368 gpt-live-1 model-spoken opening attempts on the phone, from 11 September to 29 October 2026, neither audio nor caller speech had appeared 1.5 seconds after the opening instruction was acknowledged, so the runtime sent its one reminder.

The pre-recorded clip row is measured from a different starting point, the media WebSocket accept, which preceded session start by about 55 ms on those 632 calls. Its two assistants made only 3 of the 309 model-spoken openings, so the gap between the clip and model-spoken rows is not a measured effect of caching.

All Gemini 3.1 Flash Live phone calls fall between 5 and 9 September 2026, 70% of the 154 on 5 September, when APIFleet's own Gemini voice-activity detector shipped and some replies stalled; without that day its median opening was 1,178 ms and its 90th percentile 2,250 ms, over 38 calls.

How often barge-in fired across whole calls

Each pipeline logs barge-in with its own detector, so these rates show how often that detector cut the assistant off across all of a call's audio segments, not how callers behave, and they are not comparable across pipelines. OpenAI Realtime counts caller speech while the model is still generating audio, Gemini counts the server's interrupted flag, and cascading calls interrupt only on transcribed words while an audio segment is active.

Talk-over is the reverse: the assistant's audio started while the pipeline still marked the caller as speaking. In cascading calls that mark comes from Deepgram's voice-activity event, so their talk-over rates of 12.7% to 26.3% per segment (205 to 942 segments per row) can include echo and line noise as well as real overlap.

gpt-live-1 logs neither event: OpenAI's Live guide describes a model that listens and speaks at the same time and documents no client voice-activity setting, and APIFleet's traces only infer when its output becomes audible.

Options for a consent or recording notice

Whether a notice must be heard in full, or may be interrupted, is a legal question for your jurisdiction and use case, and call data cannot settle it. What the data and vendor documentation support are a few design choices, none of which we have tested against each other.

Shorten the silence before the notice. Every model-spoken opening row in the wait table had a median of more than a second before its first audio, against well under a second for the cascading rows, and OpenAI's Live guide recommends playing a verified recording or rendered clip from your application when exact wording and a known end of playback matter.

Protect only the sentence that has to be heard, keep it short, and keep the caller's audio flowing to the model while it plays, so whatever they said can be answered straight afterwards. APIFleet's verified opening clips for gpt-live-1 work this way: barge-in cannot clear the clip, the model's reply queues behind it, and the clip stops only if the call or the model session ends.

These clips are enabled by APIFleet operators for specific gpt-live-1 assistants on inbound Telnyx calls, not through a dashboard setting, and two assistants used them in this data. Elsewhere on APIFleet phone calls interruption stays on: OpenAI Realtime and Gemini sessions stop for caller speech, and cascading sessions stop for transcribed words.

Model-level switches reach further than the notice. OpenAI Realtime's interrupt_response setting, on by default, decides whether caller speech cancels a response in progress, and Gemini Live's activityHandling can replace its default start-of-activity interruption with NO_INTERRUPTION. OpenAI's turn detection can be changed mid-session with session.update, but Gemini's configuration cannot be updated while the connection is open, so turning interruption off there also stops callers from barging in on every later answer.

Log the notice as sent, not as heard. APIFleet records when the last frame of a clip was handed to the carrier and marks playback as unconfirmed, and OpenAI's Live guide likewise advises checking playback before marking a disclosure as delivered.

On outbound calls, decide who speaks first. Most people who answered spoke before any assistant audio in this data, so if a notice is required, plan whether it plays the moment the line connects or as the first thing after that hello.

A checklist for measuring your own openings

These steps reproduce this page's measures on your own traffic. They describe how to measure, not results we have seen on other platforms.

1. Log three server timestamps per call: session start, the first assistant audio received, and every caller speech-start event with the detector that produced it.
2. Split inbound from outbound calls before computing any share, because in this data shares differed far more between directions than between pipelines.
3. Record whether the first audio was a scripted opening or a model reply, so assistants built to answer a hello are not counted as failures.
4. Count transcribed words as well as voice activity on phone lines, since voice-activity events can fire on echo and line noise.
5. Show calls and assistants beside every share, because two assistants produced all of the inbound early speech in each of two pipelines here.
6. Track when the notice's last frame was sent and whether the call was still connected, and keep that separate from evidence that the caller heard it.
7. Listen to a sample of calls where speech started before or during the opening, since voice-activity detectors can fire on sounds that are not words.
8. Change one thing at a time, such as a shorter notice or a pre-recorded clip, and compare periods with the same direction and assistant mix.

Limits of this data

These are observational production and test calls on one platform, not a controlled benchmark: no group was randomised or matched on assistant, prompt, caller population, period, opening type or call direction. Differences between rows are not effects of a model, a voice or a setting.

A few assistants and tenants dominate several rows: one assistant made 77% of the 352 inbound cascading calls, and the early speech in each inbound row came from at most two assistants. Groups also cover different weeks and code revisions, from mid-August to late September 2026 for the caller-speech measure and up to 29 October 2026 for gpt-live-1.

All times are server observation times, not what the caller heard: the carrier adds buffering, and phone playback continues after the server has received a whole segment. Phone rows include developer test and demo calls, 70% of Gemini 3.1 Flash Live's 154 phone calls fall on 5 September 2026, the day APIFleet's own Gemini voice-activity detector shipped, and browser rows are tests by definition.

Detectors, voice-activity settings and the share of assistants with a scripted opening differ between pipelines, which is why each pipeline is reported against its own events. Rows from fewer than five assistants describe those deployments, not yours.

Definitions, counts and the browser test rows

Scope: 2,423 traced phone and browser calls from 14 August to 29 October 2026, without simulations, using each call's first assistant session. The caller-speech measure covers 643 phone calls whose first session produced assistant audio, and shows a share only when at least 20 calls are behind it.

Before means a caller speech-start event earlier than the first assistant_audio_started event; during means none before, but one between that event and the next assistant_audio_stopped event, which marks the end of generation, a barge-in or an error (or the session's last event if none was logged). Before or during is their sum over calls with a first audio segment.

Speech-start events are OpenAI Realtime's input_audio_buffer.speech_started, Gemini's local voice-activity start or, with automatic detection, its first input transcript, which arrives late, Deepgram's SpeechStarted for cascading calls and, in the words-only rows, the first interim transcript. Greeting times, barge-in and talk-over rates come from APIFleet's verified per-model metrics, except the Gemini 90th percentile without 5 September, computed the same way for this page; the caller-speech measure comes from a script run on the same de-identified extract.

The browser rows below come from test and demo sessions in which the client holds back the microphone at the start of the call, and they can include automated test runs with scripted interruptions. They are listed for completeness, not as caller behaviour.

Continue with a practical next step

• Test interruptions and silence before release
• Measure the noise floor before trusting a test
• Configure Deepgram transcription for an assistant
• Configure OpenAI Realtime and GPT-Live assistants
• Configure Gemini Live assistants
• Compare Gemini Live and OpenAI Realtime on phone calls
• See how gpt-live-1 openings and clips behave
• Read more Reddit answers from APIFleet call data

Frequently asked questions

Do callers usually talk before a voice agent's greeting?

Not on inbound calls in this data: caller speech came first in 7 of 65 OpenAI Realtime calls, 12 to 50 of 352 cascading calls depending on the detector, and 0 of 91 Gemini 3.1 Flash Live calls from 5 to 9 September 2026 (0 of 38 after 5 September, when APIFleet's own Gemini voice-activity detector shipped). On outbound calls the person answering usually spoke before any assistant audio, in 37 of 52 cascading and 27 of 29 OpenAI Realtime calls, though in 35 of those 37 cascading calls the assistant had no scripted opening; all are APIFleet phone calls from 15 August to 27 September 2026.

Should a consent or recording notice be interruptible?

That is a legal and product decision that call data cannot settle. One option is to protect only the short sentence that must play, keep the caller's audio flowing to the model during it, answer what they said straight afterwards and log the notice as sent rather than heard.

Does a pre-recorded opening stop callers talking over it?

No. It lets the bridge start the opening without waiting for the model and fixes the wording, and in APIFleet's runtime barge-in cannot clear it, but callers can still speak over it. We have no controlled comparison of talk-over or hang-ups with and without a clip.

Why does the person answering an outbound call speak first?

The traces show how often, not why. The person answering spoke before any assistant audio in 37 of 52 cascading and 27 of 29 OpenAI Realtime outbound phone calls from 15 August to 27 September 2026, and in 35 of those 37 cascading calls the assistant had no scripted opening, so its first audio was a reply to what the person said.

Can I measure this on my own calls?

Yes, if your platform logs server timestamps for the session start, the first assistant audio and each caller speech-start event. Split by call direction and opening type, count words as well as voice activity on phone lines, and show calls and assistants beside every share.

Sources and evidence

• Reddit discussion: callers saying hello before an outbound agent speaks · observed 2026-10-30
• OpenAI API reference: Realtime client events and turn detection settings · observed 2026-10-29
• OpenAI guide: voice activity detection in the Realtime API · observed 2026-10-29
• OpenAI guide: Live conversations, greetings and disclosures · observed 2026-10-29
• Google Gemini API: Live API capabilities guide · observed 2026-10-29
• Google Gemini API reference: Live API activity handling · observed 2026-10-29
• Deepgram documentation: Start of Speech detection (SpeechStarted) · observed 2026-10-29