Anthropic 13. 10. 2026 popsal, jak za pět měsíců převedl své monorepo z Gitu na vlastní systém Scion (originální článek). Důvodem není, že by Git byl špatný nástroj. Anthropic ho používal jinak, než pro co vznikl: centralizovaně, s jednou autoritativní kopií, a hlavně pro agenty a CI joby, které jsou online pořád.
Po sítích koluje shrnutí s velkými čísly. Většina z nich v originále opravdu je, jen některá znamenají něco trochu jiného. Projdu, jak Scion funguje, co přesně čísla měří a co z toho plyne pro tým, který Scion nikdy neuvidí.
Proč Git v Anthropicu přestal stačit
Nejdřív měřítko. V květnu 2026 Anthropic do monorepa mergoval průměrně kolem 2 500 změn denně. Pro září text uvádí přes 30 tisíc mergů denně. Graf ve stejném článku ale ukazuje, že 30 401 mergů je jednodenní maximum z 9. září; sedmidenní průměr byl tehdy kolem 18 tisíc. Víc než desetinásobnému růstu, o kterém Anthropic mluví, tedy odpovídá srovnání květnového průměru se zářijovou špičkou. Průměr proti průměru vychází zhruba sedminásobek.
Historie main větve má skoro 100 GB, komprimovaná pracovní kopie přes 25 GB. Samotné CI dělá řádově 25 milionů checkoutů denně, a to bez vývojářských prostředí, agentních sandboxů a research jobů. Kdyby se všechno stahovalo naivně, bylo by to podle Anthropicu přes 600 PB dat přenesených Gitem denně. Jde o hypotetický výpočet, ne o naměřený provoz.
Anthropic předtím vyzkoušel, co Git nabízí pro práci s výsekem repa: shallow klony, sparse checkout, promisor remotes (partial clone). K tomu přidal standardní obezličky pro velká monorepa: interní mirrory (kopie repa, které odlehčují hlavnímu serveru) a seed snapshoty v blob storage. Ve špičce provozoval několik stovek mirrorů. Získal tím čas, ale seedy mezi obnovami čím dál víc zaostávaly za mainem, diff a blame nad částečnými klony vyžadovaly stále víc péče a mirrory přestaly škálovat, když repo přerostlo jejich disky a paměť.
Klíčová věta článku zní: „we were using git as a centralized system with one authoritative copy, but nearly all of our clients were agents and jobs that are online by definition.“ Vlastnosti, díky kterým je Git skvělý pro distribuovanou offline práci, jim podle článku začaly škálování brzdit. Otázka pak zněla: jak by vypadal source control navržený od začátku pro klienty, kteří jsou pořád připojení?
Server počítá, klient cachuje: jak Scion funguje
Odpovědí je šest principů:
- Klienti jsou vždy online. Data si stahují, až když je potřebují.
- Klient a server nejsou rovnocenní. Server počítá historii, blame, commity, merge i rebase. Klient drží omezenou cache objektů, rozkládá soubory na disk a sleduje změny ve filesystému.
- Source control je služba s API. Všechny dotazy klienta jsou dostupné i přes API. CI job, který chce diff mezi commitem a jeho merge base, se zeptá serveru a lokální repo často vůbec nepotřebuje.
- Všechno škáluje horizontálně. Kompletní kopie repa podle článku neexistuje nikde, ani na serveru. Nejsou ani packfiles, takže odpadá údržba repa.
- Commity jsou levné, inkrementální a bez zámků. Cena odpovídá velikosti změny, ne velikosti repa.
- Pracovní kopie je volitelná a řídká. Sparse checkout stáhne jen požadované adresáře, virtualizovaný checkout materializuje soubory až ve chvíli, kdy je někdo čte.
Základní jednotkou je changeset, záznam ve write-ahead logu. Zatímco Git commit ukazuje na celý strom, changeset nese jen seznam souborů změněných vůči prvnímu rodiči a content-addressed odkazy na komprimovaný obsah v blob storage. Blame nebo historie cest jsou odvozená data, která server dopočítá z rodičů. Diff vůči prvnímu rodiči je volba šitá na trunk-based vývoj.
Větve a tagy Scion technicky umí, ale mimo main a release větve od nich odrazuje: jsou to globální stav, na kterém se musí shodnout všechny servery, a ten je podle článku škálovací problém, který se blíží. Přesun refu je compare-and-swap na jednom řádku ve Spanneru.
Infrastruktura má tři vrstvy: autoritativní scion-server, regionální scion-cache a scion-daemon, který běží na každém nodu a startuje z pravidelně obnovovaného snapshotu. Klient scn mluví s daemonem a všechny vrstvy odpovídají na stejné RPC.
Podstatný rozdíl je v negociaci. Git klient serveru říká, co už má, a server dopočítá, co mu chybí. Klient Scionu jde opačně: od kořenového stromu zjistí, které stromy a bloby mu lokálně chybí, a žádá je jako konkrétní neměnné objekty. Neměnný objekt může obsloužit jakákoli cache, stahování jde navázat a sparse nebo virtuální checkout nepotřebuje speciální podporu. Klient prostě nežádá stromy, které nechce. Každá vrstva cache má podle článku hit rate přes 99 %.
Jeden kompromis Anthropic přiznává otevřeně. Merge queue s globálním zámkem při tomhle objemu neudržel, takže testuje až po merge a před deployem. Článek se sám ptá: „What does CI even mean when hundreds or even thousands of changes can merge while tests are running?“ Souběžné změny tak můžou kolidovat. Podle Anthropicu je Claude obvykle opraví rychleji, než je lidé vůbec stihnou identifikovat. Jak se rozbitá změna v mainu odhalí a vrátí, článek podrobně nepopisuje, zmiňuje jen interní automatizovaný bisect a revert nad API Scionu. Podobně stručný je u výpadků sítě nebo serveru, kde uvádí jen striktní vrstvení kvůli jejich izolaci.
Jako inspiraci článek uvádí Google Piper (popsaný v CACM 2016) a Meta Sapling.
Čísla, jak je uvádí originál
Ve shrnutí, které koluje po sítích, se objevují hlavně tato čísla:
- 200× menší nároky na CPU a paměť má infrastruktura Scionu ve srovnání s předchozí infrastrukturou Git mirrorů. Ne ve srovnání s Gitem obecně.
- 25 % CPU kapacity se podle článku uvolnilo v samotném CI.
- „Dva řády“: text říká, že CI a research joby checkoutují „two orders of magnitude faster (in seconds rather than minutes)“. Mediány v grafu stejného článku ale ukazují u checkoutu v CI ×8,8 a na startu compute jobu ×8,0. Desítky a stovky násobků mají jiné operace, třeba nový worktree u agentů nebo status u vývojářů.
- 30 tisíc mergů je denní špička, ne trvalý průměr.
Mediány z grafu v originále:
| Prostředí | Operace | Git | Scion | Zrychlení |
|---|---|---|---|---|
| Vývojář | pull | 87 s | 3,5 s | ×25 |
| Vývojář | checkout | 15 s | 1,1 s | ×14 |
| Vývojář | status | 3,9 s | 19 ms | ×207 |
| Vývojář | commit | 1,4 s | 1,1 s | ×1,3 |
| Agent | nový worktree | 7,1 min | 5,1 s | ×84 |
| Agent | commit | 18 s | 761 ms | ×24 |
| Agent | source control na change request celkem | 34 min | 3,7 min | ×9,2 |
| CI | checkout v CI jobu | 31 s | 3,5 s | ×8,8 |
| Compute | checkout na startu jobu | 175 s | 22 s | ×8,0 |
Anthropic zrychlení přepočítává na úsporu zhruba 11 000 agentních hodin denně, 85 000 strojohodin denně u compute jobů a 195 000 strojohodin denně v CI. Jde o jeho odhad. Metodiku ani období měření článek neuvádí.
Pět měsíců, sedm lidí (a Claude)
Scion postavil tým sedmi lidí za pět měsíců. Ve stejné době vznikl i nástroj pro code review Antique, code search, IAM pro source control, nové způsoby správy a začleňování velkého množství zrevidovaného kódu a zhruba půl tuctu dalších souvisejících systémů.
Nejvýraznější příklad v článku je ingestion pipeline, která převádí data z Gitu do Scionu. První verzi tým napsal převážně ručně jako prototyp. Claude Mythos Preview ji pak bez dalších pokynů přepsal na verzi, která byla 4× rychlejší a spotřebovala 20× méně paměti.
Inženýři podle článku do práce vnášeli znalost vazeb mezi systémy a návrhových kompromisů. „Very often, we found that the role of the engineers was to tell Claude ‚no.‘“ Agenti totiž občas porušovali základní omezení systému. Každý change request lidé dál reviewují, jen víc posuzují záměr změny než jednotlivé řádky.
Co si z toho vzít, když nejsi Anthropic
Scion je interní systém a Anthropic sám píše: „Scion is by no means a suitable replacement for git for general use.“ Od Gitu se výrazně odchyluje a vyžaduje vlastní code review, code search a CI, které má Anthropic šité na míru. Data z Gitu do Scionu převádí zmíněná ingestion pipeline, o rozhraní kompatibilním s Gitem pro klienty ale článek nemluví.
Místo toho chce Anthropic principy přenést do Gitu samotného: Git server podle něj nemusí fungovat stejně jako klient. Zmiňuje jiné serverové architektury, serverová RPC standardizovaná napříč forgemi (platformami jako GitHub nebo GitLab), novou negociaci a lépe kombinovatelné sparse a shallow funkce. Anthropic píše, že chce spolupracovat s GitHubem, GitLabem a open source komunitou. Zatím je to záměr, ne oznámené partnerství.
Anthropic nečeká, že by tyhle problémy většina firem řešila hned, podle jeho odhadu ale budou během 6 až 12 měsíců běžnější. Sám na ně narazil dřív, protože podle svých slov používá Clauda k psaní softwaru víc než skoro jakákoli jiná firma.
Můj výklad: pasáž o tom, co Anthropic zkoušel s Gitem, funguje jako kontrolní seznam. Shallow klony, sparse checkout, partial clone s promisor remotes, mirrory a seed snapshoty jsou běžné nástroje a Anthropicu nějakou dobu stačily. Pokud ti přibývají agenti a joby, které klonují repo, zapoj tyhle nástroje dřív, než se checkout stane úzkým hrdlem, a sleduj čas checkoutu a vytížení CI. Zaostávající seedy, pracný diff a blame nad částečnými klony nebo mirrory, kterým dochází disk a paměť, jsou signál, že obezličky přestávají stačit.
Pro koho je infrastruktura postavená
Nejužitečnější je otázka, kterou si v Anthropicu položili a kterou si můžeš položit i bez Scionu: pro koho je tvoje infrastruktura vlastně postavená? Git počítá s člověkem, který má celé repo u sebe a občas se připojí. Agent je připojený pořád a potřebuje jen kousek. Celý rozbor i grafy najdeš v původním článku na blogu Anthropicu.
