OpenAI ha presentado Pando, su innovador backend Git diseñado para gestionar el crecimiento masivo de commits dentro de su monorepositorio. Según la compañía, esta nueva tecnología ha reducido la latencia al hacer push en casi cinco veces y actualmente procesa cerca de un petabyte de datos Git diariamente, atendiendo la intensa demanda interna generada por sus desarrolladores y agentes automatizados.
Con una adopción acelerada de herramientas de codificación basadas en agentes, OpenAI proyecta que, para finales de 2026, el número de commits trimestrales en su monorepositorio habrá aumentado en más de un 2.400% en comparación con el primer trimestre de 2024. Esta explosión de actividad ha evidenciado que el propio Git comienza a ser un cuello de botella, un desafío que comparten plataformas como GitHub, donde se están enfocando en optimizar infraestructura para soportar miles de millones de pull requests mensuales.
Este contexto ha impulsado el nacimiento de startups y proyectos que intentan evolucionar Git para estos nuevos tiempos, entre ellos Entire, fundado por el ex-CEO de GitHub Thomas Dohmke, y Origin, de la empresa Cursor. Mientras que algunos, como OpenAI, optan por evolucionar Git conservando compatibilidad, otros como Anthropic presentan alternativas radicales, redefiniendo clientes y arquitecturas desde cero. 
La decisión de OpenAI: mantener la compatibilidad con Git
Según los ingenieros de OpenAI Aaron Friel, Taylor Blau y Ted Nyman, el principal reto fue discernir si el límite estaba en el protocolo Git o en la forma en que se gestionaba el monorepo. Al analizarlo, concluyeron que era la arquitectura de los servidores Git convencionales la que limitaba el rendimiento, no el cliente ni el protocolo en sí, aunque implementaron ciertos ajustes. Por esta razón, decidieron continuar dentro del ecosistema Git, aprovechando dos décadas de herramientas adaptadas para esta tecnología.
¿Cómo funciona Pando?
Pando introduce dos cambios fundamentales respecto a la mayoría de servidores Git. Primero, prescinde de mantener todas las ramas de un repositorio en un estado consistentemente sincronizado. Segundo, evita construir un packfile personalizado para cada cliente que realiza una petición de código.
En Git, cada rama simplemente apunta a un commit reciente, y el movimiento de este puntero requiere coordinación y bloqueo para evitar conflictos. Sin embargo, los servidores tradicionales ordenan estos cambios a nivel global en todo el repositorio, lo que genera colas cuando muchos desarrolladores trabajan simultáneamente y pueden bloquearse unos a otros.
Pando gestiona cada rama de forma independiente, lo que significa que los pushes a ramas distintas pueden procesarse en paralelo sin esperar mutuamente. El equipo reconoce que esto implica que clientes que consulten varias ramas a la vez podrían verlas en estados ligeramente desincronizados, pero argumentan que para la mayoría de usuarios y agentes lo importante es mantener la coherencia en el orden de actualizaciones de cada rama individual.
Cuando un cliente hace un push, Pando valida el packfile mientras se transfiere directamente a un almacenamiento de blobs, sin necesidad de descomprimirlo localmente. Registra la nueva referencia de la rama, la ubicación del packfile y sus dependencias en un sistema de metadatos. Por defecto, solo se publicita la rama principal (trunk) como base para los pushes de ramas de características, permitiendo reutilizar packs por varios clientes que ya poseen la historia conocida.
En las peticiones de fetch, Pando selecciona los packs guardados que necesita el cliente con base en su historial actual, usando la funcionalidad packfile-uri del protocolo Git para enviar enlaces de descarga. Para servir estas descargas, utilizan un servicio de caché regional llamado Express, que logra un ratio de acierto superior al 99%, permitiendo alcanzar velocidades de clonación y fetchs que saturan una conexión de 10 Gbps en máquinas virtuales estándar en la nube.
Además, para evitar que los clientes descarguen miles de packs pequeños diariamente, Pando cuenta con procesos en segundo plano que fusionan estos packs en otros más grandes, similar a la compactación usada en bases de datos log-estructuradas. Esto también permite que Pando identifique qué packs necesita un cliente en tiempo logarítmico, mejorando la eficiencia.
Comparativa entre Pando y servidores Git tradicionales
En los servidores Git tradicionales, al hacer fetch se debe determinar qué objetos le faltan al cliente y construir un packfile nuevo específicamente para esa petición — un proceso costoso y poco fácil de cachear. En cambio, Pando sirve datos ya existentes, lo que reduce costos y aumenta la rapidez.
Para un push, los servidores tradicionales deben enviar una lista de todas las ramas para ayudar al cliente a evitar enviar objetos ya presentes en el servidor. Esta lista puede superar los 100 MiB cuando hay millones de ramas. Pando mantiene esta información reducida limitándose a publicitar solo la rama principal. Aunque esa decisión implica que los pushes repetidos a la misma rama deban enviar datos no presentes en trunk, OpenAI considera que es un compromiso razonable, ya que el packfile mediano en su monorepo es inferior a 20 KiB.
Otra diferencia clave es que servidores clásicos tienen que llevar a cabo repackaging y recolección de basura para mantener la velocidad, lo que consume recursos computacionales y de I/O. Pando no elimina ninguno de los packs, lo que permite servir packs de diferentes niveles de compactación sin afectar la rapidez.
Para los desarrolladores, la experiencia no cambia: continúan usando comandos Git estándares, aunque OpenAI proporciona su propia versión personalizada de Git en los equipos de desarrollo y en la aplicación de escritorio de ChatGPT.
El desarrollo de Pando en Rust tomó diez semanas, liderado por un ingeniero principal con el apoyo de equipos de agentes Codex que contribuyeron a su implementación. La herramienta está en producción desde abril de 2026.
Contribuciones a Git y código abierto
Al construir sobre Git, OpenAI ha encontrado varias áreas para mejorar el cliente y el protocolo, y ha enviado múltiples correcciones al proyecto oficial. Por ejemplo, Pando depende en gran medida de packfile-uri, una extensión propuesta por un ingeniero de Google en 2019, por lo que el equipo tuvo que reparar la gestión de descargas concurrentes, la limpieza tras interrupciones y la reanudación de paquetes ya descargados. También añadieron trazabilidad para facilitar la identificación de cuellos de botella en transferencias.
Varias de estas mejoras ya forman parte del código fuente oficial de Git, aunque otras permanecen en el repositorio público de OpenAI, que incluye funcionalidades como la descarga e indexación paralela de packs y una característica «explicit haves» para optimizar la comunicación entre servidor y cliente durante los pushes. OpenAI mantiene un rastreador público de los parches propuestos.
No obstante, Pando como tal no es software abierto; OpenAI no ha liberado el código de este backend y solo indica que estudia formas de compartir esta tecnología con su comunidad de usuarios. Situación similar aplica Anthropic con su sistema Scion, que tampoco planean publicar.
