Anthropic hat sein Monorepo nach eigenen Angaben innerhalb von fünf Monaten von Git auf Scion umgestellt – ein internes, serverzentriertes Versionskontrollsystem, das das Unternehmen nicht als allgemeinen Git-Ersatz versteht. In seinem Bericht beschreibt Anthropic, wie Scion Änderungen verarbeitet und welche Ergebnisse das System im eigenen Betrieb erzielt.
Der Anlass war ein stark gewachsenes Arbeitsaufkommen: Anthropic meldete durchschnittlich rund 2.500 zusammengeführte Codeänderungen pro Tag im Mai 2026 und mehr als 30.000 pro Tag im September. Das sind Änderungen, keine gezählten Funktionen – und die Zahl allein sagt nichts über Codequalität oder Produktivität aus.
Was Anthropic von Git zu Scion migrierte
Die Migration betraf laut Anthropic das eigene Monorepo, nicht sämtliche Git-Nutzung des Unternehmens. Die Größenordnung des Repositories verdeutlicht die technische Herausforderung: Anthropic bezifferte die Historie des Hauptzweigs auf knapp 100 GB, eine komprimierte Arbeitskopie auf mehr als 25 GB und die CI-Code-Checkouts auf rund 25 Millionen pro Tag. Für den Fall, dass diese Checkouts jeweils naiv abgerufen würden, schätzte das Unternehmen ein Datenaufkommen von mehr als 600 PB täglich.
Eine Grafik von Anthropic markiert am 9. September 2026 genau 30.401 zusammengeführte Änderungen. Dieser Tageswert steht neben dem vom Unternehmen genannten September-Niveau von mehr als 30.000 Änderungen pro Tag; er ist kein Maß für die Zahl neuer Funktionen.
Wie Scion Änderungen und Repository-Daten verarbeitet
Scion verlagert zentrale Versionskontrollvorgänge auf Server. Dort laufen laut Anthropic etwa das Erstellen von Commits, Merges und Rebases sowie Abfragen zur Historie. Ein Client verwaltet einen begrenzten lokalen Objekt-Cache und fordert die Bäume und Dateien an, die er tatsächlich benötigt.
Ein Changeset hält fest, welche Dateien sich gegenüber dem ersten Vorgänger geändert haben. Die Dateiinhalte liegen separat als komprimierte, nach ihrem Inhalt adressierte Objekte. Scion kann einen Sparse Checkout bereitstellen, der nur angeforderte Verzeichnisse enthält, oder Dateien bei einem virtualisierten Checkout erst bei Bedarf lokal verfügbar machen. Manche CI- und Werkzeugaufgaben können Repository-Abfragen außerdem über APIs ausführen, ohne eine lokale Arbeitskopie anzulegen.
Die Cache-Architektur besteht aus drei Ebenen: dem knotenbezogenen scion-daemon, regionalen scion-cache-Servern und maßgeblichen scion-server-Servern. Anthropic meldet für jede Ebene eine Cache-Trefferquote von mehr als 99 Prozent.
Beim Verschieben einer Referenz kommt eine konkrete Koordination hinzu: Anthropic zufolge verwendet Scion dafür einen Compare-and-Swap auf einer einzelnen Spanner-Zeile. Die übrigen beschriebenen Vorgänge lassen sich also nicht pauschal als vollständig koordinationsfrei zusammenfassen.
Was Anthropic mit den Leistungszahlen vergleicht
Anthropic beziffert den CPU- und Speicherbedarf der Scion-Infrastruktur auf ein Zweihundertstel des Bedarfs seiner früheren Git-Spiegel-Infrastruktur. Das Unternehmen berichtet außerdem von Checkouts, die zwei Größenordnungen schneller seien – Sekunden statt Minuten – sowie von 25 Prozent mehr CPU-Kapazität für CI. Diese Werte beziehen sich auf Anthropics eigene Systeme.
Der Unterschied ist für Teams außerhalb des Unternehmens nicht automatisch übertragbar: Die Infrastruktur, die Anthropic vergleicht, ist die eigene frühere Spiegel-Umgebung. Scion nutzt serverseitige Vorgänge und mehrere Cache-Ebenen; ein lokales Git-Repository folgt einem dezentralen Modell, bei dem ein vollständiger Klon eigenständig nutzbar ist. Welche Variante passt, hängt daher nicht allein von einer einzelnen Geschwindigkeitszahl ab, sondern auch davon, wie ein Team seine Entwicklungswerkzeuge betreibt.
Ist Scion ein allgemeiner Git-Ersatz?
Nein: Anthropic bezeichnet Scion als internes System und sagt, es sei kein geeigneter allgemeiner Ersatz für Git. Für eine breitere Einführung müssten Organisationen laut dem Unternehmen auch verbundene Systeme wie Code-Review, Codesuche und CI migrieren. Scion setzt zudem auf einen erreichbaren Server, statt den Arbeitsablauf auf vollständig eigenständige lokale Repositories auszurichten.
Anthropic möchte mit GitHub, GitLab und der Open-Source-Community daran arbeiten, Skalierungsideen auf Git-Umgebungen zu übertragen, ohne alle Nutzer zum Wechsel auf ein anderes Versionskontrollsystem zu bewegen.
Was nach einem Merge weiter geprüft wird
Ein erfolgreicher Merge belegt nicht, dass eine Änderung sich im Betrieb korrekt verhält. Anthropic sagt, dass parallele Änderungen miteinander in Konflikt geraten können und dass das Unternehmen eine globale Repository-Sperre in der Merge-Queue bei dieser Agentenlast nicht wirksam nachbilden konnte. Als Teil seines Umgangs damit setzt Anthropic auf automatisierte Tests nach dem Merge und vor dem Deployment.
