Flux TTS

Batch vs Streaming: Which Should I Use?

Both transports serve the same Flux voices. Use streaming for live, conversational voice agents; use batch for pre-rendering fixed audio you know up front.

Flux TTS is served on /v2/speak over two transports against the same voices. They’re not tiers — pick by how the audio is consumed.

The short answer

  • Building a voice agent or any live, conversational experience? Use streaming (WebSocket) — it streams audio as text arrives and keeps prosody consistent across turns.
  • Pre-rendering audio you know up front (IVR prompts, notifications, audiobook lines)? Use batch (REST).

Side by side

Streaming (WebSocket)Batch (REST)
Endpointwss://api.deepgram.com/v2/speakPOST https://api.deepgram.com/v2/speak
InputText streamed in as it’s produced (LLM tokens)One complete block of text
OutputAudio streams back incrementallyFull audio in one response
Time-to-first-byteLow — playback starts before the full response existsWhole clip generated before you get it
Interruption / barge-inYes (planned for GA)N/A
Turn lifecycle & cross-turn contextYesN/A (stateless request/response)
Mid-stream controlConfigure speed (planned for GA)Fixed per request
EncodingsRaw linear16 / mulaw / alawContainerized/compressed too: mp3 (default), opus, flac, aac
Operational modelLong-lived connection, lifecycle to manageStateless: simple retries, high fan-out

Choose streaming when

  • The text is produced incrementally (you’re streaming from an LLM).
  • The user may barge in mid-response — when barge-in ships at GA, Interrupt will cancel in-flight synthesis and report what they heard.
  • You want the lowest possible time-to-first-audio in a back-and-forth conversation.
  • You want tone to carry across turns.

Choose batch when

  • The full text is known before you synthesize.
  • You’re pre-generating reusable assets (prompts, notifications, narration).
  • You want a stateless request/response with easy retries and high concurrency, and don’t need incremental playback or interruption.