Agenten überrennen Git: Warum OpenAI, GitHub und Meta die Versionsverwaltung umbauen

Darum geht es

Wer Anfang November die Nachrichten las, sah drei scheinbar getrennte Meldungen. Am 2. November beschreibt OpenAI ein selbst gebautes Git-Backend namens Pando. Am 4. November übernimmt OpenAI das Start-up Pierre Computer Company, am selben Tag kauft Meta Conductor. Eine Woche davor hatte GitHub im Octoverse-Bericht 2026 Rekordzahlen veröffentlicht. Zusammen ergeben die Meldungen ein klares Bild: Die Versionsverwaltung Git und vor allem die Server, auf denen Git-Repositories liegen, sind zum Engpass der KI-Programmierung geworden. Git wurde für Menschen gebaut, die ein paarmal am Tag Code hochladen. Heute arbeiten Agenten in Schleifen, legen Tausende Zweige an und lösen bei jedem Schritt Tests aus.

Die Last in Zahlen

Laut GitHubs Octoverse 2026 haben im September mehr als 40 Prozent aller Pull Requests mit einem Agenten begonnen. Pull Requests sind Änderungsvorschläge am Code, die vor der Übernahme geprüft werden. Das waren 110 Millionen Stück, im März lag der Anteil noch bei 17 Prozent. GitHub nennt die 40 Prozent selbst eine Untergrenze, weil nicht jeder Agent erkannt wird. Laut GitHubs Engineering-Blog gab es im September 7,38 Milliarden Commits (gespeicherte Änderungen), mehr als fünfmal so viele wie ein Jahr zuvor. Die Pushes, also das Hochladen von Änderungen auf den Server, stiegen auf 3,35 Milliarden im Monat, das 4,9-Fache. GitHub Actions, der Dienst für automatische Tests und Builds (CI), lief im September 3,26 Milliarden Mal. Simon Willison nennt die Kurven eine „ziemlich drastische Darstellung“ der Wirkung agentischer Programmierung.

Die Last hatte Folgen. Am 9. April verzögerten sich beim Copilot-Coding-Agenten rund 84 Prozent der neuen Sitzungen, die Wartezeit stieg auf bis zu 54 Minuten statt der üblichen 15 bis 40 Sekunden. Schuld war ein Fehler, durch den ein Rate Limit (eine Obergrenze für Anfragen) für alle Nutzer statt nur für eine Installation griff. Im August gab es zwei große Ausfälle. Am 17. August war GitHub 7 Stunden und 47 Minuten gestört, betroffen waren auch Anmeldung, Actions und Pull Requests. Eine zentrale Komponente im US-Rechenzentrum war mit einer neuen Lastspitze nicht mitgewachsen. GitHub schreibt dazu: „Beide Vorfälle waren im Kern Kapazitätsfehler“, keiner sei durch eine Code- oder Konfigurationsänderung entstanden. Während der Wiederherstellung trieb eine Wiederholungsschleife in Copilot-Clients die Last noch weiter nach oben. Laut Business Insider holt Microsoft zusätzlich Kapazität bei AWS dazu. Microsoft bestätigte das nur allgemein als „Multi-Cloud-Strategie“.

Wo Git unter Agenten bricht

Aus den Engineering-Berichten von OpenAI, GitHub und Anthropic ergeben sich vier Bruchstellen.

1. Schreibkoordination. GitHubs bisheriges Speichersystem „Spokes“ legt jedes Repository in der Regel fünfmal auf verschiedenen Servern ab. Jeder Push muss per Three-Phase-Commit von einer Mehrheit dieser Kopien bestätigt werden. Man kann es sich wie eine Abstimmung vorstellen: Erst wenn genug Kopien zugestimmt haben, gilt die Änderung. Der Push dauert deshalb so lange wie die Antwort der langsamsten Kopie, die für die Mehrheit nötig ist. GitHub schreibt dazu: „Tausende Agenten, die jeweils auf eigenen Branches in einem Repository arbeiten, erzeugen eine dauerhafte Schreibrate.“
2. Die Liste der Branches. Bei jedem Push oder Fetch schickt der Server dem Client zuerst eine Liste aller Branches. Laut OpenAI kann diese Liste bei Millionen Branches allein mehr als 100 MiB groß werden.
3. Die CI-Lawine. Jeder Push startet mehrere Test-Jobs, die alle denselben Stand herunterladen. Anthropic zählt 25 Millionen Checkouts für CI pro Tag. Würde jeder Job naiv das ganze Repository holen, wären das laut Anthropic über 600 Petabyte Git-Verkehr täglich.
4. Die Merge-Warteschlange. Eine Merge Queue nimmt Änderungen nacheinander in den Hauptzweig auf und sperrt dafür das ganze Repository. Anthropic schreibt, eine solche globale Sperre funktioniere bei Agenten-Tempo nicht mehr.

