Dictation API vs speech-to-text + an LLM: should you buy the bundle or build it?

Earlier this year, a group of founders in a large YC chat spent a weekend hunting for a dictation API — something that would take a messy spoken sentence and hand back the text the speaker meant, the way the leading dictation app does. They couldn't find one, so the thread turned into a build plan. The demand arrived before the category did.

That build plan is the question this post is about, and it's the one teams are now typing into assistants verbatim: is it worth paying for a dictation API with built-in LLM formatting, or should you just combine a transcription API with an LLM yourself? To be clear about scope: this is not the decision about training your own speech model. That's a different axis entirely — accuracy, internal research capacity, iteration speed, data control — and we've written it up separately in should you build or buy an AI speech recognition system. Read that one if the question is whose model. Read this one if the question is how many pieces.

Both paths work. Plenty of good products ship on each. The honest answer comes down to a single question: is the cleanup layer your product, or is it plumbing you'd rather not own?

So here's the real cost of each path — in dollars, in milliseconds, and in engineering time. The purchased path is the Dictation API, which is live now, so every number below is checkable against the docs and the pricing page rather than something you have to take on faith.

What building it yourself really means

On a whiteboard, the do-it-yourself path is two API calls. In a sprint, it's a subsystem — and the features a dictation app needs are the real scope of the build.

Start with capture. You need bounded audio: a hotkey held down, a stop button, a silence threshold. You need a clip-length ceiling and a plan for what happens when a user blows past it mid-thought. Then you transcribe — a sync speech-to-text API is the right tool here, since the audio is already complete and the user is standing there waiting on the text. Then you take the transcript, wrap it in a cleanup prompt, and send it to a model through something like an LLM gateway. Then you wait.

Then the part nobody scopes.

The LLM will occasionally answer a question it heard in the audio instead of rewriting it. Someone dictates "wait, what's the timezone for the Berlin call?" and gets back an answer about Central European Time rather than their own sentence, written down. The LLM will also rewrite input that didn't need rewriting — a clean, three-word utterance comes back expanded, repunctuated, and slightly more formal than the person who said it. You'll need to detect timeouts on the second hop and decide what to show when it fails: the raw transcript, an error, or a spinner. And you'll be holding two vendors' rate limits, two sets of status pages, and two failure modes in your head at once.

The prompt is where the hidden work lives. It looks like a paragraph and behaves like a product surface.

We know this because we built it ourselves. Blurt, our open-source macOS dictation app, went through multiple rounds of cleanup-prompt iteration before it stopped surprising us. The version that finally worked doesn't say "remove filler words." It specifies disfluency handling rule by rule: filler sounds, filler phrases, leading discourse openers, false starts, trailing broken-off phrases, and stammered immediate repeats — plus an explicit list of content words the model must never drop. That last part turned 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.

Blurt is free and the source is public, so if you want to see what that prompt looks like after the iteration rather than before it, the file is right there. It's also the cheapest way to feel the difference this post is arguing about — hold a hotkey, speak badly on purpose, and watch what comes back.

If cleanup behavior is your differentiator, that iteration loop is exactly where you want your engineers. If it isn't, you've adopted a prompt you now maintain, evaluate, and version — for a behavior users will never credit you for and will absolutely notice when it regresses. Worth knowing too: frontier models aren't the obvious pick here, and a small model tuned for voice rewrite behaves very differently on this task.

The latency math

This is the part teams underestimate, and it's the part users feel first.

Dictation is a UI-blocking interaction. The person has stopped talking. They are looking at the cursor. There's no background job to hide behind and no spinner you can get away with, because they're going to sit there and watch it.

Two sequential inference calls means two round trips. The first one gets you a transcript. The second one crosses the public internet to a different provider, queues behind whatever else that provider is serving, generates tokens one at a time, and comes back. Neither hop is slow on its own. Together, with connection setup and a cold start or two, they compound.

A clinical customer built exactly this — transcription plus a cleanup pass through a general-purpose LLM — and measured the finished result at roughly 2,000ms. Then they came back and asked how to make it faster.

