docs / how it works

How it works

Five stages, all on the device. The model proposes. Code checks. Then it transmits. No network hop in the core loop.

Pipeline

1. Input. Push-to-talk. No wake word, no always-on mic.
2. Speech to text. whisper.cpp on the device. 2x realtime on the RK3566 prototype. Not yet ported to the RK3588, so every RK3588 latency we publish is text input.
3. Router. The fine-tuned 3B reads your device list and returns one JSON object: a device command, a batch, a question back, or a refusal. Never free text posing as a command.
4. Gate. Code checks every action before it leaves. Only devices you set up yourself. Doors, locks, garages and gates ask first, and only a plain yes releases them. Which kinds ask first is a setting.
5. Output. IR, from codes learned off your own remote. Radio through an optional module on the expansion header.

Why 3B is enough

The model has one job: map a request onto a device list. Fine-tuning is good at one job. 30/30 on the routing eval (24 Aug). 27/30 for v4 on device types it never saw in training (15 Sep, pass mark 26). Breadth comes from adding measured jobs, not from one model doing everything.

Memory bandwidth sets the speed

Each generated token reads every weight from memory. On the RK3566, a model with 2.6x the parameters ran 2.4x slower: 93% of perfect inverse scaling. That is bandwidth-bound, not compute-bound. So the chip was picked for its memory bus.