Anthropic ha migrato il proprio monorepo da Git a Scion, un sistema di controllo versione sviluppato internamente, in cinque mesi. L’azienda lo descrive come una soluzione per il proprio carico di lavoro su larga scala e afferma che non è adatto a sostituire Git in generale, nel resoconto tecnico pubblicato il 13 ottobre 2026 e aggiornato il 15 ottobre.
La differenza pratica è dove avviene il lavoro: con Scion, molte operazioni di controllo versione passano dai computer degli sviluppatori ai server. È un’architettura pensata per gestire un monorepo enorme e un’intensa attività di agenti e processi automatici, non una sostituzione universale di Git.
Che cosa Anthropic ha migrato
Anthropic afferma di aver trasferito a Scion il proprio monorepo, cioè un unico grande repository che raccoglie numerosi progetti e file. Non dice di aver abbandonato Git per tutti gli usi aziendali.
Il contesto è un forte aumento delle modifiche unite al repository: Anthropic riporta una media di circa 2.500 al giorno nel maggio 2026 e più di 30.000 al giorno a settembre. Il grafico dell’azienda segna 30.401 modifiche unite il 9 settembre. Si tratta di modifiche di codice, non di un conteggio delle nuove funzionalità.
Anche le dimensioni e i carichi di lavoro aiutano a capire la scelta: Anthropic descrive una cronologia del ramo principale di quasi 100 GB, una copia di lavoro compressa superiore a 25 GB e circa 25 milioni di checkout CI al giorno. L’azienda stima che scaricare ingenuamente il repository per tutti quei checkout avrebbe generato oltre 600 PB di traffico Git al giorno: una stima ipotetica, non il traffico effettivamente registrato.
Come Scion evita il checkout completo
In Git, ogni clone è un repository completo e autonomo; Scion adotta invece un modello centrato sui server. Il client conserva una cache locale limitata e i file della copia di lavoro, mentre il server gestisce operazioni come commit, merge, rebase e interrogazioni della cronologia.
Un changeset registra i file modificati rispetto al primo genitore e fa riferimento ai contenuti dei file, compressi e identificati tramite il loro contenuto. Il client può richiedere solo gli alberi e i file necessari. I checkout sparse includono le parti selezionate del repository; quelli virtualizzati materializzano i file quando servono. Alcune attività di CI e alcuni strumenti possono interrogare le API di Scion senza creare una copia di lavoro locale.
Questa impostazione riduce ciò che ogni client deve conservare, ma lega le operazioni alla disponibilità dei servizi server. Anthropic descrive tre livelli: scion-daemon sul nodo, scion-cache regionali e scion-server autorevoli. L’azienda riferisce tassi di cache hit superiori al 99% a ciascun livello.
Il dettaglio sul movimento dei riferimenti
Il sistema non elimina ogni forma di coordinamento. Anthropic spiega che spostare un riferimento — per esempio quello associato a un ramo — richiede un’operazione compare-and-swap su una singola riga di Spanner. È una specifica eccezione architetturale da distinguere dalle operazioni sui changeset.
Che cosa misurano i risultati dichiarati
Anthropic riferisce che la propria infrastruttura Scion richiede 200 volte meno CPU e memoria rispetto alla precedente infrastruttura di mirror Git. Separatamente, l’azienda dichiara checkout due ordini di grandezza più veloci — nell’ordine dei secondi anziché dei minuti — e un aumento del 25% della capacità CPU per la CI. Sono risultati riferiti ai sistemi di Anthropic, con confronti diversi: il dato 200× riguarda CPU e memoria, mentre velocità dei checkout e capacità CI sono metriche distinte.
Scion può sostituire Git per altri team?
Anthropic descrive Scion come un sistema interno e afferma che non è adatto a sostituire Git per l’uso generale. Un’adozione ampia richiederebbe anche di migrare strumenti collegati, tra cui code review, ricerca del codice e CI: cambiare il solo controllo versione non basterebbe.
L’azienda dice di voler collaborare con GitHub, GitLab e la comunità open source per applicare alcune idee di scalabilità senza costringere tutti gli utenti Git a cambiare sistema. Per i team che usano repository ordinari, quindi, il progetto descritto da Anthropic resta una soluzione specializzata per carichi eccezionali, non un nuovo Git pronto all’adozione generale.
Un merge non chiude il controllo
Anthropic afferma di non essere riuscita a riprodurre, nella propria coda di merge e a questa scala di agenti, un blocco globale del repository. L’azienda punta invece su test automatizzati dopo il merge e prima del deploy e riconosce che modifiche concorrenti possono entrare in conflitto. Un’unione riuscita, da sola, non sostituisce quindi i controlli sul comportamento del software.
