Organization model settings
Organization administrators can govern which language models members use across Devs.ai. From a single settings page you decide which models are available, whether each model appears in chat, App Builder, agents, or routines, and which groups or individuals are excluded from a model.
This is separate from custom user permissions, which controls roles and resource access. Model settings focus specifically on which LLMs people can pick and where those models show up.
📝 Note: Image-generation models and org-wide default image models are managed on the same page but follow simpler allowlist rules. This guide focuses on text and LLM model governance.
Accessing model settings
- Open Organization in the left sidebar.
- Click Models (or go to Customize Organization Models).
- You need organization settings read permission to view the page and write permission to save changes.
The page lists every model your organization can see in the catalog. Use the controls on each row—and the configure drawer for a model—to shape availability and access.
Restricting which models are available
At the top of the page, choose how broadly models are exposed:
- Unrestricted — New platform models become available automatically. Members see the full catalog your plan and region allow.
- Restricted — You maintain an explicit allowlist. Only checked models are available; new platform models do not appear until an admin enables them.
When restriction is off, per-surface and per-user rules below are not applied. Every visible model is treated as enabled everywhere.
When restriction is on, you pick which models stay on the allowlist and can narrow further by surface and audience.
Per-surface availability
For each model on the allowlist, open the configure drawer (gear icon) and set Availability—which product areas may use that model:
| Surface | Where members see it |
|---|---|
| Conversational chat | Default chat and agent conversations |
| App Builder | Model picker when building apps |
| Custom agents | Model selector in the agent editor |
| Routines | Model picker when a routine selects a model directly |
A model can be enabled for App Builder and routines but disabled for general chat, which helps keep expensive models for specialized work without exposing them in everyday conversations.
📝 Note: When a routine runs through an agent, the agent’s model is governed by the agents surface, not the routines surface. The routines surface applies when you pick a model directly on the routine.
If you enable zero models for a surface while restriction is on, the product falls back to a platform default for that surface so work is not blocked. The settings page may show a warning when a surface would have no enabled models.
Access by group and user
These controls apply only when restriction is on. When the organization is unrestricted, Access settings are ignored and every visible model is available to all members.
Inside the same configure drawer, use Access to limit who can use a model:
- Everyone has access — The default. All members who can see the model for a given surface may use it.
- Restrict access — Exclude specific user groups or individual users. Excluded people do not see the model in pickers for any surface.
Restrictions are subtractive: you start with everyone allowed and remove access for groups or people who should not use a model (for example, withholding a costly coding model from teams that only need lighter models).
When restriction is on, the platform enforces these rules server-side. Pickers hide disallowed models, and explicit requests for a blocked model are rejected.
Dedicated-instance badges and clearer controls
Models that run on a dedicated instance show a badge on the settings page so admins can tell them apart from shared catalog routes. Tooltips and the configure drawer explain availability, surface checkboxes, and access exclusions before you save.
You can review changes in the drawer and save when the policy matches what you intend. Warnings appear if a configuration would leave no eligible members for a model—saving is still allowed, but you should confirm that is intentional.
What end users experience
When the organization is unrestricted, members see the full catalog their plan and region allow on every surface.
When restriction is on, members only see models they are allowed to use for the surface they are in:
- Chat model picker → models enabled for chat that the user is not excluded from
- App Builder → models enabled for App Builder
- Agent editor → models enabled for agents
- New routine with a direct model pick → models enabled for routines
If a model is missing from a picker, check whether restriction is on, org model settings, your plan, and whether an admin excluded your group or account. Custom deployments and provider keys can also add org-specific models; see Provider keys and custom deployments.
Org custom models from custom deployments are managed on the same Models page once they are registered.
Related topics
- Configuring model and data sources — how builders choose a model for an agent.
- App Builder — model picker and cost controls in the builder.
- Routines — scheduled runs and model selection.
- Provider keys and custom deployments — bring your own inference credentials and hosts.
- User permissions — roles and permissions beyond model access.