Veröffentlicht am: 17. September 2026

7 Minuten Lesezeit

KI-Credits im Überblick: faire Caps pro Team setzen

Mit GitLab 19.4 lassen sich Credit-Caps pro Nutzer setzen, die Session hinter einem Spike exportieren und die KI-Nutzung je Team zeigen.

Skalierte KI-Nutzung in der eigenen Organisation braucht Klarheit darüber, wohin das Budget fließt und wer es verbraucht. Eine Abonnement-Obergrenze hält die Gesamtausgaben im Rahmen, sagt aber nichts darüber aus, wie viel KI-Nutzung auf einzelne Teams entfällt. Je größer Teams werden, desto schwerer lässt sich künftiger Budgetbedarf vorhersehen, bevor der geschäftliche Bedarf entsteht. Ohne nutzerbezogene Daten lässt sich weder ein fairer Cap (also eine Obergrenze) für KI-Ausgaben setzen noch ein Ausschlag erklären noch einer Abteilung zeigen, was sie verbraucht hat.

GitLab 19.4 macht GitLab Credits pro Nutzer(in) steuerbar: individuelle Budgets setzen, die Ausgaben einsehen und einen detaillierten Bericht exportieren, der die Rechnung erklärt. Jedes Team erhält sein eigenes Budget, jede Entwicklerin und jeder Entwickler die eigene Verbrauchsansicht. Droht ein Power-User den gemeinsamen Credit-Pool des Teams zu erschöpfen, lässt sich die Nutzung begrenzen und die genaue Session hinter dem letzten Spike abrufen. Ändert sich der Verbrauch, lassen sich die Caps anpassen, sodass kein Team ausbremsen muss, um neu zu verhandeln, wessen Arbeit Vorrang hat.

Der Bedarf an Kontrollen für KI-Ausgaben ist dringend. Im AI-Accountability-Bericht von GitLab haben 98 % der Befragten bereits Budget für KI-Governance eingeplant oder planen dies. Verbindliche KI-Budgets über Abteilungen hinweg brauchen klare, erklärbare und berichtsfähige Nutzungsdaten.

GitLab Transcend ist im Oktober zurück

Coding-Agenten beschleunigen die Entwicklung, doch Reviews, Sicherheitsrichtlinien und Release-Zyklen müssen mithalten können. Das Transcend-Event am 6. Oktober zeigt, wie GitLab Teams dabei hilft, diese Lücke zu schließen, und beleuchtet, was nötig ist, um das Tempo agentischer KI über den gesamten Software-Lebenszyklus hinweg mitzugehen.

Jetzt für den Livestream registrieren!

Granulare Zuordnung und Transparenz

Jedes GitLab Credit erfasst den Verbrauch nach Nutzer(in), Namespace und Projekt (soweit zutreffend) mit Zeitstempel. Der Datensatz, der bestimmt, wann jemand den eigenen Cap erreicht, ist derselbe, der beantwortet, welches Team wie viele Credits wofür und wann verbraucht hat. Die Plattform, die die Agenten-Session ausgeführt hat, ist dieselbe, die die Credits erfasst hat – ein Abgleich zwischen zwei Systemen entfällt.

Teamweise Nutzungszahlen vor der Chargeback-Entscheidung

Showback bezeichnet die Praxis, jedem Team dessen eigenen Verbrauch zurückzumelden. Jedem Team zeigen, was es verbraucht hat, und Abteilungen selbst beurteilen lassen, ob sie nutzen, wofür bereits bezahlt wurde. Die meisten Teams passen ihr Verhalten an, sobald sie den eigenen Verbrauch sehen, und der Datensatz bleibt für ein späteres Chargeback erhalten.

Forecasting braucht eine Baseline pro Team

Bevor agentische Flows durch die eigenen CI-Pipelines laufen, muss bekannt sein, was ein 200-köpfiges Team in einem typischen Monat verbraucht. Es braucht außerdem nutzerbezogene Daten, um die Kosten der verbrauchten Credits je nach Modell zu verstehen, bevor sich die Nutzung zweier Teams vergleichen lässt.

Tempo braucht Kontrolle

Platform-Engineering-Teams haben das letzte Jahrzehnt damit verbracht, Delivery-Teams unabhängiges Arbeiten in CI/CD und Security sicher zu machen, indem sie Autonomie mit sichtbaren, durchgesetzten Grenzen kombiniert haben. Agentische Automatisierung skaliert nach demselben Muster. Ein Team erhält sein eigenes Budget. Der Verbrauch bleibt sichtbar. Die nächste Reihe von Flows wird auf Basis dieser Kostentransparenz freigegeben.

