Inhalt

• Erst messen: Kostenanalyse vor Budgets
• Inklusivkontingent vs. Budget: zwei verschiedene Dinge
• Was Credits kostet und was teuer werden kann
• Die vier Budget-Ebenen
• Was man wissen muss: Gotchas und Edge Cases
• Phasenweiser Aufbau
• Unsere Empfehlungen: zwei Seiten der Kontrolle
• Copilot-Governance strukturiert aufbauen

Ab dem 1. Juni 2026 rechnet GitHub Copilot token-basiert ab. Wer unseren Beitrag „Der größte Kostenhebel bei AI Engineering ist nicht das Modell, es ist die Disziplin“ gelesen hat, kennt das Modell: Das bisherige Premium-Request-System (PRU) ist abgelöst. Ab Juni gilt ausschließlich token-basiertes Billing über GitHub AI Credits, wobei 1 Credit $0,01 USD entspricht und der Verbrauch auf Basis von Input-, Output- und Cache-Tokens je genutztem Modell berechnet wird. Wer neu einsteigt: Das ist der relevante Kontext für alles, was folgt.

Was viele unterschätzen, ist das Ausmaß der Veränderung in der Praxis. Was wir bei unseren Kunden sehen: Der Credit-Verbrauch unter token-basiertem Billing liegt 5- bis 20-fach höher als unter dem alten Request-Modell. Copilot Coding Agent, Cloud Agent und lange Chat-Sessions mit großem Kontext treiben den Verbrauch strukturell nach oben. Das ist kein Randphänomen, sondern das erwartete Verhalten eines Systems, das jetzt den tatsächlichen Modellaufwand abrechnet.

Wer sich fragt, was das konkret für den eigenen GitHub Account bedeutet: GitHub stellt seit Mai 2026 eine Preview Invoice bereit, abrufbar unter Enterprise → Billing & Licensing → Usage. Sie zeigt die projizierte Monatsrechnung auf Basis der tatsächlichen Nutzung der vergangenen Wochen unter dem neuen Modell. Das ist der schnellste Weg zu einem realistischen Bild, bevor der 1. Juni greift.

Wer den Sprung der 5- bis 20-fachen Erhöhung einordnen will: Ein einfacher Chat-Turn bewegt sich im Bereich weniger tausend Tokens. Eine Copilot-Coding-Agent-Session, die über mehrere Dateien iteriert und mehrere Modell-Calls ausführt, liegt schnell bei einem Vielfachen davon, je nach Kontext-Tiefe und Aufgabenkomplexität. Die Preview Invoice macht diesen Unterschied sofort sichtbar: pro User, pro Feature, pro Modell.

Damit ist GitHub Copilot in der gleichen Kategorie angekommen wie Cloud-Infrastruktur: pooled Ressourcen, variabler Verbrauch, schwer vorhersehbare Spitzen und einzelne Workloads, die überproportional viel verbrauchen. Die Antwort auf genau dieses Problem kennen Cloud-Teams seit Jahren: FinOps-Prinzipien. Attribution (wer verbraucht was?), Showback (Transparenz für Abteilungen), Chargeback (Kostenzuordnung zu Geschäftsbereichen) und Governance-Controls, die skalieren, statt mit einem Killswitch zu reagieren.

Exakt diese Prinzipien müssen jetzt auf GitHub Copilot übertragen werden. Ein einzelnes globales Budget-Limit ist kein FinOps-Konzept, es ist ein Notausschalter. Dieser Beitrag zeigt, wie Attribution, Showback, Chargeback und Budget-Controls für Copilot konkret aussehen und wie man diese schrittweise aufbaut.

Eine Dringlichkeit sollte dabei nicht übersehen werden: Der Transition-Buffer läuft am 1. September 2026 aus. Bis dahin erhalten bestehende Copilot Business-Kunden 3.000 Credits pro User und Monat, Copilot Enterprise-Kunden 7.000. Danach gelten die Standardmengen: 1.900 für Business, 3.900 für Enterprise. Wer bis dahin keine Governance-Struktur aufgebaut hat, startet in den Herbst ohne Guardrails.

Erst messen: Kostenanalyse vor Budgets

Das erste FinOps-Prinzip lautet Kostenanalyse vor Optimierung. Wer Limits setzt, ohne den Verbrauch zu verstehen, setzt willkürliche Zahlen. GitHub empfiehlt das explizit, und wir sehen in der Praxis, wie häufig dieser Schritt übersprungen wird.

