Anthropic tauscht git gegen Scion, da die Merges 30.000 pro Tag übersteigen

Anthropic hat sein zentrales Code-Repository von git auf Scion umgestellt, ein Versionskontrollsystem, das das Unternehmen selbst gebaut hat. Nach eigenen Angaben hat es im Mai 2026 rund 2.500 Codeänderungen pro Tag gemergt und bis September mehr als 30.000 pro Tag. The Register führt diesen Sprung darauf zurück, dass Claude einen größeren Teil des Codes des Unternehmens schreibt. Git beruht auf der Idee, dass jede Kopie die vollständige Historie enthält. Das ergab keinen Sinn mehr, als fast jeder Nutzer ein ständig verbundener KI-Agent war. Anthropic hat das System am 13. Oktober beschrieben, will es aber nicht veröffentlichen.

Warum git nicht mehr funktionierte

„Der Engpass ist jetzt die gesamte Entwicklerinfrastruktur, die für menschliche Größenordnungen gebaut wurde“, schreibt Anthropic in seinem Engineering-Beitrag. Das Schreiben von Code ist nicht mehr der langsame Teil. Langsam sind die Versionskontrolle, die Builds und die Continuous Integration (CI), also die automatisierten Tests, die bei jeder Änderung laufen.

Das Repository ist ein Monorepo, ein einzelnes Repository, das den Großteil des Codes des Unternehmens enthält. Seine Größe erklärt die Belastung:

Messgröße	Wert
Historie des Main-Branches	Fast 100 GB
Komprimierte Arbeitskopie	Über 25 GB
Checkouts pro Tag allein für CI	Rund 25 Millionen
Git-Traffic, wenn jeder Checkout ein einfacher Klon wäre	Über 600 PB pro Tag
Interne git-Mirrors auf dem Höhepunkt	Mehrere hundert

Anthropic versuchte die üblichen Lösungen. Es nutzte Shallow Clones und Sparse Clones, die nur einen Teil eines Repositorys herunterladen, dazu interne Mirrors und vorgefertigte Kopien. Jede dieser Lösungen wurde mit steigenden Merges schwerer zu betreiben. Die vorgefertigten Kopien entfernten sich vom Main-Branch, und Werkzeuge wie diff und blame funktionierten bei partiellen Klonen nicht mehr.

Wie Scion funktioniert

Scion geht davon aus, dass seine Clients immer online sind. Der Server übernimmt Historie, blame, Commits, Merges und Rebases. Jede Maschine hält nur einen begrenzten lokalen Cache und ihre Arbeitskopie, also die Dateien, die sie tatsächlich bearbeitet.

Jede Änderung wird als Changeset in einem Write-Ahead-Log gespeichert, einem fortlaufenden Protokoll der Änderungen. Es listet die geänderten Dateien auf und verweist auf deren Inhalte im Blob-Speicher. Dateien werden bei Bedarf abgerufen. Ein Checkout lädt also nie zuerst ein mehrere Gigabyte großes Paket herunter.

Scion läuft in drei Ebenen: ein Daemon auf jeder Maschine, ein Cache in jeder Region und ein maßgeblicher Server. Laut Anthropic beantwortet jede Cache-Ebene mehr als 99 % der Anfragen. Von anderen Branches als main und den Release-Branches wird abgeraten.

Scion ist kein direkter Ersatz für git. Scion-Ingenieur Nick G. erklärte den Zielkonflikt auf Hacker News, wie Simon Willison zitiert. „Da Claude mit Abstand der intensivste Nutzer von Scion ist und zwangsläufig online ist, war das einfach nicht wichtig“, schrieb er. Willison vergleicht das Ergebnis mit älteren zentralisierten Systemen wie Subversion.

Was Anthropic nach eigenen Angaben gewonnen hat

Anthropic meldet diese Ergebnisse für Repositorys, die nativ auf Scion laufen:

• Rund 200-mal weniger CPU und Arbeitsspeicher als seine alten git-Mirrors.
• CI- und Research-Checkouts rund 100-mal schneller, mit Sekunden statt Minuten.
• Eine um 25 % geringere CPU-Nutzung seines CI-Systems.

Sieben Personen bauten Scion, ein Code-Review-Tool namens Antique und etwa ein halbes Dutzend verwandter Systeme. Die Migration dauerte fünf Monate. The Register berichtet, dass die Arbeit an Scion im Januar 2026 begann.

Zu den weiteren Tools gehören eine Codesuche, Zugriffsrechte pro Verzeichnis und ein Weg, Änderungen ohne eine einzige globale Merge-Queue einzuspielen. Das Team baute sie mit Hilfe von Claude. Eine von Claude geschriebene Neufassung der frühen Import-Pipeline von git zu Scion brauchte 20-mal weniger Arbeitsspeicher und lief viermal schneller, sagt Anthropic.

Menschen steuerten die Arbeit weiterhin. „Sehr oft stellten wir fest, dass die Rolle der Ingenieure darin bestand, Claude ‚nein‘ zu sagen“, sagte Anthropic laut The Register.

Bekommt sonst jemand Scion?

Nein. Laut Anthropic ist Scion schwer in einer breit nutzbaren Form anzubieten und nicht für den allgemeinen Einsatz geeignet. Stattdessen teilt das Unternehmen das Design und will nach eigenen Angaben mit GitHub, GitLab und der Open-Source-Community zusammenarbeiten.

Der Beitrag schlägt Ideen vor, die git-Hoster übernehmen könnten, ohne die Funktionsweise von git zu ändern. Dazu gehört, mehr Arbeit auf dem Server zu erledigen und Sparse Clones und Shallow Clones leichter kombinierbar zu machen. Auch Git selbst verändert sich: Wir haben bereits in diesem Monat über die Debatte um den SHA-256-Standard von Git 3.0 berichtet.

Was das für Entwickler bedeutet

• Für die meisten Teams ist git weiterhin in Ordnung. The Register merkt an, dass git für die meisten Repositorys die richtige Wahl bleibt. Scion löst ein Problem, das bei Zehntausenden Merges pro Tag auftritt.
• Die Kosten für CI-Checkouts im Blick behalten, wenn Agenten skalieren. Rund 25 Millionen Checkouts pro Tag haben git hier an seine Grenze gebracht. Wenn Ihre Agenten das Repository für jede Aufgabe klonen, messen Sie diesen Traffic jetzt.
• Agenten als ständig verbundene Clients behandeln. Offline-Kopien sind für Menschen wichtig, nicht für Agenten, die in der Cloud laufen. Tools, die Dateien bei Bedarf abrufen, können die Kosten jedes Agentenlaufs senken.
• Damit rechnen, dass git-Hoster diese Ideen übernehmen. Anthropic möchte, dass GitHub und GitLab Teile des Designs übernehmen. Serverseitige Operationen und bessere partielle Klone sind die wahrscheinlichen ersten Schritte.
• Menschen im Review behalten. Anthropics Ingenieure verbrachten einen Großteil ihrer Zeit damit, Claudes Vorschläge abzulehnen. Planen Sie diese Review-Last ein, wenn Agenten den Großteil des Codes schreiben.