OpenAI describió Pando el 2 de noviembre de 2026 como el backend compatible con Git que impulsa el desarrollo en su monorepo. La empresa afirma que redujo casi un 80 % la latencia mediana de los envíos (push) en producción. Pando empezó a servir tráfico de producción en abril de 2026, tras unas diez semanas de desarrollo, según la explicación técnica de OpenAI.

Qué cambia Pando en el trabajo con Git

Pando sustituye la infraestructura que almacena y sirve los repositorios de OpenAI, pero conserva la compatibilidad con el protocolo y el cliente de Git. Según la empresa, sus equipos pudieron mantener el flujo de trabajo habitual. El sistema está pensado para gestionar muchas operaciones simultáneas sobre el monorepo, el repositorio central que reúne el desarrollo de la compañía.

Cómo procesa los envíos y las descargas

En un push, Pando valida los paquetes entrantes de objetos Git mientras los transmite al almacenamiento de blobs. Por separado, registra en un almacén de metadatos las versiones de las referencias, como las ramas, y actualiza sus punteros. Así evita descomponer cada paquete en un repositorio local para procesarlo.

En un fetch, la operación con la que un cliente obtiene objetos que le faltan, Pando selecciona paquetes ya almacenados según el historial del cliente y devuelve sus URI. Express los sirve a través de cachés regionales. La reutilización evita tener que generar un paquete a medida para cada lectura. En segundo plano, Pando agrupa paquetes pequeños en coberturas de hasta nivel L4 en el monorepo de OpenAI, para reducir cuántos paquetes hay que recuperar y facilitar la planificación de las descargas.

El diseño también tiene un coste concreto en algunas ramas. Cuando un cliente publica una rama de funcionalidad nueva, Pando suele anunciar como base solo una rama principal designada. Esto facilita reutilizar paquetes y evita que la lista de ramas anunciadas crezca con el repositorio, pero los envíos repetidos a ramas de funcionalidad o las ramas encadenadas pueden volver a transmitir objetos que no están en esa base. En el monorepo de OpenAI, la mediana de esos paquetes fue inferior a 20 KiB y el percentil 99, inferior a 3 MiB.

Qué consistencia ofrece entre ramas

Pando serializa las actualizaciones de cada referencia individual, mientras permite actualizar en paralelo referencias distintas. Eso preserva un orden de cambios por rama, pero una lectura que abarca varias ramas no tiene por qué mostrar todas en el mismo instante. Por tanto, consultar varias ramas no equivale a obtener una única instantánea sincronizada de todo el repositorio.

Qué significan las cifras de rendimiento

OpenAI atribuye a Pando casi un 80 % menos de latencia mediana de push en producción y casi un petabyte de datos Git servido al día. La empresa también informa de más de 57 TB de paquetes servidos durante una hora de máxima actividad; más del 99 % de los bytes de esa hora procedieron de caché de disco local. Son resultados comunicados para el sistema y la carga de trabajo de OpenAI. La compañía añade que operaciones validadas de clonación y fetch saturaron enlaces de 10 Gbps en máquinas virtuales estándar de proveedores de nube.

La comparación interactiva de arquitecturas que presenta OpenAI contrapone Pando con modelos de confirmación en tres fases y de registro de escritura anticipada en almacenamiento de objetos. La empresa la identifica como una simulación sintética con fines didácticos, no como un benchmark de producción. Sus resultados ilustran esos modelos, no constituyen mediciones comparativas de rendimiento en producción.

Qué ha dicho OpenAI sobre compartir Pando

OpenAI describe Pando como un sistema interno y dice que explora formas de compartir la tecnología que lo hace posible, sin anunciar una fecha ni un formato para distribuir el propio backend. Algunas mejoras de Git surgidas durante el trabajo ya están incorporadas al proyecto Git; otras están en el repositorio público de OpenAI.