Das primäre Analyse-Instrument ist der AI Usage CSV-Report, abrufbar über Enterprise → Billing & Licensing → Download, oder programmatisch über die REST API für Copilot Usage Metrics. Der Report liefert Granularität auf User-, Modell- und Tagesebene und beantwortet die entscheidenden Fragen: Wer konsumiert wie viel? Welche Modelle dominieren? Zu welchem Zeitpunkt im Monat erschöpft sich der Pool besonders schnell?

Für den laufenden Überblick stehen in der GitHub Billing-Übersicht interaktive Dashboards bereit, darunter eine Usage Summary auf Enterprise-Ebene, Cost-Center-Ansichten und eine Preview Invoice, die projizierte Kosten vor Monatsende anzeigt. Diese Dashboards eignen sich für tagesaktuelle Beobachtung; der CSV-Report ist das richtige Werkzeug für tiefere Analyse und für das monatliche Showback-Reporting an Abteilungsleiter.

Unsere Empfehlung: CSV-Report ziehen, bevor die ersten Budgets gesetzt werden. Heavy-User identifizieren: Als Daumenregel sind das die Nutzer, die mehr als das Doppelte des Durchschnitts verbrauchen, und auf dieser Basis Power-User-Profile für differenzierte User-Level Budgets vorbereiten. Das ist die Datenbasis, ohne die jede Budget-Entscheidung Spekulation bleibt.

Inklusivkontingent vs. Budget: zwei verschiedene Dinge

Bevor wir in die Architektur der Budget-Ebenen einsteigen, ist eine Begriffsunterscheidung wichtig, die in der Praxis häufig für Verwirrung sorgt.

Das Inklusivkontingent ist das monatliche Credit-Volumen, das in den Planpreis eingerechnet ist: Copilot Business bringt 1.900 Credits pro User und Monat ($19), Copilot Enterprise 3.900 ($39). Diese Credits fließen nicht in individuelle User-Wallets, sondern in einen gemeinsamen Enterprise-Pool. Alle User ziehen gleichzeitig aus diesem Pool, ohne festgelegte Reihenfolge und ohne individuelle Reservierung. Ein User-Level-Budget (ULB) von $30 bedeutet nicht, dass dieser User „$30 aus dem Pool reserviert hat“. Andere User können seinen nominellen Anteil vorher verbrauchen, der ULB verhindert nur, dass er selbst über sein Limit hinausgeht.

Ein Budget dagegen ist ein frei definiertes Governance-Instrument, das der Admin in USD setzt. Budgets haben zwei Modi: reiner Alert (Benachrichtigung bei Erreichen eines Schwellwerts, Nutzung läuft weiter) oder Hard Stop (die Einstellung „Stop usage when budget limit is reached“ blockiert die Nutzung aktiv). Entscheidend für das Verständnis: Budgets steuern nicht das Inklusivkontingent. Sie greifen erst beim Additional Spend, also nach Pool-Erschöpfung. Die einzige Ausnahme sind User-Level Budgets, die in beiden Phasen wirken: im inkludierten Pool und im Additional Spend.

Was Credits kostet und was teuer werden kann

Nicht jede Copilot-Nutzung verursacht Kosten. Included – keine Credits, in allen bezahlten Plänen unbegrenzt:

• Code Completions
• Next Edit Suggestions

Credit-pflichtig: variabel nach Modell und Kontext:

• Copilot Chat (IDE, github.com, Mobile)
• Copilot Code Review
• Copilot CLI, Copilot Spaces, GitHub Spark

Copilot Coding Agent und Cloud Agent führen mehrere Modell-Calls pro Task aus und arbeiten mit langem Dateikontext über mehrere Repositories hinweg. Ein komplexer Agent-Run kann leicht ein Vielfaches eines einfachen Chat-Turns kosten. Code Review hat zusätzlich eine zweite Kostendimension: Neben den AI Credits für den Token-Verbrauch entstehen GitHub Actions Minutes für die Agentic Infrastruktur, die das Review antreibt. Beide Kostenpositionen müssen separat beobachtet und gegebenenfalls separat budgetiert werden.

Modellwahl ist dabei ein relevanter Hebel. Tokenpreise variieren je nach Modell erheblich, die aktuellen Raten für alle verfügbaren Modelle finden sich in der offiziellen Preistabelle. Wer leichte Modelle für schnelle Fragen und Frontier-Modelle gezielt für komplexe Reasoning-Tasks einsetzt, senkt seinen Credit-Verbrauch messbar.

