Skip to main content
A provider is an LLM service Mutagent runs on — the models used to build, evaluate and reason over your agents. You bring your own keys: you add a credential for a provider you already pay for, and Mutagent uses it on your behalf.

​
One level, attached to the workspace

A provider configuration belongs to exactly one workspace. That is the whole model. There is no personal level, no organization level, and nothing is inherited from anywhere. A workspace’s providers are the providers 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.
Because there is only one level, there is nothing to override and no precedence to reason about. A provider either exists in the workspace or it does not.
Everything a configuration needs is named at the point you create it, and the workspace it lands in is the workspace you are working in. You never select a level.

​
The provider catalog

Mutagent offers eleven provider entries. Seven talk directly to the vendor that trained the model; three are gateways that host somebody else’s models; one is an escape hatch for any endpoint speaking an OpenAI-compatible API. Each entry asks for a different set of credentials — a direct entry usually wants only a key, while a gateway wants the coordinates of your deployment as well. 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 a 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 provider — dashboard, CLI or API alike.

​
Which models a 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.
The dashboard and mutagent providers list --models show what a given configuration currently offers. Optionally, most entries accept a model allow-list to narrow that further.

​
Managing providers

Manage providers in the dashboard under Settings → Workspace → Providers, or from the mutagent providers CLI.

​
What providers power

  • Generation — the model used across the loop as you build and optimize.
  • Evaluation — the judge model. To judge on your coding agent’s own model instead — no separate provider call, no extra bill — set lifecycle.evaluator.judge_runtime: agent-dispatch in the config.
Providers configured here are distinct from the credentials_ref entries in a local Helix config.yaml. Those name an environment variable on your own machine. A provider added to a workspace stores the credential itself, encrypted, so Mutagent can call the provider for you.

​
Next steps

Provider Setup

Field-by-field configuration for every catalog entry