Pando soll Git für parallele KI-Entwicklung skalieren
OpenAI hat mit Pando ein neues Backend für das zentrale Git-Repository des Unternehmens entwickelt. Auslöser war der intensive Einsatz von Codex. Die Coding-Agenten erhöhten die Zahl paralleler Branches, Pushes, Merges, CI-Jobs und Datenabrufe deutlich.
Das bisherige System konnte mit dieser Last zeitweise nicht mehr zuverlässig umgehen. Fetches und Pushes wurden langsamer, Merges schlugen fehl und die Zuverlässigkeit sank zeitweise unter 90 %. Pando betreibt inzwischen die gesamte Entwicklung im Monorepo von OpenAI.
„Codex hat Größenordnung und Tempo der Entwicklung bei OpenAI verändert und ermöglicht deutlich mehr parallele Arbeit“, erklärt das Unternehmen sinngemäß aus dem Englischen.
Die auf den 2. November 2026 datierte Veröffentlichung beschreibt damit eine Folge des Einsatzes von Coding-Agenten, die in Kostenrechnungen leicht übersehen wird. Mehr generierter Code benötigt nicht nur Modellkapazität. Er erzeugt auch zusätzliche Last in Versionsverwaltung, Tests und CI/CD-Pipelines.
Die wichtigsten Leistungsdaten von Pando
| Kennzahl | Angabe von OpenAI |
|---|---|
| Zuverlässigkeit des vorherigen Systems | Zeitweise unter 90 % |
| Mittlere Push-Latenz | Um fast den Faktor fünf reduziert |
| Ausgelieferte Git-Daten | Fast 1 Petabyte pro Tag |
| Kompatibilität | Bestehende Git-Clients und Git-Protokolle |
OpenAI konnte das Backend austauschen, ohne die Arbeitsabläufe der Entwickler und Agenten zu verändern. Bestehende Git-Clients sprechen weiterhin die bekannten Protokolle. Das reduziert den Migrationsaufwand und verhindert, dass eine neue Versionsverwaltung in sämtliche Entwicklungsumgebungen integriert werden muss.
Dieser Ansatz unterscheidet sich von einem vollständigen Wechsel auf ein proprietäres Quellcode-System. OpenAI erweitert die Infrastruktur hinter einem offenen und etablierten Protokoll. Ob Pando selbst als Open-Source-Software veröffentlicht wird, ist allerdings nicht bekannt.
Unabhängige Branches statt globaler Schreibsperre
Pando behandelt Aktualisierungen einzelner Branches unabhängig. Pushes auf nicht zusammenhängende Branches können dadurch parallel verarbeitet werden, ohne auf eine globale Reihenfolge aller Änderungen im Repository zu warten.
Technisch setzt OpenAI auf Kausalkonsistenz. Dabei bleiben voneinander abhängige Änderungen korrekt geordnet, während unabhängige Vorgänge parallel laufen dürfen. Wer mehrere Branches gleichzeitig betrachtet, kann diese deshalb auf leicht unterschiedlichen Zeitständen sehen.
Eingehende Packfiles speichert Pando als unveränderliche Datenblöcke in einem horizontal skalierbaren Blob-Speicher. Die Versionen der Git-Referenzen liegen getrennt in einem skalierbaren Metadatenspeicher. Welche konkreten Speicherprodukte oder Datenbanken dafür eingesetzt werden, nennt OpenAI nicht.
Warum klassische Verteilungsmuster nicht ausreichten
OpenAI prüfte unter anderem Three-Phase Commit und ein gemeinsames Write-Ahead Log. Three-Phase Commit koordiniert eine Änderung über mehrere Systeme in mehreren Kommunikationsschritten. Ein Write-Ahead Log schreibt Änderungen zunächst in ein gemeinsames Protokoll, bevor sie angewendet werden.
| Ansatz | Problem bei hoher Parallelität | Pando-Prinzip |
|---|---|---|
| Three-Phase Commit | Mehrere Abstimmungsrunden zwischen Replikaten | Branch-Updates unabhängig koordinieren |
| Gemeinsames Write-Ahead Log | Zentrale Reihenfolge kann parallele Änderungen ausbremsen | Keine globale Reihenfolge für unabhängige Branches |
| Packfile pro Anfrage erzeugen | Hoher Rechenaufwand bei vielen ähnlichen Abrufen | Packfiles über Caches wiederverwenden |
Packfile-Caching entlastet die Leseseite
Git bündelt Objekte wie Dateien, Verzeichnisstrukturen und Commits in komprimierten Packfiles. Üblicherweise kann ein Server für jeden Client ein individuelles Paket erzeugen, das möglichst genau zu dessen vorhandenem Datenbestand passt. Bei sehr vielen gleichzeitigen Abrufen wird diese Berechnung teuer.
Pando verwendet Packfiles deshalb mehrfach und liefert sie aus Caches aus. Ein Client kann dadurch einige bereits vorhandene Objekte erneut erhalten. Im Gegenzug muss der Server nicht für jede Anfrage ein neues Paket berechnen und kann dieselben Daten effizient an viele Clients verteilen.
Diese Optimierung ist besonders relevant, wenn ein einzelner Push mehrere CI-Jobs auslöst, die denselben Commit abrufen. Ähnliche Skalierungsfragen entstehen auch bei steigenden Modellausgaben. Beispiele dafür sind die Senkung von Codex-Kosten durch Modell-Routing und Amazons Maßnahmen gegen Tokenmaxxing in der Softwareentwicklung.
Was Pando für Unternehmen im DACH-Raum zeigt
Fast 1 Petabyte Git-Daten pro Tag liegt weit außerhalb des Bedarfs typischer mittelständischer Entwicklungsteams. Das grundlegende Problem lässt sich dennoch übertragen. Coding-Agenten vervielfachen nicht nur die Codeproduktion, sondern auch Branches, Tests, Builds und Zugriffe auf Repositories.
Vor einem breiten Rollout solcher Agenten sollten deshalb Git-Server, Runner, Artefaktspeicher und CI/CD-Pipelines beobachtet werden. Engpässe können an Stellen auftreten, die bisher kaum als Kostenfaktor galten. Gleichzeitig steigt der Bedarf an Qualitätskontrollen, denn Untersuchungen zu minderwertigen KI-generierten Pull Requests zeigen, dass mehr Parallelität nicht automatisch besseren Code bedeutet.
Pando unterstreicht zudem den strategischen Wert offener Standards. Weil Git-Clients und Protokolle erhalten blieben, konnte OpenAI die Serverarchitektur austauschen, ohne sämtliche Werkzeuge und Arbeitsabläufe an einen neuen Anbieter zu binden. Das schafft Spielraum für Eigenentwicklung und verringert den technischen Vendor-Lock-in.
OpenAI plant, Verbesserungen aus der eigenen Git-Kopie an die Git-Community zurückzugeben. Das betrifft jedoch nicht automatisch Pando selbst. Ob das Backend öffentlich verfügbar wird oder ein internes System bleibt, ist bislang offen.