Anthropic troca o git pelo Scion quando os merges passam de 30.000 por dia
A Anthropic tirou seu monorepo do git e o levou para o Scion, um sistema de controle de versão interno, depois que os merges diários subiram de cerca de 2.500 em maio de 2026 para mais de 30.000.
4 min de leitura

Em números
- code changes merged per day in September, up from about 2,500 in May
- 30,000+
- size of the main branch's history
- ~100 GB
- less CPU and memory than the old git mirrors, per Anthropic
- ~200x
- to migrate, with a team of seven
- 5 months
A Anthropic tirou seu principal repositório de código do git e o levou para o Scion, um sistema de controle de versão que ela mesma construiu. A empresa diz que mesclava cerca de 2.500 alterações de código por dia em maio de 2026 e mais de 30.000 por dia em setembro. O The Register liga esse salto ao Claude escrevendo uma parte maior do código da empresa. O git é construído sobre a ideia de que cada cópia guarda o histórico completo. Isso deixou de fazer sentido quando quase todo usuário passou a ser um agente de IA sempre online. A Anthropic descreveu o sistema em 13 de outubro, mas não vai liberá-lo.
Por que o git deixou de funcionar
“O gargalo, agora, é toda a infraestrutura de desenvolvimento construída para a escala humana”, escreve a Anthropic em seu post de engenharia. Escrever código já não é a parte lenta. As partes lentas são o controle de versão, os builds e a integração contínua (CI), os testes automatizados que rodam a cada alteração.
O repositório é um monorepo, um único repositório que guarda a maior parte do código da empresa. Seu tamanho explica a sobrecarga:
| Medida | Número |
|---|---|
| Histórico do branch principal | Quase 100 GB |
| Cópia de trabalho comprimida | Mais de 25 GB |
| Checkouts por dia só para CI | Cerca de 25 milhões |
| Tráfego git se cada checkout fosse um clone simples | Mais de 600 PB por dia |
| Espelhos internos de git no pico | Várias centenas |
A Anthropic tentou as soluções de costume. Usou clones rasos (shallow) e esparsos (sparse), que baixam só parte de um repositório, além de espelhos internos e cópias pré-montadas. Cada uma ficou mais difícil de manter à medida que os merges aumentavam. As cópias pré-montadas se afastavam do branch principal, e ferramentas como diff e blame quebravam em clones parciais.
Como o Scion funciona
O Scion parte do princípio de que seus clientes estão sempre online. O servidor cuida do histórico, do blame, dos commits, dos merges e dos rebases. Cada máquina guarda só um cache local limitado e sua cópia de trabalho, os arquivos que ela está de fato editando.
Cada alteração é armazenada como um changeset em um write-ahead log, um registro contínuo de alterações. Ele lista os arquivos que mudaram e aponta para o conteúdo deles no armazenamento de blobs. Os arquivos são buscados sob demanda. Assim, um checkout nunca precisa baixar antes um pacote de vários gigabytes.
O Scion funciona em três camadas: um daemon em cada máquina, um cache em cada região e um servidor autoritativo. A Anthropic diz que cada camada de cache responde a mais de 99% das requisições. O uso de branches além do main e dos branches de release é desencorajado.
O Scion não é um substituto direto do git. Nick G., engenheiro do Scion, explicou essa troca no Hacker News, em trecho citado por Simon Willison. “Como o Claude é de longe o maior usuário do Scion e está necessariamente online, isso simplesmente não era importante de fazer”, escreveu ele. Willison compara o resultado a sistemas centralizados mais antigos, como o Subversion.
O que a Anthropic diz ter ganhado
A Anthropic relata estes resultados em repositórios que rodam nativamente no Scion:
- Cerca de 200 vezes menos CPU e memória que seus antigos espelhos de git.
- Checkouts de CI e de pesquisa cerca de 100 vezes mais rápidos, levando segundos em vez de minutos.
- Um corte de 25% na CPU que seu sistema de CI usa.
Sete pessoas construíram o Scion, uma ferramenta de revisão de código chamada Antique e cerca de meia dúzia de sistemas relacionados. A migração levou cinco meses. O The Register informa que o trabalho no Scion começou em janeiro de 2026.
As outras ferramentas incluem busca de código, permissões de acesso por diretório e uma forma de integrar alterações sem uma fila de merge global única. A equipe as construiu com a ajuda do Claude. Uma reescrita feita pelo Claude do pipeline inicial de importação do git para o Scion usou 20 vezes menos memória e rodou quatro vezes mais rápido, diz a Anthropic.
Pessoas ainda conduziam o trabalho. “Muitas vezes, descobrimos que o papel dos engenheiros era dizer ‘não’ ao Claude”, disse a Anthropic, em trecho citado pelo The Register.
Alguém mais vai ter o Scion?
Não. A Anthropic diz que é difícil oferecer o Scion de uma forma amplamente útil. Diz também que ele não é adequado para uso geral. Em vez disso, a empresa está compartilhando o design e diz que quer trabalhar com o GitHub, o GitLab e a comunidade de código aberto.
O post sugere ideias que os serviços de hospedagem de git poderiam adotar sem mudar o funcionamento do git. Entre elas estão fazer mais trabalho no servidor e facilitar a combinação de clones esparsos e rasos. O próprio git também está mudando: cobrimos o debate sobre o padrão SHA-256 do Git 3.0 no começo deste mês.
O que isso significa para desenvolvedores
- O git ainda serve para a maioria das equipes. O The Register observa que o git continua sendo a escolha certa para a maioria dos repositórios. O Scion resolve um problema que aparece com dezenas de milhares de merges por dia.
- Acompanhe os custos de checkout de CI à medida que os agentes escalam. Cerca de 25 milhões de checkouts por dia foi o que quebrou o git aqui. Se seus agentes clonam o repositório a cada tarefa, meça esse tráfego agora.
- Trate agentes como clientes sempre online. Cópias offline importam para pessoas, não para agentes rodando na nuvem. Ferramentas que buscam arquivos sob demanda podem reduzir o custo de cada execução de agente.
- Espere que os serviços de hospedagem de git adotem essas ideias. A Anthropic quer que o GitHub e o GitLab adotem partes do design. Operações no servidor e clones parciais melhores são os primeiros passos prováveis.
- Mantenha humanos na revisão. Os engenheiros da Anthropic passaram boa parte do tempo rejeitando sugestões do Claude. Planeje essa carga de revisão quando agentes escreverem a maior parte do código.
Fontes
Artigos relacionados

Stacked pull requests do GitHub agora estão disponíveis para todos
O GitHub liberou as stacked pull requests para todos em 6 de outubro de 2026, em todos os planos do github.com, com filas de merge compatíveis com pilhas e a CLI gh stack.

Claude Code 2.1.287 traz Claude Mods para plugins com mais alcance
O Claude Code 2.1.287, lançado em 1º de outubro, deixa plugins mudarem o comportamento mais profundo do agente com os Claude Mods e traz um agente auxiliar opcional que aponta erros.

Claude Code só lê AGENTS.md com a telemetria ligada
O suporte a AGENTS.md no Claude Code 2.1.277 depende de um feature flag remoto e para de funcionar em silêncio sem telemetria, mostra uma issue no GitHub.