Dans un billet publié le 2 novembre 2026, OpenAI a présenté Pando, son backend Git interne pour le monorepo, et lui a attribué une baisse de près de 80 % de la latence médiane des push en production. Le système, qui a commencé à traiter du trafic de production en avril 2026 après environ dix semaines de développement, conserve la compatibilité avec le protocole et le client Git. Les équipes d’OpenAI ont donc pu garder leurs habitudes de travail, selon l’entreprise. Le billet technique d’OpenAI décrit le fonctionnement de Pando et les résultats que la société lui attribue.

Comment Pando traite les push et les fetch

Lors d’un push, c’est-à-dire l’envoi de modifications vers le dépôt, Git regroupe des objets dans un fichier appelé pack. Pando le valide tout en le transmettant au stockage d’objets, sans le décompresser dans un dépôt local. Un stockage de métadonnées conserve les versions des références Git, qui désignent notamment les branches, et leurs dépendances.

Pour un fetch, l’opération qui récupère les objets nécessaires au client, Pando tient compte des commits que celui-ci connaît déjà et de ceux qu’il demande. Le système choisit des packs existants qui couvrent les objets manquants, puis fournit leurs adresses. Express et des caches régionaux servent les fichiers. Réutiliser des packs évite d’en fabriquer un nouveau sur mesure pour chaque lecteur.

Une compaction en arrière-plan regroupe aussi des packs en ensembles plus larges, appelés covers. OpenAI indique que ceux de son monorepo vont jusqu’au niveau L4. Cette organisation réduit le nombre de packs à récupérer et permet de mieux maîtriser le travail nécessaire pour préparer un fetch quand le client a pris du retard.

Ce choix a un compromis. Lors d’un push vers une nouvelle branche de fonctionnalité, Pando annonce généralement une branche principale désignée, appelée trunk, plutôt que toutes les branches. Cela limite la taille de l’annonce à traiter et facilite la réutilisation des packs. En revanche, des push répétés sur une branche de fonctionnalité, ou des branches empilées, peuvent renvoyer des objets absents du trunk. Dans le monorepo d’OpenAI, avec cette méthode, le pack médian faisait moins de 20 KiB et le 99e centile moins de 3 MiB.

Les branches avancent en parallèle, sans instantané global garanti

Pando sérialise les mises à jour d’une référence donnée, tout en permettant à des références différentes d’être mises à jour en parallèle. Une lecture qui couvre plusieurs branches peut donc réunir des états observés à des moments différents. Elle ne garantit pas une vue unique du dépôt à un instant précis.

La distinction compte surtout pour les opérations qui consultent plusieurs branches à la fois : l’ordre des mises à jour est assuré référence par référence, pas au moyen d’un instantané global simultané du monorepo.

Les performances annoncées par OpenAI

OpenAI rapporte près de 80 % de baisse de la latence médiane des push en production. L’entreprise dit aussi que Pando sert près d’un pétaoctet de données Git par jour. Lors d’une heure de pointe, plus de 57 téraoctets de packs ont été servis, et plus de 99 % des octets de cette période provenaient du cache disque local.

OpenAI rapporte également que des opérations validées de clonage et de fetch ont saturé les liaisons à 10 Gbit/s de machines virtuelles cloud standard. Ces chiffres décrivent le système et la charge de travail de l’entreprise.

La comparaison interactive d’architectures publiée par OpenAI est présentée comme un modèle synthétique à visée pédagogique, et non comme un benchmark de production. Elle illustre les compromis modélisés entre Pando, un modèle de validation en trois phases et une approche fondée sur un journal d’écriture anticipée dans un stockage d’objets ; elle ne mesure pas leurs performances en production.

Ce qu’OpenAI dit du partage de Pando

Dans son billet, OpenAI présente Pando comme un système interne et dit étudier des moyens de partager la technologie qui le rend possible, sans annoncer de date ni de format de diffusion pour Pando. L’entreprise indique par ailleurs que certaines améliorations issues de ce travail sont déjà intégrées au projet Git et que d’autres figurent dans son dépôt public.