Dazu kommen die API-Limits. In einer GitHub-Community-Diskussion vom Juni beschreibt ein Entwickler, dass schon wenige parallel laufende Review-Agenten die sogenannten Secondary Rate Limits auslösen. Eine inhaltliche Antwort von GitHub gibt es dort nicht.

Drei Antworten: neu bauen, umbauen, orchestrieren

OpenAI baut neu. Laut OpenAI-Blog wurden die Systeme rund um das Monorepo (ein einziges riesiges Repository für fast den gesamten Firmencode) ab Ende 2025 langsam, Merges schlugen fehl. Die Zuverlässigkeit lag zeitweise unter 90 Prozent. Pando behält das Git-Protokoll bei, sodass Menschen und Agenten weiter ganz normal git push nutzen. Neu ist der Server dahinter. Er stimmt jeden Branch einzeln ab, Konflikte entstehen nur noch bei Pushes auf denselben Branch. Ein Push auf einen Feature-Branch bekommt standardmäßig nur noch den Hauptzweig angekündigt statt aller Branches. Hochgeladene Pakete werden unveränderlich abgelegt und über Caches ausgeliefert. Laut OpenAI ist die mittlere Push-Zeit um fast 80 Prozent gesunken. Pando liefert demnach knapp ein Petabyte Git-Daten pro Tag aus, in der Spitzenstunde mehr als 57 TB, über 99 Prozent davon aus dem Cache. Pando ist in Rust geschrieben, läuft seit April und entstand laut OpenAI in zehn Wochen mit Hilfe von Codex. Einige Medien nennen eine Merge-Zuverlässigkeit von 99,99 Prozent nach der Umstellung. Code, Schnittstellen oder Anleitungen hat OpenAI nicht veröffentlicht.

Dazu passt der Kauf von Pierre. Dessen Dienst Code Storage ist Git-Hosting für Maschinen, mit SDKs und kurzlebigen Branches, die Agenten anlegen und wieder verwerfen. Als Kunden nennt Pierre unter anderem Lovable, Bolt, Poke und Amp. Laut einer Fallstudie, die Pierre selbst veröffentlicht hat, legt Lovable mehr als acht Millionen Repositories pro Woche an. Pierres Open-Source-Bibliotheken Diffs und Trees stecken bereits in Codex und sollen laut The Decoder offen bleiben. Der Kauf braucht noch eine behördliche Genehmigung, einen Preis nannte niemand. Ob Pando und Code Storage verschmelzen, ist offen.

GitHub baut um. Laut GitHubs Engineering-Blog vom 6. Oktober werden Speicher und Rechenleistung getrennt. Die maßgeblichen Daten wandern in Azure Blob Storage, einen Objektspeicher, der sich selbst um Kopien und Ausfallsicherheit kümmert. Davor arbeiten leichte Server, die nur Daten zwischenspeichern. Abstimmen müssen sie sich nur noch beim Aktualisieren eines Branch-Zeigers. Aufräumarbeiten wie Garbage Collection laufen getrennt vom Live-Betrieb. Für den Zwischenschritt mit Schreibkoordination pro Branch statt pro Repository nennt GitHub 3- bis 4-mal mehr Schreibdurchsatz, gemessen in „internen Tests mit realistischem Verkehr“. Für die komplette neue Architektur sind es in internen Benchmarks bis zu 35-mal mehr. Diese 35-fache Steigerung ist laut den Quellen nicht im Produktivbetrieb bestätigt. Bis 21. Oktober hatten 99,99999 Prozent der Repositories eine Kopie in Azure, die Umstellung auf mehrere Regionen soll Anfang 2027 fertig sein. Zur Universe-Konferenz meldete GitHub, man habe 2026 vier Millionen CPU-Kerne und 160 PB schnellen Speicher dazugebaut. Die Lehre daraus formulierte GitHub selbst: „Kapazität allein bringt uns nicht ans Ziel.“

