The dictation pipeline, end to end

Move work out of the window the user is actually waiting in. Pre-warm the connection before they start speaking so DNS, TCP and TLS setup is already done, and upload audio while they are still talking rather than after they stop — then the only thing left at key-up is the last stretch of audio plus the model pass. Typical short clips come back in under a second, and every response carries request_time_ms so you can measure your own numbers rather than trusting ours.

Six places: capture, bounding the clip, connection setup, upload, the model pass, and writing the text back. Only two of those are ours — which is why the table above gives the latency effect of each step rather than a single end-to-end number. Connection setup and upload are the two most teams leave in the critical path by accident, and both are removable. For the broader voice-AI picture, our 300ms rule post covers full pipeline latency.

No — and the endpoint will reject it with a 415. It takes WAV or raw 16-bit PCM only. This is usually the right trade anyway: you are capturing from a microphone, so raw PCM is already what you have, and encoding would add CPU time inside the window the user is waiting in to save bandwidth you are not short of on a clip of a few seconds.

Use dictation when the user finishes speaking before they expect text — push-to-talk, a voice input field, a hotkey. Use streaming when text has to appear mid-sentence while they are still talking, like live captions. The decision test is literally that: does text appear during the utterance, or after key release? Dictation also caps at 120 seconds per call, so open-ended sessions belong on streaming regardless.

No. One rate covers the whole request — transcription and the rewrite together, billed on audio length rather than tokens, so there is no second model to forecast and no token math to do. Keyterms, prompting and output instructions are included rather than priced as add-ons. Current rates are on the pricing page.

The rewrite is best-effort on a five-second deadline. Past it the API returns HTTP 200 with the verbatim transcript and llm_error: "timeout" — a non-null llm_error is not a failed request. In the Python SDK, result.final_text does the fallback: the rewrite when there is one, the transcript when there is not. Design for plainer text, not for an error path.

Both come back in the same response, so nothing is lost by turning cleanup on. result.text is the verbatim transcript and is always present, result.llm_response is the paste-ready rewrite, and result.final_text is the rewrite with a fallback to the transcript. Keeping the verbatim text is useful for audit trails and for letting a user see what they actually said.

Universal-3.5 Pro ranks first for accuracy across independent benchmarks and posts a mean of 3.87% normalized word error rate on short-form audio — which is the length dictation actually produces, rather than the long-form audio most WER figures are measured on. Accuracy on your own vocabulary is the part you control: pass your product, customer and domain names as keyterms, up to 100 per request.

Not necessarily. Reach for the Sync API when you want the transcript itself, and the Dictation API when the text goes straight into whatever your user is writing. If you have a working Sync build, our Sync API dictation tutorial and push-to-talk guide still apply, and Sync API or Dictation API? walks through the choice.

Yes — Blurt is a free, MIT-licensed macOS dictation app built on this API, and the source is on GitHub. It implements this pipeline end to end, including the pre-warm and upload-while-recording steps, so it is the fastest way to see the sequence working rather than described.