Model configuration
The three-scope allowed-model cascade, default-model replacement, and -fast variants.
Three scopes
Which models a Teammate can actually pick from is the intersection of three settings, each narrower than the last:
| Scope | What it controls | Where it lives |
|---|---|---|
| Company allowed models | The full set your org can use anywhere | Company model configuration |
| Agent server override | Narrows the company list for Teammates on one server | Per agent server |
| Teammate default model | The single model a Teammate actually runs on | Per Teammate |
An agent server's override must be a subset of the company list — you can narrow what a server's Teammates see, but you can't widen it past what the company allows. Leaving a server's override empty means it simply inherits the full company list. A Teammate's default model, in turn, is validated against its server's effective list (company list narrowed by that server's override, if any). Every new conversation a Teammate starts runs on its default model; you can switch a single conversation on the fly with the /model command without changing the default itself.
When a change would break a default
Narrowing the company allowed list or a server's override can leave a Teammate's current default model outside the new, smaller list. When that happens, the dashboard doesn't silently reassign it — it prompts you to choose a replacement model for every affected Teammate before the narrower list takes effect.
Model changes require a full deploy
Changing the allowed-model list at any of the three scopes stages as a pending change like anything else, and it always classifies as a full agent-server refresh on deploy, not a quick reload — the allowed-models list is only read when a server boots. See Deploys & pending changes for the full hot-reload vs. refresh breakdown.
Quick-pick and -fast variants
The dashboard offers a "Recommended" quick-pick that fills the company allowed list with a curated, capable set pulled from the current model catalog, so you don't have to hand-assemble one model at a time. It's a starting point, not a lock-in — add or remove models freely after applying it.
Some models in the catalog have a -fast cousin — a speed-optimized variant of the same model, tuned for lower latency rather than maximum capability. The platform's automatic default-model pick (used when a new Teammate is created) always skips -fast variants in favor of the canonical model; you can still select a -fast variant yourself as a Teammate's default if you want the latency trade-off.
Bringing your own provider keys
Enterprise plans can bring their own provider API keys instead of using models on the platform's managed billing — contact us if that's a fit for your team.
API and MCP
Model configuration has full dashboard/API/MCP parity at all three scopes — company allowed models, server overrides, and Teammate defaults are all available through the HTTP API and MCP tools as well as the dashboard. See API & MCP for the resource map.