One level, attached to the workspace
An LLM provider configuration belongs to exactly one workspace. There is no personal level, no organization level, and nothing is inherited from anywhere. A workspace’s LLM providers are the ones it has, and no others. If two workspaces both need OpenAI, each gets its own configuration, even if the key behind them is the same. A configuration lands in the workspace you are working in when you create it.The provider catalog
Mutagent offers thirteen LLM provider entries. Nine are direct: one credential, no deployment to describe. Three are gateways that host somebody else’s models. One, Custom, takes any endpoint that speaks an OpenAI- or Anthropic-compatible API.
Each entry asks for a different set of credentials: a direct entry usually wants only a key, while
a gateway also wants the coordinates of your deployment.
LLM provider setup lists the fields entry by entry.
Gateways host more than one vendor
A gateway does not have models of its own; it serves models that belong to someone else. Azure and Vertex each host two model families, so selecting one of them asks a second question: which family is this configuration for?
One configuration covers one family. To use both OpenAI and Anthropic models through Azure, add two
Azure configurations — one per family. They differ in that single choice and live side by side in the
same workspace.
Bedrock hosts one family, so there is nothing to choose.
A gateway never offers more than the direct entry it derives from. If a model is not available on
Anthropic directly, it is not available through Azure, Vertex or Bedrock either.
Credentials are tested before they are stored
When you add an LLM provider, Mutagent contacts the provider with the credential you submitted before writing anything. If the provider rejects it, nothing is saved and you are told why. A stored configuration is therefore one that has connected successfully at least once. The check runs on the server, so it applies however you add the LLM provider: web app, CLI or API.Which models an LLM provider offers
You do not maintain a model list. Each entry carries its own policy, and the models on offer follow from it:- Some entries admit models at or above a version floor, so a newer release from the vendor becomes available without any change on your side.
- Some admit a fixed, named set.
- Gateways admit whatever their hosted family admits, addressed the way that gateway expects.
- A custom endpoint offers whatever it publishes.
mutagent helix models lists the model ids cloud runs can use with the workspace’s active LLM providers.
mutagent providers list --models shows the catalog models for each provider type. Optionally, most entries accept a model allow-list to narrow that further.
Managing LLM providers
Manage LLM providers in the web app under Configuration › LLM Providers, or from themutagent providers CLI.
--api-key-stdin keeps the key out of shell history. A successful add exits 0 and returns the new
provider’s id. LLM provider setup has the
flags for every entry and the common failures.
What uses a workspace’s LLM providers
- Helix Cloud sessions: every active LLM provider’s key is added to the cloud sandbox, and the session’s model comes from one of them. See Cloud sandboxes.
- Managed agent runs: the model the agent’s package names must belong to an active LLM provider.
- GitHub and Slack runs: they start cloud sessions, so they use the same keys.
Helix on your machine does not use these. It reads keys on your machine: the ones you sign in with
in Helix, or the
credentials_ref entries in a local Helix
config.yaml, which name environment variables. A workspace LLM
provider stores the credential itself, encrypted, so Mutagent can call the provider during cloud
runs. To copy the keys from Helix on your machine into the workspace, run
mutagent providers mirror.Next steps
LLM provider setup
Field-by-field configuration for every catalog entry