Los commits en la rama principal del monorepo de OpenAI crecieron un 1.378 % entre el primer trimestre de 2024 y el tercero de 2026, y la culpa es sobre todo de Codex. Con ese volumen, el backend de Git anterior llegó a bajar a veces del 90 % de fiabilidad. La respuesta, publicada el 2 de noviembre de 2026, se llama Pando: un backend compatible con Git que recorta casi un 80 % la latencia mediana de un push sin pedir a nadie que cambie de cliente.
Lo interesante es el contraste. En octubre de 2026, Anthropic contó que había resuelto el mismo problema abandonando Git en su monorepo. Dos laboratorios, la misma causa (los agentes escriben mucho más código que las personas) y dos respuestas opuestas.
El problema: Git no se diseñó para miles de agentes empujando a la vez
Un servidor Git clásico trata el repositorio como una unidad con un orden global: cada actualización de referencias se serializa contra todas las demás. Con equipos humanos eso apenas se nota. Con agentes que abren ramas, empujan y fusionan sin descanso, esa serialización se convierte en la cola en la que espera todo el mundo. La otra mitad del problema son las lecturas: cada clon o fetch obliga al servidor a calcular un packfile a medida, y el CI y los agentes clonan constantemente.
OpenAI no publica pushes por segundo ni número de escritores concurrentes. Sí da la curva de crecimiento, y su estimación para el cuarto trimestre de 2026 sube al 2.442 %.
La solución: consistencia causal y packfiles reutilizables
Pando reemplaza el lado servidor y deja intactos el protocolo y los clientes. Las dos decisiones clave:
- Consistencia causal en lugar de consistencia de todo el repositorio. Los pushes a referencias distintas avanzan en paralelo; solo los que apuntan a la misma referencia se ordenan entre sí. El precio es explícito: un cliente que lee varias ramas no puede asumir que todas reflejan el mismo instante del repositorio.
- Lecturas servidas desde caché. En vez de generar un packfile por cliente, Pando reutiliza packfiles ya calculados, de modo que puede entregar los mismos bytes a muchos clientes con muy poco cálculo.
Está escrito en Rust y pasó del arranque a producción en unas 10 semanas: recibe tráfico real desde abril de 2026. El diseño del núcleo fue de un solo ingeniero, la implementación la hicieron equipos de agentes con Codex y el despliegue, un puñado de ingenieros.
Los resultados que publica OpenAI:
| Métrica | Pando |
|---|---|
| Latencia mediana de push | casi un 80 % menor que el backend anterior |
| Datos Git servidos | cerca de 1 PB al día |
| Pico | más de 57 TB de packs en una hora |
| Servido desde disco local | más del 99 % de ese pico |
Pando frente a Scion: compatibilidad o reescritura
Anthropic midió su problema con otras cifras: de 2.500 merges al día en mayo a más de 30.000 en septiembre, un historial de la rama principal de casi 100 GB y unos 25 millones de checkouts de CI al día. Su respuesta, Scion, es un sistema de control de versiones nuevo que lleva el trabajo al servidor: los commits se hacen allí y cada checkout solo baja los directorios que pide, con los ficheros descargados a medida que se leen. Adoptarlo obliga a sustituir también la revisión de código, la búsqueda de código y el CI.
| Pando (OpenAI) | Scion (Anthropic) | |
|---|---|---|
| Relación con Git | Mantiene clientes y protocolo | Sistema nuevo; sustituye también revisión, búsqueda y CI |
| Escrituras | Consistencia causal: pushes en paralelo por referencia | Los commits se hacen en el servidor |
| Lecturas | Packfiles cacheados, más del 99 % desde disco local | Checkouts parciales; los ficheros se bajan al leerlos |
| Equipo y plazo | 1 ingeniero de diseño, agentes y unos pocos para desplegar; 10 semanas | Un equipo pequeño con mucho Claude; unos 5 meses |
| Resultado destacado | Push mediano casi un 80 % más rápido | 200 veces menos CPU y memoria que la flota de espejos Git |
| Código publicado | No | No |
Son dos apuestas distintas. OpenAI paga el coste de mantener la semántica de Git en el servidor a cambio de no tocar ni una herramienta, un IDE o un pipeline. Anthropic paga una migración de todo el ciclo de desarrollo a cambio de que ningún cliente tenga que clonar el repositorio entero. Las dos coinciden en lo esencial: a esta escala, lo caro es mover bytes repetidos, y gana quien deja de calcularlos o de enviarlos para cada cliente.
Qué se puede aprender
La lección que más me interesa es la de la consistencia. Casi nadie necesita que todas las ramas de un repositorio avancen en un orden global; lo que necesitas es que cada rama tenga un orden. Relajar esa garantía es lo que convierte un cuello de botella en un sistema que escala añadiendo máquinas, y la idea vale igual para una cola, un almacén de configuración o un registro de artefactos.
La segunda es medir antes de que duela. Si tu equipo empieza a delegar tareas en agentes, el número de pushes, fetches y ejecuciones de CI no va a crecer con la plantilla, sino con las sesiones de agente abiertas. Vigilar la latencia de push y la cola del CI con la misma atención que la de un servicio de producción es lo que te avisa a tiempo.
Y la tercera: la compatibilidad tiene un valor enorme. Pando llegó a producción en 10 semanas en parte porque no tuvo que convencer a nadie de cambiar de herramienta.
Qué no es trasladable
Ninguno de los dos sistemas es código abierto, y ninguna de las dos empresas ha publicado una guía de despliegue. Las cifras son las que da cada laboratorio, sin un banco de pruebas independiente. Para un monorepo de unos pocos gigas con decenas de ingenieros, un Git alojado con clones parciales y un CI que reutilice cachés sigue siendo suficiente; esto solo empieza a importar cuando los agentes multiplican por diez tus escrituras.
Fuentes
- Scaling Git at OpenAI (OpenAI, 2 de noviembre de 2026)
- OpenAI details Pando Git backend after Codex commit surge (AI Weekly, 3 de noviembre de 2026)
- Scaling Git at OpenAI (daily.dev)
- Why Anthropic replaced Git, and whether you'll need to (Arize, octubre de 2026)