One question decides it: does your product have to act on speaker identity before the conversation ends?

A yes means streaming diarization, because a label that arrives after the call is over cannot change what happens during it. A no means batch is the better engineering choice, since a model that sees the whole timeline before committing makes better decisions than one committing on partial evidence.

Most teams land somewhere less tidy, running both on the same audio. This guide covers how to make the call, what the hybrid pattern looks like in practice, and what changes in your own code once speaker labels start arriving incrementally.

For what streaming diarization is and how pyannoteAI built it, start with the Live-1 launch post and the engineering writeup. This piece assumes you already know roughly what the thing does and are deciding whether to put it in your stack.

The two modes, side by side

The output has the same shape in both modes. What differs is when you get it and how much the system knew when it committed.

Working the decision

The test splits cleanly once you ask what your product does with the label.

Streaming is required when the label drives an action inside the conversation. A voice agent deciding whether the voice it just heard belongs to its user or to someone else in the room. A compliance check that has to prompt an agent who has not yet read a required disclosure. A fraud signal that fires when an unfamiliar voice joins a banking call, early enough to challenge it. Live captions that need the speaker label attached to the line as it scrolls. A supervisor alert that only helps while the call is still open.

Batch is the better choice when the conversation is already over. Post-call QA and contact-center analytics run on finished recordings. Podcast editing, subtitling, and media repurposing work from completed files. Meeting summaries and action items get generated after the meeting. Legal transcription and anything that becomes an official record should use the configuration that sees everything before deciding.

A useful sharpening question for the ambiguous middle: would a label that arrives 30 seconds late still be worth having? Live coaching fails that test, since the moment to intervene has passed. Talk-time analytics on the same call passes it easily.

Where batch still wins, and why

Streaming is a constraint rather than an upgrade. Paying its cost without needing its timing is a bad trade, for three reasons worth being explicit about.

Full context produces better labels. Batch diarization clusters speakers knowing every utterance in the file. Streaming clusters them knowing only what has arrived. Early in a call, a streaming system has heard very little from each person, and its clusters are still forming.

Decisions become permanent. Batch can revise an early label once later audio clarifies it. Streaming labels have usually been consumed by the time better evidence shows up, which is why stability matters more than eventual correctness.

Batch costs less per audio hour. Live-1 carries a meaningful premium over Precision-2 on a per-hour basis. Check the pricing page for current rates, and factor the difference into any design that would otherwise stream everything by default.

The hybrid pattern

The architecture most production systems converge on runs both layers against the same conversation, each doing the job it is suited to.

During the call, Live-1 streams over a WebSocket and emits speaker events as people talk. This layer feeds anything interactive: agent routing, barge-in handling, live captions, in-call compliance prompts, supervisor alerts. Its output is disposable by design, since its only job is to be right enough, soon enough, to drive a decision.

After the call, the recording goes to Precision-2 as a normal diarization job, optionally with STT Orchestration for a speaker-attributed transcript in the same call. This layer produces the artifact you keep: the archive record, the analytics input, the transcript a human might later read or a regulator might later request.

Three properties make this worth the extra call rather than a compromise.

The archival record gets full-context accuracy, so your stored transcript is not permanently limited by a decision made on partial evidence mid-turn. Both layers come from one vendor on one integration, so you are not reconciling two vendors' notions of a speaker. And the expensive real-time path only runs on audio that actually needs it, which matters once volume grows.

The practical caveat is worth stating plainly: speaker labels from the two passes are generic, per-job identifiers rather than shared identities, and Live-1 and Precision-2 are separate models. Resolving a label to an actual person is a job for voiceprints and speaker identification, which run on the Precision-2 pass. The streaming pass emits anonymous per-stream labels only.

What changes in your code

This is the part teams underestimate. Consuming incremental labels is a different programming model from consuming a finished diarization job, and the differences show up in production rather than in the prototype.

Labels arrive as events, not as a document. The stream emits diarization_speaker_start and diarization_speaker_end, each carrying a timestamp in seconds from the start of the stream and a stable speaker label such as SPEAKER_00. Your application consumes a timeline that is still being written, so any component expecting a complete segment list needs an adapter.

