Read the trigger field on the EndOfTurn event. Deepgram Flux stamps every EndOfTurn with one of three words — model, manual or timeout — and that word names the cause. The surprise is usually timeout: eot_timeout_ms defaults to 5000 ms and force-ends the turn even when eot_threshold is 1.0.
This page is about one engine. If you are still choosing an engine, the endpointing surfaces of Deepgram Flux, ElevenLabs Scribe and Speechmatics compared on turn detection is the page for that decision. If you do not yet know which layer is truncating callers — the speech-to-text engine, the framework silence timer or the barge-in gate — start at why your AI voice agent interrupts callers, which composes LiveKit Agents, Pipecat, Vapi, Retell and HighLevel defaults against each other. What follows assumes you have narrowed it to Flux.
Why did my agent cut the caller off when they were still speaking?
Because something ended the turn, and on Flux exactly one field records what. Flux runs a documented state machine over a WebSocket at /v2/listen: StartOfTurn when speech begins, Update roughly every 0.25 seconds of transcribed audio, optional EagerEndOfTurn and TurnResumed events, then EndOfTurn. Deepgram states that the trigger field is present on every EndOfTurn event and only there, and that it states what caused the turn to end (Force End Turn, read 18 September 2026).
So the diagnosis is a lookup, not an inference from audio. Pull the raw TurnInfo messages for the calls that drew the complaint, find the EndOfTurn on the turn that got cut, and read two fields.
The two-field turn autopsy
Call it the two-field turn autopsy: trigger names the cause, and end_of_turn_confidence tells you how far the model was from agreeing. Both arrive on the same message, and the second is the part almost nobody reads.
| What the EndOfTurn says | What actually ended the turn | The fix |
|---|---|---|
trigger is model, confidence at or above your eot_threshold |
Flux native detection. The model judged the utterance complete at a confidence you told it was good enough. | Raise eot_threshold toward 0.85. Deepgram ships 0.85 in its own High-Reliability configuration. |
trigger is timeout |
eot_timeout_ms elapsed. Deepgram documents that this forces EndOfTurn after the specified silence duration even if confidence is below eot_threshold. |
Raise eot_timeout_ms. Deepgram suggests 7000 to 10000 for users with frequent pauses; the ceiling is 60000. |
trigger is manual |
Your own code, or the framework plugin you imported, sent a ForceEndTurn message. Flux decided nothing. |
Fix your detector. Changing any Flux threshold will do nothing at all. |
An EagerEndOfTurn fired, then a TurnResumed, and the agent still spoke |
Eager mode is on and the speculative generation was never cancelled downstream. | Handle TurnResumed as a cancellation, or unset eager_eot_threshold — eager mode is off by default. |
| No EndOfTurn at all, transcript ends mid-word | CloseStream closed the connection without finalising the active turn. |
Deepgram says no EndOfTurn is emitted for it; treat the most recent Update as the last transcript for that turn. |
That order is not a measured incidence rate, and we will not invent one. It follows the published defaults: native detection is on unless you set eot_threshold to 1.0, the 5000 ms timeout is on with no opt-out, manual requires something in your stack to send ForceEndTurn, and eager mode requires a threshold that is unset by default. Reorder it once you have counts from your own calls.
The case that catches people: timeout fires even at eot_threshold 1.0
Setting eot_threshold to 1.0 is what you do when you have your own detector and want Flux for transcription only. Deepgram is explicit that this suppresses natural EndOfTurn events. It is equally explicit that it does not suppress everything. On the Bring Your Own Turn Detection page, read 18 September 2026, three things still end a turn at 1.0: a ForceEndTurn you send, eot_timeout_ms firing with a trigger of timeout, and CloseStream, which emits no EndOfTurn at all.
The default is 5000 ms, and the bring-your-own recipe on that same Deepgram page sets eot_timeout_ms to 30000 precisely because 5000 is too tight for a backstop. Leave it unset and an engineer who believes they own turn detection outright still has a five-second guillotine running, and a caller who reads a policy number in groups, or translates in their head, will meet it. Deepgram frames the parameter as a safety net: keep eot_timeout_ms as a backstop, not a primary mechanism, and if it fires often, tune your detector rather than lowering the timeout.
Note the second-order effect. Deepgram documents that the timer resets when new speech is detected, so a caller who murmurs every three seconds never trips it and a caller who goes properly quiet at five seconds always does. The failure is therefore concentrated in exactly the callers you least want to cut off.
Counting it in the log without a debugger
Two published Flux figures give you a signature to grep for. Deepgram documents on the Flux state machine page, read 18 September 2026, that Update messages are sent for approximately every 0.25 seconds of transcribed audio regardless of transcript updates — which is what makes them countable through a silence — and the default timeout is 5000 ms, so 5000 / 250 gives about 20 consecutive Update messages whose transcript does not change, then an EndOfTurn with a trigger of timeout. That arithmetic is ours, from two numbers Deepgram publishes separately; the cadence is documented as approximate, so treat roughly 20 as a shape, not an exact expectation.
What end_of_turn_confidence tells you that trigger does not
On a manual end, Deepgram documents that end_of_turn_confidence is the actual confidence of the model at the moment you forced the end, and is not inflated to 1.0. Their worked example on the Force End Turn page shows 0.35 against a transcript reading “I need to cancel my subscription” — the model was well short of ending that turn on its own. Deepgram says plainly: use it as diagnostic data.
That makes it a free scoring system for your own detector. Log end_of_turn_confidence on every manual EndOfTurn for a week. A distribution clustered near your eot_threshold means your detector and Flux broadly agree, and you can leave both alone. A distribution clustered around 0.3 means your detector is consistently cutting in before the model would have, and the truncated turns your callers are complaining about come from your detector, not from Flux.
The fix that is not a single number: Configure per segment
The instinct is to pick one patient value and ship it, which charges every caller the same wait on every turn, including one-word answers. Flux offers better: the Configure control message updates eot_threshold, eager_eot_threshold, eot_timeout_ms, keyterms, language hints and numerals mid-stream, with no reconnection and no dropped audio.
Deepgram names this use case itself on the Configure page, read 18 September 2026: when you are collecting a password, one-time code or account number, you do not want Flux cutting off the user mid-utterance, so increase eot_timeout_ms and eot_threshold for that segment and decrease them when you are back to natural conversation. Three behaviours to design around, all on the same page: updates apply immediately when processed and turn boundaries do not affect when they take effect; already-transcribed audio is not reprocessed; and a Configure that fails validation returns ConfigureFailure and leaves the stream on the previous configuration. The last one matters because a silently rejected patience setting looks exactly like one that did not work.
The published ranges, and the one rule that errors the connection
Every value below was read from Deepgram End-of-Turn Detection Parameters on 18 September 2026.
| Parameter | Range | Default | What it causes when it is wrong |
|---|---|---|---|
eot_threshold |
0.5 to 1.0 | 0.7 | Too low, the model ends turns on thinking pauses. At 1.0 native detection stops entirely and the timeout becomes your only ending. |
eager_eot_threshold |
0.3 to 0.9 | Not set, eager mode disabled | Set low, more false starts and more LLM calls. Set above eot_threshold, the request errors. |
eot_timeout_ms |
500 to 60000 | 5000 | Fires regardless of confidence. At the 500 floor almost every pause truncates; at 60000 a dropped detector hangs the turn for a minute. |
The validation rule is the one that bites in staging: eager_eot_threshold must be less than or equal to eot_threshold if both are set, and setting it higher results in an error. Deepgram documents an error rather than a degraded transcript, so the pair fails loudly rather than quietly, but it does not document what form that error takes on the connection URL; sent mid-stream, the same rule comes back as a ConfigureFailure message and the stream carries on with the previous configuration. It is easy to create by tuning the two numbers in separate commits.
Worth knowing where that check happens. In the framework layer between you and the vendor API, it may not happen at all: pipecat-ai/pipecat issue 5637, opened 5 September 2026 and still open as at 18 September 2026, reports that DeepgramFluxSTTService serialises the keyterm list and all three threshold values straight into the connection URL without validating them against the documented ranges first. The reporter is careful about scope — they verified the serialisation offline and did not execute the live handshake — so read it as an unvalidated value reaching the provider, not as an observed provider response. Either way, the range check you assume your SDK performs may be Deepgram performing it at connect time.
Tune it yourself, or hand the tuning over
The method above is complete and you can run it this afternoon. What it costs to run is the honest part.
| Your situation | Do it yourself | Hand it over |
|---|---|---|
| One language, one call type, thresholds set once at connect | Yes. Read the trigger field on twenty calls, change one number, re-measure. | Not worth it |
| Calls that collect account numbers, codes or addresses mid-flow | Workable, but you are now writing Configure messages keyed to your dialogue state | Marginal |
| Several languages with different pause habits on one number pool | Costly. Each needs its own threshold pair and its own labelled sample. | Reasonable |
| Framework plugin changes under you mid-quarter | Ongoing. Issue 5637 has been open since 5 September 2026. | Reasonable |
| Audio cannot leave your infrastructure | Only if you can self-host the engine | Only with private model deployment on your own infrastructure |
The arithmetic is yours. A single-language agent with fixed thresholds is an afternoon of log reading and then it is finished. A multilingual programme means a threshold pair per language, re-validated whenever the plugin or the model version moves. Zian AI runs its Customer Support Agent across 30+ languages for that reason, and supports private model deployment on customer infrastructure where audio cannot leave the building.
Either way, do this before launch: a scripted call that pauses deliberately mid-number, folded into the pre-launch test pass for a voice agent, because unscripted human testers do not reproduce a five-second pause reliably. And if the agent is stopping its own sentence rather than truncating the caller, that is a different subsystem — see the agent interrupting itself on false interruptions.
Frequently asked questions
Which field tells me why Deepgram Flux ended the turn?
The trigger field on the EndOfTurn event. Deepgram documents it as present on every EndOfTurn event and only there, with three values: model for native detection, manual for a ForceEndTurn you sent, and timeout for eot_timeout_ms elapsing. Deepgram also notes that trigger is an open set, so handle unrecognised values gracefully.
Does eot_threshold of 1.0 stop Flux ending turns by itself?
It stops native detection only. Deepgram documents on its Bring Your Own Turn Detection page that at 1.0 three things still end a turn: a ForceEndTurn you send, the eot_timeout_ms backstop firing with a trigger of timeout, and CloseStream, which emits no EndOfTurn at all. The timeout defaults to 5000 ms and the maximum is 60000 ms.
What is the default Deepgram Flux end of turn timeout?
5000 ms, with a documented range of 500 to 60000 ms. It forces an EndOfTurn after that much silence even if confidence is below eot_threshold, and the timer resets when new speech is detected. Deepgram suggests 7000 to 10000 for users with frequent pauses and 3000 to 4000 for rapid-response environments.
Can I change Flux turn detection settings during a call?
Yes. A Configure control message updates eot_threshold, eager_eot_threshold and eot_timeout_ms mid-stream without reconnecting, and Deepgram recommends exactly that for segments where a caller reads a password or an account number. Updates apply immediately when processed, and a rejected Configure leaves the stream running on the previous settings.
What happens if eager_eot_threshold is higher than eot_threshold?
Deepgram states that eager_eot_threshold must be less than or equal to eot_threshold when both are set, and that setting it higher results in an error. Sent mid-stream instead, the same rule comes back as a ConfigureFailure message and the stream continues on the previous configuration. Eager mode is disabled by default, and turning it on also adds EagerEndOfTurn and TurnResumed events that your application has to handle as speculative generation and cancellation.
If trigger says manual, is the problem Deepgram?
No. A trigger of manual means something in your stack sent a ForceEndTurn message, so Flux ended the turn on request rather than on judgement. Changing a Flux threshold will not help. The useful signal is end_of_turn_confidence on that same message, which Deepgram documents as the real model confidence rather than an inflated 1.0, so a low value means your own detector cut in early.
Turn truncation is not a prompt problem and a better voice will not fix it. On Flux it is a one-field lookup followed by a deliberate choice about how patient you can afford to be, per segment of the call rather than per deployment. If you would rather have that tuned per language and per campaign than maintain it yourself, Zian AI is in partnership-application beta. Apply For Partnership.