30.000 Merges am Tag: Was Anthropics Scion über Git im Agentenmaßstab verrät
Victoria Shinder3 Min. LesezeitDer Engineering-Beitrag von Anthropic vom 13. Oktober 2026 beschreibt etwas, das die meisten Teams nie bauen werden: ein eigenes Versionskontrollsystem namens Scion, auf das das Unternehmen sein Monorepo in fünf Monaten von Git umgestellt hat. Lesenswert ist er trotzdem wegen der Problembeschreibung, denn sie benennt genau die Stellen, an denen Werkzeuge für menschliches Arbeitstempo versagen, sobald die meisten Commits von Agenten stammen.
Die Zahlen hinter der Entscheidung. Anthropic nennt rund 2.500 zusammengeführte Änderungen pro Tag im Mai 2026 und über 30.000 pro Tag im September. Allein die Historie des Hauptzweigs umfasst fast 100 GB, eine komprimierte Arbeitskopie über 25 GB, und die CI führt in der Größenordnung von 25 Millionen Checkouts täglich aus – naiv geladen wären das laut Beitrag über 600 PB Git-Verkehr am Tag. Vor Scion nutzte das Unternehmen alle üblichen Auswege – Shallow- und Sparse-Klone, Promisor-Remotes, Snapshots im Blob-Speicher – und betrieb in der Spitze mehrere Hundert interne Git-Spiegel.
Die Beobachtung, die das Design bestimmt. Das zentrale Argument lautet: Die Stärken von Git setzen Clients voraus, die offline und autark arbeiten, während fast alle Clients bei Anthropic Agenten und Jobs sind, die per Definition online sind. Daraus folgen die Prinzipien: Der Server beantwortet Fragen zu Historie und Blame und erzeugt Commits, Merges und Rebases; der Client hält nur einen begrenzten Cache; jede Repository-Abfrage gibt es auch als API, viele Jobs brauchen also gar keine lokale Kopie; Commits sind serverseitige „Changesets“, deren Kosten mit der Größe der Änderung wachsen, nicht mit der des Repositorys; Refs werden vermieden, weil globaler gemeinsamer Zustand ein Skalierungsproblem ist.
Was es laut Anthropic gebracht hat. Der Bedarf an CPU und Speicher sei 200-mal kleiner als bei der früheren Spiegelflotte, Checkouts dauerten Sekunden statt Minuten, allein die CI habe 25 Prozent CPU-Kapazität gewonnen, und jede Cache-Stufe erreiche eine Trefferquote über 99 Prozent. Ein Team aus sieben Personen baute in dieser Zeit Scion, ein Code-Review-Werkzeug und weitere Systeme.
Was sich übertragen lässt. Zwei Bemerkungen verdienen mehr Aufmerksamkeit als die Architektur. Erstens bestand die Hauptaufgabe der Ingenieure laut Team oft darin, dem Modell „Nein“ zu sagen – Agenten verletzten Systemgrenzen, um einem Muster zu folgen, und adversariale Reviews trieben zu defensiver Überkonstruktion. Zweitens räumt Anthropic ein, die übliche globale Sperre der Merge-Queue nicht halten zu können; getestet wird nun nach dem Merge und vor dem Deployment, Konflikte zwischen gleichzeitigen Änderungen werden in Kauf genommen. Jede Organisation mit wachsendem Anteil von Agenten-Code wird vor derselben Frage stehen: Was bedeutet CI, wenn Änderungen schneller zusammengeführt werden, als Tests durchlaufen?
Was der Beitrag nicht behauptet. Anthropic sagt klar, dass Scion kein allgemeiner Ersatz für Git ist, sich zu weit davon entfernt, um von anderen übernommen zu werden, und dass der eigene Token-Verbrauch ungewöhnlich ist. Der Vorschlag ist enger: Git-Server müssen nicht wie Git-Clients arbeiten, Forges könnten serverseitige RPCs wie bei Scion anbieten, und die vorhandenen Sparse- und Shallow-Funktionen ließen sich besser kombinierbar machen. Anthropic erwartet, dass diese Probleme in sechs bis zwölf Monaten mehr Organisationen erreichen.
Quelle: Anthropic Engineering, „Redesigning source control at Anthropic“ — https://www.anthropic.com/engineering/redesigning-source-control