Anthropic reescreve a Messages API em Rust com o Claude, e uso de CPU cai 40–50%

A Anthropic reescreveu em Rust a Messages API, a interface pela qual os desenvolvedores acessam o Claude. Segundo Katelyn Lesse, da Anthropic, que falou sobre o assunto no podcast Latent Space, não havia nenhum desenvolvedor Rust entre os participantes do projeto. O código foi escrito pelo próprio Claude. As pessoas elaboraram o plano e verificaram se o comportamento da implementação antiga e da nova coincidia com tráfego real. O resultado, conforme resumiu no X o autor Somi: o uso de CPU caiu 40–50%. A publicação passou de 182 mil visualizações porque atinge um dos dogmas mais persistentes do setor: "nunca reescreva tudo do zero".

Quem fez o quê: o modelo escreve, as pessoas aprovam o trabalho

A divisão de tarefas importa mais aqui do que a linguagem em si. O Claude ficou responsável por escrever o código. Os engenheiros cuidaram de duas coisas: o plano de reescrita e o critério de aceitação. O critério foi a comparação entre a versão antiga e a nova em requisições reais. Se os dois serviços entregam resultado equivalente com o mesmo tráfego, a nova implementação é considerada funcional. Para isso, não é preciso dominar os idiomatismos do Rust; basta saber descrever com precisão o que o serviço deve fazer e verificar isso com dados.

Isso explica por que "zero desenvolvedores Rust" não soa como loucura. Antes, a principal barreira para trocar de linguagem era a falta de gente capaz de escrever e revisar o código. Neste caso, a barreira sai da escrita e vai para a verificação. A equipe tem um parâmetro de referência, que é o sistema em produção funcionando, e a nova versão precisa se comportar da mesma maneira que ele. Esse formato combina bem com modelos: a tarefa é claramente definida e o resultado pode ser verificado automaticamente.

O que significam 40–50% de CPU

Para uma API que atende um número enorme de requisições, o tempo de processador se converte diretamente em custo de infraestrutura. Se, com a mesma carga, o serviço consome metade da CPU, ou se precisa de menos servidores, ou o mesmo parque aguenta mais tráfego. Essa é uma dedução nossa a partir do número, e não uma declaração da Anthropic: o resumo não diz quanto dinheiro a empresa economizou.

Há outro ponto que chama atenção. A estratégia de "reescrever um serviço crítico em uma linguagem compilada com controle rígido de memória" é conhecida há muito tempo. Antes, ela custava meses de trabalho de especialistas, e a maioria das equipes desistia. Se a maior parte do código é escrita por um modelo, o custo do experimento cai, e a conta do retorno passa a ser outra. O veredito de Somi — "o conselho de não fazer uma grande reescrita está morto" — soa forte, mas um único caso não derruba a regra. Ele apenas mostra as condições em que a regra deixa de valer.

O que falta no resumo

A fonte aqui é uma postagem curta com link para o podcast, e não um relatório técnico. Dela não dá para saber várias coisas importantes:

• qual parte exatamente da Messages API foi reescrita: a stack inteira ou componentes isolados;
• como mudaram a latência e a vazão, e não apenas a carga de CPU;
• quanto tempo o trabalho levou e quantas iterações o Claude precisou;
• que divergências entre a versão antiga e a nova foram encontradas na comparação e como foram analisadas;
• como a equipe vai manter um código escrito em uma linguagem que ninguém lá domina.

O último ponto é o mais incômodo. Um código que nenhuma pessoa leu a fundo terá de ser mantido, e será preciso rastrear nele erros raros e adicionar funcionalidades. Enquanto o Claude estiver à disposição, isso é contornável. Mas o custo de longo prazo dessa abordagem não é visível a partir de um único caso.

Conclusão prática

A receita que dá para aproveitar não depende do Rust. Primeiro, é preciso fixar o comportamento do serviço existente: coletar requisições e respostas reais e montar a comparação entre as duas implementações. Depois, o plano e a aceitação ficam com as pessoas, e o trabalho bruto fica com o modelo. Quanto melhor for a sua infraestrutura de testes e o shadowing de tráfego (execução em paralelo com tráfego espelhado), mais segura será uma reescrita desse tipo. Sem isso, o modelo simplesmente gera rapidamente muito código não verificado. Antes de repetir a experiência da Anthropic, vale esperar a versão completa do relato e ver como a equipe resolveu as questões que não aparecem no resumo.