> ## 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.

# ACU limits

> Set team, group, and user ACU limits for federal deployments.

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

ACU limits control how many Agent Compute Units (ACUs) a user can consume during the team's billing cycle. Federal administrators can manage a team default, a per-group cap, and a per-user override.

For information about creating groups and assigning members, see [Groups](/federal/groups). For model restrictions that can be managed alongside ACU limits, see [Model provisioning](/federal/model-provisioning).

***

## The three ACU controls

| Control            | Scope                    | Behavior                                                                                       |
| ------------------ | ------------------------ | ---------------------------------------------------------------------------------------------- |
| **Team ACU limit** | Each user on the team    | The default per-user ACU limit for the team.                                                   |
| **Group ACU cap**  | Each member of one group | A per-member cap for that group for each billing cycle. It is not a shared pool for the group. |
| **User ACU cap**   | One user                 | A per-user override that takes precedence over the team limit and group caps.                  |

### How the effective limit is resolved

The effective limit for a user is:

```text theme={null}
valid user override ?? min(team limit, lowest positive group cap)
```

In words:

1. If the user has a valid user override, that value wins outright.
2. Otherwise, the team limit and the lowest positive ACU cap among the user's groups are compared.
3. The lower of those limits applies.

A user override wins even when it is higher than the team limit or the user's group caps. Group caps only restrict users who do not have a valid user override.

If the user belongs to multiple groups with positive ACU caps, the lowest positive cap is the group component of the calculation. The effective limit is still compared with the team limit. Group caps are per-member limits, not a shared amount that the group members draw down together.

## Zero and unset values

| Control state               | Meaning                                                                      |
| --------------------------- | ---------------------------------------------------------------------------- |
| Team limit set to `0`       | ACU usage is blocked for users who resolve to the team limit.                |
| User override set to `0`    | ACU usage is blocked for that user.                                          |
| Portal group cap set to `0` | The group cap is cleared; it is not treated as a zero-ACU group limit.       |
| Control unset               | That control adds no enforcement. Other applicable controls can still apply. |

The portal's group ACU limit control accepts `cycle_acu_limit: 0` and clears the group cap. The service-key `UpdateGroup` operation uses `set_cycle_acu_limit` and `clear_cycle_acu_limit`: its set value must be finite and positive, and zero is rejected rather than treated as a blocking group cap. A user cap set to `0` remains an explicit per-user block.

An ACU-billed team can have no numeric limit configured. In that case, there is no enforcement from the team limit unless a positive group cap or valid user override applies.

## Set group ACU caps

Group ACU caps can be configured from **Settings → Groups** when the team is already on ACU billing. The group details view shows either the configured per-member value or **Team ACU limit** when the group inherits the team setting.

Group caps cannot be configured before the team has an ACU billing configuration. The portal or API can report:

```text theme={null}
team is not on ACU billing
```

The portal accepts finite, nonnegative group-cap values; `0` clears the cap. The service-key group-management API requires a finite, positive `set_cycle_acu_limit` and uses `clear_cycle_acu_limit` to remove the override.

## Set user overrides

A user override takes precedence over both the team limit and group caps. To return a user to normal team/group resolution, remove the override. Do not set a negative value: negative user overrides are rejected for new changes, and reverting means removing the override.

Older configurations can contain negative legacy values. Those values are treated as no valid user override, so the user's team and group controls are used instead.

## Enforcement and reset behavior

The effective limit is checked before ACU-billed work. When the user's current-cycle usage is at or above the effective limit, the request is denied and the user sees:

```text theme={null}
monthly acu limit reached
```

Limits reset with the team's billing cycle. Enforcement uses the current billing-cycle window configured for the team, including its current cycle start and end.

Disabling or removing the team's ACU billing configuration:

* Clears the team's ACU configuration and user overrides.
* Clears group ACU caps.
* Preserves group model controls.

After ACU billing is disabled, group model restrictions remain available even though group ACU caps no longer apply.

## Viewing ACU consumption by group

Open **Analytics → Team Usage** in the portal. Use the group selector to choose a group and the date-range selector to choose the reporting period. You can also open a group-scoped view with a `groupId` query parameter in the Analytics URL.

For ACU-billed teams, the page includes:

* An **ACUs used** summary stat.
* An **ACUs Used** column in the per-user table.
* User name, email, active days, tabs generated, Cascade messages, unique Cascade sessions, and IDEs used.

Analytics and enforcement use different time concepts:

* Analytics report ACUs consumed within the selected date range, irrespective of the billing cycle.
* Enforcement checks usage against the team's current billing-cycle window.

ACU consumption and ACU caps can also be queried and managed programmatically — see the [ACU Consumption API](/federal/api/acu-consumption) and [User ACU Caps API](/federal/api/acu-caps).

<AccordionGroup>
  <Accordion title="Does a group cap create a shared group budget?">
    No. A group cap applies separately to every member of the group. If three users share a 100-ACU group cap, each user can resolve to a 100-ACU cap; they do not share one 100-ACU pool.
  </Accordion>

  <Accordion title="Which limit wins when a user has several controls?">
    A valid user override wins outright. Without one, the user's effective limit is the lower of the team limit and the lowest positive group cap among their groups.
  </Accordion>

  <Accordion title="How do I revert a user override?">
    Remove the user override. Negative values are not the way to inherit the team and group controls.
  </Accordion>

  <Accordion title="Why can Analytics differ from the current-cycle usage?">
    Analytics follows the date range selected in the portal, while enforcement uses the team's current billing cycle. A date range can include usage outside the current enforcement cycle.
  </Accordion>
</AccordionGroup>