A Anthropic parou de usar o Git no próprio monorepo e criou um sistema de controle de versão do zero, o Scion. O motivo cabe numa linha: os agentes do Claude multiplicaram o código da empresa, e os merges por dia passaram de 2.500 em maio para mais de 30.000 em setembro. O Git, feito para pessoas, virou o maior gargalo.

Li o post original de engenharia, publicado em 13 de outubro, e vou explicar o que o Scion faz de diferente, os números, o papel do Claude Mythos na construção e a resposta para a pergunta que todo mundo fez: dá para usar o Scion aqui no Brasil? Spoiler: não, mas dá para copiar as ideias hoje, no seu Git.

• O que é o Scion e por que ele vive conectado

• Por que o Git não aguentou 30 mil merges por dia

• Os resultados e o papel do Claude Mythos

• Dá para usar o Scion no Brasil, e o que fazer no lugar

O que é o Scion

O Scion é o sistema de controle de versão que a Anthropic construiu para substituir o Git no monorepo interno. A grande diferença está na premissa: o Git assume que cada máquina tem uma cópia completa e pode trabalhar sem internet; o Scion assume que o cliente está sempre conectado e que o servidor é a fonte da verdade.

Nas palavras do post de engenharia da Anthropic, "Clients are always online". Na prática, isso muda tudo:

• Sem push: commits, merges e rebases acontecem no servidor. Não existe o "subir" do Git.

• Consultas por API: histórico, blame e diferenças ficam disponíveis por API, então muitos robôs de CI nem precisam baixar o repositório.

• Cópia local opcional: "The working copy is optional, and sparse by design". Quando há cópia, um arquivo só é baixado no momento em que alguém o lê.

• Changesets em vez de packfiles: cada mudança guarda a lista de arquivos alterados e ponteiros para o conteúdo, guardado num armazenamento de blobs.

Por baixo, são quatro camadas: o cliente scn, um daemon local, um cache regional e o servidor. A Anthropic diz que cada camada acerta o cache em mais de 99% das vezes, e que mover uma branch é uma troca atômica numa linha do Spanner, o banco distribuído do Google Cloud. O desenho se inspira no Piper, do Google, e no Sapling, da Meta.

Por que o Git não aguentou

Porque o Git foi desenhado para pessoas trabalhando em cópias completas, e quase todos os "clientes" da Anthropic hoje são agentes e jobs automáticos, sempre online, fazendo checkout o dia inteiro. Quando os merges cresceram mais de dez vezes em quatro meses, o controle de versão virou o maior gargalo do desenvolvimento.

Os números que o post mostra explicam o tamanho do problema:

Medida	Valor
Merges por dia em maio de 2026	Cerca de 2.500
Merges por dia em setembro de 2026	Mais de 30.000 (cerca de 12 vezes)
Histórico da branch principal	Quase 100 GB
Cópia de trabalho compactada	Mais de 25 GB
Checkouts de CI por dia	Cerca de 25 milhões
Tráfego Git por dia, sem otimização	Mais de 600 PB

Para segurar isso no Git, a empresa chegou a manter várias centenas de espelhos internos do repositório, cada vez mais difíceis de manter. Imagine 25 milhões de vezes por dia alguém baixando um repositório de 25 GB: não existe servidor que aguente isso por muito tempo, por mais que você o espelhe.

O Git foi feito para um programador com o notebook no colo. O Scion foi feito para milhares de agentes que nunca desconectam.

Os resultados e o papel do Claude

A infraestrutura nova usa 200 vezes menos CPU e memória que os espelhos de Git, e o checkout de código para CI ficou cerca de 100 vezes mais rápido, de minutos para segundos. A migração inteira levou cinco meses, com uma equipe de sete pessoas e muito trabalho feito pelo Claude.

Resultado	Antes (Git)	Depois (Scion)
CPU e memória da infraestrutura	Centenas de espelhos	200 vezes menos
Checkout para CI e pesquisa	Minutos	Segundos (cerca de 100 vezes mais rápido)
Capacidade de CPU do CI	Base	25% liberada

A parte que mais me chamou atenção é como o sistema foi construído. A mesma equipe de sete pessoas fez o Scion e o Antique, a ferramenta interna de revisão de código. E o Claude Mythos Preview, a versão interna do modelo mais forte da Anthropic, reescreveu o pipeline que importava o histórico do Git para o Scion, antes feito à mão: o resultado usou 20 vezes menos memória e ficou 4 vezes mais rápido.

O papel dos engenheiros mudou junto. Segundo o post, eles definiam a intenção, a arquitetura e as restrições, e muitas vezes o trabalho era dizer "não" quando o agente violava uma regra do sistema. O Claude também foi usado para monitorar o sistema, pelo Claude Tag, e para achar otimizações em consultas de ancestralidade de commits. É o mesmo jeito de trabalhar que descrevi no post sobre o Claude Code, numa escala que poucos vão ver.

Outra mudança de processo: a fila global de merge saiu de cena. A Anthropic passou a testar depois do merge e antes do deploy, e diz que o Claude costuma resolver os conflitos mais rápido do que um humano os perceberia.

