Dictation features: What product teams are shipping in 2026

On August 17, the leading dictation app closed a $280M Series B at a $2B valuation. Whatever anyone believed about voice input as a category last year, the demand question is settled — and it got settled by a balance sheet rather than by an argument.

The how isn’t settled at all.

Ask ten teams shipping voice input what a dictation feature consists of and you’ll get ten different lists, most of them assembled after launch in response to what users complained about. Nearly all of them start from the same assumption: that dictation is a transcription call with a microphone in front of it. It isn’t. Teams who find that out in week six rebuild what they shipped in week two.

So this is the inventory, written from the build side. It’s not a roundup of apps to install, and it’s not an explainer on what a dictation API is — that page exists and covers the mechanics step by step. What follows is the feature list your users will measure you against, whether you’re adding voice to a notes app, a collaboration tool, a developer tool, or a clinical workflow.

Seven features. Two architectures. And one thing nobody puts on the list.

The seven features that define a dictation feature in 2026

Dictation used to be a toggle. Now it’s a system, and users notice each piece of it individually — usually by noticing an absence.

Here are seven features that are defining the dictation features in 2026"

AI cleanup (the one that changed the category)

Speech recognition returns what was said. People want what they meant.

Those are different products. Read a verbatim transcript of yourself talking and you’ll find what cleanup removes: filler sounds, a false start, a sentence you abandoned halfway, and a word you said twice. None of that is a recognition error — it’s a faithful record of how humans talk. It’s also not text anyone wants to paste into a Jira ticket.

Cleanup is what separates 2026 dictation from the dictation built into your operating system, and users feel it in the first ten seconds. Building it yourself means a second inference pass, a cleanup prompt you’ll rewrite a dozen times, and rules specific enough to drop a stammered repeat without eating a real word. Most teams reach for a general-purpose model through something like an LLM Gateway and discover the prompt is the product surface, not the plumbing.

Custom vocabulary and jargon handling

This is the most repeated complaint in every community thread about dictation, in every vertical.

A developer dictates a package path and gets “bolt module pa portal” instead of bolt.module.paportal. A clinician who spent three months training a Dragon vocabulary still watches “thickened endometrium” come back as “chicken endometrium.” The words that matter most in a dictated sentence are the ones a general model has least reason to expect: internal product names, drug names, version strings, ticket IDs, surnames.

The fix belongs at the recognition layer, not the cleanup layer, and it’s cheap in the right order — keyterms prompting for terms you know are coming, plus contextual prompting for domain jargon to describe the setting the audio comes from. And track entity accuracy rather than word accuracy, because aggregate word error rate will happily hide every miss your users care about.

Push-to-talk and hands-free modes

Two interaction models, and shipping one of them annoys half your users.

Hold a hotkey and speak, release and the text lands: that’s push-to-talk, and it’s what people want for short bursts inside another app. Double-tap the same key and stay open, and that’s hands-free, for the long note where holding a key gets tiring. Ship both, plus configurable shortcuts, because a hotkey that collides with someone’s IDE binding is a hotkey they turn off.

Our walkthrough on how to build push-to-talk dictation covers capture, encoding, and the error cases real hardware produces.

Voice commands and spoken punctuation

“New paragraph.” “Delete that.” “Send it.”

Voice commands look like polish and turn out to be load-bearing. The clearest case is medicine, where it isn’t a preference at all: physicians are trained in medical school to speak their punctuation. A doctor says “patient open parentheses Andrew close parentheses is tired” and expects (Andrew) on the screen, because that’s how they were taught to dictate into a recorder and have done every year since.

Get it wrong and you don’t get a bug report. You get a clinician who hand-edits every note and quietly stops using the feature — one reason clinical dictation carries its own expectations instead of inheriting the consumer ones.

Context awareness

The same sentence should come out differently depending on where it lands.

Dictated into a terminal, “run the tests and fix whatever breaks” is an instruction — the whole premise of dictating to coding agents. Dictated into an email, it’s a request that needs a greeting. Dictated into a field that already holds half a paragraph, it needs to continue that paragraph’s tense and register rather than starting fresh. Context means what app you’re in, what’s already in the field, and what the user had selected when they started talking.

