Build1 publisher3 min readPublished
A second check on a 300ms silence cutoff cut voice-agent interruptions from 22% to 3.1%
Preterview's developer cut mid-answer interruptions from 22% to 3.1% by confirming Deepgram's 300ms silence cutoff with a completeness check. The fix added 140ms at the median, against about 900ms for a longer timer, and threw away one drafted reply in five.
The Engineer · Build desk
What happened
- At Deepgram endpointing=300, 251 of 1,140 long answers in a week of Preterview traffic were cut off mid-thought, a 22% rate.
- Raising endpointing to 1200ms brought cutoffs down to 6% but added about 900ms of dead air to every turn.
- Treating 300ms as a tentative end, confirming it with a trailing-word heuristic and a small LLM classifier, and drafting replies speculatively gave 3.1% cutoffs at +140ms median delay.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost The operator pays for LLM generation that gets thrown away on 19% of drafted replies, plus a classifier call on every tentative end.
- constraint No single silence timer covers this pause distribution, because every longer setting is charged to every turn and still leaves the 2.4-second tail exposed.
- decision Teams with long-answer traffic have to choose between charging latency to every user and charging compute on discarded drafts, and these numbers favour paying the compute.
Deepgram's flag is a statement about silence and nothing more. The endpointing parameter is a timer on the streaming speech-to-text side. When the voice activity detector hears no speech for that many milliseconds, the transcript is finalized and marked speech_final: true [1]. Most agent loops, the developer's included, read that flag as the user handing over the turn [2]. The developer wrote that speech_final means "silence happened" and does not mean "the thought is finished" [15].
The config was `endpointing=300`, on nova-2 with `utterance_end_ms=1500` and interim results on [3]. Thinking pauses had a median of 0.9 seconds [5], so the timer fired at about a third of the typical pause [3]. In 97% of the long answers there was at least one pause the config counted as a finished turn [6]. The developer had spent two weeks making the agent respond faster [17], and wrote: "I had built a very fast machine for interrupting people." [16]
A longer timer cannot close that gap. The 90th-percentile pause was 2.4 seconds [5]. At least one thinking pause in ten therefore outlasted both the 1200ms setting tried first and the 1500ms utterance_end_ms already in the config [4]. Every step up the timer is charged to every turn, including turns that were plainly over. After two days at 1200ms, the developer wrote, "The session recordings sounded like talking to someone on a satellite phone." [10]
The two-gate design keeps the fast timer and changes what it means. A 300ms silence becomes a candidate end. A trailing-word heuristic and a small LLM classifier then judge whether the transcript is complete before the agent commits, and the reply is drafted speculatively in the meantime [11]. The waiting cost moves from the user to compute. The 140ms median is about 760ms less than the roughly 900ms the long timer added [2]. One figure is a median and the other an approximation, so treat that gap as indicative. Cutoffs fell about sevenfold from the 300ms baseline, and to roughly half the rate at 1200ms [5].
The measurement is careful work. Cutoffs were counted as barge-backs: the user speaking again within 2.5 seconds of the bot starting its turn. The developer checked that proxy against 200 hand-labeled sessions and it agreed in 181 [7], or 90.5% [1]. Most misses were people saying "sorry, go ahead" or coughing [7]. The developer set the limit plainly: "Good enough to trust the trend, not good enough to trust the second decimal place." [8] I would read 3.1% as about 3%. The post does not say how long the two-gate build ran or how many answers the 3.1% was measured over.
Whether the result transfers depends on how users talk. Preterview is a mock-interview tool the developer built, and the developer calls interview answers close to the worst case for endpointing [13]. For quick commands, silence and a finished thought are the same event [14]. A bare 300ms timer is probably fine there. The numbers apply to agents whose users speak for more than 10 seconds at a stretch and stop to think mid-answer, the population the 22% came from [4]. For that traffic I would pick the two-gate design over the long timer.
What to watch
- Whether the developer publishes the sample size and run length behind the 3.1% figure, and re-validates the barge-back proxy on the two-gate build.
- How often the completeness classifier holds a turn open when the user was actually done, a cost that would show in tail latency rather than the 140ms median.