Pando di OpenAI: il backend Git che riduce di cinque volte la latenza dei push

Quando a scrivere codice non sono più solo gli sviluppatori ma anche centinaia di agenti che lavorano in parallelo, anche il sistema che custodisce quel codice entra in crisi. È quello che è successo a OpenAI, che ha deciso di non aspettare che Git si adattasse e ha costruito da sé il backend per il proprio monorepo. Si chiama Pando, è scritto in Rust ed è già in produzione.

Il dato che colpisce di più riguarda i push: la latenza mediana è scesa di quasi cinque volte, circa l’80% in meno. Vediamo che cosa è successo davvero e perché la storia interessa anche a chi non lavora in un grande laboratorio.

Che cos’è Pando e perché OpenAI lo ha costruito

Pando è un backend compatibile con Git progettato per servire il monorepo principale di OpenAI. Gli sviluppatori continuano a usare i normali comandi Git, mentre dietro le quinte cambia completamente il modo in cui il server gestisce branch, pacchetti di oggetti e richieste di fetch. La descrizione tecnica pubblicata da OpenAI porta la firma di Aaron Friel, Taylor Blau e Ted Nyman.

Il motivo è semplice da enunciare e difficile da gestire. Secondo OpenAI, i commit trimestrali sul monorepo saranno cresciuti di oltre il 2.400% entro fine anno rispetto al primo trimestre 2024. Una crescita di questo genere non arriva dagli umani, ma dagli agenti di programmazione che aprono branch, spingono modifiche e chiedono merge a ritmo continuo.

Un Git che non reggeva più

Prima del cambio, l’affidabilità del backend Git era scesa sotto il 90%. In pratica significava fetch lenti e merge che fallivano, con un costo diretto sulla produttività di chiunque, persona o agente, lavorasse sul repository.

Il team si è posto una domanda precisa: abbiamo toccato il limite di Git o il limite del modo in cui lo serviamo? La conclusione è che il problema non stava tanto nel client o nel protocollo, quanto nell’architettura dei server Git tradizionali. OpenAI ha comunque introdotto alcune modifiche anche lato client.

Una scelta controcorrente: invece di abbandonare Git, l’azienda lo ha mantenuto. Anni di strumenti, abitudini e integrazioni costruiti attorno a Git hanno un valore che non conviene buttare via.

Come funziona Pando, dal branch al pacchetto

L’idea di fondo è rinunciare a due garanzie che i server Git standard offrono ma che, a questa scala, costano troppo. Pando non mantiene tutti i branch in uno stato coerente nello stesso istante e non costruisce un packfile su misura per ogni client che fa fetch.

Ogni branch va per conto suo

Un server tradizionale coordina gli aggiornamenti dei branch a livello di intero repository, quindi un push su un ramo può aspettare un push su un altro ramo senza alcuna relazione. Pando tratta ogni branch in modo indipendente, così gli aggiornamenti non si bloccano a vicenda.

Il compromesso è dichiarato: un client che guarda più branch potrebbe vederli a istanti leggermente diversi. Secondo OpenAI, a persone e agenti importa solo l’ordine degli aggiornamenti dentro un singolo branch.

Il percorso di push

Quando arriva un push, Pando valida il packfile mentre scorre verso lo storage a blob, senza scompattarlo. Poi registra in un archivio di metadati la nuova punta del branch, la posizione del pacchetto e le sue dipendenze.

Un dettaglio intelligente riguarda l’annuncio dei riferimenti. Per impostazione predefinita Pando annuncia solo il branch principale (trunk) come base per i push dei feature branch. L’elenco resta piccolo e ogni pacchetto diventa riutilizzabile da altri client che hanno già la storia del trunk. Il prezzo da pagare è che i push ripetuti sullo stesso branch rinviano tutto ciò che non è nel trunk.

Il problema che si evita è concreto: con milioni di branch, la sola lista dei riferimenti può superare i 100 MiB su un server standard.

Fetch, cache e compattazione

Sul fronte del fetch, Pando sceglie tra i pacchetti già salvati quelli che servono al client in base alla sua storia, e restituisce link di download tramite packfile-uri, una funzione di Git che permette ai client di scaricare i pacchi separatamente. Un servizio di cache chiamato Express serve i pacchetti da cache regionali, con un tasso di hit regionale superiore al 99%.

In background, dei worker uniscono i pacchetti piccoli in pacchetti più grandi, in modo simile a un database log-structured. Questo permette di individuare i pacchetti necessari in tempo logaritmico. Pando non scarta mai un pacchetto: li conserva a ogni livello di compattazione e serve da tutti.

Il risultato, in sintesi, è che il server serve soprattutto byte che ha già, invece di ricalcolare ogni volta ciò che manca al client.

I numeri: dall’80% in meno di latenza al petabyte al giorno

