Give your voice agent human turn-taking
The difference between a voice agent that feels alive and one that talks over people is endpointing — knowing the instant a user starts and stops speaking. VoxRT's voice activity detection makes that call in under a millisecond per frame, on the device or on your own servers, before any audio is shipped anywhere.
What local endpointing buys an agent
Interruptible, like a person
Barge-in only works if speech is detected the moment it starts. Local VAD flags it within a frame, so the agent stops talking when the user does — instead of finishing its paragraph.
Faster turns, tighter loops
Every millisecond between the user's last word and the model's first token is felt. Detecting end-of-speech locally starts the response immediately — no cloud VAD round-trip inside your latency budget.
A cheaper pipeline by construction
When VAD gates the pipeline, only actual speech flows to metered transcription and inference. The silence between turns stops costing money before it leaves the device.
Where turn-taking is the product
Every conversational system has this problem; most solve it late, in the cloud, after paying to ship the audio.
Barge-in on hold-music energy
Callers interrupt, correct, and talk over — agents that yield instantly feel human; agents that don't get hung up on.
Endpointing on the phone
Mobile assistants that close the turn on-device, so the round trip carries the request — not the job of noticing it ended.
Telephony at scale
Server-side VAD on your own boxes: ~54 parallel streams per CPU core means turn detection that scales with calls, not costs.
Who spoke, and when
Speech segments with clean boundaries are the backbone of summaries, action items, and speaker timelines.
Auto start-and-stop
Recording that begins when speech begins and trims the dead air — no push-to-talk, no ragged silences.
Turn detection for tutors
Conversation-practice products that know when the learner finished a sentence — patient, not interruptive.
Wiring VAD into an agent loop
Run VAD at the edge of the pipeline
On the user's device, or at your server ingress — wherever audio first arrives. Each 32 ms frame gets a speech probability in well under a millisecond.
Tune endpointing to your UX
The threshold and end-of-speech hangover are yours to set: snappy for command-style agents, patient for people who pause mid-thought.
Drive turn logic from speech events
Speech start during agent playback → barge-in: stop speaking, start listening. Speech end → close the turn and hand the utterance to your model.
Gate everything metered
Downstream STT and inference only see speech. The gate is also how you cut the transcription bill — a use case of its own.
The numbers behind the promise
VAD numbers are measured on real hardware and published — see the benchmark methodology and the VAD comparison.
Pipeline. Audio → VAD (per-frame speech probability, ~0.6 ms per 32 ms frame) → speech-start/speech-end events → your turn-taking logic, with downstream STT and inference gated on speech. The model is Silero v5 weights running on the VoxRT CPU runtime.
Platforms. iOS 16+ (Swift Package Manager) and Android 8.0+/API 26 (JitPack/Gradle), plus Linux aarch64 for device-class hardware — validated on Raspberry Pi 3/4/5 and Pi Zero 2 W, NVIDIA Jetson Nano and Orin Nano, AWS Graviton and similar Cortex-A53/A55 boards — shipped as a single ~480 KB shared library with Python, Node.js, Go, C/C++ and Rust wrappers. Quickstarts: iOS · Android.
Licensing. The VAD SDK and model are free for commercial use with no per-user, per-device, or per-stream fees — on user devices and on your servers alike. See licensing.
Agent endpointing, answered
Why not just use our STT provider's built-in VAD?
Because by then you've already shipped the audio: the silence has crossed the network, entered the latency budget, and hit the meter. VAD at the edge acts before any of that — and it keeps your turn-taking logic independent of whichever STT or LLM vendor you use this quarter.
Can it run server-side for telephony?
Yes — the Linux build handles roughly 54 parallel streams per CPU core, so a single modest box gates a lot of concurrent calls. The same SDK runs on user devices when you'd rather endpoint before audio leaves them.
How configurable is the endpointing behavior?
The speech threshold and end-of-speech hangover are exposed, so you tune how eagerly the agent treats a pause as a finished turn — snappy for command bots, patient for narrative speakers.
What does a 1.85% real-time factor mean in practice?
It means processing 32 ms of audio takes ~0.6 ms of CPU — the detector uses under 2% of one core to listen continuously. Definitions for RTF and friends are in the glossary.