/v1/transcribe/live gets them back fastest. That endpoint accepts up to 120
seconds of audio. /v1/transcribe accepts a finished recording of up to 20
minutes, with the same config and the same response. You don’t know how long
the user will talk when they start, so start every dictation on the live
endpoint, and send it to /v1/transcribe only when it runs past 120 seconds.
How the fallback works
When a live upload passes 120 seconds, the endpoint answers413 with
error_code: "audio_too_large" as soon as the limit is crossed. That can
arrive while the user is still talking. The fallback is built around that one
response:
- Keep a copy of every audio frame you send to the live endpoint, from the first one.
- Fall back only on
413witherror_code: "audio_too_large". Surface every other error as usual. A413with any other body is a different problem. - Keep recording after the
413. The user hasn’t stopped talking, so keep reading the microphone into the copy until they do. - Send the whole copy to
/v1/transcribeonce, with the sameconfig, when the recording ends. Treat its response exactly like a live one. If it fails, surface its error, not the413. - Stop at 20 minutes, the limit on
/v1/transcribe. - On cancel, drop everything. Don’t send a fallback request for a recording the user discarded.
/v1/transcribe reads the full body before it starts. That only applies
to recordings over two minutes. Shorter ones get the live endpoint’s latency,
as before.
Example
Both examples upload 16 kHz mono 16-bit PCM while recording, and take your microphone loop as an iterator of audio frames that ends when the user stops.- Python
- JavaScript (Node.js 18+)
The Python SDK’s
transcribe_live() and open_live() stop at 120 seconds
and don’t fall back, so use HTTP for recordings that can run longer. Blurt,
AssemblyAI’s open-source dictation app, ships the same fallback in Swift:
see AssemblyAITranscriber+LiveCapFallback.swift.Making the fallback faster
The fallback’s wait is mostly upload time, so a smaller file comes back sooner./v1/transcribe accepts compressed audio, such as Ogg/Opus
(audio/ogg) and FLAC (audio/flac). Encoding the copy before you send it
cuts the upload for long recordings. FLAC is lossless; Opus is much smaller
but lossy, so check transcription quality on your own audio before switching.
See Audio requirements for the accepted
formats.
Related pages
- Achieve lowest latency: the live upload this builds on
- Audio requirements: the limits on each endpoint
- Error handling: every status code and what to do about it