Aber Modellwahl alleine löst das Problem nicht. Wer Agentic Sessions wie Chats führt, kann sich durch Modellauswahl nicht aus den Kosten optimieren. Der wirksamere Hebel ist Disziplin auf Entwicklerseite: wie Aufgaben spezifiziert werden, wie Context-Fenster kontrolliert werden, wie Sessions geführt werden. Dazu mehr am Ende dieses Beitrags.

Die vier Budget-Ebenen

Ein wichtiger Hinweis zur Verfügbarkeit: Die token-basierten Budgetkontrollen für GitHub Copilot Business und Copilot Enterprise werden erst ab dem 1. Juni 2026 allgemein verfügbar. Vor diesem Datum sind AI-Credit-Budgets in der Oberfläche noch nicht freigeschaltet. Bestehende Premium Request Unit (PRU)-Budgets werden automatisch ins neue Modell übertragen, können aber bis zum Go-Live nicht als separate AI-Credit-Budgets konfiguriert werden. Ab dem 1. Juni erscheinen alle Budget-Optionen automatisch im Bereich Billing & Licensing für berechtigte Admins (sowohl über die UI als auch über die REST API). Kein separater Early Access, kein Feature-Flag: der Rollout erfolgt global für alle Copilot Business- und Enterprise-Kunden mit dem Start von Usage-Based Billing.

GitHub Copilot Enterprise stellt vier Budget-Ebenen bereit. Wichtig ist von Anfang an das richtige Verständnis ihrer Funktionsweise: Budget-Ebenen sind parallele Guardrails, kein hierarchischer Allocation-Tree. GitHub prüft alle aktiven Ebenen gleichzeitig, und das restriktivste aktive Limit gewinnt.

Ebene	Scope	Greift bei	Empfohlener Modus
Enterprise	Gesamtes Enterprise	Additional Spend	Alert, kein Hard Stop
Organisation	Einzelne GitHub-Org	Additional Spend	Optional, nur in einfachen Setups
Cost Center	Abteilung / Team	Additional Spend	Hard Stop pro Abteilung
User-Level (ULB)	Einzelner User	Inkludiert + Additional	Hard Stop als Baseline

Das Enterprise-Budget dient als globales Safety-Net gegen unkontrollierten Additional Spend. Wir empfehlen ausdrücklich, es nicht als Hard Stop zu konfigurieren. Ist die Option „Stop usage when budget limit is reached“ auf Enterprise-Ebene aktiv, werden bei Budget-Erschöpfung alle User der gesamten Organisation gleichzeitig geblockt, unabhängig davon, ob auf Cost-Center- oder ULB-Ebene noch Kapazität vorhanden ist. Sobald Cost Centers im Einsatz sind, empfehlen wir die Cost-Center-Exklusion zu aktivieren: Das Enterprise-Budget erschöpft sich, aber Cost-Center-Usage läuft weiter, solange das Cost-Center-Budget und die ULB-Kapazität vorhanden sind.

Organisationsbudgets können direkt auf eine einzelne GitHub-Org gesetzt werden und sind als einfacher Einstieg sinnvoll, bevor Cost Centers eingerichtet sind. Sobald User-based Cost Centers aktiv sind, empfiehlt GitHub explizit, diesen Ansatz nicht mehr zu nutzen, da Org-Scope-Budgets mit User-based Cost Centers interferieren.

Cost Centers sind das primäre FinOps-Instrument für Attribution und Showback auf Abteilungsebene. Jeder User gehört genau einem Cost Center an. Für die Strukturierung gibt es zwei Ansätze:

• Organization-based: Sinnvoll, wenn Org-Struktur und Billing-Struktur übereinstimmen und SCIM (Cross-domain Identity Management) im Einsatz ist. Geringer operativer Aufwand, gut kombinierbar mit automatischer Mitgliedschaftsverwaltung.
• User-based: Die richtige Wahl in den meisten Enterprise-Setups, da Org-Struktur und Billing-Struktur selten deckungsgleich sind. Mehr initialer Aufwand, aber die einzige Variante für saubere Kostenzuordnung über Org-Grenzen hinweg.

