Em 2 de novembro de 2026, a OpenAI descreveu o Pando como o backend Git interno que alimenta o desenvolvimento em seu monorepo, um repositório compartilhado pela empresa. A OpenAI relata que, em produção, a latência mediana de push caiu quase 80%. O sistema mantém compatibilidade com o protocolo e o cliente Git, enquanto reorganiza a forma de armazenar e distribuir os dados. Veja a explicação técnica da OpenAI sobre o Pando.

A empresa afirma que o Pando começou a receber tráfego de produção em abril de 2026, após cerca de dez semanas de desenvolvimento. A OpenAI relaciona a demanda por mais branches, pushes, clones e fetches ao aumento do trabalho paralelo que o Codex tornou possível em suas equipes.

Como o Pando processa push e fetch

No Git, uma referência, ou ref, é um ponteiro para um commit, como uma branch. Ao receber um push, o Pando valida o packfile, arquivo que reúne objetos do Git em formato compactado, enquanto o transmite ao armazenamento de blobs. Em paralelo, registra no armazenamento de metadados a versão da referência, suas dependências e a atualização do ponteiro da branch.

No fetch, o sistema considera o histórico que o cliente já tem e seleciona packs armazenados que cobrem os objetos necessários. Ele devolve os endereços desses arquivos, e o Express os entrega por meio de caches regionais. Assim, o servidor pode reutilizar packs entre clientes, em vez de gerar um arquivo sob medida para cada fetch.

A compactação em segundo plano agrupa packs menores em coberturas maiores, chamadas covers, que chegam ao nível L4 no monorepo da OpenAI. Elas reduzem a quantidade de arquivos que um cliente precisa buscar e ajudam o sistema a planejar a entrega quando há muitas atualizações acumuladas.

Há um custo específico nessa estratégia. Ao enviar uma nova branch de funcionalidade, o Pando anuncia como base apenas uma branch principal designada, chamada trunk. Isso mantém o anúncio de referências independente do número crescente de branches e facilita a reutilização dos packs. Mas, em envios repetidos para a mesma branch ou em branches empilhadas, o cliente pode reenviar objetos que não estão na trunk. No monorepo da OpenAI, os packs gerados com essa configuração tiveram mediana abaixo de 20 KiB e percentil 99 abaixo de 3 MiB.

Atualizações paralelas não criam uma fotografia única do repositório

O Pando ordena as atualizações de cada referência individualmente. Por isso, pushes para branches sem relação entre si podem avançar em paralelo; atualizações concorrentes para a mesma referência continuam ordenadas.

A consequência aparece em leituras que abrangem várias branches: elas não têm garantia de representar o estado do repositório em um único instante. Se duas branches forem atualizadas durante um clone, por exemplo, um cliente pode observar uma versão nova de uma e uma versão anterior da outra. Outro cliente pode ver a combinação inversa. A OpenAI diz que seus usuários dependem da ordem de atualização de cada referência, não de uma visão global sincronizada de todas as branches.

O que significam os números divulgados pela OpenAI

Além da queda de latência mediana de push, a empresa relata que o Pando entrega quase 1 petabyte de dados Git por dia. Em uma hora de pico, serviu mais de 57 TB de packs, com mais de 99% dos bytes atendidos pelo cache local em disco. A OpenAI também diz que operações validadas de clone e fetch saturaram links de 10 Gbps em máquinas virtuais padrão de provedores de nuvem.

Esses números descrevem a operação da OpenAI. A comparação interativa da empresa entre o Pando, um modelo de commit em três fases e um modelo de log de gravação antecipada (write-ahead log, ou WAL) é identificada como uma simulação sintética para fins didáticos, não como benchmark de produção. Ela ilustra os modelos de arquitetura; as métricas de desempenho são resultados que a própria OpenAI relata para seu sistema.

O que a OpenAI diz sobre compartilhar o Pando

A OpenAI descreve o Pando como um sistema interno e diz que está explorando maneiras de compartilhar a tecnologia que o viabiliza. A empresa também afirma que algumas melhorias identificadas durante o trabalho já foram incorporadas ao Git upstream, enquanto outras estão em seu repositório público.