Offline vs Realtime: A Selection Guide
On this page
Course updated November 3, 2026 for Voxtral 3, based on Mistral’s Migrate from Voxtral 2 guide: Voxtral 2 models (
voxtral-mini-2602,voxtral-mini-transcribe-realtime-2602,voxtral-mini-tts-2603), deprecated on October 31, 2026 and retired on April 30, 2027, are replaced in examples byvoxtral-mini-transcribe-3,voxtral-mini-transcribe-realtime-3, andvoxtral-mini-tts-3-0. Key changes: timestamps are segment-only (wordreturns a 400 error), diarization is possible in realtime, realtime session settings are fixed after the first audio chunk, andcontext_biasinputs are free-form (phrases with spaces allowed). Sources: Migrate from Voxtral 2 · Speech to Text.
Two Modes, Two Philosophies
Voxtral offers two transcription approaches that differ not in quality, but in nature. Choosing between them isn’t an implementation detail you tweak at the end of a project. It determines the features available to you, how you write your code, the costs you incur, and the user experience you deliver. This lesson gives you the facts to make that choice, stick with it, and even combine both modes when it makes sense.
Full Comparison
| Criterion | Offline (Batch) | Realtime (Streaming) |
|---|---|---|
| Model | Voxtral Mini (or Small) Transcribe 3 | Voxtral Mini Transcribe Realtime 3 |
| Latency | Seconds to minutes (depending on duration) | Configurable delay from 80 ms to 1.2 s, or 2.4 s |
| Audio Limit | Context window, shared with context_bias | Continuous session |
| Diarization | Yes, with segment timestamps | Yes, without timestamps; not available with turn-end detection |
| Context Biasing | Yes (term list, allowed phrases) | Yes, in session configuration |
| Timestamps | Per segment (no word-level) | No |
| Turn-end Detection | No | Yes |
| Audio Format | Common file formats | 16-bit mono PCM (16 kHz default) |
| Languages | 50 | 45 languages and dialects |
| Price as of November 3, 2026 | $0.0035/min (Mini), $0.004/min (Small) | $0.008/min |
| Programming | Synchronous (simple) | Asynchronous (async/await) |
| Primary Use Case | Recorded files | Live audio |
A close look at this table reveals what truly separates the two modes. Offline is the only mode that timestamps every segment because it sees the entire audio before responding. Realtime is the only mode that detects turn ends and returns text while someone is speaking. You aren’t choosing between a full version and a lite version. You’re choosing between two ways to serve the user: after the fact, or in the moment.
How to Choose
Offline is the clear choice whenever you’re processing audio files that already exist—archived meetings, podcasts, interviews—since the audio is complete and there’s no gain in artificially chopping it up. It’s your only option if you need to identify speakers, as diarization remains out of reach for streaming. It’s also the right pick if your domain requires specialized vocabulary that context biasing must guide, or if you need precise timestamps for post-production video subtitling. Finally, it saves you from any upfront conversion when your sources arrive in various formats, and it becomes the obvious choice when latency isn’t critical: deferred processing, overnight batches, archival pipelines.
Realtime becomes necessary when audio arrives continuously, from a microphone or network stream, meaning there’s no file to send. It’s mandatory when results must be available in under a second, as with a voice assistant, dictation tool, or live subtitling for a conference or webinar. Two other strategic reasons can drive the choice regardless of latency: on-premise or edge deployment, made possible by open weights, and sovereignty requirements when no data may leave your infrastructure.
There’s a third path, often the best one: combine both. You subtitle a conference in realtime, then reprocess the recording offline to produce clean, timestamped subtitles. You display live transcription during a meeting, then run an offline pass with diarization to attribute each utterance to its speaker. You dictate in realtime, then reprocess the file offline for review and corrections. Realtime serves the moment; offline serves the document.
What Each Mode Costs
The two modes don’t share the same pricing structure. As of April 2026, Mistral AI’s pricing is based on processed audio duration. Offline is generally cheaper per minute because batch processing is optimized, while realtime carries a premium for the persistent WebSocket connection and continuous processing.
Three habits cut costs without sacrificing anything. In offline mode, batch your files to limit the number of API requests. In realtime mode, close the connection as soon as speech stops instead of leaving it open “just in case”: a forgotten session consumes resources without producing output. Most importantly, always ask whether live processing is truly necessary—if realtime adds no value for the user, offline is both cheaper and more feature-rich.
A Hybrid Pipeline: From Live to Report
The code below shows the hybrid pattern in its most common form: a meeting. During the session, the realtime stream feeds the display: participants see text scrolling, no one waits. Once the meeting ends, the same audio, now available as a complete file, is reprocessed offline with diarize=True and segment-level timestamps, producing a report that attributes each utterance to its speaker. The two calls don’t compete; they complement each other. The first serves immediacy; the second, traceability.
import asyncio
import os
from mistralai.client import Mistral
from mistralai.client.models import (
AudioFormat,
TranscriptionStreamTextDelta,
TranscriptionStreamDone
)
async def hybrid_pipeline(realtime_audio_source, complete_file_path):
"""
1. Realtime transcription for immediate display
2. Offline transcription for final report with diarization
"""
client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])
# Phase 1: Realtime (during the meeting)
print("=== LIVE TRANSCRIPTION ===\n")
audio_format = AudioFormat(encoding="pcm_s16le", sample_rate=16000)
async for event in client.audio.realtime.transcribe_stream(
audio_stream=realtime_audio_source,
model="voxtral-mini-transcribe-realtime-3",
audio_format=audio_format,
target_streaming_delay_ms=800,
):
if isinstance(event, TranscriptionStreamTextDelta):
print(event.text, end="", flush=True)
elif isinstance(event, TranscriptionStreamDone):
break
# Phase 2: Offline (after the meeting)
print("\n\n=== DETAILED ANALYSIS ===\n")
with open(complete_file_path, "rb") as f:
response = client.audio.transcriptions.complete(
model="voxtral-mini-transcribe-3",
file={"content": f, "file_name": complete_file_path},
diarize=True,
timestamp_granularities=["segment"]
)
for seg in response.segments:
print(f"[{seg.speaker_id}] ({seg.start:.1f}s) {seg.text}")
return response
Note the practical constraint this pattern imposes: you must record the audio in parallel with streaming, since the chunks consumed by the realtime stream aren’t retained. Plan for this disk write from the start, or the offline phase will have nothing to process.
Key Takeaways
- Offline excels for recorded files with diarization and timestamps
- Realtime excels for live audio with ultra-low latency
- Both modes can be combined in a hybrid pipeline
- Offline is more feature-rich (diarization, context biasing, timestamps)
- Realtime is more flexible for deployment (open weights, edge)
- Choose based on audio source (file vs. live) and required features