Understand "make it a bit warmer" — without a cloud
Speech-to-intent maps natural phrasing straight to a structured command: intent and slots in a single on-device inference, with no transcript stage and no NLU server. Users speak the way people speak; your product receives {intent: set_temperature, value: 72}.
Why intent beats transcription for control
Users say it their way
"Turn it up", "warmer", "set it to 72", "make it two degrees warmer in here" — no memorized command list. The model was trained on the many ways people phrase your product's actions.
Your code gets structure, not strings
Engineers receive a typed intent with named slots — not free text to regex through. It's the difference between handling an API call and parsing a sentence.
One inference, not a pipeline
The traditional route is speech-to-text, then a language model over the transcript. One model that goes straight from audio to intent means lower latency, less memory, and fewer places to lose accuracy.
Products that understand phrasing
Anywhere the natural sentence is friendlier than the memorized command.
Thermostats & HVAC"Make it two degrees warmer"
Relative and absolute changes, units, rooms — resolved into one structured set_temperature intent on the device.
Lighting"Dim the kitchen to twenty percent"
Scenes, rooms, and levels extracted as slots — no cloud round-trip between the sentence and the dimmer.
Automotive cabins"Open the passenger window halfway"
Cabin controls that work identically in a parking garage, a tunnel, or the middle of nowhere.
Kitchen appliances"Preheat to four hundred"
Ovens and cooktops that take natural instructions with wet or full hands — numbers arriving as typed slot values.
AV & conference rooms"Switch to HDMI two"
Room systems driven by the sentence a presenter would actually say, not a code from the manual.
Assistive & care devices"Raise the bed a little"
Natural phrasing matters most for users who can't reach controls — and privacy matters most at the bedside.
From context spec to structured commands
Write the context spec
Declare your intents and slots in a few lines of YAML — set_temperature with value and unit, set_light with room and level. The spec is the contract.
We train the model on your spec
VoxRT trains a model that maps the many natural phrasings of your intents to that structure — tuned for your languages, acoustics, and target hardware.
Your team drops in the SDK
Same runtime as every VoxRT primitive: Swift Package, Gradle dependency, or C library on Linux. Add a wake word in front if the product should answer by name.
Handle intents like API calls
Switch on the intent, read the slots, act. Out-of-domain speech produces no intent rather than a wrong one — you decide the fallback experience.
What's under the hood
Speech-to-intent rides the same measured, published VoxRT runtime — see the benchmark methodology for how runtime numbers are produced.
Pipeline. Microphone → on-device VAD → (optional wake word) → speech-to-intent model → {intent, slots} event to your code. Compared with ASR-plus-NLU, the single-inference design cuts latency and memory and removes the error compounding between two models.
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.
Licensing. Speech-to-intent models are trained per product from your context spec as a one-time paid engagement; the runtime and published models are free for commercial use — see licensing.
Speech-to-intent, answered
How is this different from speech recognition plus an NLU model?
The traditional pipeline transcribes audio to text, then runs a second language-understanding model over the transcript. Speech-to-intent is one model that maps audio directly to a structured intent with slots — one inference instead of two, which means lower latency, a smaller memory footprint, and fewer places to lose accuracy.
How do I define what my product understands?
You declare intents and slots in a few lines of YAML — for example set_temperature with value and unit slots. VoxRT trains a model on that spec and delivers it as a tuned on-device model for your product.
What happens when a user says something outside the spec?
The model is a closed-domain understander: speech that doesn't match your intents yields no intent rather than a forced guess. Your product chooses the fallback — a gentle prompt, a help hint, or silence.
Does it need a wake word in front of it?
They pair naturally — the wake word gets the product's attention, speech-to-intent understands the sentence that follows — but each works independently. A push-to-talk button in front of speech-to-intent is equally valid.