Deepgram smart_format delays finalising one-word numeric answers by about 7 seconds
With smart_format=true, Deepgram streaming holds back is_final and speech_final for lone spoken numbers ('Five.') for roughly 7 s. Measured table, background-noise effect on endpointing, and why a 1.5 s client-side stability timer is too short.
deepgramsttlatencyvoice-agentsendpointing History
Symptom
In a live voice-agent call, every one-word ratings answer ("Five.", "One.") was followed by 7-9 s of silence before the agent replied. Per-turn timing showed the delay was entirely in end-of-speech to end-of-turn (5.7-7.9 s). LLM and TTS latency were normal. Full sentences ended their turn in 1.2-1.8 s and two-word answers ("Twenty hours.") in 1.7-2.7 s.
Cause
Deepgram's documentation says that with smart_format=true it "may purposefully wait for additional audio from the speaker so it can properly format the transcript" (numbers, phone numbers). A lone spoken number is exactly that case, so the service waits in case more digits follow. Interim results keep repeating about every 1.2 s until the final arrives.
Measurement
A synthesised answer was streamed in real time in 40 ms frames followed by silence, with endpointing=850, utterance_end_ms=1000, punctuate=true.
| Answer | smart_format=true | smart_format=false | |---|---|---| | "One." | final + speech_final at 7.0 s | 1.13 s | | "Five." | 6.9 s | 1.14 s | | "Twenty hours." | 1.1 s | 1.1 s | | Full sentence | 1.3 s | 1.3 s |
Fix
Set smart_format=false and keep punctuate=true. Punctuation still arrives promptly, and numbers come back as words, which an LLM handles without trouble. After the change, one-word answers ended their turn in 1.2-1.4 s in the full application.
Background noise also delays the final
Measured October 2026 with smart_format off, using white noise mixed into the audio and continuing after the words:
| Noise level | Result | |---|---| | Quiet | final + speech_final at 1.1 s | | Peak 300 (about -41 dBFS) | 1.1 s | | Peak 1200 (about -29 dBFS) | 3.5 s | | Peak 4000 (about -18 dBFS) | no speech_final; final at 4.9 s together with UtteranceEnd |
Noise delays the final rather than suppressing it. UtteranceEnd also waited for the final and did not fire from interim word timings, so using UtteranceEnd as an early signal buys little.
Client-side stability timer
A client-side timer that ends the turn when the interim transcript has not changed for 3 s (with no final received) worked, dropping the late final only if it repeats the same words and appending any extra words if it is longer. A 1.5 s timer was too short: in a quiet test Deepgram left the interim unchanged for 1.5 s mid-sentence before finalising, the turn ended on "Most days, I" and "No. That", and the rest of each answer was lost. Interim cadence is not a reliable end-of-speech signal.
Sources
- https://developers.deepgram.com/docs/smart-format Vendor documentation stating smart_format may wait for additional audio to format the transcript.
- Observed directly with a streaming probe, October 2026, Deepgram live streaming API.