Auf den ersten Blick wirken die neuen Copilot-Limits wie eine Tarifkorrektur. Tatsächlich geht es um mehr: GitHub muss neu berechnen, was eine „Copilot-Anfrage“ überhaupt ist. Früher war das oft eine Code-Vervollständigung oder eine Chat-Antwort. Heute kann daraus ein Agentenlauf werden, der Kontext liest, Teilaufgaben startet und über längere Zeit parallel arbeitet. Genau diese Agents und Subagents nennt GitHub als Grund dafür, dass Infrastruktur und Preisstruktur unter Druck geraten; laut GitHub können inzwischen schon wenige Anfragen Kosten verursachen, die über dem jeweiligen Tarifpreis liegen ^[14].

Was aus den Quellen sicher hervorgeht

Vier Punkte sind durch die vorliegenden öffentlichen Quellen gut belegt.

Erstens hat GitHub neue Registrierungen für Copilot Pro, Pro+ und Student pausiert, die Nutzungslimits für Individual-Tarife verschärft und Opus-Modelle aus Pro entfernt ^[15].

Zweitens beobachtet GitHub bei Copilot eine Zunahme von Mustern mit hoher Parallelität und intensiver Nutzung. Auch wenn solche Nutzung aus legitimen Workflows entstehen kann, belastet sie laut GitHub die gemeinsame Infrastruktur und operative Ressourcen erheblich ^[17].

Drittens stellt GitHub alle Copilot-Tarife ab dem 1. Juni 2026 auf nutzungsbasierte Abrechnung um. Copilot-Nutzung soll dann GitHub AI Credits verbrauchen ^[19].

Viertens wird Copilot code review ab dem 1. Juni 2026 GitHub Actions minutes verbrauchen, also Minuten aus dem Ressourcenkontingent für automatisierte GitHub-Abläufe ^[24].

Vorsicht ist bei der Zahl „30-fach“ angebracht. Ein externer Bericht schreibt, GitHub müsse Systeme für das 30-Fache des heutigen Maßstabs auslegen ^[30]. In den hier genannten GitHub-Quellen ist diese Zahl jedoch nicht als offiziell bestätigter Ausbauplan belegt. Sicher belegt ist: GitHub bestätigt Kapazitäts-, Parallelitäts- und Abrechnungsdruck. Die 30-fache Skalierung bleibt nach aktuellem Quellenstand eine externe Größenordnung, keine offizielle Kennzahl.

Vom Editor-Helfer zum laufenden Agentenprozess

Der entscheidende Wandel ist nicht, dass mehr Menschen Copilot verwenden. Der entscheidende Wandel ist, wie Copilot verwendet wird.

Klassische KI-Coding-Hilfen arbeiteten oft im Takt des Menschen: ein Vorschlag für eine Zeile, eine Erklärung, ein kurzer Chat, ein Code-Snippet. Agentic coding, also agentenbasiertes Programmieren, verschiebt diesen Rhythmus. Ein Nutzer gibt ein Ziel vor, und ein Agent kann daraus eine Reihe von Arbeitsschritten machen.

GitHub beschreibt in den Copilot-Veröffentlichungen für Visual Studio Code unter anderem

Autopilot for fully autonomous agent sessions

[18]

GitHubs eigene Begründung für die Planänderungen zeigt in dieselbe Richtung: Agents und Subagents erzeugen lange, parallelisierte Workflows, die bei komplexen Coding-Problemen wertvoll sein können, aber Infrastruktur und Preisstruktur herausfordern ^[14].

Warum Coding-Agenten die Infrastruktur stärker belasten

1. Eine Anfrage wird zur Sitzung

Bei einer normalen Code-Vervollständigung ist die Last relativ klar begrenzt: Eingabe, Modellantwort, Ende. Ein Agentenlauf kann dagegen mehrere Schritte umfassen. Er muss Kontext verarbeiten, planen, Zwischenergebnisse bewerten und weitere Aktionen anstoßen.

GitHub sagt ausdrücklich, dass diese langen, parallelisierten Agents- und Subagents-Workflows die Infrastruktur und das Pricing-Modell herausfordern und dass wenige Anfragen Kosten verursachen können, die über dem Tarifpreis liegen ^[14]. Das erklärt, warum reine Nutzerzahlen nicht mehr ausreichen. Ein einzelner intensiver Agentenlauf kann mehr Ressourcen binden als viele kurze Interaktionen.