Cost Centers ermöglichen darüber hinaus echtes Chargeback: Über separate Azure-Subscription-IDs pro Cost Center lässt sich die Kostenzuordnung direkt an die entsprechenden Geschäftsbereiche übertragen, ohne manuelles Reporting.

User-Level Budgets (ULBs) sind der einzige Mechanismus, der in beiden Phasen greift: im inkludierten Pool und im Additional Spend. Sie sind das primäre Werkzeug gegen unfaire Pool-Verteilung durch Heavy-User und wirken unabhängig von Enterprise- und Cost-Center-Kapazitäten. $0 ULB bedeutet kein Copilot für diesen User. Das GitHub Well-Architected Framework empfiehlt, ULBs als einzige Hard-Enforcement-Ebene zu konfigurieren und alle anderen Ebenen im Alert-Modus zu belassen.

Was man wissen muss: Gotchas und Edge Cases

Einige Verhaltensweisen des Systems sind nicht intuitiv und führen ohne Vorwissen zu Überraschungen.

Stop vs. Alert ist eine explizite Einstellung. „Stop usage when budget limit is reached“ muss pro Budget aktiv gesetzt werden. Ohne diese Einstellung ist ein Budget ausschließlich eine E-Mail-Benachrichtigung, die Nutzung läuft ungebremst weiter. Mit ihr greift ein harter Blockstopp. Die falsche Einstellung auf Enterprise-Ebene kann, wie beschrieben, die gesamte Organisation lahmlegen.

Most-restrictive gewinnt immer. Wenn das Enterprise-Budget erschöpft ist und Hard Stop aktiv ist, werden alle User blockiert, auch wenn Cost-Center- und ULB-Kapazität noch vorhanden ist. Die Cost-Center-Exklusion ist die einzige Ausnahme.

Der Fallback auf günstigere Modelle ist abgeschafft. Im alten PRU-Modell macht Copilot einen stillen Downgrade bei erschöpften Kontingenten auf ein günstigeres Modell. Im neuen Modell bedeutet Budget-Erschöpfung: sofortige Fehlermeldung für den User, keine stille Alternative.

Code Review erzeugt zwei separate Kostenpositionen. AI Credits für den Token-Verbrauch und GitHub Actions Minuten für die Agentic Infrastruktur. Beide müssen separat beobachtet werden, und in manchen Setups ist auch eine separate Budget-Steuerung sinnvoll.

User mit mehreren Lizenzen. Hat ein User Copilot-Zugang über mehrere Enterprises oder Standalone-Organisationen, muss er aktiv eine Billing-Entität wählen (in der Oberfläche als „Usage billed to“ sichtbar). Ohne diese Auswahl werden AI Credits geblockt, ein automatisches Fallback auf eine der verfügbaren Entitäten findet nicht statt.

Upgrade statt dauerhaft hohes ULB. Bei Entwicklern mit Copilo Business-Seats und konstant hohem Verbrauch lohnt sich eine Upgrade-Prüfung: Ab einem bestimmten Verbrauchsniveau ist ein Wechsel auf Copilot Enterprise günstiger als kontinuierlicher Additional Spend auf Business-Seats, da Enterprise-Seats mehr inkludierte Credits mitbringen.

Alerting braucht einen Prozess. Die konfigurierbaren Schwellen bei 75%, 90% und 100% des Budgets sind nur dann wirksam, wenn definiert ist, wer bei welchem Threshold was tut. Ein Alert ohne Reaktionsprozess ist eine E-Mail ohne Konsequenz.

Phasenweiser Aufbau

GitHub empfiehlt einen schrittweisen Aufbau der Governance-Struktur, den wir aus der Praxis bestätigen können. Wir strukturieren ihn in drei Phasen.

Phase 1: Minimum Viable Governance. Das Ziel der ersten Phase ist Sichtbarkeit und die Verhinderung von unkontrolliertem Overspend. Konkret: CSV-Report erstellen und Heavy-User identifizieren, Enterprise-Budget im Alert-Modus mit Schwellen bei 75%, 90% und 100% setzen, und ein universelles ULB als Hard Stop für alle User konfigurieren. Bevord das Enforcement greift, müssen Teams informiert werden, was sich ändert, welche Limits gelten und was bei Erschöpfung passiert. Das klingt trivial, ist in der Praxis aber oft der entscheidende Unterschied zwischen einer reibungslosen Einführung und einem Vertrauensverlust.