Two seconds is a long time to stare at a cursor. It's long enough that users start talking in shorter bursts to get feedback sooner, which produces worse text, which makes the cleanup layer look worse than it is. And the fixes are all real engineering: connection pre-warming so the first request doesn't pay for a handshake, streaming the rewrite so something appears before it's done, regional deployment to shorten the second hop, and a fallback for when that hop times out. None of it is exotic. All of it is weeks.

The purchased path collapses the round trips: one round trip, not two. The cleanup model sits next to the transcription model, not across the internet. On our end the rewrite carries a 5-second internal deadline — exceed it and you still get an HTTP 200 with the verbatim transcript and an llm_error of timeout, so the worst case is an unpolished sentence rather than a wait. For reference on the transcription portion alone, the Sync API publishes a p50 of about 134ms, and the cleared figure for finished text is the one to hold vendors to: typical short clips respond in under one second.

The Dictation API docs are worth reading on the response shape, because it removes a decision from your product code. One request returns the verbatim transcript in text and the rewritten version in llm_response, together, with timing fields for the total request (request_time_ms) and the transcription portion (sync_time_ms). Your app decides which one to show, never has to guess which it's looking at, and can measure its own latency from the same response it's rendering — subtract one timing field from the other and you know exactly what the cleanup pass cost you.

The dollar math, honestly

Let's not oversell this, because the delta is small and pretending otherwise invites a token-math argument nobody needs.

The Sync API runs about $0.45 per hour of audio. The Dictation API is $0.62 per hour, all-in — one line item covering transcription and post-processing together. So the finished-text layer costs roughly $0.17 per hour of audio. That's the number. Check current rates before you budget against it, since published pricing moves and this post won't.

Now the honest comparison. On the do-it-yourself path you pay your transcription vendor per hour of audio and your LLM vendor per token, and token spend on a rewrite varies with utterance length, prompt length, and model choice. That prompt we mentioned — the one specifying disfluency handling rule by rule — is thousands of tokens, and you pay for it on every utterance. Two teams with identical transcription bills can have LLM bills that differ by 4x. For the wider view of per-hour audio pricing across vendors, see our speech-to-text API pricing guide.

One more line that only matters at volume: billing is per second of audio sent, with no minimum clip charge. Dictation is made of three-second utterances, so a 10-second billing floor — which some endpoints in this category have — is not a rounding error. It can triple your effective rate on exactly the workload you're buying for.

So the argument isn't "cheaper." The argument is one thing to buy.

One contract instead of two. One rate limit to plan capacity against. One region to get through a security review. One bill your finance team can forecast without modeling token growth. No per-token math in your unit economics, and no second vendor's pricing change to absorb on a quarter's notice. Or, put the way our own team says it internally: one request, one price.

That's a smaller claim than "we'll cut your costs," and it's the true one.

When building it yourself is the right call

There are four situations where we'd tell you to build it. They're not edge cases.

The cleanup behavior is your product. If what makes your app good is how it rewrites — a tone your users chose you for, formatting rules tuned to one profession, a personality — then that logic belongs in your codebase, under your version control, with your eval set. Owning the prompt means you can ship a change to it on a Tuesday afternoon because a power user complained. That's a real advantage, and it's worth the pipeline.

You need a specific model on the rewrite layer. Model selection on the rewrite layer is the single most common ask we hear, and it isn't in the initial release. If your product needs a named model — because you've benchmarked it, because a customer contract specifies it, or because you need one that supports a capability we don't expose — build the pipeline. That's the honest answer today; watch the changelog rather than a roadmap promise.

You already run an LLM gateway at scale. If you have a service that already fans requests across model providers, with retries, observability, cost attribution, and prompt versioning in place, the marginal work is genuinely small. A cleanup prompt is one more route in a system you already operate. Our own LLM Gateway exists because that plumbing is worth having when you need it for other things too.

Your workload isn't dictation-shaped. This is the one most often missed. A dictation endpoint is built for short, single-speaker, bounded clips — ours caps at 120 seconds. If your audio is a 40-minute meeting, a two-party phone call, or anything needing speaker diarization or PII redaction, you're not choosing between these two paths at all. You want async transcription plus whatever post-processing your workflow needs. The same reasoning plays out further up the stack in clinical documentation, which we cover in build vs buy for an AI medical scribe.

