A Anthropic migrou por inteiro a Messages API que sustenta o Claude, de Python para Rust. Katelyn Lesse, responsável pela engenharia, e Angela Jiang, responsável pelo produto, contaram como foi a migração no podcast Latent Space: depois da troca, o uso de CPU caiu cerca de 40% a 50%, o tempo de resposta do primeiro token encurtou em torno de 10% a 20%, e nas tarefas de longa duração a melhoria foi ainda mais nítida. Segundo as convidadas, a API em Rust estava totalmente implantada uma semana antes da gravação.
A Messages API é a principal porta de entrada para desenvolvedores que chamam o Claude. Angela Jiang lembra que, quando entrou na empresa, há cerca de um ano, o sistema ainda era um serviço monolítico em Python, rodando em uma única região do GCP.
O gargalo era a CPU
Quando se fala dos gargalos das empresas de modelos de linguagem, o olhar externo costuma ir para as GPUs, mas nesta entrevista o que apareceu repetidamente foi a CPU. Com o crescimento rápido do uso, o serviço de API, o back-end do produto, os sandboxes de código e a integração contínua passaram a disputar CPU; quanto mais código se escreve, mais frequentemente a CI roda. Conforme a descrição das convidadas, a equipe de pesquisa e os sandboxes do produto dividiam a mesma cota de CPU: o que um lado usa a mais, o outro precisa usar a menos. Nesse ambiente, o serviço em Python se mostrava especialmente custoso em recursos.
Escolher Rust gerou controvérsia interna, e o motivo era direto:
"we don't have a single Rust developer in the room."
(Não há um único desenvolvedor Rust na sala.)
Só depois a equipe foi contratando engenheiros com experiência em Rust.
Humanos desenham a arquitetura, Claude escreve a implementação
A divisão de trabalho foi esta: os engenheiros cuidam do projeto e da verificação do sistema distribuído, e a maior parte do código de implementação fica com Claude, que também foi usado para ajudar os engenheiros a adquirir o conhecimento de Rust necessário. As convidadas ressaltaram que planejar e verificar importam mais do que escrever o código em si.
A verificação seguiu um método bastante tradicional. A equipe primeiro construiu uma ramificação completa da API em Rust, replicou em sombra o tráfego real para ela e comparou, requisição por requisição, se as saídas dos sistemas antigo e novo coincidiam; depois, com feature flags e balanceamento de carga, foi deslocando o tráfego real aos poucos. A migração ficou a cargo de um grupo dedicado, enquanto os demais engenheiros continuaram desenvolvendo novos recursos. Para que os dois lados não se afastassem cada vez mais, a equipe usou análise estática para marcar funcionalidades adicionadas em Python que ainda não tinham correspondente em Rust, e o grupo da migração procurou recusar novos pedidos durante o período.
A estimativa das convidadas é que, pelo método habitual de migrar de forma incremental, bloco a bloco, o trabalho poderia levar vários anos; desta vez foi uma portabilidade integral, de uma só vez. Quanto tempo exatamente levou e que proporção do código foi gerada por Claude, a entrevista não informou, e hoje não há como verificar externamente.
Comparando com reescritas semelhantes
Reescritas em grande escala nesse molde, "o modelo escreve, o humano garante", já apareceram algumas vezes recentemente. O GitHub revelou antes ter usado o Copilot para reescrever seu próprio runtime em cerca de 830 mil linhas de Rust; por volta do lançamento do Opus 5.5, uma equipe também o usou para levar o compilador do TypeScript para Rust em duas semanas. O ponto comum é que a linguagem de destino foi Rust em todos os casos, e a verificação se apoiou na comparação entre saídas antigas e novas ou em uma suíte de testes completa.
A diferença está no custo do erro. Quando compiladores e ferramentas de desenvolvimento falham, o impacto costuma ficar na máquina local do desenvolvedor; a Messages API recebe todas as chamadas externas, e qualquer inconsistência de comportamento cai direto nos sistemas de produção dos clientes. O fato de a Anthropic conseguir fazer uma migração integral nesse caminho se deve ao método antigo de tráfego em sombra e comparação resposta a resposta; a velocidade de escrita do modelo, sozinha, não sustentaria isso.
Para outras empresas, o que talvez se aproveite é o processo de verificação, e não necessariamente a escolha da linguagem. Sem condições de ter tráfego em sombra e comparação de saídas, é difícil saber se um grande lote de código despejado de uma vez pelo modelo se comporta como o sistema antigo.
Próximo passo: o estado da conversa
A equipe revelou que fará ajustes na camada de arquitetura, e uma das direções é guardar o estado da conversa no servidor, para que o cliente não precise reenviar o histórico completo a cada turno. Em conversas longas, isso pode eliminar muita transmissão e processamento repetidos. Quando essa mudança chega, e se afetará as interfaces atuais ou a forma de cobrança, a Anthropic ainda não divulgou.
Fontes: entrevista do podcast Latent Space, CocoLoop, documentação para desenvolvedores da Anthropic; a queda de CPU, a faixa de melhoria da latência do primeiro token e a situação da implantação total foram conferidas com base na entrevista.