Veröffentlicht am: 17. September 2026
7 Minuten Lesezeit
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.
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.
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.
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.
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.
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.
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.
Der Schalter für den einheitlichen Cap bleibt der Hauptschalter: Wird er ausgeschaltet, greifen auch die Overrides nicht mehr.

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

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.

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.
Die Sichtbarkeit der GitLab-Credits-Nutzung ist enthalten und bereits mit Premium- und Ultimate-Abonnements verfügbar.
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.
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.
Kostenlose 30-tägige
GitLab-Testversion starten
Keine Kreditkarte erforderlich.
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 teilenBeginne noch heute, schneller zu entwickeln
Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.