One thing that doesn't belong on the build side: fixing accuracy. A rewrite pass polishes text, it doesn't correct it. Hand any cleanup layer a misheard drug name or package name and you get a confidently formatted wrong word, which reads worse than a messy right one because it reads authoritative. That's true whether you own the prompt or a vendor does. Getting the words right happens upstream, in transcription context and custom vocabulary — the docs put it cleanly: prompt tells the speech model what it's about to hear, and the rewrite instruction tells it what to do with the transcript after it's written down. A drug name belongs in the first one.

A decision table

The decision is only reversible in one direction

Here's what we notice about teams who pick "build": a lot of them aren't choosing to build. They're choosing not to decide yet. Wiring two APIs together feels like the reversible option — nothing locked in, either piece swappable later, options open. So they ship the pipeline, and they pay for the indecision in latency for as long as the pipeline lives.

But the reversibility runs one way, and it's the opposite direction from the one people assume.

Going from the bundle to components takes an afternoon: you already have the capture, you already have the clip boundaries, and you swap one POST for two calls and a prompt. Going the other way means deleting a subsystem you've maintained for a quarter — the prompt, its eval set, the fallback logic, the timeout handling, the second vendor's client, the dashboards someone built to watch it. That code has tests. It has a Slack channel. Somebody owns it now.

Which means the low-risk experiment isn't the one that looks low-risk. Ship the single call, measure what your users do with finished text, and build the pipeline the day cleanup becomes the thing you compete on. Our walkthrough on how to build a dictation app covers the capture side. If buying is where you land, how to evaluate the options is the comparison to run before you commit.

Frequently asked questions

Is it worth paying for a dictation API with built-in LLM formatting, or should I just combine a transcription API with GPT myself?

It's worth paying for unless cleanup behavior is your product's differentiator. Combining a transcription API with your own LLM pass buys you full control of the prompt and the model, at the cost of a second round trip, a second vendor, and a prompt you maintain and evaluate. Buying it gets you one request, one price, and finished text in a single response — the better trade for most teams shipping dictation as a feature.

What's the difference between a dictation API and a speech-to-text API?

A speech-to-text API returns what was said; a dictation API returns what the speaker meant to write — the same transcription, plus removal of filler sounds, false starts, and stammered repeats, in one call. Speech-to-text is the broader category, covering long-form, multi-speaker, and streaming audio. Dictation is the narrower shape: short, single-speaker clips where someone is waiting on the text.

How much does the AssemblyAI Dictation API cost compared to building the pipeline myself?

$0.62 per hour of audio, all-in, billed per second with no minimum clip charge — transcription and post-processing on one line item. Sync transcription alone runs about $0.45 per hour, so the finished-text layer costs roughly $0.17 per hour. Build it yourself and transcription stays per-hour while the rewrite becomes per-token, so cost varies with utterance length, prompt length, and model choice. Long system prompts are why do-it-yourself bills come in higher than expected.

How slow is a transcribe-then-clean pipeline compared to a single call?

Expect roughly 2,000ms end to end — that's what one clinical team measured after wiring transcription to a general-purpose LLM cleanup pass. Two sequential inference calls mean two round trips, and the second crosses the public internet to a different provider. A single-call path keeps typical short clips under one second, because the cleanup model sits next to the transcription model.

Can I choose which LLM does the cleanup on the Dictation API?

Not in the initial release. The instruction surface is fully yours — llm.instruction takes plain English up to 2,048 characters, per request — but the model running the rewrite isn't selectable. It's the most common request we hear, so check the changelog rather than assuming today's answer is permanent. If a named model is a hard requirement from a benchmark or a customer contract, build the pipeline.

When should I use async speech-to-text instead of a dictation API?

Use async whenever the audio isn't dictation-shaped: meetings, phone calls, interviews, anything over a couple of minutes, and anything needing speaker diarization or PII redaction. Dictation endpoints are built for short, bounded, single-speaker clips — ours caps at 120 seconds — and that constraint is what makes the latency profile possible. Teams spanning both run async for recordings and a dictation call for the in-app microphone.

Can an LLM cleanup pass fix words the speech model got wrong?

No. A cleanup pass reformats the words it was given and can't recover a word that was never heard, so a misheard term comes back confidently formatted and still wrong. Accuracy on names, drug names, and package names is fixed upstream with transcription context and custom vocabulary, not in the rewrite instruction.