Engines & models

An engine is a connection to an AI model — a CLI that's already logged in on your machine, an API provider with a key, or your own OpenAI- or Anthropic-compatible endpoint. Every bot runs on one, you can swap it mid-conversation, and every reply is stamped with exactly which engine produced it.

What an engine is

An engine is how a bot gets a brain. Muster supports three kinds:

• CLI engines — agent CLIs installed and logged in on your machine: Claude, Codex, Grok, Gemini, Kimi, Qwen, Hermes, Droid, Antigravity, OpenCode Go. Muster detects them on your PATH and they appear in the picker automatically — no key pasting.
• API providers — twelve built-ins (OpenAI, Anthropic, Google, xAI, DeepSeek, Mistral, Cohere, Groq, Together, Fireworks, OpenRouter, OpenCode Zen) driven by an API key. No CLI required. OpenRouter carries a large :free catalog including the Nex AGI N2.5 agentic models (262K context, tool calling; Pro adds vision).
• Custom providers — any OpenAI- or Anthropic-compatible endpoint you register yourself, including Ollama and LM Studio on 127.0.0.1.

All of them normalize to the same runtime event stream — streaming replies, tool calls, approvals — so a bot behaves identically no matter which engine sits underneath. Swapping models mid-conversation is normal practice: let the cheap one triage, the smart one write.

Adding an engine in Settings

Open Settings and you'll find two relevant panels:

• Settings → Engines — for CLI engines. Muster lists what it detected. Each engine has a Set CLI… control to override the binary path: pick from every binary the server found on your PATH, or enter a manual path (useful for wrappers). Saving probes the binary with a version check; if the probe fails — typically a path your terminal sees but the GUI app doesn't — Muster asks before registering it anyway.
• Settings → Providers — for keys and custom endpoints. Paste a provider's API key into its row, or click Add model provider to register your own endpoint: a name, a base URL, an optional key, a wire format (openai or anthropic), and the model list to expose in the picker. Muster can fetch the model list from the endpoint's /models route automatically; if the endpoint doesn't serve one, enter the model IDs manually.

For the very first setup, muster setup walks you through connecting to the server and picking an engine before introducing your first bot — see Quick start.

Naming instances

Each engine connection is an instance, and you can have several per provider — that's not a workaround, it's the intended shape. Two OpenAI keys with different budgets, a personal and a work Anthropic account, one OpenRouter instance routed through a gateway and one direct: each gets its own entry, its own key, and its own display name. Bots pick an instance, not just a provider, so the assignment is exact.

Assigning engines to bots

Every bot carries its own model selection: an instance plus a model from that instance's list. Set it when you hire the bot, change it later from the bot's settings or the model picker in the chat header, and the next turn uses it — the transcript doesn't care. Two bots in the same team can run on entirely different providers, and handing one conversation from a fast model to a frontier one mid-thread takes one click.

Your keys stay on your server

Muster is bring-your-own-key by design. API keys are stored server-side in your data directory (~/.muster on a desktop install), never echoed back to the UI once saved — the settings panel shows a configured-or-not flag — and never sent anywhere except to the provider the key belongs to. Custom-provider keys ride the instance's own environment into the driver, not a shared process env. There is no Muster-side key escrow and no model billing through us: usage is between you and your providers.

Health and status

Muster watches engines from local signals, never by scraping provider dashboards:

• The provider health dashboard (Settings → Usage → Provider health) shows, per provider: instances and which bots use them, turns, tokens in/out, spend, and rate-limit hits in the last 24 hours. "Healthy" means traffic without recent rate limits; "rate-limited recently" means the provider pushed back within a day; "no traffic yet" means unused. When an instance trips a rate limit, it sits out a cooldown before it's picked again.
• A CLI engine that isn't installed or isn't signed in surfaces a focused setup card — the install command for your platform or a sign-in prompt — rather than a silent failure.
• Drivers that can't start degrade to unavailable. One broken engine never takes down the fleet.

Provenance chips

Every bot reply in chat carries a small via chip — the model, and when it differs, the instance display name that produced it. It's low-key by default: hover the reply and the chip fades in, with the full instance name (and effort level, when set) in its tooltip. When you swap a bot's model mid-thread, the older bubbles still show what produced them, so "which brain said this?" is always answerable by looking.

Browsers and computers

An engine is the thinking half of a bot; the computer is the doing half. Bots on computer-use-capable providers can drive a live browser — a session in the chat's side panel that you can watch frame-by-frame and grab control of mid-task — alongside the other computer options (cloud desktop, your own machine, a local VM, or a BYO VPS over SSH). See Approvals & privacy for what the bot may do on that computer without asking first.

Quick reference

Next: put engines to work — Goals & autonomy and Automation.