Model control
Model control is where organization admins choose which models and providers your org can use, and set defaults for each surface — desktop, CLI, cloud agents, and mobile.
Members only see models you allow. If a model is disabled, it won't appear in pickers — and manual picks in the CLI are blocked too. This is not where you change your commercial plan; your contract defines the ceiling of what can be enabled. Model control is how you curate that catalog for day-to-day work.
What this page is for
Model control curates which models members can use inside your plan. Included providers and model groups come from your agreement — set in the Console, not here. Allowed models still consume allowance — pair catalog choices with Usage & billing budgets and weekly review during rollout.
Who can see and change what
If you cannot open Model control, your role may be member only — ask an admin in Members. Members still pick from allowed models when they run agents; they just cannot change org policy.
Why model control matters
Model control works best together with Usage & billing — allowed models still consume allowance when people run agents. Tightening the catalog is often the fastest cost lever before raising budget caps.
How model control fits together
Think of Model control as the model catalog boundary; other modules handle spend and people:
When someone reports a blocked run, check model policy here and budget policy on Usage — both can stop runs, but only model usage drives spend.
In practice
What admins control
Only admins and super admins change org-wide catalog settings. Delegated managers may narrow policy for their team or project where your plan supports it — never widen beyond the org catalog or plan.
Set org-wide catalog
See what your plan includes
Your contract defines the ceiling — you can only enable providers and models your plan includes. Unavailable entries appear disabled in the dashboard. If something is missing, see Contracts & capacity or Help.
Enable what you use in production
Turn on the providers your team actually uses. Prefer model groups (for example "standard" or "reasoning") over long manual lists so new models in a group roll out smoothly.
Set defaults and save
Pick defaults for each surface (below), save, and tell the team which models to use for which jobs. Changes are recorded in the audit log.
Enable a small catalog first, watch Usage for a week, then expand if you need more capability. Most teams need fewer models than they expect at rollout.
Defaults per surface
Defaults improve onboarding — members get a good experience without configuring anything.
You can use the same default everywhere or tune per surface for cost and quality. The CLI default applies to headless and automation when no model is specified.
Team and project limits
Delegated managers may narrow org policy for their team or project — for example, production projects allow only standard models while a sandbox allows experimental ones.
They cannot enable models the org catalog blocked or your plan excludes. Org policy is the outer boundary; team and project settings refine it inward.
Restricting the catalog is one of the fastest ways to keep spend predictable. Pair model control with budget policies and review usage weekly during rollout.
When a model is blocked
If someone reports "model not allowed" in the desktop app or CLI:
Confirm which model and surface
Note the model name and where they ran — desktop, CLI, or cloud.
Check the org catalog
In Model control, see whether that model (or its group) is enabled for the org and surface.
Check team or project scope
If they're on a restricted project, they may need an allowed default or a catalog update at project level — not a one-off workaround.
Fix or redirect
Either add the model to the allowed set, adjust the project limit, or ask them to use the org default for that surface.
Policy denials may also appear on the Usage page when someone tries a blocked model — useful when the member only saw a generic error in the app.
If a recent catalog change caused confusion, use Change history in Model control to restore a prior version instead of re-clicking every model manually.