> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Model provisioning

> Control Cascade, Command, and CLI model availability by team and group.

<Info>
  This documentation is for the federal deployments of Devin. [Back to Devin Docs](/get-started/devin-intro)
</Info>

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](/federal/groups).
Group membership can also affect a user's ACU limit; see [ACU limits](/federal/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:

| Group                      | Cascade selection                   |
| -------------------------- | ----------------------------------- |
| Engineering                | `Model A`, `Model B`                |
| Security                   | `Model B`, `Model C`                |
| **Effective availability** | **`Model A`, `Model B`, `Model C`** |

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:

| Group                      | Command selection        |
| -------------------------- | ------------------------ |
| Engineering                | `Model A`                |
| Security                   | `Model B`                |
| **Effective availability** | **`Model A`, `Model B`** |

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.

<AccordionGroup>
  <Accordion title="Can a group make a team model available?">
    No. Groups can only narrow the models already available to the team. Team-level model availability is always the upper bound.
  </Accordion>

  <Accordion title="What does an empty group selection mean?">
    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.
  </Accordion>

  <Accordion title="What happens when a user belongs to multiple restricted groups?">
    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.
  </Accordion>

  <Accordion title="Can automatic routing bypass a group restriction?">
    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.
  </Accordion>
</AccordionGroup>