Meta orchestriert. Conductor ist eine Mac-App, mit der Entwickler mehrere Agenten wie Claude Code oder Codex gleichzeitig laufen lassen. Jeder Agent bekommt einen eigenen Worktree, also eine separate Arbeitskopie desselben Repositories. Laut Axios ist der Kaufpreis unbekannt, laut Runtimewire wechselt das Team zu Meta Superintelligence Labs. Für Nutzer bedeutet das: Seit dem 4. November gibt es keine Neuanmeldungen mehr. Ab dem 13. November ist die Cloud nur noch lesbar, am 20. November wird sie abgeschaltet und die Daten werden gelöscht. Arbeitsbereiche lassen sich per „Transfer to local“ auf den Mac holen. Die lokale App bekommt allerdings nur noch bis Anfang 2027 neue Modelle und Fehlerkorrekturen und wird danach ebenfalls auslaufen.

Was unabhängig belegt ist und was nicht

Gut belegt sind die Lastzahlen und Ausfälle. GitHub dokumentiert sie in eigenen Störungsberichten, und mehrere Firmen schildern unabhängig voneinander dasselbe Problem. Alle Leistungsgewinne stammen dagegen von den Herstellern selbst. Laut InfoQ weist etwa Casey Lee, CTO von Liatrio, darauf hin, dass Cursors Zahlen nicht unabhängig geprüft sind. Auffällig ist außerdem: Pierre bewirbt Code Storage auf der eigenen Website noch mit genau dem Prinzip „Three-Phase-Commit mit Quorum“, von dem sich GitHub gerade verabschiedet. Im Hacker-News-Thread zum Kauf (96 Punkte) fasst ein Nutzer zusammen: „Agentisches Programmieren macht GitHub kaputt.“ Andere halten dagegen, Entwicklerwerkzeuge seien ein notorisch unprofitabler Markt, und sprechen von „KI-Bros, die KI-Bros kaufen“.

Was das für Teams heißt, die selbst Agenten einsetzen

Pando und Scion bekommt man nicht, Cursors Origin und Ex-GitHub-Chef Thomas Dohmkes Spiegeldienst Entire sind noch in der Vorschau. Für normale Teams bleibt es deshalb vorerst bei Handarbeit. Aus den Berichten lassen sich ein paar Punkte ableiten:

• Die Zahl paralleler Agenten begrenzen. Mehrere Praxisberichte sehen in den API-Limits und der eigenen Fähigkeit zum Review den eigentlichen Engpass, nicht im Modell.
• CI gezielt auslösen. Entwürfe nicht bei jedem Zwischen-Commit testen lassen und Abhängigkeiten cachen. Dazu Shallow oder Partial Clones nutzen, bei denen nur der benötigte Teil der Historie geladen wird.
• Wiederholungen bremsen. Agenten sollten nach Fehlern mit wachsenden, leicht zufälligen Pausen neu anfragen (Backoff mit Jitter). Der August-Ausfall zeigt, wie Wiederholungsschleifen eine Störung verlängern.
• Branches aufräumen. Verwaiste Agenten-Branches blähen die Branch-Liste auf, die bei jeder Anfrage übertragen wird.
• Conductor-Nutzer: Daten vor dem 20. November exportieren.

Einordnung

Unsere Einschätzung: Die Meldungen der ersten Novemberwoche hängen zusammen. Wer Coding-Agenten verkauft, muss inzwischen auch die Infrastruktur darunter kontrollieren. Sonst bremsen fremde Server und deren Limits das eigene Produkt aus. OpenAI holt sich dafür Speicher-Know-how und Oberflächen-Bausteine, Meta die Orchestrierungsschicht. Für den Speicher hat Meta mit Sapling ohnehin schon ein eigenes System, auf das sich auch Anthropic beruft. GitHub muss währenddessen seine Plattform im laufenden Betrieb umbauen. Ob die versprochenen Faktoren in der Praxis ankommen, kann bisher niemand von außen prüfen. Die zentrale Erkenntnis teilen dennoch alle Beteiligten: Mehr Hardware allein reicht nicht. Agenten verlangen eine Versionsverwaltung, die nicht mehr das ganze Repository abstimmt, sondern nur noch einzelne Zeiger. Der nächste Engpass ist absehbar, und das ist der Mensch, der all die Pull Requests noch prüfen muss.