Phase 2: Kostenanalyse und Showback. In der zweiten Phase wird das FinOps-Prinzip zur Kostenanalyse operativ. User-based Cost Centers werden angelegt und Usern zugewiesen, die Cost-Center-Exklusion am Enterprise-Budget wird aktiviert, und Cost-Center-Budgets für Additional Spend werden als Hard Stop pro Abteilung gesetzt. Für Power-User-Profile werden individuelle ULB-Overrides definiert. Das Ergebnis ist ein monatlicher Showback-Report: CSV-Daten werden auf Cost Center gemappt und als Kostenbericht an Abteilungsleiter übergeben. Damit wird AI-Nutzung zum ersten Mal sichtbar gemacht, ohne dass sofort verrechnet wird.

Phase 3: Automatisierung und Chargeback. Die dritte Phase eliminiert manuelle Pflege und schließt den FinOps-Kreislauf. Cost Centers, ULBs und Budgets lassen sich vollständig über die GitHub Billing REST API automatisieren, beispielsweise als Scheduled GitHub Actions Workflow, der Cost-Center-Zuweisung mit Team-Mitgliedschaft oder HR-System synchronisiert. Terraform bietet für Billing-Ressourcen keinen nativen Support im offiziellen Provider. Für echte Chargebacks werden Cost Centers mit Azure-Subscription-IDs verknüpft, was eine direkte Verrechnung an Geschäftsbereiche ohne manuelles Reporting ermöglicht.

Unsere Empfehlungen: zwei Seiten der Kontrolle

Was wir nicht empfehlen: Das Enterprise-Budget als einzigen Schutzmechanismus zu konfigurieren, ist die häufigste Fehlannahme, die wir sehen. Es verhindert Overspend, aber nicht die unfaire Verteilung des Inklusivkontingents. Und mit aktiviertem Hard Stop kann es die gesamte Organisation gleichzeitig abschalten.

Konkret empfehlen wir folgende Szenarien differenziert:

• Noch kein Budget gesetzt: Phase 1 jetzt. Enterprise-Budget und Universal-ULB sind in 30 Minuten konfiguriert. Den CSV-Report vorher zu erstellen ist keine optionale Vorbereitung, sondern die Grundlage für sinnvolle ULB-Limits.
• Org-Struktur = Billing-Struktur + SCIM im Einsatz: Organization-based Cost Centers – geringer Aufwand, gut wartbar.
• Teams org-übergreifend (Regelfall): User-based Cost Centers – mehr initialer Aufwand, aber saubere Kostenzuordnung.
• Copilot Coding Agent aktiv oder geplant: Power-User-ULBs von Anfang an. Agent-Sessions sind der stärkste Kostentreiber im neuen Modell. Ohne differenzierte Limits ist der Pool schneller erschöpft als erwartet, und das zu Lasten aller anderen im Enterprise.
• Heavy-User mit dauerhaftem Mehrverbrauch: Upgrade-Check: ab einem gewissen Verbrauchsniveau ist Copilot Enterprise günstiger als dauerhafter Additional Spend auf Business-Seats.
• Bestehende FinOps-Prozesse: Direkt mit Phase 3 einsteigen und Copilot-Governance als weiteren Datenstrom in das bestehende System integrieren.

Die zweite Seite: Budget-Controls steuern den Rahmen. Was innerhalb dieses Rahmens verbraucht wird, bestimmen Entwickler.

Admin-Controls setzen Grenzen, aber sie optimieren den Verbrauch nicht. Den eigentlichen Hebel auf Entwicklerseite haben wir in unserem Beitrag „Der größte Kostenhebel bei AI Engineering ist nicht das Modell, es ist die Disziplin“ beschrieben: wie Aufgaben mit Specs statt vagen Prompts spezifiziert werden, wie Context-Fenster kontrolliert werden, wie Sessions klar abgegrenzt werden. Modellwahl ist ein Hebel. Disziplin ist die größere. Beide Seiten braucht es, keine ersetzt die andere.

Copilot-Governance strukturiert aufbauen

Wir helfen Unternehmen dabei, GitHub Copilot-Governance strukturiert aufzubauen: Von der initialen Budget-Konfiguration und dem Cost-Center-Design über Showback-Reporting bis zur REST-API-Automatisierung und Integration in bestehende FinOps-Prozesse. Wenn Sie wissen wollen, wo Sie heute stehen und wie ein sinnvoller nächster Schritt aussieht, sprechen Sie uns an.