Models, router and privacy
Built-in models
Section titled “Built-in models”Yttri ships with a set of models that run right on the device — no internet, no data sent out: a language model, search, speech recognition, OCR. What each one does, how big it is, and how well it performs — on its own page: Built-in models.
The router: which model does which job
Section titled “The router: which model does which job”Settings → Assistant → the Router tab.
A table of three columns — task, provider, model:
| Task | What it is |
|---|---|
| Quick answers | a fast reply without tools |
| Standard work | tools without delegation |
| Deep work | the full agent loop |
| Image recognition | describing pictures and screenshots |
| Image generation | creating images from a description |
| Background tasks | tags, summaries, mail translation, filling the wiki |
| Background orchestrator | plans the work and assembles the result |
| Fallback model | where a task goes if the built-in model fails |
Provider values: Main (inherits your main model — the default), Yttri Cloud, any provider of yours, Built-in (background and orchestrator only), Same as background (orchestrator only) and Off (fallback only).
The model list is fetched from the provider; when it can’t be fetched, the ID is typed by hand. Image recognition filters to models that accept images, generation to models that produce them.
Background tasks: the decision that matters
Section titled “Background tasks: the decision that matters”Background tasks are the agent’s quiet work: tags, summaries, mail translation, fact extraction, filling the wiki.
The difference from chat. In chat you send a specific text yourself and so consciously choose the route. A background task runs over your whole corpus — mail, notes, documents — without per-item consent. That is why it has its own setting, and why it points at the built-in model by default.
Three scenarios
Section titled “Three scenarios”Background on the built-in model (the default). Data never leaves the machine, works offline, spends no subscription — its inference and generation parameters are tuned and validated by tests (more in Built-in models). The price is quality: a 4B model is simpler than a cloud one, so summaries are shorter and rougher.
Background on your own inference. Your own server with a model larger than 4B gives near-cloud quality while keeping data in your perimeter. Check three things before calling it private: the address really is yours and on your network; the server doesn’t log requests outward; the model has enough context — background tasks receive long emails and notes in full.
Background in the cloud. Faster and smarter, but your mail and notes go out, and not everything is masked. It spends your plan’s tokens.
Turning background work off entirely is also an option: no auto-tags, summaries, fact extraction or proactive suggestions, everything else works.
The orchestrator
Section titled “The orchestrator”The orchestrator doesn’t read your data — it plans the work, hands out subtasks and receives digests. A 4B model is weak for that role, so a cloud model makes sense here.
Understand the risk: the digests go out, and names and amounts stay in them. If that’s unacceptable, leave “Same as background”.
The fallback model
Section titled “The fallback model”Where a task goes if the built-in model fails. Off by default: without explicit consent nothing goes to the cloud, and background processing simply stops with a notification.
What is masked before going to the cloud
Section titled “What is masked before going to the cloud”Personal data masking. Before a request goes to a cloud provider, card numbers (Luhn-validated), phone numbers, document identifiers, passwords and API keys are stripped from the text. Email addresses and amounts are deliberately not masked — without them contact matching and finance parsing break.
For a local provider masking is not applied by default: the data doesn’t leave the machine anyway.
The private layer. Deal and work economics — contract totals, rates — are removed from structured data for any cloud provider and for external MCP clients. This is not a user setting: switching personal-data masking off does not open this layer.
Three lines of control
Section titled “Three lines of control”- Indexing (Data and privacy) decides what the agent sees: notes, meetings, mail as separate switches.
- Topic permissions decide what it does: reading, editing notes, sending mail, web search, fetching pages, running code, MCP, finance writes — as Auto, Ask or Deny.
- The router decides where data goes while being processed.
Separately there’s “Terminal and file system”: permission for the agent to run commands and work with files outside the Yttri workspace. Enable it only if you understand the risks.
Other data-exit channels
Section titled “Other data-exit channels”The model provider is not the only boundary.
Web search. The agent’s query goes to a search provider. DuckDuckGo works without a key, the others need an API key; keys live in secure storage and are not written into the settings.
The MCP server. Yttri hands its tools to external AI clients. Three things matter: domain permissions (start with read-only), project context (the output can be limited to one project) and client API keys — a key is shown once.
Plugins. They run in a sandbox and request access per domain. On update the new permissions are listed separately — access is never widened silently.
Remote access. An outbound tunnel with no inbound ports opened, and the authenticator code is verified locally; the Yttri server acts as a router and stores none of your data.
Three ready-made configurations
Section titled “Three ready-made configurations”Maximum privacy. Main model — your own local server; background — built-in; orchestrator — “Same as background”; fallback — off. Nothing goes out. The price: quality is bounded by your hardware.
A reasonable compromise (the default). Main — Yttri Cloud; background — built-in; orchestrator — cloud; fallback — off. What goes to the cloud is what you send yourself, plus the orchestrator’s anonymised digests.
Maximum quality. Everything in the cloud, fallback on. Background processing will read your correspondence and notes with a cloud model, and only cards, phones, documents and keys are masked.
Verifying the setup
Section titled “Verifying the setup”- Main model: “Test connection” should say connected, with a latency.
- Built-in model: selected in the assignments, not “Not selected”.
- Routes: the Main tab shows a summary of what runs locally and what in the cloud.
- Background works: create a note and see whether tags and a short description appear.
- Spend: the Main tab shows requests and tokens per day, week and month. A zero where you expect work means the route isn’t running.
When something doesn’t work
Section titled “When something doesn’t work”| Symptom | Where to look |
|---|---|
| The agent doesn’t answer in chat | Assistant → Models → Test connection |
| A limit or budget error | Account → subscription |
| No tags or summaries | Assistant → Router → Background tasks |
| Data went somewhere unexpected | Assistant → Main; Agent settings → Action history |
| Unclear token spend | Assistant → Main, or AI tracing |
| The agent doesn’t see an email or note | Data and privacy → indexing |
| The agent asks instead of acting | topic settings → tool permissions |
The built-in model disabled itself. That happens after a run of failures — the background task settings show the reason and the date, with a button to enable it again.
Requests break on large payloads. There’s a dedicated message about TLS inspection: an antivirus or network filter inspecting secure connections corrupts large requests. Adding the domain to its exclusions fixes it.
The agent says a feature doesn’t exist. Its knowledge about the app is the built-in help. Most likely the article is missing, not the feature.