Early-call labels deserve less trust than late-call labels. Speaker clusters sharpen as audio accumulates. Actions that are cheap to get wrong and easy to reverse can fire immediately. Actions that are expensive or irreversible, such as escalating to a supervisor or flagging a fraud event, are better gated behind a few seconds of accumulated evidence.

Design the UI against label churn. A caption rail or speaker indicator that reassigns a line the moment the model firms up a cluster reads as a bug to users. Committing a label once and leaving it alone generally beats showing your users the model changing its mind.

Make your handlers idempotent. Reconnects, retries, and duplicate events are ordinary in a long-lived WebSocket session. Handlers that assume exactly-once delivery will double-count turns.

Plan for the speaker ceiling. Live-1 tracks up to 8 speakers simultaneously, and the documentation is explicit about what happens past that: "In case the stream involves more speakers, multiple speakers will end up being merged into one." Conference rooms, panel formats, and open-plan contact centers can all cross that line, so decide in advance whether merged labels are tolerable for your use case.

Constraints that shape the design

These are the numbers to check a design against, from pyannoteAI's streaming tutorial, its API reference for the audio format, and the pricing page for the plan tiers:

• Audio format: 16 kHz mono, PCM float 32-bit little-endian, sent in 100 ms chunks of 6,400 bytes

• Speakers: up to 8 tracked simultaneously, with any beyond that merged into one label

• Stream duration: maximum 5 hours per stream

• Concurrency: 10 concurrent running streams per team on Developer and Starter, custom on Enterprise

• Billing: based on audio duration sent over the WebSocket, with a 20-second minimum per stream

• Idle timeout: 5 seconds with no audio received

• Maximum buffer: 5 seconds, so pushing audio faster than real-time closes the connection

• Cold starts: may delay the WebSocket connection by a few seconds

Three of these shape architecture more than the rest. The 20-second minimum per stream makes many very short streams an expensive pattern, so batching brief interactions into a single session is worth considering. The 10-stream concurrency ceiling on the standard plans is the first wall a growing contact-center deployment hits, well before any accuracy limit. And the 5-second maximum buffer catches most teams during testing rather than in production, since replaying a recorded file at full speed pushes audio faster than real-time and closes the connection.

Accuracy and latency, briefly

Two facts, both documented elsewhere and both worth carrying into the decision.

On accuracy, pyannoteAI benchmarked four real-time systems on DIHARD III with no scoring concessions for overlapped speech. The pyannote API recorded 19.8% DER against 31.3%, 39.1%, and 39.2% for the ASR-bundled alternatives, with most of the gap coming from missed speech. The full benchmark post has the complete decomposition and the methodology.

On latency, the target is sub-300 ms end to end, achieved largely by processing audio in 100 ms chunks rather than the multi-second windows of earlier approaches. The engineering writeup covers how, while noting that "[o]ther details, including the specifics of the inference strategy, remain our secret recipe."

Frequently asked questions

How do I know whether I need streaming diarization? Ask whether your product has to act on speaker identity before the conversation ends. Voice agents, live captioning, in-call compliance, fraud detection, and live coaching do. Post-call analytics, media production, and meeting summaries do not.

Can I run streaming and batch diarization on the same audio? Yes, and it is the pattern most production systems converge on: Live-1 during the conversation for real-time behavior, Precision-2 afterward for the archival record. They are separate models, so the speaker labels do not carry across, though the integration and the vendor stay the same.

Is batch diarization more accurate than streaming? Batch has the structural advantage of seeing the complete timeline before committing to speaker clusters, while streaming commits incrementally on partial evidence. That is the reason to keep batch in the loop for anything that becomes a stored record.

How many speakers can streaming diarization handle? Live-1 tracks up to 8 simultaneously, over streams of up to 5 hours.

Can streaming diarization tell me who a speaker actually is? No. Live-1 emits anonymous per-stream labels such as SPEAKER_00. Resolving a label to a named person uses voiceprints and speaker identification, which are Precision-2 features and therefore run on the batch pass.

Getting started

Run your own audio through both modes before deciding. The API playground tests batch diarization on a file with no code, which establishes your accuracy ceiling. The streaming tutorial wires live labels into an application, and the streaming diarized transcription tutorial pairs them with a realtime transcription model for speaker-attributed captions. Comparing the two on the same conversation tells you more about the tradeoff than any benchmark, including this one.