NO_TOOL and confidence checks. An unsupported or uncertain
choice stops routing before a plan is released.
Setup
Use Python 3.11 or newer:Define the command tree
This example supports a small subset of the source assistant:
General app commands select exact targets from the local maps below. The model returns an
ID such as
downloads; local code supplies the actual target. It cannot invent a URL,
app name, shell command or executable argument. Coding mode’s extra apps are available
only through that named preset.
Ask one question at a time
Router.ask sends the original WAV and a fresh question for the current stage. Earlier
selections tell Tazo what has already been chosen. A stage needs at least 65% confidence
and a 12-point lead over the runner-up. NO_TOOL or an unrecognized choice never passes.
The helper records a trace and enforces a ten-decision ceiling and a 1,000-character text
budget per stage. If a menu grows too large, shorten descriptions or split the stage into
smaller choices rather than silently dropping options.
Assemble the plan
Add this method toRouter. First choose a structure for the whole command. Open-only
commands select one or two distinct apps. An app-action command then selects an operation
from that app’s menu and a target from that operation’s menu.
A final app-command question compares the entire recording with the plan: opening Finder
does not also fulfill “show Downloads.” A confident missing answer discards the plan,
just as an uncertain stage does. This recipe asks the speaker to clarify rather than trying
to repair a partial plan automatically.
Timers select one exact duration, and Coding mode expands a fixed local preset; these two
branches return directly after their bounded decisions.
Route recordings and inspect the result
route_command validates the recording before sending it. It returns an empty plan when
routing is unresolved. API and SDK errors propagate, so a failed request cannot return a
partly built plan as though it were complete.
say, voice Samantha.
A live SDK 0.1.2 check routed the six supported fixtures to their intended plans and
rejected both unsupported fixtures. Outputs remain probabilistic between runs.
Multiple input files are routed independently. A result with
status="needs_clarification"
includes a reason and trace, with plan=[]. No desktop side effect occurs in this example.
Build on it
- Add an app or action. Extend the app menu, its operation map, and its exact target maps together. Keep concrete URLs and device identifiers in application code.
- Filter by availability. Before asking, remove choices whose apps, saved targets or permissions are unavailable on the current device.
- Execute a reviewed plan. Preflight every step, show the entire plan for review, then call typed adapters in order. Keep a receipt if a later step fails after earlier effects.
- Support longer combinations. Add another bounded structure and corresponding stages. Keep the completion check and decision ceiling, and account for extra serial latency.
Limitations
- This is a planner. Timers, app launches and window placement are output steps; real desktop adapters, a countdown and a review interface belong in your application.
- Only the structures and targets above are supported. A request for an arbitrary URL, dictation or a third general-command app must stop without a plan.
- Confidence and completeness checks are probabilistic, not guarantees of correct routing. Test your actual spoken commands before connecting side effects.
- Every stage resends the same recording and consumes another decision. More stages add inference usage and serial network time. Failed routes are not automatically replayed.