It’s the least visible feature here and the biggest quality jump per line of code, because it costs one extra string in the request and changes every output.

Dictation history

Boring. Expected. The loudest complaint when it’s missing.

Users treat dictation as a place they put thoughts, which means they assume the thoughts are kept. A dropped transcript — a network blip during a four-minute brain dump, a crash, a window that closed — is the first reported failure of thin voice integrations, and it turns an enthusiastic user into a suspicious one permanently. Ship a history tab, make it searchable, and be explicit about what you retain. Voice-note transcription features hit the same wall: “where did my recording go” is the support ticket that never stops.

Latency you can design around

The bar isn’t “fast.” It’s predictable.

Dictation is a UI-blocking interaction. The user has stopped talking, they’re looking at the cursor, and there’s no background job to hide behind or spinner that reads as acceptable. What matters is the shape of the distribution, not your best result out of twenty attempts — a p50 you can design an animation around, plus a p95 that doesn’t embarrass you.

That’s why short-clip endpoints exist as their own product class. The Sync API returns a complete transcript for a bounded clip at roughly 134 ms p50, and dictation is the first use case named on its page — not a coincidence, since it’s the workload that motivated it.

Granola, whose notes app runs on AssemblyAI transcription, put the user-visible version of that better than a chart can:

The speed difference is immediately noticeable — our users see their conversations transcribed almost instantaneously. It feels so much more responsive than what we were using before.

— Jonathan Kim, Software Engineer

Two patterns teams are using today

Once you have the feature list, the architecture question narrows. Nearly everything shipping today is one of two shapes.

One clip per utterance

The user controls the start and the stop. They hold a key, they speak, they release, and you send one bounded clip and get one finished result back.

This is the shape that fits dictation, because the audio is already complete when you send it. No turn to detect, no endpointing heuristic to tune, no partial hypothesis to render and then revise on screen. Bounded audio is its own category of workload — push-to-talk dictation, voice notes, voice commands — and it behaves differently from a live stream in ways worth knowing before you pick a transport. If that distinction is new, sync vs streaming vs batch is the map.

One request also fails more gracefully than a socket does. A single POST survives a WiFi-to-cellular handoff that would kill a WebSocket mid-sentence.

Chunk per pause

The second pattern cuts on natural silence and inserts progressively instead of dumping a block of text at the end.

Teams reach for it when dictation runs long, which in practice means clinical documentation. A routine SOAP note runs 250–400 words, or two to three minutes of speech; complex hospitalist and psychiatric notes run past 800. Nobody dictating that long wants to watch a blank field for three minutes and then read a wall of text from the top.

Chunking on pause solves the experience problem and the architectural one together: each request stays comfortably inside a per-clip length ceiling, and the person dictating gets something to react to while they’re still talking. The tradeoff is that your cleanup layer sees each chunk without the ones around it, so context has to be carried forward deliberately.

Who’s shipping what

The list above isn’t theoretical. It describes what’s already in market.

Fireflies ships a desktop dictation app where Fn dictates into any application, a double-tap switches to hands-free, shortcuts are configurable, there’s a dedicated dictation history tab, and they’re explicit about not logging private data. Every one of those maps to an item above. Granola offers dictation on desktop and mobile, and exposes model choice on mobile — a strong signal about how much users care about the cleanup layer once they’ve compared two of them. Confluence and Rovo are adding dictation-style input to a surface nobody was asking to talk to two years ago.

Different products, converging spec. When several teams independently ship the same seven things, that’s not a trend. It’s a baseline.

What the build looks like today

Which brings me to the part teams underestimate, because on a whiteboard it’s two boxes.

You capture bounded audio, you transcribe it, and you run the transcript through a rewrite pass. The transcription half is the easy half. The Sync API is built for exactly this shape — audio that’s already complete, and a person waiting on the text — and it runs on Universal-3.5 Pro, the same flagship model behind our pre-recorded and streaming endpoints rather than a smaller variant tuned for speed. That distinction matters more than it sounds like it should, because in most stacks “make it faster” means “use the smaller model,” and the accuracy tax hides inside the latency win.

