> ## 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. # ACU-Limits auf Nutzerebene > Begrenzen Sie den monatlichen ACU-Verbrauch jedes Nutzers mit Ebenen, IdP-Gruppenzuordnungen und Nutzerüberschreibungen Limits auf Nutzerebene befinden sich in der Beta-Phase und erfordern, dass die Funktion für Ihr Enterprise aktiviert ist. Wenden Sie sich an Ihr Account-Team, um diese Funktion zu aktivieren. Ein Limit auf Nutzerebene begrenzt die kombinierte \*\*lokale und Cloud-\*\*ACU-Nutzung eines Nutzers — Cloud-Devin-Sitzungen sowie Devin Desktop, Windsurf JetBrains und Devin CLI werden auf dieselbe Obergrenze angerechnet. Wenn ein Nutzer sein Limit erreicht, kann er auf diesen Oberflächen keine neue Arbeit starten, bis das Limit erhöht wird oder die Nutzung im nächsten monatlichen Zeitfenster zurückgesetzt wird. Sie können Ebenen und Limits auf Nutzerebene in der Web-App unter **Enterprise Settings** in den **Nutzungsrichtlinien** (siehe den [Leitfaden zu Nutzungsrichtlinien](/de/enterprise/features/usage-policies)) oder über die unten aufgeführten [Endpunkte für Nutzungsrichtlinien](#tier-endpoints) verwalten. Limits auf Nutzerebene werden über **Ebenen** verwaltet. Eine Ebene ist eine benannte, kontoweite Standardobergrenze, die für alle ihre Member gilt: * Nutzer werden auf drei Arten einer Ebene zugeordnet: Ein Admin **weist** sie **explizit zu**, eine [**IdP-Gruppenzuordnung**](#idp-group-endpoints) ordnet sie zu (eine Gruppe wird einer Ebene zugeordnet und ihre Member erben diese Ebene, sofern sie nicht explizit einer anderen Ebene zugewiesen sind), oder sie werden der **Standardebene** zugeordnet. Jedes Konto kann eine Ebene als Standardebene festlegen; jeder Konto-Member, dem keine andere Ebene zugewiesen ist, gehört zu ihr. Es gibt kein separates „Standardlimit pro Nutzer“ — konfigurieren Sie stattdessen die Standardebene. * Einzelne Nutzer können eine **Überschreibung** haben — entweder **dauerhaft** (läuft nie ab) oder **temporär** (läuft am Ende des aktuellen monatlichen Zeitfensters ab). Überschreibungen gelten für einzelne Nutzer: Das Festlegen einer Überschreibung ändert niemals die Ebenenzuweisung des Nutzers. * Das **effektive Limit** eines Nutzers wird in dieser Reihenfolge bestimmt: dauerhafte Überschreibung, andernfalls eine aktive temporäre Überschreibung, andernfalls `cycle_acu_limit` der explizit zugewiesenen Ebene, andernfalls das Limit der am höchsten eingestuften über eine IdP-Gruppe zugeordneten Ebene, andernfalls das Limit der Standardebene. Ein `null`-Limit bedeutet, dass keine Obergrenze besteht. * Nutzer können ein höheres Limit anfordern; Admins prüfen diese [**Anfragen zur Erhöhung des Limits**](#limit-increase-request-endpoints). Die `policy` jeder Ebene steuert, ob Anfragen automatisch genehmigt oder zur manuellen Prüfung zurückgehalten werden. Limits auf Nutzerebene sind unabhängig von [Limits auf Organisationsebene](/de/admin/billing/org-acu-limits) — eine Anfrage wird blockiert, wenn eines der beiden Limits erreicht wurde. Informationen zu Authentifizierung, Berechtigungen und der von allen Endpunkten auf dieser Seite verwendeten `PATCH`-Semantik finden Sie unter [ACU-Limits](/de/admin/billing/acu-limits). Die Endpunkte für Limits pro Nutzer und Standardnutzer aus der Zeit vor den Ebenen sind veraltet; siehe [Legacy user ACU limit endpoints](/de/admin/billing/legacy-user-acu-limits).
## Endpunkte der Ebenen
### Ebenen auflisten
```http theme={null} GET /v3beta1/enterprise/usage-policies/tiers ``` Gibt eine paginierte Liste von Ebenen in Vorrangreihenfolge zurück: höchste `priority` zuerst, innerhalb einer Priorität die neueste Ebene zuerst. Jede Ebene hat folgende Struktur: ```json theme={null} { "tier_id": "tier-abc123", "name": "Engineers", "is_default": true, "cycle_acu_limit": 500, "policy": "manual", "max_limit": null, "priority": 0, "member_count": 42, "created_at": 1735689600 } ``` * `is_default`: ob dies die Standardebene des Kontos ist. * `cycle_acu_limit`: das Standard-ACU-Limit pro Abrechnungszyklus für jeden Member; `null` bedeutet keine Obergrenze. * `policy`: wie Anfragen zur Erhöhung des Limits für die Ebene behandelt werden — `unconditional` und `conditional` genehmigen bis zu `max_limit`, `manual` erfordert eine Admin-Prüfung. Die Richtlinie `conditional` (effizienzbasierte automatische Genehmigung) muss separat aktiviert werden; wenden Sie sich an Ihr Account-Team. * `max_limit`: das maximale Limit, bis zu dem Erhöhungsanfragen genehmigt werden; `null` genehmigt ohne Obergrenze. Immer `null`, wenn `cycle_acu_limit` `null` ist. * `priority`: ordnet die einem Nutzer über IdP-Gruppen zugeordneten Ebenen — der höchste Wert hat Vorrang; bei Gleichstand entscheidet die neueste Ebene. Die Rangfolge bestimmt lediglich den Vorrang: Eine Ebene mit höherer Priorität kann ein niedrigeres `cycle_acu_limit` haben. Eine explizite Nutzerzuweisung überschreibt diese Rangfolge, und die Standardebene wird nie eingestuft. * `member_count`: die Anzahl der Nutzer, die sich aktuell in der Ebene befinden — explizit zugewiesene Nutzer sowie Nutzer, die über eine IDP-Gruppenzuordnung zugeordnet wurden. Für die Standardebene werden alle Konto-Member gezählt, die keiner anderen Ebene angehören. Konfigurieren Sie die Standardebene und die Ebenenpriorität in der Web-App unter **Nutzungsrichtlinien**.
### Eine Ebene erstellen
```http theme={null} POST /v3beta1/enterprise/usage-policies/tiers ``` **Request-Body** ```json theme={null} { "name": "Engineers", "cycle_acu_limit": 500, "policy": "manual" } ``` Die erste Ebene des Kontos wird automatisch zur Standardebene. Gibt HTTP `201` und die erstellte Ebene zurück.
### Eine Ebene abrufen
```http theme={null} GET /v3beta1/enterprise/usage-policies/tiers/{tier_id} ```
### Eine Ebene aktualisieren
```http theme={null} PATCH /v3beta1/enterprise/usage-policies/tiers/{tier_id} ``` Teilaktualisierung; nicht angegebene Felder bleiben unverändert. Um die Standardebene oder die Priorität einer Ebene zu ändern, verwenden Sie die Web-App unter **Nutzungsrichtlinien**. ```json theme={null} { "name": "Engineering", "cycle_acu_limit": 750 } ```
### Eine Ebene löschen
```http theme={null} DELETE /v3beta1/enterprise/usage-policies/tiers/{tier_id} ``` Gibt bei Erfolg HTTP `204` zurück. Die Standardebene kann nicht gelöscht werden (stufen Sie zuerst eine andere Ebene hoch). Einer Ebene mit noch zugewiesenen Nutzern müssen diese zunächst entzogen werden, und alle IdP-Gruppenzuordnungen zu dieser Ebene müssen ebenfalls zuerst entfernt werden.
## Nutzer-Endpunkte auf Ebene
### Nutzer einer Ebene auflisten
```http theme={null} GET /v3beta1/enterprise/usage-policies/tiers/{tier_id}/users ``` Gibt eine paginierte Liste der Nutzer dieser Ebene mit ihren ermittelten Limits zurück — explizit zugewiesene Nutzer sowie Nutzer, die über eine IdP-Gruppenzuordnung zugeordnet wurden. Für die Standardebene umfasst dies alle Account-Member, die keiner anderen Ebene angehören: ```json theme={null} { "user_id": "user_abc123", "name": "Ada Lovelace", "email": "ada@example.com", "cycle_acu_limit_override": null, "temporary_cycle_acu_limit": 800, "effective_cycle_acu_limit": 800, "limit_source": "temporary_override", "membership": "explicit" } ``` * `cycle_acu_limit_override`: die permanente Überschreibung des Nutzers, falls vorhanden. * `temporary_cycle_acu_limit`: die temporäre Überschreibung des Nutzers, die nur während des aktuellen monatlichen Zeitfensters aktiv ist. * `effective_cycle_acu_limit`: das aktuell für den Nutzer geltende Limit; `null` bedeutet ohne Obergrenze. * `limit_source`: die Herkunft des effektiven Limits — `override` (permanent), `temporary_override` oder `tier`. * `membership`: warum der Nutzer dieser Ebene angehört — `explicit` (direkt zugewiesen), `idp_group` (über seine maßgebliche IdP-Gruppenzuordnung) oder `default` (Rückfall auf die Standardebene).
### Einen Nutzer einer Ebene zuordnen
```http theme={null} PUT /v3beta1/enterprise/usage-policies/tiers/{tier_id}/users/{user_id} ``` Idempotent. Gibt bei Erfolg HTTP `204` zurück. Wird ein Nutzer aus einer anderen Ebene verschoben, wird jede Nutzerüberschreibung gelöscht, sodass er zunächst das Limit der Zielebene erbt.
### Einen Nutzer aus einer Ebene entfernen
```http theme={null} DELETE /v3beta1/enterprise/usage-policies/tiers/{tier_id}/users/{user_id} ``` Entfernt die explizite Ebenenzuweisung des Nutzers (und alle Überschreibungen) und setzt ihn auf die Standardebene zurück. Gibt bei Erfolg HTTP `204` zurück.
## Endpunkt für Nutzerüberschreibungen
### Überschreibung eines Nutzers festlegen oder löschen
```http theme={null} PATCH /v3beta1/enterprise/usage-policies/users/{user_id} ``` Nutzerbezogen: Das Ziel muss lediglich ein Konto-Member sein — es ist keine Ebene beteiligt, und die Ebenenzuweisung des Nutzers wird nie geändert. Ein Nutzer mit nur einer Überschreibung (ohne explizite Ebenenzuweisung) bleibt in der Standardebene. **Request-Body — temporäre Überschreibung festlegen** ```json theme={null} { "cycle_acu_limit": 800, "kind": "temporary" } ``` `kind` ist beim Festlegen eines Werts erforderlich: `permanent` läuft nie ab; `temporary` läuft am Ende des aktuellen monatlichen Zeitfensters ab. **Request-Body — alle Überschreibungen löschen** ```json theme={null} { "cycle_acu_limit": null } ``` Der Endpunkt gibt bei Erfolg HTTP `204` zurück.
## Endpunkte für IdP-Gruppen
Ordnen Sie eine IdP-Gruppe einer Ebene zu, damit ihre Member diese Ebene automatisch erben. Zuordnungen werden anhand der Gruppenmitgliedschaft live ermittelt und ändern niemals die explizite Ebenenzuweisung eines Nutzers – eine explizite Zuweisung hat immer Vorrang. Bei einem Nutzer in mehreren zugeordneten Gruppen wird die am höchsten eingestufte zugeordnete Ebene ermittelt (höchste Ebenen-`priority`; bei Gleichstand die neueste Ebene).
### IDP-Gruppenzuordnungen auflisten
```http theme={null} GET /v3beta1/enterprise/usage-policies/idp-groups ``` Gibt eine paginierte Liste der Gruppen-Ebenen-Zuordnungen des Kontos zurück, beginnend mit den ältesten. Mit `?tier_id=` können Sie nur Gruppen auflisten, die einer Ebene zugeordnet sind: ```json theme={null} { "idp_group_id": "grp_abc123", "idp_group_name": "Engineering", "tier_id": "tier-abc123" } ```
### IdP-Gruppenzuordnung einer IdP-Gruppe abrufen
```http theme={null} GET /v3beta1/enterprise/usage-policies/idp-groups/{idp_group_name} ``` Gibt HTTP `404` zurück, wenn der Gruppe keine IdP-Gruppenzuordnung zugewiesen ist.
### Eine IdP-Gruppe einer Ebene zuordnen
```http theme={null} PUT /v3beta1/enterprise/usage-policies/idp-groups/{idp_group_name} ``` **Request-Body** ```json theme={null} { "tier_id": "tier-abc123" } ``` Idempotentes Upsert. Eine Gruppe kann höchstens einer Ebene zugeordnet sein. Wird eine bereits zugeordnete Gruppe erneut zugeordnet, wird sie in die angegebene Ebene verschoben.
### IdP-Gruppenzuordnung einer IDP-Gruppe aufheben
```http theme={null} DELETE /v3beta1/enterprise/usage-policies/idp-groups/{idp_group_name} ``` Gibt bei Erfolg HTTP `204` zurück. Die über die IdP-Gruppenzuordnung zugeordnete Ebene gilt nicht mehr für die Mitglieder der Gruppe; Nutzer ohne explizite Zuweisung und ohne andere IdP-Gruppenzuordnung fallen auf die Standardebene zurück.
## Endpunkte für Anfragen zur Erhöhung des Limits
Nutzer können ein höheres Limit pro Abrechnungszyklus anfordern. Die `policy` der Ebene des Antragstellers bestimmt, was geschieht: `unconditional` und `conditional` genehmigen Anfragen bis zum `max_limit` der Ebene automatisch, während `manual` die Anfrage zur Prüfung durch Admins über diese Endpunkte (oder unter **Nutzungsrichtlinien** in der Web-App) zurückstellt. Anders als bei den anderen Endpunkten auf dieser Seite ist zum Abrufen von Anfragen zur Erhöhung des Limits die Berechtigung **ManageBilling** erforderlich — Anfragen enthalten die Identität von Membern und Freitextnachrichten, die Daten für Admin-Workflows darstellen.
### Anfragen zur Erhöhung des Limits auflisten
```http theme={null} GET /v3beta1/enterprise/usage-policies/requests ``` Gibt eine paginierte Liste zurück, die nach `?status=` (`pending`, `approved`, `denied`) und `?user_id=` gefiltert werden kann: ```json theme={null} { "request_id": 42, "user_id": "user_abc123", "name": "Ada Lovelace", "email": "ada@example.com", "tier_id": "tier-abc123", "tier_name": "Engineers", "current_cycle_acu_limit": 500, "requested_cycle_acu_limit": 800, "message": "Wrapping up a large migration this month", "status": "pending", "created_at": 1735689600, "reviewed_at": null, "reviewer": null } ``` * `tier_id` / `tier_name`: die Ebene des Antragstellers (explizite Zuweisung, IdP-Gruppenzuordnung oder Standardebene); `null`, wenn das Konto keine Ebenen hat. * `current_cycle_acu_limit`: die aktuell für den Antragsteller geltende Obergrenze; `null` bedeutet, dass keine Obergrenze festgelegt ist. * `reviewer`: der Admin, der die Anfrage geprüft hat; `null`, solange die Anfrage aussteht.
### Eine Anfrage zur Erhöhung des Limits abrufen
```http theme={null} GET /v3beta1/enterprise/usage-policies/requests/{request_id} ```
### Anfrage zur Erhöhung des Limits genehmigen
```http theme={null} POST /v3beta1/enterprise/usage-policies/requests/{request_id}/approve ``` Gewährt das angeforderte Limit als **temporäre Überschreibung**, die am Ende des aktuellen monatlichen Zeitfensters verfällt. Optional kann ein abweichendes Limit gewährt werden: ```json theme={null} { "cycle_acu_limit": 700 } ``` Gibt die aktualisierte Anfrage zurück. Gibt HTTP `409` zurück, wenn die Anfrage bereits geprüft wurde oder der Anfragende kein Konto-Member mehr ist.
### Anfrage zur Erhöhung des Limits ablehnen
```http theme={null} POST /v3beta1/enterprise/usage-policies/requests/{request_id}/deny ``` Gibt die aktualisierte Anfrage zurück oder HTTP `409`, wenn sie bereits bearbeitet wurde.
## Beispiel-Workflows
### Ebenen mit einer Standardobergrenze einrichten
Erstellen Sie eine Standardebene, damit jeder Nutzer eine monatliche Obergrenze von 500 ACU erhält: ```bash theme={null} curl -X POST "https://api.devin.ai/v3beta1/enterprise/usage-policies/tiers" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"name": "Standard", "cycle_acu_limit": 500, "policy": "manual"}' ``` Erstellen Sie eine Ebene mit einem höheren Limit und weisen Sie ihr einen Nutzer zu: ```bash theme={null} curl -X POST "https://api.devin.ai/v3beta1/enterprise/usage-policies/tiers" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"name": "Power users", "cycle_acu_limit": 2000, "policy": "manual"}' curl -X PUT "https://api.devin.ai/v3beta1/enterprise/usage-policies/tiers/tier-abc123/users/user_abc123" \ -H "Authorization: Bearer " ``` Einem Nutzer für den Rest des Monats vorübergehend ein höheres Limit gewähren: ```bash theme={null} curl -X PATCH "https://api.devin.ai/v3beta1/enterprise/usage-policies/users/user_abc123" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"cycle_acu_limit": 800, "kind": "temporary"}' ``` Ordnen Sie eine IdP-Gruppe der Ebene mit höherem Limit zu und prüfen Sie eine ausstehende Anfrage zur Erhöhung des Limits: ```bash theme={null} curl -X PUT "https://api.devin.ai/v3beta1/enterprise/usage-policies/idp-groups/Engineering" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"tier_id": "tier-abc123"}' curl -X POST "https://api.devin.ai/v3beta1/enterprise/usage-policies/requests/42/approve" \ -H "Authorization: Bearer " ```
## Häufig gestellte Fragen
Lokale und Cloud-Nutzung: Cloud-Devin-Sitzungen sowie die lokale Nutzung über die CLI und IDEs (Devin Desktop, Windsurf JetBrains und Devin CLI) werden auf dieselbe Obergrenze angerechnet. Zuerst gilt eine dauerhafte Überschreibung, dann eine aktive temporäre Überschreibung, anschließend das Limit der dem Nutzer explizit zugewiesenen Ebene, danach das Limit der ihm über IdP-Gruppen zugeordneten am höchsten eingestuften Ebene und zuletzt das Limit der Standardebene. Ein `null`-Limit auf jeder Ebene bedeutet, dass der Nutzer keine Obergrenze hat. Nein. Eine Überschreibung ersetzt das Ebenenlimit für diesen Nutzer. Beträgt das Ebenenlimit 500 ACUs und hat ein Nutzer eine Überschreibung von 200 ACUs, liegt sein effektives Limit bei 200 ACUs. Eine dauerhafte Überschreibung läuft nie ab. Eine temporäre Überschreibung läuft am Ende des aktuellen monatlichen Zeitfensters ab. Danach gilt wieder das Limit der Ebene des Nutzers. Die Genehmigung einer Anfrage zur Erhöhung des Limits gewährt eine temporäre Überschreibung. Nicht als eigenständige Einstellung. Konfigurieren Sie stattdessen das Limit der Standardebene — es gilt für jedes Konto-Member, das keiner anderen Ebene zugewiesen ist. Die [Legacy-Endpunkte für das Standardlimit pro Nutzer](/de/admin/billing/legacy-user-acu-limits#default-user-limit-endpoints) lesen und schreiben jetzt das Limit der Standardebene. Neue Arbeit wird sowohl lokal als auch in der Cloud blockiert. Der Nutzer kann sich an einen Enterprise-Administrator wenden, um das Limit anzupassen, oder warten, bis das nächste monatliche Zeitfenster beginnt.