I numeri diffusi da OpenAI aiutano a capire la scala. Pando serve quasi un petabyte di dati Git al giorno, mentre la latenza mediana dei push è scesa di quasi cinque volte. Su macchine virtuali cloud standard, clone e fetch possono saturare un collegamento di rete da 10 Gbps. Il pacchetto mediano nel monorepo pesa meno di 20 KiB, un’indicazione di quanto siano piccole e frequenti le modifiche prodotte dagli agenti.

C’è poi il capitolo tempi di sviluppo. Pando è stato costruito in Rust in dieci settimane: un ingegnere ha progettato il nucleo, mentre dei team di agenti Codex ne hanno realizzato l’implementazione. È entrato in produzione ad aprile.

Questo è forse l’aspetto più interessante dal punto di vista strategico. L’infrastruttura pensata per gestire l’ondata di codice generato dall’AI è stata, a sua volta, in buona parte scritta dall’AI.

Un confronto con i server Git classici

Un server standard calcola gli oggetti mancanti al client e comprime un nuovo packfile per ogni fetch, un lavoro costoso e difficile da mettere in cache. Deve inoltre elencare tutti i branch a ogni push e occuparsi di repack e garbage collection, che consumano calcolo e I/O su disco. Pando evita gran parte di tutto questo grazie al modello a compattazione.

Sul lato sviluppatori, l’esperienza non cambia: si usano i comandi Git di sempre. OpenAI distribuisce però una propria build di Git sulle macchine degli sviluppatori e dentro l’app desktop di ChatGPT.

Il contesto: Git sotto pressione nell’era degli agenti

La mossa di OpenAI non è isolata. Anche altri attori stanno ripensando la gestione del codice per un mondo in cui gli agenti producono più modifiche degli umani. Anthropic, per esempio, ha seguito una strada diversa con un nuovo client e una nuova architettura, come abbiamo raccontato parlando di Scion, il sistema che sostituisce Git nel monorepo di Anthropic. Secondo quanto riportato, quel progetto non verrà rilasciato.

Il tema si lega anche alle piattaforme di collaborazione. Se vuoi inquadrare la direzione in cui si muove l’ecosistema, ti conviene leggere la nostra analisi su GitHub Copilot Fusion e i dati Octoverse 2026 sugli agenti sempre attivi. Il filo comune è chiaro: il collo di bottiglia non è più scrivere codice, ma farlo circolare in sicurezza e in fretta.

Che cosa OpenAI ha restituito alla comunità

OpenAI ha corretto in Git la gestione dei download concorrenti dei pacchetti, la pulizia dopo i trasferimenti interrotti e la ripresa dei download già completati. Ha aggiunto anche una tracciatura dei download che mostra se un fetch lento perde tempo nella generazione dei pacchetti o nel trasferimento.

Alcune modifiche sono già nel progetto upstream. Altre, come il download e l’indicizzazione parallela dei pacchetti e la nuova funzione “explicit haves”, vivono per ora solo nel repository Git pubblico di OpenAI, che le tiene in un tracker pubblico delle patch. Il backend Pando, invece, non sarà open source: l’azienda dice di valutare modi per condividere la tecnologia sottostante con i propri utenti.

Cosa cambia per te e per chi sviluppa con gli agenti

Se non gestisci un monorepo da migliaia di commit al giorno, Pando non è uno strumento che installerai domani. Ma è un segnale utile. Dimostra che i limiti dei flussi di lavoro attuali emergono molto prima di quanto si pensi, quando gli agenti entrano davvero nel ciclo di sviluppo.

Ci sono tre lezioni pratiche. La prima: misura dove si perde tempo, tra generazione dei pacchetti e trasferimento, prima di accusare lo strumento. La seconda: a volte basta rinunciare a una garanzia che non ti serve, come la coerenza simultanea di tutti i branch, per guadagnare moltissimo. La terza: gli agenti sono ottimi anche per costruire l’infrastruttura, non solo per scrivere funzioni.

Le riserve restano. Il progetto non è aperto, i dettagli arrivano dalla stessa OpenAI e i benefici dipendono da un carico molto particolare. Prima di prendere spunto, verifica sempre se il tuo collo di bottiglia è lo stesso.

Conclusioni

Pando racconta una trasformazione più ampia di un singolo strumento: l’AI sta cambiando il volume e il ritmo del lavoro sul codice, e le fondamenta dello sviluppo software devono adattarsi. OpenAI ha scelto di restare su Git e di rivedere il server, con risultati misurabili sulla latenza e sull’affidabilità.

Se sviluppi con agenti o stai valutando come organizzare i tuoi repository, tieni d’occhio questo filone e confronta le soluzioni che emergono. Se vuoi, scrivici nei commenti come gestisci oggi il codice generato dall’AI e quali colli di bottiglia hai incontrato, e continua a seguire intelligenzaartificiale.net per i prossimi aggiornamenti.