Skip to main content
Lesson 14 of 16 · Voxtral Audio: Transcription and Speech-to-Text

Offline vs Realtime: A Selection Guide

Lesson 14 of 16 Updated November 3, 2026 Developer
On this page
  1. Two Modes, Two Philosophies
  2. Full Comparison
  3. How to Choose
  4. What Each Mode Costs
  5. A Hybrid Pipeline: From Live to Report
  6. Key Takeaways

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 by voxtral-mini-transcribe-3, voxtral-mini-transcribe-realtime-3, and voxtral-mini-tts-3-0. Key changes: timestamps are segment-only (word returns a 400 error), diarization is possible in realtime, realtime session settings are fixed after the first audio chunk, and context_bias inputs 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

CriterionOffline (Batch)Realtime (Streaming)
ModelVoxtral Mini (or Small) Transcribe 3Voxtral Mini Transcribe Realtime 3
LatencySeconds to minutes (depending on duration)Configurable delay from 80 ms to 1.2 s, or 2.4 s
Audio LimitContext window, shared with context_biasContinuous session
DiarizationYes, with segment timestampsYes, without timestamps; not available with turn-end detection
Context BiasingYes (term list, allowed phrases)Yes, in session configuration
TimestampsPer segment (no word-level)No
Turn-end DetectionNoYes
Audio FormatCommon file formats16-bit mono PCM (16 kHz default)
Languages5045 languages and dialects
Price as of November 3, 2026$0.0035/min (Mini), $0.004/min (Small)$0.008/min
ProgrammingSynchronous (simple)Asynchronous (async/await)
Primary Use CaseRecorded filesLive 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