Budget-Leitplanken für jede Ebene der Organisation

Wird die Abonnement-Obergrenze erreicht, werden credit-verbrauchende Funktionen für alle Nutzer(innen) ausgesetzt, bis die nächste Abrechnungsperiode beginnt oder eine Administratorin bzw. ein Administrator sie anhebt. Wird ein persönlicher Cap erreicht, betrifft das nur die einzelne Person.

Es gibt klare Warnungen. Das GitLab-Credits-Dashboard benachrichtigt Administrator(inn)en per E-Mail bei 50 %, 80 % und 100 % des Credit-Verbrauchs sowie erneut, wenn eine Abonnement-Obergrenze erreicht wird. Eine Einschränkung: Die Nutzung synchronisiert sich periodisch statt in Echtzeit, sodass bereits laufender Verbrauch einen Cap überschreiten kann, bevor die Durchsetzung nachzieht.

GitLab Flex fügt eine zweite Kontrollebene hinzu. Jede Fähigkeit lässt sich als Restricted, Usage cap oder Unlimited gegenüber der gemeinsamen Reservierung markieren, sodass die Überschreitung einer Fähigkeit nicht das aufbraucht, was jede andere Fähigkeit braucht.

Nutzerbezogene Caps und Ausnahmen von einer Einstellungsseite

Die Credit-caps-Seite bündelt sämtliche nutzerbezogenen Kontrollen auf einem Bildschirm. Einen Standardwert für alle setzen, dann für Einzelpersonen anheben oder senken.

  • Einheitlicher Nutzer-Cap. Die Anzahl an GitLab Credits eingeben, die eine Person pro Abrechnungsperiode verbrauchen darf, und die Durchsetzung aktivieren. Jede Person im Abonnement übernimmt diesen Cap, sofern es nicht überschrieben wird.
  • Individuelle Overrides. Add override auswählen, eine oder mehrere Personen im Auswahlfeld suchen, deren Cap festlegen und speichern. Overrides können über oder unter dem einheitlichen Cap liegen, sodass dieselbe Seite eine Senior-Entwicklerin anheben und eine externe Kraft absenken kann.
  • Umkehrbare Ausnahmen. Jeder Override hat einen eigenen Aktivierungsschalter. Den Schalter ausschalten und speichern, um die Person wieder auf den einheitlichen Cap zurückzusetzen. Eine Ausnahme rückgängig zu machen löscht nichts. Der Wert wartet in der Tabelle auf den Monat, in dem er wieder gebraucht wird.

Der Schalter für den einheitlichen Cap bleibt der Hauptschalter: Wird er ausgeschaltet, greifen auch die Overrides nicht mehr.

Credit caps

Nutzungsexporte bis auf die einzelne abrechenbare Aktion

Exporte laufen jetzt im Hintergrund und kommen per E-Mail mit einem sicheren Download-Link an. Jeder Export deckt bis zu 31 Tage ab und enthält drei Dateien: die bereits bekannte Tagesübersicht, eine neue Datei pro Ereignis sowie ein Manifest.

  • Ereignis-ID, Zeitstempel und Ereignistyp
  • Produkt und Flow-Typ
  • Session-ID
  • Nutzer-ID
  • Namespace-ID
  • Projekt-ID
  • Verbrauchte Credits, Menge und Maßeinheit
  • LLM-Aufrufzahl, Token-Summen und genutzte Modelle
  • Flex-Fähigkeit und Abonnementname

Ist bei einer Gruppe die Einstellung Display GitLab Credits user data deaktiviert, folgen die Nutzerspalten dieser Einstellung.

Eine Gruppierung nach Namespace-ID ergibt die Zeile einer Abteilung – genau darauf baut Showback auf. Ein Filter nach Nutzer-ID und Datum ergibt die Session hinter dem Spike vom letzten Dienstag. Da Namespaces selten direkt mit Kostenstellen der Finanzabteilung übereinstimmen, lässt sich eine einmalige Zuordnung vornehmen, damit künftige Monatsexporte die eigene Kostenstruktur automatisch widerspiegeln.

Credit usage mapping

Was Entwickler(innen) sehen

