> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Usage policies: per-user ACU limits
> Cap each user's monthly ACU consumption with usage tiers, IdP group mappings, per-member overrides, and additional usage requests.
Usage policies let enterprise administrators cap each member's monthly ACU consumption. A member's **local usage** (Devin Desktop, Devin CLI) and **cloud usage** (Devin sessions) count against a single per-user limit, and new work is blocked on all surfaces once the limit is reached.
Manage usage policies from [Enterprise Settings > Usage policies](https://app.devin.ai/settings/usage-policies).
Per-user ACU limits are in beta and require enablement for your enterprise. Reach out to your account team to turn them on.
A few things to know up front:
* Managing usage policies requires the **Manage ACU limits** or billing admin permission.
* Limits reset monthly, aligned with your contract's billing cycle (a contract starting on the 23rd resets limits on the 23rd).
* Devin Review usage does not count toward per-user limits.
* Per-user limits are independent of [organization-level ACU limits](/admin/billing/enterprise#setting-organization-acu-limits) — a session is blocked if either limit is reached.
## Usage tiers
A **usage tier** is a named group of members that share the same monthly ACU allocation — for example, an engineering team, a data analyst team, or a group of admins. Tiers are enterprise-wide. The allocation applies to each member individually; it is not a pooled budget shared by the tier.
You always have a **default tier** — it's where every member lands unless they're assigned to another tier, including members who join later. The first tier you create becomes the default, and you can change which tier is the default from the tier list.
### Guided setup
If you haven't configured tiers yet, or are just getting started, click **Set up with recommendations** on the tiers page. Devin analyzes your last three billing cycles of per-member usage, suggests a complete tier configuration with a tier for each member, and lets you edit everything before applying. A built-in simulation shows who would be over their limit and the projected request volume, so there are no surprises.
### Creating tiers manually
1. Go to **Enterprise Settings > Usage policies > Usage tiers**.
2. Click **Add tier**.
3. Give the tier a name and a **monthly usage allocation** — the baseline ACU limit each member of the tier starts every cycle with. Leave it blank for no limit.
4. Optionally configure [additional usage](#approval-policies) — how members of this tier can receive more ACUs.
5. Click **Create tier**.
### Assign members to a tier
Open a tier, switch to its **Members** tab, and click **Assign member**. Moving a member from another tier clears any per-member override they had, so they start out with the destination tier's allocation.
### Map IdP groups to tiers
Instead of assigning members one by one, you can map your identity provider's groups to tiers. From the tiers page, click **Configure group mappings**, then **Add mapping** and pick a group and a tier. Members inherit their group's tier automatically, based on live group membership from your [IdP integration](/enterprise/security-access/idp-groups).
#### Tier priority
A member's IdP groups can map to several tiers, so tiers are ordered by priority to break ties. To rank them, click **Edit priority** on the tiers page and drag tiers into order — the closer to the top, the higher the priority. Priority is precedence only: a higher-priority tier can have a lower allocation.
## How a member's tier is resolved
A member can be covered by several tiers at once. Their tier resolves in this order:
1. **Explicitly assigned tier** — a direct tier assignment beats any group mapping.
2. **Highest-priority IdP-mapped tier** — if the member's IdP groups map to several tiers, the higher-ranked tier wins.
3. **Default tier** — the fallback for everyone else.
For example, say Ada is in two IdP groups: *Engineering*, mapped to a 500 ACU tier, and *Platform*, mapped to a 1,000 ACU tier that ranks higher in the tier list. Ada is in the 1,000 ACU tier. If an admin assigns her directly to the 500 ACU tier, that assignment wins and her limit becomes 500.
## Per-member overrides
Admins can override an individual member's limit without changing their tier: from the **Members** page, click the member's limit and set a new value.
* A **temporary override** lasts until the end of the current billing cycle, then the member returns to their tier's baseline. The expiry date is shown next to the override.
* A **permanent override** persists across cycles until you clear it.
An override changes the member's limit value only — they stay in their tier, which still defines things like their [approval policy](#approval-policies) for additional usage.
Before applying a change that lowers limits, Devin previews its blast radius — how many members would be blocked, lowered, or unaffected — so you can confirm with full context.
## Additional usage requests
### How members request more usage
A member who needs more ACUs can request an increase from the **Request more** button on the ACU consumption chart in their **My analytics** page, or directly from the limit warnings shown as they approach or hit their limit. They pick an amount, optionally add a reason, and can track or cancel the pending request. Requested increases are always **temporary** — they apply for the current billing cycle only.
### Approval policies
Each tier's **approval policy** controls what happens to its members' requests:
| Policy | Behavior |
| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Manual approval** | Every request waits for admin review. |
| **Always approve** | Requests are auto-approved up to the tier's **maximum auto-approve allocation**. |
| **Approve based on efficiency** | Requests are auto-approved up to the maximum auto-approve allocation, but only while the member's [efficiency score](#efficiency-scores) is **Healthy** or **Satisfactory**, and only in small increases ahead of their current usage. Members in good standing near their cap also get increases granted automatically, without manually filing a request. |
Auto-approval only ever works in the member's favor:
* Requests are never denied automatically — denying is always an admin decision. A request that can't be auto-approved simply waits for review.
* A request above the auto-approve ceiling is granted up to the ceiling so the member can keep working; the remainder stays pending for an admin.
* A permanent override set by an admin is never replaced by an auto-approval.
### Efficiency scores
Devin grades each member's recent cloud-session usage as **Healthy**, **Satisfactory**, or **Needs improvement**. Members whose recent usage is mostly local, or too small to grade, show as **Unknown** and are not eligible for efficiency-based auto-approval. Members can see their own score — along with tips for improving it — on their **My analytics** page, and [Devin Coach](/enterprise/features/devin-coach) helps them improve it as they work.
### Reviewing requests
Review requests from **Usage policies > Additional usage requests**. Pending requests are labeled **Blocked** (the requester hit their limit) or **Proactive** (requested ahead of time), and you can approve or deny them individually or in bulk. Click a request to see the member's tier, current limit, message, and efficiency score before deciding. Approving grants the increase as a temporary override for the rest of the cycle.
Admins with permission to approve requests are notified through an in-app nudge and by email — immediately when a requester is actively blocked, and in a daily digest for proactive requests.
## Monitoring members
The **Usage policies > Members** page lists every member with their current usage, limit, tier, and limit source, ordered by utilization so at-risk members surface first. Blocked members are highlighted, and you can click a member to drill into their usage and session efficiency for the current cycle — useful context before approving a request or adjusting a limit. You can also change a member's tier or override directly from this page.
## What members see at the limit
Members get progressively stronger warnings as they consume their allocation — a notification around two-thirds of the limit, then persistent banners as they approach and reach it. Once blocked, they see a message explaining that their per-user ACU limit was exceeded, with a **Request more ACUs** action that opens the request dialog.
## Frequently asked questions
No. [Organization-level limits](/admin/billing/enterprise#setting-organization-acu-limits) cap an organization's total usage, while usage policies cap each member individually. Both are enforced independently.
No. A tier's allocation applies to each member individually. For a shared pooled budget, create an organization with an organization-level ACU limit and assign the team to it.
Existing API-set limits appear in the UI as permanent overrides, and the API keeps working. See the [user-level ACU limits API reference](/admin/billing/user-acu-limits) for programmatic management.
No. Devin Review ACU usage is excluded from per-user limits.
At the start of each monthly billing window, which follows your contract cycle. Temporary overrides and approved requests expire at the same time.