Anthropic indique avoir migré son monorepo de Git vers Scion, son système interne de contrôle de versions, en cinq mois. Dans un billet publié le 13 octobre et actualisé le 15 octobre 2026, l’entreprise précise que Scion ne vise pas à remplacer Git pour tous les projets. Son compte rendu technique décrit une architecture conçue pour son propre dépôt et ses volumes de changements.
Ce qu’Anthropic a migré vers Scion
La migration concerne le monorepo d’Anthropic, pas l’ensemble des usages de Git dans l’entreprise. Anthropic rapporte une moyenne d’environ 2 500 changements de code fusionnés par jour en mai 2026, puis plus de 30 000 par jour en septembre. Ces chiffres comptent des changements fusionnés : ils ne mesurent pas, à eux seuls, le nombre de fonctionnalités ni la qualité du code.
La taille du dépôt et la fréquence des extractions aident à comprendre ce choix. Anthropic décrit près de 100 Go d’historique sur la branche principale, une copie de travail compressée de plus de 25 Go et quelque 25 millions d’extractions de code par jour pour l’intégration continue (CI). L’entreprise estime qu’une récupération naïve du dépôt à cette cadence aurait généré plus de 600 Po de trafic par jour.
Comment Scion évite de cloner tout le dépôt
Scion déplace vers des services serveur des opérations comme la création de commits, les merges, les rebases et les recherches dans l’historique. Le client conserve un cache local borné et gère les fichiers présents dans la copie de travail. Il peut demander seulement les arbres et les fichiers nécessaires, plutôt que de conserver une copie complète du dépôt.
Un changeset décrit les fichiers modifiés par rapport au premier parent du changement. Il pointe vers leur contenu compressé, stocké séparément et identifié par son contenu. Les checkouts sparse ne matérialisent que les répertoires demandés ; les checkouts virtualisés récupèrent les fichiers à la demande. Certaines tâches d’intégration continue et certains outils peuvent aussi interroger les API de contrôle de versions sans créer de copie locale.
Les couches de cache et le déplacement des références
Anthropic décrit trois niveaux de service : scion-daemon sur chaque nœud, des serveurs régionaux scion-cache, puis les serveurs faisant autorité scion-server. L’entreprise rapporte un taux de succès du cache supérieur à 99 % à chacun de ces niveaux.
Le déplacement d’une référence — par exemple, celle qui désigne une branche — utilise une opération de compare-and-swap sur une ligne de Spanner. Ce détail situe précisément l’étape qui implique cette coordination, au lieu de laisser entendre que toutes les opérations du système en sont dépourvues.
Ce que mesurent les gains annoncés
Anthropic rapporte que son infrastructure Scion nécessite 200 fois moins de ressources CPU et mémoire que l’infrastructure de miroirs Git qui la précédait. L’entreprise distingue de ce résultat des extractions deux ordres de grandeur plus rapides — en secondes plutôt qu’en minutes — et une hausse de 25 % de la capacité CPU de sa CI. Ces chiffres portent sur les systèmes d’Anthropic et sur des comparaisons distinctes : le gain de 200 fois concerne les besoins CPU et mémoire de l’ancienne infrastructure de miroirs.
Scion peut-il remplacer Git pour d’autres équipes ?
Anthropic décrit Scion comme un système interne et affirme qu’il ne convient pas comme remplacement général de Git. L’entreprise estime qu’une adoption plus large exigerait aussi de migrer des outils liés au développement, notamment la revue de code, la recherche de code et la CI. Les clients de Scion sont par ailleurs conçus pour fonctionner avec un serveur joignable.
Pour une équipe extérieure, Scion n’est donc pas un simple outil à substituer à Git : son architecture et ses services associés impliqueraient de revoir une partie du flux de développement.
Une fusion réussie garantit-elle le bon fonctionnement ?
Anthropic indique ne pas avoir réussi à reproduire à cette échelle un verrou global du dépôt dans sa file de fusion. L’entreprise rapporte que des changements concurrents peuvent entrer en conflit et décrit des tests automatisés après fusion et avant déploiement dans son approche de l’intégration.
