Model Governance (Settings → Models)
Stage: Settings (admin) · What it does: control which models can be used for which functionality across the platform — like the Instances tab does for GPU types. Admins set tenant-wide defaults and per-user overrides; every model-backed feature (Ask AI, judges, LLM Format, custom assistants, chat) checks this gate on every call.
Why it matters
- One switchboard, many features. A model enabled in one place is enabled consistently everywhere — no feature-by-feature allowlists to keep in sync.
- Cost governance. Every model is metered at its real blended price (see below). Enabling a frontier model can't silently undercharge; locking a model to a tenant can't break a feature that never used it.
- Least privilege. Give a tenant or a user exactly the models they're approved for, per purpose — nothing else is even offered in the dropdowns.
The purposes (what "functionality" means)
Each model can be granted one or more purposes. These map directly to platform features:
| Purpose | Feature it gates |
|---|---|
| Ask AI | The Ask AI assistant in the console |
| Chat | General chat surfaces |
| Assistant | Custom AI assistants you build and embed |
| LLM Format | The LLM Format pipeline node (formatting training data) |
| Judge | LLM-as-judge (quality review of generated rows, gateway safety checks) |
| Glossary | Glossary AI |
| Notebook | Notebook agent |
| Guide | Guided-workspace help agent |
| Healer | Self-healing assistant |
| Embed | Embeddings (Titan) |
A model's capabilities are fixed in the catalog — you can only grant purposes a model actually supports (you can't make an embeddings model do chat).
How it works (resolution order)
When any feature uses a model, the platform resolves the effective grant for that user, highest wins:
Per-user override → role (their role's Models) → tenant default → catalog default
- No grants configured at all: every default-on model works for its catalog capabilities (the platform's current working set).
- Tenant default set: applies to everyone in the tenant who has no per-user override.
- Per-user override set: applies to that user only (typical for a locked-down analyst or a pilot user).
Your per-user "allowed models" are what the model dropdowns actually show you — if a model isn't granted, it doesn't appear as an option.
Deployed endpoints are exempt by design. A model you deployed yourself (
deploy:…), a BYO endpoint, or a legacy DeepSeek id is your model serving whatever you pointed it at — the gate only governs the platform's managed catalog models.
How to use (admin)
- Settings → Models.
- Tenant defaults: set the model × purpose grid for the whole tenant, then Save. - Unchecking a cell = that model is not available for that purpose in this tenant. - Saving an empty grid clears the override — back to catalog defaults (never "deny everything").
- Per-user overrides: pick a user, set their grid, Save. Clear removes their override.
- Model rows show price per 1M tokens and region availability — the numbers an admin needs to decide "should this be on?".
Real-world examples
🏦 Financial services — model approval workflow
A bank's ML platform team approves exactly three models for production: the default DeepSeek v3.2 for Ask AI + judges, Llama 3.3 70B for LLM Format, and Nova Micro for assistants. The tenant default grid encodes that; a data scientist who tries to use Claude for LLM Format finds it simply isn't in the dropdown. Their vendor review is "here's the grid" — one screen.
🧑💼 SaaS — pilot user, then rollout
A SaaS company enables a new Qwen model for a pilot user first (per-user override), watches cost and quality for a week, then promotes it to the tenant default.
🏥 Healthcare — least privilege per role
A health system gives researchers the small local models only (Gemma/Llama 8B), keeps frontier models admin-only, and locks the embeddings model to the pipeline role — PHI-bearing features run on the smallest capable model by policy.
Gotchas
- Empty grant list = catalog defaults, not deny-all. To lock a tenant down you must set the grid you do want; clearing it re-opens the default-on set.
- Unknown models are rejected at save — the catalog is the source of truth; you can't grant a model the platform doesn't know.
- Model dropdowns show only what's granted to you — if a feature's select is missing a model you expected, check your tenant/user grants, not the feature.
- Grant changes take effect on the next request — no restart, no redeploy.