The current preview build uses push-to-talk; the local wake-word stage described below is the planned hands-free activation path.
Every hands-free voice assistant has to answer an uncomfortable question: if it can hear an activation phrase, what is listening, where does it run, and what happens to ordinary room audio? This design keeps that first decision on the Mac.
In the planned first stage, a small acoustic model would run locally and do one narrow job: score a short rolling audio window against the activation phrase. It would not transcribe ordinary speech, store the rolling window, or send it to a server.
After a local match, Soren would open a bounded recording window for the actual command. The window would end when speech ends, so command capture remains a distinct, inspectable stage rather than continuous cloud streaming.
Transcription would continue to use the current on-device path. The recorded command runs through speech-to-text on the Apple Neural Engine, producing text locally while voice audio stays on the Mac.
Reasoning is the boundary that can leave the machine. The transcript and task context needed to plan the work may go to the selected model provider. As tools run, relevant results, UI text, or screenshots may be returned to that provider so the task can continue; the voice recording itself is not part of that request.
Action then returns to the Mac: operating supported accessibility elements, running managed commands, or driving a paired Chrome tab. Consequential effects pause for approval, and file deletion prefers the Trash so Finder can undo it.
The hands-free path remains a design until it ships and passes the same egress checks as push-to-talk. The current product should be evaluated on its current behavior: bounded capture while the hotkey is held, local speech-to-text, explicit model-provider boundaries, and visible approval before risky effects.