Anthropic torna o Claude.ai três vezes mais rápido em duas semanas

O sprint e os resultados

Em agosto, engenheiros da Anthropic conduziram um sprint de duas semanas que tornou o claude.ai e o aplicativo desktop do Claude cerca de 3x mais rápidos (média pela média geométrica de treze medições). O ponto de partida foi o feedback de usuários sobre lentidão - que, segundo a equipe, estava correto. Todo o trabalho aconteceu em um único canal do Slack, com o Claude presente em todas as conversas.

O foco foram quatro jornadas que representam 95% da atividade dos usuários: abrir o aplicativo, iniciar uma conversa, carregar uma conversa existente e enviar uma mensagem. No percentil 75, o carregamento fresco do claude.ai caiu de 3,1 segundos para 0,55 segundo (5,6x mais rápido), o início de uma sessão do Claude Code caiu de 0,8 para 0,3 segundo, e o carregamento de uma sessão Claude Cowork na nuvem caiu de 2,6 para 0,73 segundo. Em termos agregados, a equipe estima economizar dezenas de milhares de horas de espera dos usuários por dia. Foram mescladas mais de três mil alterações sem nenhum incidente visível ao cliente ou rollback.

A metodologia: medir para escalar

A tese central do sprint: qualquer coisa pode ser otimizada por hill climbing se puder ser medida. Antes do sprint, o Claude analisou dados de uso via servidor MCP do Datadog e identificou as jornadas prioritárias. Cerca de vinte projetos planejados foram concluídos cedo - doze dos treze alvos foram atingidos até o terceiro dia, com mudanças como um composer estático embutido no HTML (permitindo digitar antes da inicialização do React) e cache pré-compilado de código V8 no desktop.

Para iterar mais rápido que o ritmo de deploys, a equipe buscou medições determinísticas em laboratório: contagens de instruções com Valgrind e node --predictable, contagens de chamadas do V8, commits do React, recalculações de estilo e mutações do DOM. Cada benchmark tinha duas funções: métrica que o Claude podia mover no laboratório e ratchet no CI que só podia baixar. Benchmarks instáveis ou sem correlação com a latência real eram descartados. Em dois caminhos quentes, o Claude reduziu instruções em 48% e 31%, com queda no tempo real de 78% e 44%, provando que as contagens acompanhavam o relógio.

O loop de trabalho e a escala horizontal

O loop funcionava assim: alguém abria uma thread sobre um trecho lento, o Claude traçava o fluxo, construía um benchmark, enviava PRs dimensionados para revisão (com mudanças visíveis atrás de feature flags), acompanhava o deploy, lia os dados de campo e, se a performance melhorava, travava o ganho no ratchet. Na prática, rodavam mais de 150 threads simultâneas, com o próprio Claude abrindo novas threads para perseguir oportunidades que descobria sozinho.

Cada medição revelava problemas: um censo de hooks do React encontrou 6.900 hooks e 900 assinaturas de store renderizando a cada tecla no composer; um seletor :root:has() adicionava 24 milissegundos a cada mudança no DOM; um location.reload() residual causava meio milhão de recarregamentos ocultos por dia; e snapshots de cache eram clonados no IndexedDB duas vezes por minuto na thread principal. Um caso emblemático: caracteres fora do Latin-1, como travessões, faziam o V8 armazenar strings como UTF-16, colocando regexes de syntax highlighting no caminho de dois bytes e congelando a página por até um segundo - corrigido com uma mudança de vinte linhas.

Guardrails e direção humana

Segurança veio antes da velocidade: revisão automatizada em todos os PRs com ao menos uma aprovação humana, testes de unidade antes das otimizações e quase duzentas feature flags (mais da metade limpas ao fim do sprint). O composer estático, deliberadamente frágil, recebeu dezenas de guardrails: testes que garantem que a marcação estática não desvia do render do React, comparações em catorze tamanhos de viewport e relatos de deslocamento no campo com precisão de décimos de pixel. Rollouts incrementais capturaram um caso que nenhum teste de laboratório detectaria: um deslocamento de layout causado por um prerender do Chrome em páginas gerenciadas por organizações, com rodapé que encolhia a página.

O papel humano se dividiu em três funções: ambição (encorajar o Claude a ser mais ousado que seu escopo padrão), taste (decisões sobre tradeoffs perceptíveis ao usuário, com screenshots antes/depois) e direção (sequenciamento de threads e fechamento quando os retornos diminuíam - um PR de 900 linhas foi rejeitado porque 2ms por envio não justificavam a complexidade).

Sidequest de streaming e próximos passos

Numa sidequest de streaming, o Claude construiu um rig de 120 Hz no headless Chrome via controle de frames do DevTools e trabalhou com um orçamento de 8,33ms por frame. Foram quase sessenta PRs em uma thread: respostas longas que antes bloqueavam a thread principal por cerca de 750ms passaram a bloquear cerca de 200ms, com um terço do uso de CPU e 120 fps sustentados. O renderizador de streaming foi reconstruído para tocar apenas o que muda; respostas longas travam 9x menos em laptops mais lentos.

A conclusão: claude.ai e o app desktop estão cerca de 3x mais rápidos que no início de agosto, e os ratchets devem manter o ganho. Restam o percentil 95, outras jornadas e conversas muito longas a melhorar. Um post futuro cobrirá contribuições que chegaram a Electron, Chromium e Node.js.