A empresa Anthropic divulgou em 13 de outubro como realizou a migração de seu monorepo de Git para Scion, um sistema de controle de versão que move operações de repositório para o servidor e utiliza content-addressed storage e tiered caches para workloads de agentes e CI.
O crescimento do monorepo de Anthropic exigiu essa transição. As mudanças diárias consolidadas cresceram de aproximadamente 2.500 em maio para mais de 30.000 em setembro de 2026. Seus sistemas CI executam cerca de 25 milhões de checkouts diários contra um repositório com quase 100 GB de histórico na branch principal e cópia de trabalho comprimida superior a 25 GB. A empresa havia empregado shallow clones, sparse checkouts, promisor remotes, snapshots de repositório e centenas de mirrors Git, mas essa abordagem se tornou operacionalmente insustentável conforme as taxas de merge aumentavam.
Modelo de dados e operações server-side
Scion move operações de commits, merges, rebases, consultas de histórico e blame queries para o servidor. Clientes mantêm caches limitados de objetos, e checkouts virtualizados materializam arquivos sob demanda. Ferramentas podem consultar diffs e realizar algumas operações de escrita via APIs sem necessidade de checkout de código.
Cada changeset em Scion registra arquivos alterados relativos a seu primeiro parent com pointers content-addressed para conteúdo comprimido em blob storage. A criação de changesets é separada da atualização de referências, de modo que aceitar changesets não requer coordenação cross-server. Para consultas de histórico e blame, Scion constrói estruturas chamadas "derived data", computadas recursivamente de changesets pai, seja eager ou sob demanda. Essa implementação server-side permite que derived data evolua sem alterar clientes.
/filters:no_upscale()/news/2026/10/anthropic-source-control/en/resources/1scion-changes-merged-per-day-1792669828881.png)
Imagem: InfoQ. Mudanças diárias consolidadas no monorepo do Anthropic cresceram de cerca de 2.500 em maio para mais de 30.000 em setembro de 2026
Arquitetura de cache em tiers
Para checkouts, clientes solicitam árvores e blobs imutáveis ausentes em vez de negociar packfiles customizados. Um daemon node-local compartilha objetos em cache entre jobs e busca de caches regionais, que por sua vez buscam de servidores autoritativos respaldados por Spanner e cloud storage. Os caches regionais transmitem objetos no formato de storage do daemon sem compressão delta por-request.
Os tiers expõem as mesmas RPCs de protocolo de checkout, mas Anthropic força sua ordenação para isolar falhas e impedir que uma falha de cache regional sobrecarregue servidores autoritativos. Checkouts sparse e virtualizados solicitam apenas os objetos necessários.
/filters:no_upscale()/news/2026/10/anthropic-source-control/en/resources/1scion-changeset-structure-1792669828881.png)
Imagem: InfoQ. Changesets em Scion registram arquivos alterados e referências para conteúdos; estruturas de árvore são derivadas separadamente pelo servidor
Resultados reportados e recomendações
Anthropic relata cache-hit rates acima de 99% em cada tier, infraestrutura de CPU e memória 200 vezes menor que seus mirrors Git anteriores, e aceleração de checkout de duas ordens de magnitude para jobs de CI e pesquisa. A empresa ressalva que esses são resultados reportados para sua carga de trabalho interna específica, não benchmarks gerais contra Git.
Anthropic credita Mononoke e seu data model Bonsai por pioneirar muitas das técnicas usadas em Scion. Porém, a empresa adverte que Scion não é um Git replacement genérico. Requer seus próprios sistemas de code-review, code-search e CI, com implementações altamente específicas para o caso Anthropic. A empresa recomenda trazer ideias selecionadas, incluindo APIs server-side abrangentes e protocolos de fetch aprimorados, para plataformas Git existentes.
Para contexto, Uber apresentou anteriormente GitFarm, que centraliza operações Git padrão sem substituir o sistema de controle de versão. Scion vai além, mudando o data model subjacente.
Para arquitetos, o aprendizado principal é reconsiderar onde o trabalho acontece conforme cargas evoluem. Consultas de repositório não precisam necessariamente de checkouts locais, e objetos imutáveis podem ser compartilhados via caches, reduzindo trabalho redundante. Porém, Scion depende de disponibilidade de servidor, e a integração requerida é substancial.