Jedes Mitglied der eigenen Top-Level-Gruppe kann die eigene GitLab-Credits-Ansicht unter User Settings öffnen und ein Tagesdiagramm des eigenen Verbrauchs sehen, mit denselben Produktfiltern und Datumsbereichs-Kontrollen wie im Gruppen-Dashboard, beschränkt auf die eigenen Ereignisse.

Credit usage report

Enthaltene Promotion-Credits jetzt vor Evaluierungs-Credits

Enthaltene monatliche Promotion-Credits werden jetzt pro Nutzer(in) angewendet, bevor gemeinsame Evaluierungs-Credits genutzt werden, sodass jede Person zuerst verbraucht, was ihr ohnehin zusteht. Enthalten sind 12 Credits pro Premium-Sitzplatz und 24 pro Ultimate-Sitzplatz und Monat. Der Evaluierungspool wird über das gesamte Abonnement geteilt. An der Rechnung ändert sich nichts: Monthly Commitment Pool, One-Time Charge und On-Demand-Credits behalten ihre Reihenfolge.

Um die intensive Nutzung eines Teams zu finanzieren, ohne das Budget für alle zu öffnen, lässt sich ein niedriger einheitlicher Cap setzen und für die Personen mit agentischer Arbeit überschreiben. Alle unterhalb des einheitlichen Caps erhalten weiterhin ihre vollen enthaltenen Credits jeden Monat, denn Caps greifen erst, nachdem die enthaltenen Credits aufgebraucht sind. Der gemeinsame Pool zahlt für die Ausnahmen, nicht für alle.

Erste Schritte

Die Sichtbarkeit der GitLab-Credits-Nutzung ist enthalten und bereits mit Premium- und Ultimate-Abonnements verfügbar.

  • Bei Owner- oder Administrator-Zugriff: die Credit-caps-Seite auf GitLab.com und Self-Managed aufrufen.
  • Bei Verwaltung des Abrechnungskontos: der Export pro Ereignis steht auf GitLab.com, Self-Managed und Dedicated zur Verfügung.
  • Als Entwickler(in): die eigene Nutzungsansicht auf GitLab.com einsehen.

1. Die Abonnement-Obergrenze setzen. Für Verwaltende des Abrechnungskontos: im Customers Portal unter GitLab Credits dashboard > Spend controls. Begrenzt On-Demand-Credits für alle.

2. Nutzerbezogene Caps setzen. Für Gruppeneigentümer(innen): auf der Credit-caps-Seite unter Settings > GitLab Credits > Credit caps für eine Top-Level-Gruppe; für Administrator(inn)en auf GitLab Self-Managed unter Admin > GitLab Credits > Credit caps. Ein Standardwert für alle, plus Overrides.

3. Exportieren, was passiert ist. Über das GitLab-Credits-Dashboard oder die Monatsübersicht von GitLab Flex Export usage data auswählen. Eine Zeile pro abrechenbarem Ereignis, bis zu 31 Tage, per E-Mail zugestellt.

Für nutzerbezogene Daten muss Display GitLab Credits user data für die eigene Top-Level-Gruppe auf GitLab.com oder die eigene Self-Managed-Instanz aktiviert sein. Diese Einstellung ist standardmäßig aktiv, die meisten Gruppen müssen also nichts ändern.

An bereits vorhandenen Einstellungen ändert sich nichts. Die Abonnement-Obergrenze funktioniert wie bisher, das Durchsetzungsverhalten bleibt unverändert, und die GraphQL-API schreibt weiterhin in dieselben Datensätze, die die Seite ausliest, sodass bestehende Automatisierung weiterläuft. Die Dokumentation zur Nutzungsreihenfolge beschreibt die vollständige Abfolge über alle Credit-Typen hinweg.

Nächste Schritte

Heute die eigene Abonnement-Obergrenze setzen, dann die Nutzung des letzten Monats exportieren und auswerten.

Neu bei GitLab Duo Agent Platform? Kostenlose Testversion starten. Bereits auf Premium oder Ultimate? Duo Agent Platform aktivieren und die im eigenen Abonnement enthaltenen Credits nutzen.

Feedback erwünscht

Hat dir dieser Blogbeitrag gefallen? Hast du Fragen oder Feedback? Erstelle ein neues Diskussionsthema im GitLab-Community-Forum und lass andere an deinen Eindrücken teilhaben.

Feedback teilen

Beginne noch heute, schneller zu entwickeln

Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.