OpenAI betreibt sein Monorepo auf Pando, einem eigenen Git-Backend, mit fast fünfmal schnel­leren Pushes

OpenAI betreibt die gesamte Entwicklung in seinem Monorepo, dem einen gemeinsamen Code-Repository, inzwischen auf Pando, einem selbst gebauten Backend für Git-Repositories. Im Betrieb sank der Median der Push-Latenz um fast das Fünffache, und Pando liefert täglich fast ein Petabyte Git-Daten aus. Anthropic stand vor derselben Art von Last und hat im Oktober gemeldet, Git im eigenen Monorepo durch das Versionssystem Scion ersetzt zu haben. OpenAI geht den anderen Weg: Git-Protokoll und Git-Client bleiben, ausgetauscht wird der Server dahinter.

Was das alte System nicht mehr schaffte

Anlass ist das Tempo, das Codex in die Arbeit bringt. Ein Entwickler hat nun mehrere Änderungen gleichzeitig für die CI bereit, und jeder Push lässt mehrere Jobs denselben Commit holen. Seit etwa Ende 2025 kamen die Systeme hinter dem Monorepo damit nach OpenAIs Angaben nicht mehr zurecht: Fetches und Pushes liefen langsam, Merges schlugen fehl, die Zuverlässigkeit fiel zeitweise unter 90 Prozent. OpenAI fragte sich, ob Git selbst an eine Grenze gestoßen war oder die Art, wie das Monorepo bedient wurde. Das Unternehmen wollte den vertrauten Ablauf behalten und das Backend so umbauen, dass Pushes auf verschiedene Branches parallel laufen und viele Leser zugleich denselben Verlauf bekommen.

Wie Pando die Last verteilt

Beim Schreiben landet jeder Push als unveränderliches Packfile, Gits Format für gebündelte Objekte, im Blob-Storage. In einem Metadatenspeicher legt Pando je Branch eine neue Version ab. Jeder Branch wird einzeln koordiniert, nur wer denselben Branch gleichzeitig beschreibt, kommt sich in die Quere. Dafür fällt die Konsistenz schwächer aus: Pando liefert keinen einheitlichen Schnappschuss aller Branches, und wer mehrere gleichzeitig liest, kann sie in verschiedenen Zuständen sehen. OpenAI hält das für verkraftbar, weil Entwickler und Agenten sich nach der Reihenfolge der Änderungen an einem einzelnen Branch richten.

Beim Lesen berechnet Pando nicht für jeden Client ein eigenes Packfile. Es wählt bereits gespeicherte Packfiles aus und nennt dem Client Adressen zum Herunterladen. Ein Client kann dabei Objekte bekommen, die er schon hat. Dafür bedienen regionale Zwischenspeicher mit einer Trefferquote von über 99 Prozent die Anfragen, und auf gewöhnlichen Cloud-Rechnern sättigten Clone und Fetch Leitungen mit 10 Gbit/s. Im Hintergrund fasst Pando die Packfiles stufenweise zusammen, damit ein Client, der Tage zurückliegt, nicht Zehntausende Einzeldateien laden muss.

Auch beim Schreiben kostet das etwas. Der Server nennt einem pushenden Client standardmäßig nur den Hauptzweig, damit sich das Packfile später für andere Leser wiederverwenden lässt. Wer mehrfach auf denselben Branch pusht, schickt deshalb Teile erneut. Im Monorepo lag die Hälfte der Packfiles unter 20 KiB und 99 Prozent unter 3 MiB.

Gebaut wurde Pando in zehn Wochen vom Start bis zur Produktion. Den Kern entwarf ein einzelner Ingenieur, Agententeams setzten ihn mit Codex um, seit April läuft er im Betrieb. Die Umstellung erfolgte ohne Ausfall, zunächst als durchleitender Proxy vor dem alten System. Dieselbe Verbesserung beziffert OpenAI auch als fast 80 Prozent weniger Latenz beim Median-Push, und in der Spitze lieferte Pando in einer Stunde über 57 Terabyte Packfiles aus. Einige Verbesserungen am Git-Client hat das Unternehmen bereits in das Git-Projekt zurückgegeben.

