How-to guides
How OOMU picks a model
The understanding model, and what it decides.
Every message you send passes through a model whose only job is to understand the request and choose how to handle it. It is small, it is local, it never writes your answer, and it runs before anything else happens.
The chat shows it working: "Understanding your request…"
Your choice comes first
The Model control above the composer sets the frame the router has to work inside:
| Choice | Behavior |
|---|---|
| Automatic | "OOMU chooses on-device or your default cloud model for each request." |
| On this Mac | "Keep reasoning on this Mac." |
| Cloud | "Always use the exact cloud service and model you select." |
Agents carry the same three-way choice, so a research agent can be pinned to cloud while an everyday agent stays local.
Two things override Automatic and cannot be argued with:
- A project set to Only this Mac removes cloud from consideration entirely.
- Air-Gap Mode removes it globally. See Enterprise security.
- Use cloud models in Automatic in Settings turns the whole escalation path off: "Local-only projects always stay on this Mac."
What the router sees
Before the router runs, OOMU builds a turn snapshot: a complete, structured picture of the situation. It contains, among other fields:
| Field | |
|---|---|
| Your prompt, recent context, and recent conversation | |
| Attachment metadata: type, size, digest, whether it is an indexed document | |
| The capability manifest version, so the router only proposes actions that exist | |
| Which local and cloud models are actually configured | |
local_only and cloud_permitted: the project's policy | |
network_available, and per-provider availability | |
| Which Apple permissions macOS has actually granted | |
| Any workflow the turn is continuing | |
| Source labels for every segment of context, recording where it came from |
That last one matters. Text you typed and text that arrived from a web page or a document are labeled differently, all the way through. The router knows which is which.
What the router decides
It emits a turn decision, not an answer. The decision names:
| Field | What it carries |
|---|---|
| Reasoning route | Local · Cloud · Deterministic · Clarify |
| Mode | Conversation · Tool · Workflow · Mixed · Clarification |
| Normalized goals | What you actually asked for, each tied to the spans of your text it came from |
| Proposed capabilities | Which actions might be needed, each tied to a goal |
| Requires fresh information | Whether this needs a live lookup |
| Requires visible browser | Whether it needs the browser panel |
| Non-command mentions | Spans that mention an action without asking for one |
| Ambiguities and risk signals | What is unclear, and what looks risky |
| Router model and manifest digest | Which router, against which capability set |
The four routes
| Route | Meaning |
|---|---|
| Local | Answer with the model on this Mac. |
| Cloud | Escalate to your configured cloud model. |
| Deterministic | No language model needed: native code can answer. Arithmetic, runtime status, and similar. |
| Clarify | The request is genuinely ambiguous. Ask one question first. |
Deterministic is the underrated one. A calculation does not need a language model, and OOMU does not use one for it. This is why the Quick Launcher can evaluate an expression instantly and exactly.
Mentions are not commands
Non-command mentions is a small idea with a large effect. When you write "he asked me to delete the old drafts", you are reporting speech, not issuing an instruction. The router marks those spans explicitly so the difference survives into execution.
The router's evaluation corpus tests this deliberately, across twelve languages, alongside negation and reported speech.
When you need a clarification
If the router chooses Clarify, the chat shows a small panel rather than guessing:
One detail OOMU needs a little more information.
Answer it and the turn continues. This is a deliberate design choice: a wrong guess that runs is worse than a question that costs you three seconds.
Validation after the decision
The decision is checked before it is acted on. A decision that is internally inconsistent (for example, claiming the deterministic route for a plain conversation) is rejected rather than executed.
Every accepted decision is recorded with its digest, alongside the request digest, so what the router decided for a given turn is reconstructable afterwards.
If the router cannot produce a reliable decision, the chat says so plainly: "OOMU couldn't understand that request reliably. Try saying it another way." It does not fall back to guessing.
Watching it work
- The composer shows Auto-route ready · {route} once the decision lands.
- The Tuning panel shows the Active route for the session.
- The reply carries its own provenance: whether it came from this Mac, a cloud provider, or native code, and which model.
A reply from native code cannot claim a cloud provider. The provenance record enforces that, and a response with no native execution receipt behind it cannot claim one either.
Web grounding
When the router sets requires fresh information, OOMU may use web.public.retrieve. That runs one search, entirely out of sight: a direct text-only request first, and a headless pass only if that comes back empty. No browser window ever opens. The chat labels the section Web research and lists the Sources it read, so an answer that depended on the web says which pages.
The sources go straight to the model that writes your answer, with no intermediate scoring or rewriting step in between. Every link the answer cites is checked against the URLs the search actually returned. The prose is the model's; the citations have to be real.
Details are in Automating your Mac.
Related
- Choosing a local model: the models the router is choosing between.
- Enterprise security: Air-Gap Mode, which removes the cloud route.
- System design overview: where routing sits in the whole.