The rewrite half is where the sprint goes.

You’ll wire the transcript to a model — through an LLM Gateway or straight to a provider — and then you’ll discover the failure modes nobody scopes. The model will occasionally answer a question it heard in the audio instead of writing it down. It will rewrite input that didn’t need rewriting, returning a clean three-word utterance expanded and slightly more formal than the person who said it. You’ll need to detect timeouts on the second hop and decide what to render when it fails: the raw transcript, an error, or a spinner nobody wants.

And the prompt looks like a paragraph and behaves like a product surface. The version that finally works doesn’t say “remove filler words” — it specifies handling rule by rule, filler sounds through trailing broken-off phrases, plus an explicit list of content words the model must never drop. That last part turns out to matter most. Getting a rewrite to remove things is easy. Getting it to stop removing things is the hard part, and you only learn which rules you’re missing by watching real users lose real words.

Now the boundary, because it’s the thing teams most often assume works the other way.

The rewrite polishes. It does not correct. Hand it a misheard drug name and you get a confidently formatted wrong drug name — properly capitalized, correctly punctuated, and worse than the messy version, because it reads authoritative. A fluent wrong answer is harder to catch than an obvious one. That fix is upstream work, at the recognition layer where the word was lost, in contextual prompting and keyterms.

The feature nobody lists

Every feature above is table stakes, and none of them is what users judge you on.

What they judge is whether the text is there when they look up from the microphone. That’s the whole evaluation, and it happens before they’ve read a word of the output. Cleanup quality gets noticed on the second use. Jargon accuracy gets noticed on the fifth. Whether the text beat their eyes back to the screen gets noticed every time, and it sets the mood for everything they’re about to read.

Which says something slightly uncomfortable about how these features get prioritized. Cleanup, vocabulary, history, and commands go on a changelog. There when they look doesn’t, and it decides whether anyone uses the rest.

Frequently asked questions

What features should a dictation app have?

A modern dictation app ships seven things: AI cleanup of filler words and false starts, custom vocabulary for domain terms, push-to-talk and hands-free modes, voice commands including spoken punctuation, awareness of the app and field being dictated into, a searchable dictation history, and predictable low latency. Users notice each one individually, and they notice absences faster than features. Those seven are what separate a 2026 dictation feature from the dictation built into an operating system.

How does AI dictation cleanup work?

AI dictation cleanup takes the transcript of what someone said and returns the text they meant, removing filler sounds, false starts, and stammered repeats while leaving the remaining words, spellings, and punctuation as spoken. It runs after recognition, so it reformats words it was given rather than recovering words that were never heard. Cleanup polishes; it does not correct a misrecognized term.

How do I add a dictation feature to my app using an API?

Capture bounded audio with a push-to-talk hotkey, send the clip to a sync speech-to-text endpoint in one request, and insert the returned text at the cursor. Most teams add a rewrite pass next, to strip the filler that a verbatim transcript faithfully preserves, and then custom vocabulary after that, since domain terms are the first thing users complain about. The order matters: getting the words right has to happen before anything downstream tries to tidy them.

What’s the difference between a dictation API and a transcription API?

A transcription API returns an accurate record of what was said; a dictation API returns finished text a user can send without editing. The workloads differ too: dictation means short, single-speaker clips where someone is waiting on the result, while transcription usually means longer multi-speaker recordings processed in the background. That changes what you test for, starting with time to finished text rather than aggregate word error rate.

How much does it cost to add dictation to an app?

Budget for two line items rather than one. Transcription is priced per hour of audio and is the predictable half — check current rates before you model anything. The rewrite pass is usually priced per token, which means it varies with utterance length, prompt length, and model choice, and a long system prompt is charged on every single utterance. Two teams with identical transcription bills can have rewrite bills that differ several times over.

Can a dictation feature handle medical or technical terminology?

Yes, but the fix has to happen at the recognition layer rather than the cleanup layer. Passing a prompt that describes the setting, plus keyterms for the specific terms you expect, biases recognition toward the drug names, package paths, and internal product names your users say. Adding those terms to a rewrite instruction does nothing, because the word was already lost before the rewrite ran.