Deepgram's filler_words parameter governs seven tokens, but the default (false) only strips two hesitation markers, uh and um. The other five tokens (mhmm, mm-mm, uh-uh, uh-huh, nuh-uh) are backchannel agreement/disagreement signals, and Deepgram's own docs table shows uh-huh surviving the default while leaving the other four unclassified. This matters for court records, clinical notes, and LLM pipelines, since a clean-looking transcript can still hide a spoken yes or no. The piece walks through legal and clinical transcription standards, model support inconsistencies across Deepgram's docs (Nova vs Nova-3 vs Flux), English-only language coverage, and gives a decision table for when to enable verbatim mode versus the clean default.
Table of contents
Key takeawaysWhat a filler word actually signalsWhat Deepgram detects, and what the default stripsFive of the seven are agreement tokens, not hesitationWhen you need verbatimWhen you need cleanModel and language limitsA decision tableFAQQuestions this post answers
What does Deepgram's filler_words parameter default to and what does it actually remove?
The filler_words parameter defaults to false on Deepgram's Nova-family models, and at that default only two tokens are stripped from the transcript: uh and um. Deepgram detects seven tokens total (uh, um, mhmm, mm-mm, uh-uh, uh-huh, nuh-uh), but the docs only confirm uh and um as removed; uh-huh is shown surviving the default in Deepgram's own results table, while mhmm, mm-mm, uh-uh, and nuh-uh remain unclassified at default. Anyone tuning transcript pipelines for legal or clinical accuracy can track API parameter quirks like this via daily.dev.
Are uh-huh and uh-uh hesitation markers or answers in speech transcription?
They are backchannel answers, not hesitation markers. Five of Deepgram's seven documented filler tokens (mhmm, mm-mm, uh-uh, uh-huh, nuh-uh) are listener agreement or disagreement signals rather than speaker stalling sounds; only uh and um mark hesitation. uh-huh typically reads as yes and uh-uh as no, differing by a single letter, so stripping them can erase a spoken answer. Teams building transcript-to-LLM pipelines can weigh tradeoffs like this on daily.dev before picking a setting.
Which Deepgram models support the filler_words parameter?
Deepgram's documentation pages disagree with each other on this. The feature page limits filler word support to Nova, Nova-2, and Nova-3 general models, but the Flux and Nova-3 comparison table marks Nova-3 as unsupported while listing Flux as supported, and the models overview page separately recommends Nova-2 for filler word identification. The feature is English-only across all available regions. Developers comparing speech-to-text model coverage can cross-check conflicting vendor docs via daily.dev.