OpenAI a reconstruit le backend Git de son monorepo pour suivre le rythme des agents Codex

OpenAI a publié un récit détaillé du remplacement du système qui sert son principal dépôt de code. Dans Scaling Git at OpenAI, daté du 2 novembre, Aaron Friel, Taylor Blau et Ted Nyman présentent Pando, un nouveau backend pour dépôts Git qui « alimente désormais tout le développement dans le monorepo d'OpenAI ». La raison invoquée est simple : le volume de travail en parallèle que permet Codex avait dépassé ce que l'ancienne infrastructure pouvait encaisser.

Le billet est arrivé en quelques heures en première page de Hacker News. Il intéresse bien au-delà d'OpenAI, car c'est l'une des premières descriptions détaillées, de première main, de ce que les agents de code font subir à la gestion de versions quand on les utilise à grande échelle.

Ce qui a cassé

Selon OpenAI, Codex permet à chaque ingénieur de mener beaucoup plus de travail en parallèle : plus de branches, plus de push, plus de merges et plus de fetch depuis les environnements de développement, les jobs de recherche et la CI. « Un ingénieur a désormais plusieurs changements prêts pour la CI en même temps, et chaque push peut déclencher plusieurs jobs qui récupèrent le même commit », écrivent les auteurs.

À partir de la fin 2025 environ, les systèmes derrière le monorepo « peinaient à suivre » : fetch et push lents, merges en échec, et une fiabilité « tombant parfois sous les 90 % », indique le billet. The New Stack rapporte que, d'après OpenAI, le nombre de commits trimestriels dans le monorepo aura progressé de plus de 2 400 % d'ici la fin de l'année par rapport au premier trimestre 2024.

L'équipe s'est demandé si elle avait atteint une limite de Git lui-même ou de la façon dont elle servait le dépôt. Sa réponse : la seconde. Elle a donc conservé le protocole et le client Git et reconstruit le côté serveur.

Comment fonctionne Pando

OpenAI explique que Pando renonce à deux choses que la plupart des serveurs Git considèrent comme indispensables.

Pas d'instantané global du dépôt. Les architectures classiques ordonnent toutes les mises à jour de références sur l'ensemble du dépôt, si bien qu'un push sur une branche peut attendre un push sur une branche sans rapport. Pando coordonne chaque branche indépendamment. La seule clé disputée est le pointeur de branche, protégé par une opération atomique de type compare-and-swap. OpenAI parle de cohérence causale : les mises à jour d'une même branche sont sérialisées, mais un client qui lit plusieurs branches peut les voir à des instants légèrement différents. « En pratique, les utilisateurs et les agents ne dépendent pas de l'ordre global des mises à jour de références », défendent les auteurs.

Pas de packfile sur mesure pour chaque client. Un serveur Git classique calcule, à chaque fetch, les objets qui manquent au client et compresse un nouveau packfile. Pando stocke au contraire chaque packfile poussé comme un blob immuable, enregistre chaque nouvelle tête de branche et ses dépendances dans une base de métadonnées, puis, au fetch, sélectionne les packs déjà stockés qui couvrent les besoins du client. Il renvoie des liens de téléchargement via packfile-uri, une fonction du protocole Git qui existe depuis longtemps mais reste peu utilisée, et un service de cache baptisé Express sert les octets depuis des caches régionaux, avec un taux de succès supérieur à 99 %.

Pour rendre les packs réutilisables, Pando n'annonce que la branche principale (trunk) quand un client pousse une nouvelle branche de fonctionnalité, au lieu de lister toutes les références. OpenAI précise qu'avec des millions de branches, la seule annonce complète des références peut dépasser 100 Mio. Contrepartie : les push répétés sur une même branche renvoient tout ce qui n'est pas sur trunk. Dans le monorepo d'OpenAI, le pack médian produit ainsi faisait moins de 20 Kio, et le 99e centile moins de 3 Mio.

Comme des milliers de petits packs par jour ralentiraient les clients, des workers en arrière-plan les fusionnent en « couvertures » plus grandes, un mécanisme que le billet compare au compactage des arbres LSM (log-structured merge-trees). Le monorepo utilise aujourd'hui jusqu'à quatre niveaux de couvertures, ce qui permet aussi à Pando de planifier un fetch en temps logarithmique selon le retard du client.