2. Parallelität heißt nicht mehr nur: Wie viele Nutzer sind online?

In klassischen SaaS-Modellen wird Kapazität oft grob entlang aktiver Nutzer geplant. Bei Coding-Agenten greift das zu kurz. Eine Person kann mehrere Agenten oder Subagenten parallel starten, und jeder dieser Prozesse kann länger laufen.

GitHub schreibt, bei Copilot nähmen Muster mit hoher Parallelität und intensiver Nutzung zu; solche Muster belasteten die gemeinsame Infrastruktur und operative Ressourcen erheblich ^[17]. Die relevante Frage lautet also nicht mehr nur: Wie viele Entwicklerinnen und Entwickler verwenden Copilot gerade? Sondern: Wie viele automatisierte Workflows laufen gleichzeitig, wie lange laufen sie, und wie viel Kontext verarbeiten sie?

3. KI rückt in zentrale GitHub-Workflows vor

Copilot ist längst nicht mehr nur ein Chatfenster neben dem Code. Copilot code review zeigt, wie KI-Funktionen in die kollaborativen Kernprozesse von GitHub hineinwachsen.

GitHub schreibt, die Nutzung von Copilot code review sei seit dem vorherigen April um das Zehnfache gewachsen und mache inzwischen mehr als ein Fünftel der Code Reviews auf GitHub aus. Außerdem sei die zugrunde liegende Architektur auf ein agentisches Modell umgestellt worden, das Repository-Kontext abruft und über Änderungen hinweg Schlussfolgerungen zieht ^[13].

Das ist infrastrukturell schwerer als eine einzelne Chatantwort. Code Review ist Teil des Pull-Request- und Kollaborationsflusses. Wenn KI dort Repository-Kontext liest und Änderungen übergreifend bewertet, steigt die Last auf Plattformressourcen. Dazu passt, dass Copilot code review ab dem 1. Juni 2026 GitHub Actions minutes verbrauchen wird ^[24].

4. Das Pauschal-Abo trifft auf Maschinentakt

Ein fester Monatspreis funktioniert gut, solange die Nutzung relativ vorhersehbar bleibt und vor allem vom Tempo der Menschen abhängt. Agenten verschieben diesen Rahmen. Sie können mit Maschinentakt arbeiten, länger laufen und parallelisiert werden.

GitHub benennt genau diese Kombination als Problem: lange, parallelisierte Workflows liefern Nutzen, stellen aber Infrastruktur und Preisstruktur infrage ^[14]. Die Umstellung auf nutzungsbasierte Abrechnung ab dem 1. Juni 2026 ist daher kein isolierter Preisschritt, sondern eine Reaktion auf eine neue Workload-Form. Copilot wird weniger als reine Sitzplatzlizenz für einen KI-Assistenten behandelt und stärker nach tatsächlichem KI-Verbrauch gemessen ^[19].

Welche Schritte GitHub bereits geht

Die Änderungen sehen nicht nach einer einzelnen Notbremse aus, sondern nach einer breiteren Neujustierung von Kapazität, Kosten und Fair Use.

• Neue Registrierungen für Copilot Pro, Pro+ und Student wurden pausiert; Individual-Tarife erhalten engere Nutzungslimits; Opus-Modelle wurden aus Pro entfernt ^[15].
• GitHub setzt neue Limits durch und entfernt Opus 4.6 Fast aus Copilot Pro+. Als Hintergrund nennt GitHub hohe Parallelität und intensive Nutzung, die gemeinsame Infrastruktur und operative Ressourcen belasten ^[17].
• Alle Copilot-Tarife sollen ab dem 1. Juni 2026 auf nutzungsbasierte Abrechnung umgestellt werden; Copilot-Nutzung verbraucht dann GitHub AI Credits ^[19].
• Copilot code review soll ab dem 1. Juni 2026 GitHub Actions minutes verbrauchen ^[24].
• GitHub hat pro Nutzer ausgewiesene GitHub-Copilot-CLI-Aktivität in die Copilot-Nutzungsmetriken für Organisationsberichte aufgenommen ^[16].

