Skip to main content
This documentation is for the federal deployments of Devin. Back to Devin Docs
Federal enterprise administrators can control model availability at two levels:
  1. Team-level model availability determines which models are available to the team.
  2. Group model allowlists further restrict the models available to members of each group.
Group controls can narrow team availability, but they cannot expand it. A model that is not available to the team cannot be made available by adding it to a group. For information about creating and managing groups, see Groups. Group membership can also affect a user’s ACU limit; see ACU limits.

Configure group model availability

In Settings → Groups, open a group and select Edit models. Cascade and Command surfaces have separate selections:
  • Cascade Models
  • Command Models
An empty selection means no opinion about a member’s model access for that surface. It does not override another group’s restriction. If no group the user belongs to has a non-empty selection for that surface, the effective group policy has no restriction and the user receives the models available to the team. The portal uses No Cascade model policy, No Command model policy, and No model policy for these unrestricted states. Group selections are limited to the team’s current model availability. If an administrator later removes a model at the team level, the stored selection can continue to contain that unavailable model. The portal warns: Unavailable models remain in this group’s restriction until you change that model list. Unavailable selections remain restricted until an administrator edits the list. If all stored selections are unavailable, the group can show No available models. If saving an edited model list fails, the portal shows Changes may not have been saved. Review the group’s selections and retry the edit.

Resolve controls across groups

A user who belongs to one restricted group receives that group’s allowlist for the relevant surface. A user who belongs to multiple groups receives the union of every non-empty allowlist for that surface. Groups with an empty selection have no opinion and do not change the result. For example: Cascade and Command are resolved independently. A user’s effective Cascade list can differ from their effective Command list.

The union gotcha

Under union semantics, each additional group can add models to the user’s effective availability. The union is the most permissive combination of the user’s non-empty group selections, still bounded by the models available to the team. For example, disjoint restrictions are combined rather than rejected: A broad group can undo a narrow group’s restriction. If one group selects Model A and another group selects Model A, Model B, and Model C, the user receives all three models. To restrict a user, every group they belong to must be restricted appropriately; one broad non-empty group can widen the effective result. An empty selection is different: it has no opinion and does not itself widen access. An empty effective model list can still occur when stored selections contain only models no longer available to the team, or when team-level and other availability filtering leaves no matching models. This is separate from multi-group resolution: disjoint valid selections produce their union.

Where controls apply

Group model controls apply to:
  • Model pickers and available-model lists.
  • Cascade requests.
  • Command requests.
  • Direct model requests at request time.
  • Automatic model routing and assignment.
  • Models selected indirectly by a router.
Group restrictions are applied to routing candidates and checked again at request time. A user therefore cannot bypass a group restriction by selecting a model through an automatic router instead of selecting it directly.

Devin CLI and Devin Local

Devin CLI and Devin Local use the Cascade group selection. They are not configured with a separate group-level CLI allowlist. The CLI’s available model list and request-time model checks follow the Cascade policy. An empty Cascade selection has no effect; it produces the team’s available Cascade models only when no other group contributes a non-empty Cascade selection. It does not by itself disable or broaden the CLI.

Private team models

Private models configured for the team are also filtered by the applicable group controls. Private team models do not bypass a member’s Cascade or Command restrictions.
No. Groups can only narrow the models already available to the team. Team-level model availability is always the upper bound.
It means the group has no opinion about model access for that surface. If no group the user belongs to has a non-empty selection, the user receives the models available to the team. If another group is restricted, the empty selection does not override that restriction.
The non-empty allowlists are unioned separately for Cascade and Command. Disjoint selections are combined, so a user with Model A in one group and Model B in another can use both, subject to team availability. To keep a user restricted, review every group they belong to because a broad non-empty selection can widen access.
No. Automatic routing and assignment are evaluated against the models remaining after team and group controls are applied, so a disallowed model cannot be reached indirectly.