First-time setup

Yttri works with personal data: mail, notes, meetings, finances. So setup comes down to one question — which model sees which of your data. Everything else is secondary.

The order worth following:

1. Account and subscription — what is available at all.
2. The main model — who answers you in conversation.
3. The built-in model — whether you need it and whether the machine can run it.
4. The router and background tasks — the important privacy decision.

The first run

After signing in the app walks you through a few screens. Any of them can be skipped.

Model check. The screen tests two things separately: the cloud AI and the built-in model for background tasks. For the cloud it shows the latency in milliseconds, for the built-in one whether it is available on this machine. The errors are specific: too many requests, plan budget exhausted, provider unavailable, re-authentication needed. Next to them: “Test again”, “Download the model again”, “Use the cloud”.

Audio. A microphone and system-sound check — needed for recordings and meetings.

Background tasks and privacy. The screen explains what these tasks are and why the built-in model is preferable for them. Without a suitable GPU you get a choice instead: run background work through the cloud (everything works, your plan’s tokens are spent) or turn it off (no tokens spent, but no auto-tags, summaries, fact extraction or proactive suggestions).

Questionnaire. Six steps: name, role, what you work on, tone, interests, connecting mail. The answers become your initial profile, which the agent leans on. The mail step can be skipped and done later — a step-by-step guide per provider is in Connecting mail.

Summary. Status per item — subscription, cloud AI, built-in model, audio, mail — each linking to the right settings page.

Account and subscription

Settings → Account.

Subscription: plan, status (trial, active, cancelled, expired, past due), end date. “Change plan” opens the management page, “Refresh subscription status” re-checks it.

Cloud models require an active subscription or trial. Without one the app runs in free mode: local features stay, the cloud AI is off.

Offline. With no internet the subscription is not verified — a grace period with a countdown applies. The app states plainly that the status could not be confirmed instead of silently disabling AI.

Payment card: next charge date, turning auto-renewal off, unlinking the card. A failed charge raises a banner — access stays until the end of the paid period.

The main model

Settings → Assistant → the Models tab.

The main model answers you in conversation. Two options:

• Yttri Cloud — Yttri’s cloud AI: no keys, no model to pick;
• your own provider — any service with a compatible API, your own server included.

Next to it is Test connection: it tests the current choice and shows the latency or the error text.

Note

The built-in local model is deliberately absent from the list of main models: it is meant for background tasks, not conversation. An older config with a local provider in chat raises a “local models temporarily unavailable” banner.

Your own provider

The add dialog has five fields:

Field	What to enter
Name	how the provider appears in lists
API type	Chat Completions (OpenAI-compatible), Messages API (Anthropic) or Responses API (OpenAI)
Base URL	the full base URL — the app appends the final segment itself
API key	not required for local servers
Local provider	detected from the address, switchable by hand

The dialog has its own connection test, before saving. Deleting a provider deletes its API key too; if it was active, Yttri Cloud becomes active.

For non-cloud providers you also get a model picker, context length, maximum output tokens and the reasoning effort level. Parameters are filled from a model registry, and can be set by hand when a model isn’t in it.

Your own inference: LM Studio, Ollama, LiteLLM

A local server connects as an ordinary provider: API type Chat Completions, Base URL of your server, usually no key.

The Local provider flag is set from the address automatically: localhost, 127.0.0.1, ::1, *.local and the private ranges 10.*, 192.168.*, 172.16–31.*. Everything else counts as external.

Caution

The “local” flag is not cosmetic. It decides whether Yttri masks personal data before sending, how the thinking mode is handled and whether some heavy tools are available. A model on a VPS is an external address: clearing the flag there switches the protection off.

Step by step — LM Studio, Ollama and your own gateway for multiple models (LiteLLM in Docker, for example).

The built-in model

Settings → Assistant → Models → Built-in model.

Qwen3.5-4B, shipped with the app. It handles background processing and internal routes, not conversation.

Options: the standard build (GGUF), the Apple Silicon build (MLX) and “Not selected” — in which case the internal routes that depend on it simply don’t run.

Requirements are checked automatically, and when they aren’t met the app names the reason: not enough RAM, Intel Mac unsupported, no discrete NVIDIA GPU, less than 8 GB of VRAM, a CPU-only Linux build, the model file missing or corrupted.

The model downloads with a button — about 3.2 GB, in the background. Windows additionally needs the CUDA runtime (about 450 MB) and a restart after installing it.

Note

The requirements are strict for a reason: a 4B model is too heavy for a CPU — without a GPU it produces stalls and timeouts instead of results, so local processing is disabled in those cases.

The same tab assigns the speech recognition (ASR) and speech generation (TTS) models — they download on demand, with progress and errors shown in the row.

Voice

Speech recognition and speech output use separate local models, unrelated to the main model choice. Speech is processed on the device — one more reason for meeting recordings not to travel to the cloud.