When you start building with a speech-to-text API, one of the first choices you face is deceptively simple looking: do you process audio as a file after the fact, or do you stream it in real time as it is recorded?
Most teams pick one based on gut feel, then spend weeks debugging the wrong problems because the choice did not fit the use case. This guide covers what actually separates these two modes, where each one belongs, and what it can cost you.
The Core Difference
Batch transcription works on audio that already exists. You have a file, a recorded meeting, a call center conversation, a podcast episode, an uploaded voice note, and you send it to the API to get a transcript back. The audio is complete before any processing begins.
Real-time streaming transcription works on audio that is happening right now. Instead of waiting for a recording to finish, you open a continuous connection and send audio as it comes off the microphone or phone line. The system returns partial transcripts as the speaker talks, updating them as more audio arrives.
Both approaches sit inside Shunya Labs as separate API modes, batch for recorded files and livestream for live audio, because the technical requirements underneath them are genuinely different, not just cosmetically different.
How Batch Transcription Works
When you submit a file to a batch transcription API, the system processes the entire audio in one pass. Because it can see the whole recording at once, it can use full context to resolve ambiguities. A word that sounds unclear at the four-minute mark can be interpreted correctly because the system has already seen what came before and what comes after.
Batch mode tends to produce the most accurate transcripts. The model has the luxury of bidirectional context and can make more confident decisions at every word boundary.
The trade-off is time. Even fast batch systems add some processing overhead, the file has to be uploaded, queued, processed, and returned. For a ten-minute recording this might take a few seconds. For a two-hour video it takes longer. This is acceptable when the recording is already complete and the user is not waiting in real time.
Batch transcription also makes it easier to run the full suite of intelligence features. Things like speaker diarization, summarization, sentiment analysis, intent detection, and word timestamps all benefit from seeing the complete audio before producing output. These are not impossible in streaming contexts, but they are more computationally clean in batch mode.
How Real-Time Streaming Transcription Works
Streaming transcription works through a persistent connection, typically a WebSocket. Your application sends audio chunks to the API continuously as they are captured, and the API returns partial transcripts as it processes each chunk.
Because the system can only see audio that has arrived so far, it has to make probabilistic guesses about incomplete utterances. Those guesses get updated as more audio comes in. You will often see a transcript that says “how can I” turn into “how can I help you” as the speaker continues talking. This is normal and expected behavior, it is sometimes called transcript revision or instability.
The benefit is immediacy. Words appear on screen within milliseconds of being spoken. A voice agent can start preparing its response before the user has finished their sentence. A live captioning system can display text fast enough for a deaf viewer to follow the conversation in real time.
The technical overhead is higher. You need to manage a persistent WebSocket connection, handle connection drops gracefully, buffer audio correctly, and deal with partial transcript updates in your UI logic. It is not complicated, but it is more moving parts than a simple file upload.
When Batch Is the Right Choice
Meeting and interview transcription. When a meeting ends and you want a clean record of who said what, batch is the obvious choice. The recording is complete, accuracy matters more than speed, and no one is waiting in real time for the output.
Podcast and video production. Creators uploading content for subtitling or SEO transcription do not need live output. They need high accuracy and clean speaker labels. Batch gives both.
Call center QA and analytics. Thousands of calls are recorded every day. Analyzing them for compliance, sentiment, agent performance, and intent patterns often does not need to happen while the call is live. A batch pipeline that processes recordings after they finish is simpler to build, more accurate, and easier to scale.
Legal, medical, and compliance transcription. When the transcript is going to be reviewed by a human and potentially used in a formal context, you want the best possible accuracy. Batch mode delivers that. Shunya Labs’ medical transcription is built with this in mind, accuracy and medical keyterm correction take priority over speed.
Content search and indexing. If you are building a system that lets users search through hours of recorded audio, batch processing feeds the index at a schedule that your infrastructure controls. No need for a live connection.
When Streaming Is the Right Choice
Voice agents and conversational AI. This is the clearest use case for streaming. A voice agent that has to wait until the user stops speaking, upload a file, wait for the transcript, and then respond will feel broken. The user expects a natural conversation rhythm. Streaming delivers sub-second partial transcripts so the agent can start processing the user’s intent almost immediately.
Live captioning and accessibility. Whether it is a live conference, a classroom lecture, or a TV broadcast, captions need to appear fast enough for viewers to read them in sync with the speaker. Streaming transcription is the only viable option here.
Real-time agent assist in contact centers. Some contact center platforms surface suggestions and scripts to the agent while the customer is still talking. This requires a transcript of the live call, not a recording of it. Streaming feeds those assist panels with the words the customer is saying right now. Shunya Labs’ contact center solution uses this pattern to deliver real-time intelligence during calls.
Voice-first apps and command interfaces. If a user speaks a command and expects immediate action, you cannot wait for a file to process. A restaurant ordering kiosk, a hands-free navigation app, or a voice-controlled warehouse management tool all need responses that feel instant. Streaming makes that possible.
Live event monitoring. Streaming transcription lets you scan spoken content for specific keywords, phrases, or sentiment signals in real time. For a live radio broadcast or a town hall meeting, that kind of monitoring requires a live feed, not a recording processed after the fact.
Accuracy vs Latency: The Real Trade-Off
A lot of guides describe this as a simple accuracy-versus-speed trade-off, but that framing is slightly misleading.
Streaming transcription can be highly accurate, Shunya Labs’ Zero STT model maintains strong accuracy in streaming mode. The difference is that streaming transcripts may revise themselves as more context arrives, whereas batch transcripts are final from the start. For most users reading live captions, this is invisible. For downstream systems that need to act on transcribed words the moment they appear, it requires some thought about when to treat a partial transcript as stable enough to process.
The technical trade-off is really about context window access. In batch mode, the model sees everything. In streaming mode, it sees only what has arrived so far. On clean, clearly-spoken audio the gap is small. On noisy, accented, or code-switched audio, the difference becomes more noticeable. This is why Zero STT Codeswitch, built for mixed-language speech like Hinglish, is particularly useful for streaming contexts where the model has to handle language switches on the fly without the benefit of seeing the full sentence first.
A Simple Decision Framework
If you are not sure which mode to use, walk through these questions.
Does the audio already exist as a file? Yes, use batch. No, use streaming.
Does the user need to see or act on the transcript while audio is still being recorded? Yes, use streaming. No, batch is simpler and more accurate.
Are you running intelligence features like summarization, sentiment, or diarization on the output? These work in both modes, but are more reliable in batch where the full audio context is available.
Is cost a factor? Batch processing tends to be more infrastructure-efficient at scale. Streaming requires persistent connections and more compute resources per minute of audio.
Do you need the absolute best accuracy for a formal document or compliance record? Use batch.
Is your product a conversation, a live interface, or a real-time assist tool? Use streaming.
You Do Not Always Have to Choose One
Some products use both modes in parallel. A contact center might stream transcription during the call for real-time agent assist, then send the completed recording through a batch pipeline after the call ends to run deeper analytics, diarization, summarization, sentiment trends, and intent classification. The streaming output serves the live use case. The batch output serves the analytics use case. Both draw from the same underlying model.
Shunya Labs supports both modes through its API, so you can build this kind of dual-pipeline architecture without switching providers. The batch API and livestream API share the same authentication and the same set of intelligence features, so output is consistent across both.
If you want to try both modes and compare output on your own audio, the Shunya Labs playground lets you test without writing any code. Full documentation is at docs.shunyalabs.ai.