OpenAI détaille Pando, son serveur Git : la cohérence causale permet d'écrire à l'échelle par branche, latence médiane des pushs en baisse de près de 80 % selon OpenAI, mais la simulation est pédagogique et Pando n'est pas proposé à l'extérieur

Le 2 novembre 2026, trois ingénieurs d'OpenAI, Aaron Friel, Taylor Blau et Ted Nyman, ont publié « Scaling Git at OpenAI ». L'article décrit Pando, un nouveau serveur pour dépôts Git qui alimente désormais tout le développement du monorepo d'OpenAI. La raison, écrivent-ils, est Codex : les ingénieurs mènent beaucoup plus de travaux en parallèle, ce qui signifie plus de branches, de pushs, de fusions, de fetchs et de clones depuis les environnements de développement, les tâches de recherche et l'intégration continue. À partir de la fin de l'année dernière, les anciens systèmes ont peiné, avec des fetchs et des pushs lents, des fusions échouées et une fiabilité parfois inférieure à 90 %.

Pando conserve le protocole et le client Git, si bien que ingénieurs et agents n'ont pas changé leur façon de travailler. Il vise deux objectifs : des écritures qui passent à l'échelle horizontalement sur de nombreuses branches, et des lectures assez rapides pour saturer la liaison réseau du client. Pour les écritures, Pando stocke chaque packfile reçu comme un blob immuable et consigne une « version de ref » dans un magasin de métadonnées. Les mises à jour de branches sans lien avancent indépendamment, et seul un push vers la même ref entre en conflit. Pour les lectures, il réutilise des packfiles stockés au lieu de construire un pack sur mesure pour chaque client, et renvoie des URI de packfiles servies par des caches régionaux.

Les auteurs comparent cette approche à deux conceptions courantes qu'ils ont modélisées : la validation en trois phases entre réplicas complets, où chaque push demande plusieurs allers-retours et où les disques des réplicas se trouvent sur le chemin d'écriture, et un journal d'écriture anticipée partagé dans un stockage d'objets, où chaque push se dispute la mise à jour d'un même manifeste. Leur simulation interactive, avec 1 000 clients, montre que la première ralentit les écritures et la seconde les lectures sous charge. La page présente cette simulation comme des modèles pédagogiques synthétiques, pas des mesures de production : elle explique la conception sans prouver les chiffres de production.

Les affirmations de production sont précises. Le passage à Pando a amélioré la fiabilité des fusions et réduit la latence médiane des pushs de près de 80 %, ce que l'introduction formule comme près de 5 fois. Pando livre près d'un pétaoctet de données Git par jour, a servi plus de 57 téraoctets de packs en une heure dont plus de 99 % des octets depuis le cache disque local, et a saturé en validation des liaisons de 10 Gbit/s sur des machines virtuelles cloud standard. Express, le service de distribution de packs, annonce des taux de succès du cache supérieurs à 99 %. Ce sont les chiffres d'OpenAI pour un seul monorepo, sans mesure indépendante ni comparaison en production avec un autre système.

L'article est franc sur les compromis. Pando offre une cohérence causale, pas une vue instantanée de toutes les refs : pendant un clone, deux clients peuvent voir deux branches à des versions différentes, tandis que les mises à jour d'une même ref restent sérialisables. Pour garder les packs réutilisables, Pando ne publie par défaut qu'une branche principale désignée lors d'un push, de sorte que des pushs répétés vers une même branche de fonctionnalité, ou des branches empilées, renvoient plus de données. Dans le monorepo d'OpenAI, le pack médian ainsi produit faisait moins de 20 Kio et le 99e centile moins de 3 Mio. Pando conserve aussi des packs à chaque niveau de compactage, jusqu'à L4, pour que la planification d'un fetch soit logarithmique au lieu de milliers de petits téléchargements.

Sur la construction, les auteurs disent que Pando est passé du lancement à la production en 10 semaines, a servi du trafic de production dès avril, et que son cœur a été conçu par un seul ingénieur, implémenté par des équipes d'agents et déployé par une poignée d'ingénieurs. Il est écrit en Rust, avec une suite de tests de conformité et des tests de simulation déterministes, et des agents GPT-6 Astra ont écrit des modèles Lean et TLA+ qui ont trouvé des bogues. Le déploiement a commencé avec Pando comme proxy en lecture et écriture vers l'ancien système, ce qui a permis de déplacer le trafic sans interruption. L'article ne dit pas que Pando soit disponible hors d'OpenAI.

OpenAI contribue aussi à Git lui-même. Elle a corrigé des cas limites dans les téléchargements de packs concurrents, le nettoyage après des transferts interrompus et la reprise de téléchargements déjà terminés, ajouté du traçage pour les téléchargements packfile-uri, et ajouté des « explicit haves » pour qu'un client qui pousse puisse utiliser --force-with-lease et construire son pack par rapport à la seule branche principale. Plusieurs changements sont dans Git en amont et d'autres dans le fork public d'OpenAI. Lors de la capture, ce fork sur GitHub était un fork public de git/git dont la branche codex avait 115 commits d'avance et 522 de retard sur la branche master de git/git, avec une fusion récente nommée d'après la réutilisation de packfile-uri. Pour les équipes qui exploitent de grands monorepos, la leçon est le compromis : relâcher la cohérence entre branches a permis de passer à l'échelle en écriture, et cela a fonctionné ici parce que les utilisateurs et les agents dépendent de l'ordre des mises à jour d'une seule ref, pas d'un ordre global.