Les chiffres annoncés par OpenAI

Tous les chiffres ci-dessous viennent du billet d'OpenAI et n'ont pas été mesurés de façon indépendante :

• latence médiane des push divisée par près de 5 (le billet parle aussi d'une baisse de près de 80 %) ;
• près d'un pétaoctet de données Git servi par jour, « avec une poignée de cœurs CPU » ;
• plus de 57 téraoctets de packs servis en une seule heure, dont plus de 99 % depuis le cache disque local ;
• des clones et fetch qui saturent des liens à 10 Gbit/s sur des machines virtuelles cloud standard.

La simulation interactive du billet, qui compare Pando à des architectures à validation en trois phases et à journal d'écriture anticipée, est présentée par OpenAI comme des « modèles pédagogiques synthétiques, pas des benchmarks de production ».

Construit avec des agents, en 10 semaines

OpenAI affirme être passé du lancement à la production en 10 semaines, avec un cœur « conçu par un seul ingénieur, implémenté par des équipes d'agents et déployé par une poignée d'ingénieurs ». Pando est écrit en Rust et sert du trafic de production depuis avril. L'équipe a écrit une suite de tests de conformité Git pour que les agents puissent vérifier leurs modifications par rapport au comportement standard de Git, et a utilisé des tests par simulation déterministe pour débusquer des conditions de concurrence. Elle indique aussi que des agents sous GPT-6 Astra ont écrit des spécifications en Lean et TLA+ pour formaliser une « théorie de Pando », utilisée pour trouver des bugs et prouver des propriétés du système.

La migration s'est faite progressivement. Pando a d'abord tourné comme proxy en lecture et en écriture devant l'ancien système, et OpenAI distribue désormais sa propre version de Git sur les postes des développeurs et dans l'application ChatGPT pour ordinateur. Les développeurs pouvaient demander à Codex de migrer leurs environnements grâce à des skills dédiés.

Ce qui revient à Git, et ce qui reste chez OpenAI

OpenAI dit avoir renvoyé au projet Git des correctifs côté client, sur les téléchargements packfile-uri concurrents, le nettoyage après un transfert interrompu et un nouveau traçage, et que plusieurs sont déjà intégrés à Git. La série de patchs de Ted Nyman sur les téléchargements concurrents est publique sur la liste de diffusion de Git. D'autres changements, comme l'indexation des packs en parallèle et les « explicit haves », vivent pour l'instant dans le fork public de Git d'OpenAI, suivi sur une page d'état des patchs qui, lors de notre vérification, recensait 50 patchs destinés à Git et 92 commits appliqués par-dessus la version officielle.

Pando lui-même n'est pas open source. OpenAI dit seulement « étudier des moyens de partager la technologie qui rend Pando possible avec nos utilisateurs ». The New Stack note qu'Anthropic a aussi construit son propre système de gestion de versions, Scion, sans projet de le publier, et que des startups comme Entire ou le projet Origin de Cursor s'attaquent au même problème.

Ce que ça change pour les équipes qui utilisent des agents de code

Peu d'équipes ont le volume d'OpenAI, mais le schéma de panne décrit se retrouve à plus petite échelle. Quand chaque développeur fait tourner plusieurs agents, le goulot d'étranglement se déplace de l'écriture du code vers tout ce qui l'entoure : push simultanés, jobs de CI qui clonent le même commit, nombre de branches qui explose. Le diagnostic d'OpenAI : le client et le protocole Git ont tenu, l'architecture du serveur non.

Quelques enseignements concrets du billet :

• Surveiller la contention, pas seulement le stockage. Les systèmes qui ordonnent chaque écriture sur tout le dépôt font attendre des branches d'agents qui n'ont rien à voir entre elles.
• Les lectures se multiplient plus vite que les écritures. Un push peut déclencher plusieurs fetch ; pour OpenAI, mettre en cache des réponses identiques a compté davantage que réduire la taille de chaque pack.
• Rester sur Git a payé. Garder le protocole évitait de former à nouveau ingénieurs et agents, et chaque correctif côté client peut profiter à tout l'écosystème.

Reste à savoir si GitHub et les autres hébergeurs adopteront des compromis similaires, comme l'abandon de la cohérence globale du dépôt, avant que les équipes les plus équipées en agents ne se mettent à construire leurs propres backends.