OpenAI beschreibt Pando als Git-kompatibles Backend, das die Entwicklung im eigenen Monorepo trägt. Für die Produktionsumgebung meldet das Unternehmen eine knapp 80 Prozent niedrigere mediane Push-Latenz. Das erklärte OpenAI am 2. November 2026 in einem Engineering-Beitrag über Pando.

Pando ging laut OpenAI im April 2026 nach rund zehn Wochen Entwicklungszeit in Produktion. Zunächst lief das System als Read-/Write-through-Proxy zum bisherigen Backend. Das ermöglichte eine schrittweise Migration ohne Ausfallzeiten.

Wie Pando Pushes und Fetches verarbeitet

Beim Push prüft Pando eingehende Packfiles, während es sie in einen Blob-Speicher streamt. Ein separater Metadatenspeicher hält Referenzversionen und Abhängigkeiten fest und aktualisiert den Verweis auf den neuen Stand. So muss Pando die eingehenden Packs nicht erst in ein lokales Repository entpacken.

Beim Fetch gleicht Pando die dem Client bekannten Commits mit den angeforderten ab und wählt gespeicherte Packs aus, die die fehlenden Objekte abdecken. Das System gibt Packfile-URIs zurück; Express liefert die Daten über regionale Caches aus. Durch die Wiederverwendung gespeicherter Packs muss nicht für jeden Abruf ein individuelles Pack neu erstellt werden.

Eine Hintergrundverdichtung fasst kleinere Packs zu größeren „Covers“ zusammen. In OpenAIs Monorepo reichen diese Ebenen bis L4. So sinkt die Zahl einzelner Packs, die ein Client beim Fetch abrufen muss.

Bei einem neuen Feature-Branch nennt Pando dem Client im Allgemeinen nur einen festgelegten trunk-Branch als Basis. Das hält die Branch-Ankündigung unabhängig von der wachsenden Zahl der Branches und erleichtert die Wiederverwendung von Packs. Bei wiederholten Pushes auf einen Feature-Branch oder bei gestapelten Branches können allerdings Objekte erneut übertragen werden, die nicht im trunk liegen. Für diesen Ansatz meldet OpenAI im eigenen Monorepo eine mediane Packgröße von unter 20 KiB; am 99. Perzentil lag sie unter 3 MiB.

Parallele Branches und die Konsistenzgrenze

Pando kann Änderungen an unabhängigen Referenzen parallel verarbeiten. Updates derselben Referenz werden dagegen serialisiert, also in einer festgelegten Reihenfolge verarbeitet. Wer mehrere Branches liest, erhält keine Garantie, dass alle gelesenen Stände denselben Zeitpunkt im Repository abbilden.

Das erlaubt parallele Arbeit an getrennten Branches, ohne für jeden Lesezugriff über das gesamte Repository einen gemeinsamen Stand zu versprechen. Für OpenAIs System zählt die Reihenfolge der Updates auf einer einzelnen Referenz.

Welche Leistungswerte OpenAI meldet

Neben der niedrigeren medianen Push-Latenz berichtet OpenAI, dass Pando täglich nahezu ein Petabyte Git-Daten ausliefert. In einer Spitzenstunde wurden demnach mehr als 57 TB Git-Packs bereitgestellt; über 99 Prozent der Bytes in dieser Stunde kamen aus dem lokalen Festplattencache.

OpenAI zufolge lasteten validierte Clone- und Fetch-Vorgänge auf Standard-VMs von Cloud-Anbietern zudem 10-Gbit/s-Verbindungen aus. Diese Werte beschreiben OpenAIs eigene Produktionsumgebung und deren Arbeitslast.

Die interaktive Architektur-Gegenüberstellung auf OpenAIs Seite behandelt Drei-Phasen-Commit, ein Write-Ahead-Log im Objektspeicher und Pando. OpenAI bezeichnet die Simulationen als synthetische Lehrmodelle, nicht als Produktionsbenchmarks.

Was OpenAI zum Teilen von Pando sagt

OpenAI beschreibt Pando als internes System und erklärte am 2. November, Wege zum Teilen der zugrunde liegenden Technologie zu prüfen. Einen Veröffentlichungstermin oder ein Verteilungsformat für Pando selbst nannte das Unternehmen nicht. Einige Verbesserungen aus der Arbeit sind laut OpenAI bereits upstream in Git eingeflossen; weitere liegen im öffentlichen Repository des Unternehmens.