There's a school of voice-agent development that treats turn detection as something you buy, not something you build. Pick a streaming STT provider, let its end-of-turn logic decide when the user is done, and move on. For a lot of teams that's the right move — and if you're weighing the options, our breakdown of turn detection vs forced endpoints is the place to start.
But some teams have already solved turn detection. They've tuned their own voice-activity detection over thousands of calls, they know their audio, and they trust their endpointing more than any default. For those teams, a streaming model's built-in turn logic isn't a feature — it's something to work around. What they want is narrower and faster: hand over a finished chunk of speech, get accurate text back, get out of the way.
That's the case for bringing your own turn detection and pairing it with fast ASR over HTTP.
Turn detection is an architectural decision, not a default
Here's the framing that matters. In a streaming setup, the STT model is a participant in the conversation — it's watching the audio and deciding, continuously, whether the user has finished. That's genuinely useful when you want the provider to own that judgment.
But it means the model is inserting its own decision between "user stopped talking" and "you get the transcript." If you already know the turn is over — because your VAD just fired — you don't want the model deliberating. You want it transcribing. Every millisecond the STT layer spends re-deciding a question you've already answered is latency you're adding for no benefit.
So the decision isn't "which provider has the best turn detection." For these teams it's "who owns the turn boundary?" If the answer is you, then the ideal STT layer is one that does exactly one thing: turn a finished clip into accurate text, fast.
Built-in vs. bring-your-own
Built-in (streaming). The model reads tonality, pacing, and rhythm to detect end-of-turn — with Universal-3.5 Pro Realtime, around 300ms — then commits the transcript. Great when you want conversation-aware endpointing handled for you, and when you value partial transcripts as the user speaks.
Bring-your-own (sync HTTP). Your VAD decides the turn is over and hands the completed clip to the Sync API, which returns the transcript in a single response at roughly 134ms p50, for clips up to 2 minutes (40 MB max), at $0.45/hr. No end-of-turn step on the model's side, because you already made that call. You trade mid-utterance streaming for a tighter, you-controlled loop.
The distinction isn't fast versus slow — both are fast. It's about who decides when the turn ends, and whether you want that decision inside or outside the STT layer.
The sub-500ms budget, with you owning the turn
Teams building responsive agents often target something under 500ms from end-of-speech to the start of the agent's reasoning. Here's roughly where the time goes when you own turn detection and use sync ASR:
- Your VAD end-of-turn decision: however tight you've tuned it — often the biggest lever you control.
- Sync transcription: ~134ms p50 for the clip.
- Network overhead: tens of milliseconds, minimized by reusing a warm HTTP connection.
Because you're not waiting on the model to detect end-of-turn, the transcription step is close to pure processing time. That's the appeal: when you've already done the hard work of knowing when the user stopped, sync ASR adds very little on top before the LLM can start. The budget math gets a lot friendlier when the STT layer isn't also trying to be the turn detector.
One practical note that pays off here: keep the HTTP connection warm between turns. Reuse a single session so DNS, TCP, and TLS setup don't land on the critical path of every utterance. It's a small change that protects the latency you worked to win.
You don't trade accuracy for control
The reason this pattern works for serious teams is that owning turn detection doesn't cost you transcript quality. Sync returns the same accuracy as async — the same handling of names, numbers, and domain terms that you'd get from the batch path. In an agent, that's the number that matters most: if the transcript is wrong, the LLM answers the wrong question, and no amount of speed rescues the interaction.
So the tradeoff is clean. You give up the model's built-in end-of-turn detection and mid-utterance streaming. You keep full control of the conversation loop and full accuracy on the words. For a team that already trusts its VAD, that's a trade worth making.
When to hand turn detection back to us
Be honest about which camp you're in. Bring-your-own turn detection is the right pattern when you've genuinely tuned your VAD and you want the STT layer to stay out of the conversation logic. It is the wrong pattern if you're bringing your own turn detection mostly to avoid learning someone else's — in that case you're taking on the hardest part of voice UX to save yourself a config page.
If you'd rather not own endpointing, interruption handling, and the rest of the orchestration, hand it back. The Voice Agent API builds conversation-aware turn detection and barge-in directly into Universal-3.5 Pro Realtime, over one WebSocket, at a flat $4.50/hr. Bring your own turn detection when control is the goal; use the Voice Agent API when shipping fast is the goal. Both run on the same speech accuracy underneath — the difference is only how much of the loop you want to hold.
Frequently asked questions
What does "bring your own turn detection" mean for a voice agent?
Bringing your own turn detection means your application's own voice-activity detection decides when the user has finished speaking, rather than the speech-to-text model. Once your VAD fires, you hand the completed audio clip to a synchronous ASR endpoint and get the transcript back in one response. The STT layer does exactly one thing — turn a finished clip into accurate text — instead of also deliberating about when the turn ended.
When should I use my own VAD instead of a streaming model's built-in turn detection?
Use your own VAD when you've genuinely tuned it over real calls, you trust your endpointing more than any default, and you want the STT layer to stay out of the conversation logic. In that case a streaming model's built-in end-of-turn detection is redundant — it inserts a decision between "user stopped talking" and "you get the transcript" that you've already made. Stick with built-in turn detection if you value mid-utterance partial transcripts or you'd simply rather not own endpointing.
How do I build a low-latency voice agent under 500ms with sync ASR?
When you own turn detection, the sub-500ms budget breaks down into three pieces: your VAD's end-of-turn decision (the biggest lever you control), sync transcription at roughly 134ms p50, and network overhead of tens of milliseconds. Because you're not waiting on the model to detect end-of-turn, the transcription step is close to pure processing time. Keep the HTTP connection warm between turns — reuse one session so DNS, TCP, and TLS setup stay off the critical path.
Is synchronous HTTP ASR as accurate as streaming or batch transcription?
Yes. The Sync API returns the same accuracy as async transcription — the same handling of names, numbers, and domain terms you'd get from the batch path — because it runs on the same Universal-3.5 Pro model. Owning turn detection costs you the model's built-in endpointing and mid-utterance streaming, not transcript quality. In an agent that's the trade that matters, since a wrong transcript means the LLM answers the wrong question.
Should I bring my own turn detection or use AssemblyAI's Voice Agent API?
Bring your own turn detection when control is the goal — you've tuned your VAD and want to own the conversation loop, pairing it with fast sync ASR. Use the Voice Agent API when shipping fast is the goal: it builds conversation-aware turn detection and barge-in directly into Universal-3.5 Pro Realtime over one WebSocket at a flat $4.50/hr. Both run on the same speech accuracy underneath — the difference is only how much of the loop you want to hold.
What are the Sync API's limits and pricing?
The Sync API accepts clips from 80 ms up to 2 minutes (40 MB max) across 18 languages, runs on the flagship Universal-3.5 Pro model, and returns a finished transcript in a single HTTP response at roughly 134 ms p50. It's priced at $0.45/hr of audio, with keyterms prompting and conversation context included and no rate limits. For audio longer than two minutes, use the pre-recorded (async) API instead.
Top comments (0)