Voice control for Windows, with intent kept visible.

How a spoken request becomes a Windows action

Fluent separates speech recognition from action planning. A constrained Windows listener waits for the Fluent wake phrase. A microphone click or the Ctrl+Alt+, shortcut can also arm one utterance. Chromium captures that command, and a bundled whisper.cpp runtime transcribes it locally.

The text request then enters the same command path as typed input. A hosted planning provider selects from bounded automation tools, such as observing the accessibility tree, opening an app, clicking a named control, or typing text. The app displays action progress and accepts cancellation while work is interruptible.

• Wake phrase, microphone click, or push-to-talk arms one command.
• Raw speech audio is transcribed on the device, not by a cloud speech API.
• The text request is sent to the configured hosted planning provider.
• The planner uses Fluent tools backed by Windows UI Automation and PowerShell.
• The overlay shows progress and lets the user cancel an active run.

Natural requests are different from command memorization

Traditional voice control often asks the user to remember an exact command, identify a control by name, or select a numbered overlay. Fluent explores a different layer: the user describes the outcome and the planner decomposes it into smaller semantic actions.

That approach can reduce command syntax, but it also introduces model uncertainty. Fluent therefore treats visibility, cancellation, semantic targets, and consequence-aware approval as core requirements, not optional polish.

A natural-language planner is useful when the route is multi-step. It is also less deterministic than a fixed voice command, so review and measurement matter more.

Where Fluent may fit

Fluent is being designed for people who want to reduce repeated keyboard and mouse work across changing Windows applications. That may include people navigating pain, fatigue, tremor, injury, limited reach, or simply a workflow where speaking the outcome is easier than relaying every click.

Voice is not the only path. Typed requests use the same surface when speech is private, tiring, unreliable, or unavailable, and a request typed into the overlay is planned and executed exactly as a spoken one is.

• Cross-app tasks where the desired outcome is easier to say than the exact route.
• Workflows that benefit from a visible action trace and a nearby cancel path.
• Users who need voice and text to coexist rather than compete as separate modes.
• Early testers who can tolerate preview setup and help document failures.

What Fluent does not promise yet

Fluent is not a replacement for every established accessibility tool, and it is Windows only - there is no macOS or Linux build. Planning happens through a hosted gateway on the standard plans, so a standard install needs a connection; only the enterprise HIPAA mode runs inference on the device. Recognition has not been formally evaluated for dysarthric or accented speech, which is the largest open gap in the published conformance report.

A production claim must eventually be supported by fresh-install success, repeatable workflow results, consequence fixtures, accessible recovery, signed distribution, and user testing. Until those gates pass, Fluent should be evaluated as a transparent preview.

Questions

Keep reading

• Is there a real Dragon NaturallySpeaking alternative?The consumer edition is gone and the professional one costs $699. Here is the honest field, including where Fluent is the wrong answer.
• Which should you choose?Windows Voice Access is the mature default. Fluent explores a different natural-language layer.
• Does voice control help with RSI?Reduce keystrokes and clicks in the order that costs least. Voice is one layer of that, not the whole answer.

Sources

• Fluent privacy and safety disclosure — Current speech, planner, and action boundaries.