Zusammen ergibt das ein klares Bild: Es geht nicht nur darum, ein besonders teures Modell zu begrenzen oder eine kurzfristige Traffic-Spitze abzufedern. GitHub passt Limits, Modellverfügbarkeit, Messung und Abrechnung an eine neue Art von Entwicklungsarbeit an.

Die 30-fach-Zahl richtig einordnen

Sollte sich die externe Darstellung einer 30-fachen Skalierungsanforderung bewahrheiten, wäre sie nicht automatisch als 30-fache Nutzerzahl zu verstehen. Technisch plausibler ist ein Multiplikatoreffekt: mehr Nutzer probieren agentenbasiertes Coding aus; einzelne Nutzer starten längere und stärker parallelisierte Workflows; hohe Parallelität belastet gemeinsame Infrastruktur; Funktionen wie Copilot code review lesen Repository-Kontext und greifen in weitere Plattformressourcen ein ^{[13][14][17][24][30]}.

Trotzdem bleibt die Grenze wichtig: Die 30-fach-Zahl ist derzeit eine externe Größenordnung ^[30]. Die robustere Aussage lautet: GitHub reagiert nachweislich auf die Lastcharakteristik von agentic coding, indem es Copilot-Limits, Modellzugang, Nutzungsmetriken und Abrechnung verändert ^{[14][15][17][19]}.

Was Entwicklungsteams jetzt tun sollten

1. KI-Agenten als Produktionslast behandeln. Wer Copilot nur nach Entwicklerplätzen budgetiert, übersieht künftig einen wichtigen Teil der Kosten. Relevanter werden Fragen wie: Wie viele Agenten laufen parallel? Wie lange dauern typische Aufgaben? Welche Workflows verbrauchen AI Credits oder GitHub Actions minutes? ^[17][19][24]

2. Nutzung auf Organisationsebene messen. GitHub macht Copilot-Nutzung zunehmend sichtbarer, etwa durch pro Nutzer ausgewiesene Copilot-CLI-Aktivität in Organisationsberichten ^[16]. Für Teams, die Copilot CLI, Agentenmodi oder KI-gestützte Code Reviews ausrollen, gehören solche Metriken in Engineering- und Budgetgespräche.

3. Autonomen Agenten klare Leitplanken geben. Wenn vollständig autonome Agentensitzungen in die öffentliche Vorschau kommen und GitHub zugleich Steuerungsmöglichkeiten für Agents betont, sollten Teams nicht nur auf Produktivität schauen ^[18]. Sinnvoll sind Grenzen für Parallelität, Timeouts, Wiederholungen und manuelle Prüfungen, bevor Agentenläufe in gemeinsam genutzte Ressourcen hineinwachsen.

4. Das Kostenmodell vor dem 1. Juni 2026 anpassen. Ab diesem Datum soll Copilot-Nutzung GitHub AI Credits verbrauchen, und Copilot code review soll GitHub Actions minutes nutzen ^[19][24]. Damit rückt die tatsächliche Nutzungsintensität stärker in den Vordergrund als die bloße Zahl der Lizenzen.

Fazit: Copilot-Limits sind ein frühes Signal für agentenbasierte Softwareentwicklung

GitHub Copilot gerät nicht einfach deshalb unter Druck, weil KI-Coding populär ist. Der tiefere Grund ist, dass sich die Lastform ändert. Aus kurzen, vom Menschen getakteten Interaktionen werden lange, parallele, kontextreiche Agenten-Workflows. GitHub hat diesen Druck öffentlich benannt und reagiert mit pausierten Neuregistrierungen, strengeren Limits, geänderter Modellverfügbarkeit, AI Credits und der Einbindung von Copilot code review in GitHub Actions minutes ^{[14][15][19][24]}.

Die nüchternste Einordnung lautet daher: KI-Coding-Agenten schreiben gerade die Kapazitäts- und Abrechnungslogik von Copilot um. Die 30-fache Skalierung sollte man bis zu einer offiziellen Bestätigung als externe Schätzung behandeln, nicht als feststehende GitHub-Zusage ^[30].