Zwei Antworten auf dieselbe Last

Beide Unternehmen nennen Coding-Agenten als Auslöser, und beide legen unveränderliche Daten im Blob-Storage ab, mit einem Metadatenspeicher davor und Zwischenspeichern mit Trefferquoten über 99 Prozent. Die Grenze ziehen sie an verschiedenen Stellen.

• Was bleibt. OpenAI behält Protokoll und Client, die Clients halten weiter eine vollständige Kopie, und Entwickler wie Agenten behalten ihre Abläufe. Anthropic ersetzt Client, Format und Protokoll. Bei Scion beantwortet der Server Fragen zu Verlauf und Blame und erzeugt Commits, Merges und Rebases, der Client hält nur einen begrenzten Zwischenspeicher. Review, Codesuche und CI müssen zu Scion passen.
• Warum. Anthropic setzt bei der Bauform an: Git sei auf Clients ausgelegt, die offline arbeiten und alles besitzen, während seine Clients fast durchweg Agenten und Jobs sind, die immer online sind. OpenAI behandelt das Problem als eines des Servers: Es baut das Backend neu und behält Git.
• Commits und Branches. In Scion entstehen Commits auf dem Server, es gibt nichts zu pushen, und Anthropic rät von Branches außer dem Hauptzweig und Release-Zweigen ab, weil globaler Zustand schlecht skaliert. Pando nimmt weiter Pushes eines Git-Clients entgegen und macht die große Zahl paralleler Branches zum Ziel, indem es jeden einzeln koordiniert.
• Messgrößen. OpenAI misst Push-Latenz und ausgelieferte Datenmenge. Anthropic misst Checkout-Zeiten, die um zwei Größenordnungen sanken, eine 200-fach kleinere Infrastruktur und 25 Prozent gewonnene CPU-Kapazität in der CI. Beide Zahlenreihen lassen sich nicht aufeinander umrechnen, und OpenAI nennt die Größe seines Repositories nicht, Anthropic spricht von fast 100 GB Historie.

Anthropic schreibt in seinem Beitrag, Scion sei kein Ersatz für Git im allgemeinen Gebrauch, die Konzepte ergäben nur bei sehr großen Monorepos Sinn. Zugleich hält das Unternehmen fest, ein Git-Server müsse nicht so arbeiten wie ein Git-Client, und neue Server-Architekturen könnten Git deutlich besser skalieren. Pando ist ein Server dieser Art, den Anthropic in seinem Beitrag nicht erwähnt.

Was offen bleibt

Die Produktionszahlen sind OpenAIs Selbstauskunft, ohne absolute Latenzen und ohne Vergleichswert. Der Vergleich mit anderen Bauarten stammt aus einer Simulation, die OpenAI selbst als synthetisches Lehrmodell ohne Pro­duk­ti­ons­mes­sung kennzeichnet. Ob Pando außerhalb von OpenAI zugänglich wird, ist offen: Das Unternehmen prüft Wege, die Technik zu teilen, ohne einen Termin zu nennen. Anthropic hält Scion für kaum übertragbar und regt an, dass Git-Plattformen solche Server-Schnittstellen anbieten. Ob sie es tun, ist offen.

Einordnung

Für ein gewöhnliches Repository ändert sich nichts, denn beide Lösungen antworten auf Lasten sehr großer Monorepos mit vielen gleichzeitigen Agenten und CI-Jobs. Im Kleinen gilt aber dieselbe Richtung: Wer Coding-Agenten parallel arbeiten lässt, erzeugt mehr Commits, Pushes und kurzlebige Branches als ein Mensch allein. Warum Git bei der Arbeit mit Agenten kein Nebenschauplatz ist und wie kleine, häufige Commits den Rückweg sichern, erklärt Vibe-Coding / Agentic Engineering, Kapitel 04.