04 / Operate

Engines & models

An engine is a connection to an AI model. Connect your own provider API key in the web app, or use the engine options available in an existing desktop installation. Model availability, costs and rate limits depend on the provider and execution environment.

What an engine is

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

• Desktop CLI engines — supported agent CLIs installed and logged in on the computer running the engine: 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. Provider catalogs, access requirements and charges can change; check the provider before choosing a model.
• Custom providers — supported OpenAI- or Anthropic-compatible endpoints. Local Ollama or LM Studio endpoints require a compatible desktop runtime on that computer; the hosted web service cannot reach your laptop through its own 127.0.0.1.

Muster presents replies, tool calls and supported approval requests in the conversation. Capabilities and usage reporting vary by engine, so check the selected engine before assigning a task or enabling recurring work.

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 first setup, open your workspace and follow Quick start. Muster account sign-in does not supply a provider API key or make a provider chat subscription valid for API usage.

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.

Provider charges and key storage

Muster is a free app. You supply your provider API key and pay that provider for model usage. Connected tools and computer services can charge separately. This does not include an unlimited or prepaid model allowance.

Keys saved in a hosted account are stored by the service in an account-scoped encrypted vault and used server-side for provider requests. Settings shows whether a key is configured without displaying the saved value. Existing desktop configurations can store credentials on the installation instead. A key entered through the web app is not promised to remain only on your device.

Check the contents and requirements of the backup controls available in your version. Connecting Drive or signing in on another device does not by itself establish provider-key backup, recovery or automatic synchronization. See Account & device setup.

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 an approved remote computer where supported). 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.