Dá para usar o Scion no Brasil?

Não, nem no Brasil nem em lugar nenhum fora da Anthropic. O Scion é interno: não tem código aberto, não é vendido como produto e a própria empresa diz que ele "não é substituto do Git para uso geral". O que dá para usar hoje são as ideias dele, aplicadas ao seu Git.

A Anthropic explica que seria difícil oferecer o Scion a outras empresas, porque adotá-lo exige migrar todo o ciclo de desenvolvimento junto, incluindo revisão de código, busca e CI. Em vez disso, ela publicou a visão para que plataformas como GitHub e GitLab adotem partes, como operações de merge feitas no servidor por API. Perguntei ao Jev se isso muda até junho de 2027: ele dá 6% de a Anthropic abrir o código do Scion, 4% de ela vendê-lo como produto e 5% de o GitHub lançar merge e rebase só no servidor, por API, para agentes.

O que você pode fazer hoje, no Git, com as mesmas ideias do Scion (baixar só o que precisa):

1. Clone parcial: baixa o histórico sem o conteúdo antigo dos arquivos, que vem sob demanda.

2. Clone raso no CI: baixa só o último commit. A ação actions/checkout do GitHub já faz isso por padrão.

3. Checkout esparso: baixa só as pastas que aquele job usa, ótimo para monorepo.

4. Scalar: vem com o Git desde a versão 2.38 e liga várias dessas otimizações de uma vez em repositórios grandes.

# clone parcial: histórico completo, arquivos antigos só quando precisar
git clone --filter=blob:none https://github.com/sua-empresa/seu-repo.git

# clone raso para CI: só o último commit
git clone --depth 1 https://github.com/sua-empresa/seu-repo.git

# checkout esparso: só as pastas que o job usa
git sparse-checkout set apps/site packages/ui

Se você quer experimentar algo mais parecido com o Scion, o cliente do Sapling, da Meta, é de código aberto e funciona com repositórios do GitHub. O servidor e o sistema de arquivos virtual dele, que são a parte "sempre conectada", não têm suporte público para uso fora da Meta.

O que isso muda para quem programa aqui

Para a maioria dos times brasileiros, nada de imediato: o Git aguenta com folga um repositório de empresa média. O recado é outro: quando os agentes escrevem o código, o volume muda de ordem de grandeza, e a infraestrutura feita para humanos vira gargalo em lugares inesperados, como o CI e o controle de versão.

Se você usa agentes como o Claude Code ou os agentes que trabalham sozinhos, os sinais aparecem cedo: CI na fila, clone lento, conflito de merge todo dia. As técnicas acima resolvem boa parte disso antes de qualquer migração. Na minha leitura, mais agentes mexendo no repositório também aumentam o risco de um segredo ir parar no histórico, como mostrei no post das 543 mil chaves vazadas no GitHub.

Também vale acompanhar como a própria Anthropic trabalha, porque o que ela faz por dentro costuma virar produto meses depois. Eu explico como faço isso em minha estratégia para acompanhar a Anthropic, e o próximo lançamento esperado está no post do Claude Opus 6.

Se o seu time começou a usar agentes de IA e o CI, os merges ou os deploys viraram gargalo, é o tipo de diagnóstico e ajuste que faço na consultoria técnica.

As apostas, escritas pelo lado que o Jev acha mais provável. Eu confiro em julho de 2027, e o resultado vai para o placar de previsões:

Perguntas frequentes

O que é o Scion da Anthropic?

É o sistema de controle de versão que a Anthropic criou para substituir o Git no monorepo interno, anunciado em 13 de outubro de 2026. Ele assume clientes sempre conectados, faz commits e merges no servidor e baixa arquivos só quando alguém os lê.

Por que a Anthropic trocou o Git?

Porque os agentes de IA multiplicaram o volume de código: os merges por dia foram de cerca de 2.500 em maio para mais de 30 mil em setembro de 2026. O Git, desenhado para cópias completas e trabalho offline, virou o maior gargalo.

Posso usar o Scion no Brasil?

Não. O Scion é interno da Anthropic, sem código aberto e sem versão comercial, e a empresa diz que ele não substitui o Git para uso geral. Dá para aplicar as ideias dele no Git com clone parcial, clone raso e checkout esparso.

O Scion funciona sem internet?

Não foi feito para isso. O Scion assume que o cliente está sempre conectado ao servidor, e muitas operações acontecem só por API, sem cópia local do repositório. O post da Anthropic não descreve um modo offline.

Quais foram os ganhos do Scion?

Segundo a Anthropic, a infraestrutura usa 200 vezes menos CPU e memória que os antigos espelhos de Git, o checkout para CI caiu de minutos para segundos e 25% da capacidade de CPU do CI foi liberada.

Quem construiu o Scion?

Uma equipe de sete pessoas, em cinco meses, com muito trabalho do Claude. O Claude Mythos Preview reescreveu o pipeline de importação do histórico do Git, que ficou 4 vezes mais rápido e com 20 vezes menos memória.