Pando: OpenAI baut Git-Server seines Monorepos neu, um mit seinen Agenten Schritt zu halten
OpenAI hat am 2. November Pando vorgestellt, ein neues Git-kompatibles Backend, das seit April das gesamte Monorepo des Unternehmens bedient. Entwickelt, um die parallelen Push-Vorgänge von Codex zu bewältigen, soll es die mediane Push-Latenz um fast das Fünffache gesenkt haben. Es wurde innerhalb von zehn Wochen größtenteils von Agenten gebaut.

OpenAI hat am 2. November 2026 Pando vorgestellt, ein neues Backend für Git-Repositories, das ab sofort das gesamte Monorepo bedient. Der Ausgangspunkt ist eine direkte Folge von Programmieragenten: Mit Codex pusht jeder Ingenieur mehrere Branches parallel, jeder Push löst mehrere Continuous-Integration-Aufgaben aus, die denselben Commit abrufen, und das bisherige System konnte nicht mehr mithalten. Dem Beitrag zufolge sank die Zuverlässigkeit ab Ende 2025 zeitweise auf unter 90 Prozent, mit langsamen Fetches und fehlgeschlagenen Merges.
Abkehr von zwei Gewohnheiten bei Git-Servern
Statt Git aufzugeben, behielt das Team Protokoll sowie Client bei und überdachte zwei Annahmen, die die meisten Git-Server als selbstverständlich voraussetzen.
- Kein konsistenter Snapshot des gesamten Repositories. Pando koordiniert jeden Branch separat: Zwei Pushes auf unterschiedliche Branches müssen nicht mehr aufeinander warten. Nur gleichzeitige Schreibvorgänge auf demselben Branch führen zu Konflikten. Der bewusste Kompromiss: Ein Client, der mehrere Branches liest, sieht diese unter Umständen zu leicht versetzten Zeitpunkten. OpenAI geht davon aus, dass sowohl Menschen als auch Agenten in der Praxis nur von der Reihenfolge der Aktualisierungen innerhalb ein und desselben Branches abhängen.
- Keine maßgeschneiderte Packfile für jeden Client. Anstatt für jeden Fetch ein Paket von Objekten neu zu berechnen, speichert Pando die bei einem Push empfangene Packfile unverändert und stellt sie anderen Clients über
packfile-urizur Verfügung, eine selten genutzte Funktion des Git-Protokolls. Um diese Pakete wiederverwendbar zu machen, kündigt es dem pushenden Client standardmäßig nur einen einzigen Referenz-Branch (den Trunk) an.
Die Pakete lagern in einem Objektspeicher, die Metadaten in einer verteilten Datenbank, und ein regionaler Caching-Dienst namens Express verteilt sie. Eine Hintergrundkomprimierung, inspiriert von LSM-Trees, fasst kleinere Pakete in aufeinanderfolgenden Ebenen zusammen (derzeit bis zu L4).
Die genannten Zahlen
| Kennzahl (laut OpenAI) | Wert |
|---|---|
| Mediane Push-Latenz | um fast das Fünffache verringert |
| Bereitgestellte Git-Daten | fast ein Petabyte pro Tag |
| Spitzenwert | mehr als 57 TB in einer Stunde bedient |
| Trefferquote des Express-Caches | über 99 Prozent |
| Klon-Durchsatz auf Standard-Cloud-VMs | Sättigung von 10-Gbit/s-Verbindungen |
Von OpenAI veröffentlichte Zahlen, nicht von Dritten gemessen.
In zehn Wochen gebaut – von Agenten
Der aufschlussreichste Abschnitt betrifft die Umsetzung. Pando wurde von einem einzelnen Ingenieur entworfen, von Agententeams implementiert und von einer Handvoll Personen bereitgestellt – innerhalb von zehn Wochen vom Projektstart bis zur Produktion; es bedient seit April 2026 den Produktivverkehr. Das in Rust geschriebene System stützt sich auf eine Git-Konformitätstestsuite, mit der die Agenten ihre Änderungen überprüften, auf deterministische Simulationstests sowie auf Lean- und TLA+-Spezifikationen, die von Agenten mittels GPT-6 Astra verfasst wurden, um Fehler aufzuspüren. Die Migration selbst erfolgte unterbrechungsfrei über einen Proxy, und Codex unterstützte die Teams bei der Umstellung ihrer Umgebungen.
OpenAI gibt an, mehrere Korrekturen in das Upstream-Git-Projekt eingebracht zu haben (parallele Paket-Downloads, Traces für packfile-uri, das Konzept der „explicit haves“) und nach Wegen zu suchen, Pando für seine Nutzer bereitzustellen – bislang ohne konkrete Ankündigung.
Unsere Einschätzung
Pando offenbart eine wenig beachtete Konsequenz von Programmieragenten: Der Engpass liegt nicht mehr allein bei der Rechenleistung der Modelle, sondern bei den umliegenden Werkzeugen – allen voran dem Git-Server. Die Entscheidung, kompatibel mit Git zu bleiben, statt ein völlig neues Werkzeug zu erfinden, ist pragmatisch, und die Upstream-Beiträge können der gesamten Community zugutekommen. Die gemeldeten Leistungssteigerungen sind spektakulär, lassen sich von außen jedoch nicht überprüfen, und die Simulationen im Blogbeitrag sind ausdrücklich didaktischer Natur. Für Teams, die den Einsatz von Agenten massiv ausbauen, liegt die Lehre vor allem in der Architektur: die globale Konsistenz des Repositories aufweichen und Pakete konsequent wiederverwenden. Sollte OpenAI Pando letztlich seinen Kunden anbieten, träte das Unternehmen in direkte Konkurrenz zu GitHub und anderen Plattformen.
Quellen
- OpenAI — Scaling Git at OpenAI (2. November 2026) Primärquelle
- OpenAI Developers auf X — Ankündigung von Pando (3. November 2026) Primärquelle
- The New Stack — OpenAI built itself a new Git backend, too Sekundärquelle
Eine Primärquelle stammt direkt von dem betreffenden Unternehmen, Labor oder der Organisation. Eine Sekundärquelle gibt die Information wieder, ohne ihr Urheber zu sein: Wir kennzeichnen sie als solche. Einen Fehler entdeckt? Lesen Sie unsere Korrekturrichtlinie.


