OpenAI beschreibt Pando, sein Git-Backend: Kausale Konsistenz ermöglicht Schreibskalierung je Branch, Mediane Push-Latenz laut OpenAI um fast 80 % gesunken, doch die Simulation ist ein Lehrmodell und Pando wird nicht extern angeboten
Am 2. November 2026 beschrieben OpenAI-Ingenieure Pando, ein neues Backend, das das Monorepo bedient, ohne Git-Protokoll oder -Client zu ändern, und jetzt die gesamte Entwicklung im OpenAI-Monorepo antreibt. Pando speichert jeden Push als unveränderlichen Packdatei-Blob mit einer Ref-Version, lässt unabhängige Branches getrennt schreiben und bedient Lesezugriffe durch Wiederverwendung gespeicherter Packs über regionale Caches. OpenAI meldet zuverlässigere Merges, eine um fast 80 % gesunkene mediane Push-Latenz (in der Einleitung fast das Fünffache), fast ein Petabyte pro Tag und 57 TB in einer Stunde, davon über 99 % aus dem lokalen Cache. Der Preis ist nur kausale Konsistenz ohne Momentaufnahme über Branches und standardmäßig nur der gemeldete Trunk, sodass wiederholte Pushes Daten erneut senden. Die Simulation mit 1.000 Clients gilt als Lehrmodell, und der Beitrag sagt nicht, dass Pando außerhalb von OpenAI verfügbar ist.
Am 2. November 2026 haben die drei OpenAI-Ingenieure Aaron Friel, Taylor Blau und Ted Nyman „Scaling Git at OpenAI“ veröffentlicht. Der Beitrag beschreibt Pando, ein neues Backend für Git-Repositories, das jetzt die gesamte Entwicklung im Monorepo von OpenAI antreibt. Der Grund sei Codex: Ingenieure erledigen viel mehr Arbeit parallel, was mehr Branches, Pushes, Merges, Fetches und Clones aus Entwicklungsumgebungen, Forschungsjobs und kontinuierlicher Integration bedeutet. Ab etwa Ende des vergangenen Jahres hatten die alten Systeme Mühe, mit langsamen Fetches und Pushes, fehlgeschlagenen Merges und einer Zuverlässigkeit, die zeitweise unter 90 % fiel.
Pando behält das Git-Protokoll und den Git-Client bei, sodass Ingenieure und Agenten ihre Arbeitsweise nicht ändern mussten. Es hat zwei Ziele: Schreibzugriffe, die über viele Branches horizontal skalieren, und Lesezugriffe, die schnell genug sind, die Netzwerkverbindung des Clients auszulasten. Beim Schreiben speichert Pando jede eingehende Packdatei als unveränderlichen Blob und hält in einem Metadatenspeicher eine „Ref-Version“ fest. Aktualisierungen unabhängiger Branches laufen unabhängig voneinander, und nur ein Push auf dieselbe Ref kollidiert. Beim Lesen verwendet es gespeicherte Packdateien wieder, statt für jeden Client ein eigenes Pack zu bauen, und gibt Clients Packdatei-URIs, die aus regionalen Caches kommen.
Die Autoren vergleichen das mit zwei verbreiteten Entwürfen, die sie modelliert haben: Dreiphasen-Commit zwischen vollständigen Replikaten, bei dem jeder Push mehrere Hin- und Rückwege braucht und Replikat-Festplatten auf dem Schreibpfad liegen, und ein gemeinsames Write-ahead-Log im Objektspeicher, bei dem jeder Push um die Aktualisierung eines einzigen Manifests konkurriert. Ihre interaktive Simulation mit 1.000 Clients zeigt, dass das erste unter Last die Schreibvorgänge und das zweite die Lesevorgänge verlangsamt. Die Seite kennzeichnet die Simulation als synthetische Lehrmodelle und nicht als Produktions-Benchmarks; sie erklärt den Entwurf, beweist aber nicht die Produktionszahlen.
Die Aussagen zum Produktivbetrieb sind konkret. Der Wechsel zu Pando verbesserte die Merge-Zuverlässigkeit und senkte die mediane Push-Latenz um fast 80 %, was die Einleitung als fast das Fünffache angibt. Pando liefert fast ein Petabyte Git-Daten pro Tag, hat in einer einzigen Stunde mehr als 57 Terabyte an Packs ausgeliefert, davon über 99 % der Bytes aus dem lokalen Festplatten-Cache, und lastete in der Validierung 10-Gbit/s-Verbindungen auf üblichen virtuellen Cloud-Maschinen aus. Express, der Pack-Auslieferungsdienst, meldet Cache-Trefferquoten über 99 %. Das sind OpenAIs eigene Zahlen für ein einziges Monorepo, ohne unabhängige Messung und ohne Vergleich mit einem anderen System im Produktivbetrieb.
Der Beitrag spricht die Kompromisse offen an. Pando bietet kausale Konsistenz, keine Momentaufnahme aller Refs: Während eines Clones können zwei Clients zwei Branches in unterschiedlichen Versionen sehen, während Aktualisierungen einer einzelnen Ref serialisierbar bleiben. Damit Packs wiederverwendbar bleiben, meldet Pando bei einem Push standardmäßig nur einen bestimmten Trunk-Branch, sodass wiederholte Pushes auf denselben Feature-Branch oder gestapelte Branches mehr Daten erneut senden. Im Monorepo von OpenAI lag das mediane so erzeugte Pack unter 20 KiB und das 99. Perzentil unter 3 MiB. Pando behält zudem Packs auf jeder Verdichtungsstufe, bis zu L4, damit die Fetch-Planung logarithmisch statt über Tausende kleiner Downloads läuft.
Zum Bau sagen die Autoren, Pando sei in 10 Wochen vom Start bis in die Produktion gekommen, habe im April den Produktivverkehr übernommen, und sein Kern sei von einem Ingenieur entworfen, von Agententeams umgesetzt und von wenigen Ingenieuren ausgerollt worden. Es ist in Rust geschrieben, mit einer Konformitäts-Testsuite und deterministischen Simulationstests, und GPT-6-Astra-Agenten schrieben Lean- und TLA+-Modelle, die Fehler fanden. Der Rollout begann mit Pando als lesender und schreibender Durchleit-Proxy zum alten System, sodass der Verkehr ohne Ausfall umzog. Der Beitrag sagt nicht, dass Pando außerhalb von OpenAI verfügbar ist.
OpenAI trägt auch zu Git selbst bei. Es behob Randfälle bei gleichzeitigen Pack-Downloads, beim Aufräumen nach abgebrochenen Übertragungen und beim Fortsetzen bereits abgeschlossener Downloads, fügte Tracing für packfile-uri-Downloads hinzu und führte „explicit haves“ ein, damit ein pushender Client --force-with-lease nutzen und sein Pack allein gegen den Trunk bauen kann. Einige Änderungen sind im Upstream-Git, andere in OpenAIs öffentlichem Fork. Bei der Erfassung war dieser Fork auf GitHub ein öffentlicher Fork von git/git, dessen Branch codex 115 Commits vor und 522 hinter dem master von git/git lag, mit einem jüngsten Merge, der nach der Wiederverwendung von packfile-uri benannt ist. Für Teams mit großen Monorepos liegt die Lehre im Kompromiss: Gelockerte Konsistenz über Branches hinweg brachte Schreibskalierung, und es funktionierte hier, weil Nutzer und Agenten auf die Reihenfolge der Aktualisierungen einer einzelnen Ref angewiesen sind und nicht auf eine globale Ordnung.
Sources
FAQ
Warum lockert Pando die Konsistenz?
Damit unabhängige Branches parallel geschrieben werden können. Pando hält Aktualisierungen einer einzelnen Ref serialisierbar, bietet über Branches hinweg aber nur kausale Konsistenz, sodass zwei Clients bei einem Clone zwei Branches in verschiedenen Versionen sehen können. OpenAI meint, Nutzer und Agenten hingen von der Reihenfolge einer Ref ab, nicht von einer globalen.
Sind „fast 80 %“ und „fast das Fünffache“ zwei verschiedene Verbesserungen?
Nein. Die Einleitung nennt für die mediane Push-Latenz fast das Fünffache, der Abschnitt zum Rollout fast 80 %; beides beschreibt etwa dieselbe Änderung, denn ein Rückgang auf ein Fünftel ist eine Senkung um rund 80 %. Es sind selbst berichtete Zahlen von OpenAI für das eigene Monorepo, keine unabhängigen Messungen.
Belegt die Simulation mit 1.000 Clients die Leistung im Betrieb?
Nein. Die Seite nennt sie synthetische Lehrmodelle und keine Produktions-Benchmarks, und nutzt sie, um Unterschiede zwischen Dreiphasen-Commit, Write-ahead-Log und Pando zu erklären. Die Betriebsaussagen stützen sich auf OpenAIs eigene Zahlen, und der Beitrag sagt nicht, dass Pando außerhalb von OpenAI angeboten wird.