Outro dia um CTO que mentoro me mandou um print. O dev sênior dele — o melhor do time — tinha acabado de reclamar que o Claude Code “ficava travado depois de 40 minutos”. A sessão começava rápida, respostas em segundos. Depois de meia hora de refactoring pesado, cada resposta levava 15, 20, 30 segundos. No final, o dev reiniciava a sessão, perdia contexto, e começava tudo de novo.
O CTO perguntou: “É rate limit? É o modelo? É a máquina dele?”
Nenhum dos três. Era um bug de arquitetura interna que fazia o Claude Code ficar exponencialmente mais lento a cada mensagem. E na v2.1.90, lançada em 1 de abril, a Anthropic corrigiu três gargalos de uma vez — todos com o mesmo padrão: operações que escalavam de forma quadrática.
Vou te explicar por que isso é mais importante do que parece.
O Que Significa “Quadrático” e Por Que Você Deveria Se Importar
Quando um programador diz que algo é “quadrático”, ele quer dizer que o tempo de processamento cresce com o quadrado do tamanho da entrada. Na prática:
Ou seja: dobrar a conversa não dobra a latência — quadruplica. É por isso que a sessão começa voando e depois de 40 minutos parece que travou. Não é que ficou “um pouco mais lenta”. Ficou geometricamente mais lenta.
E o pior: o dev não sabe se é rate limit, se é o modelo pensando, se é a internet. Ele só sabe que está lento. E a resposta natural? Reiniciar a sessão. Perder todo o contexto acumulado. Começar do zero.
Os Três Gargalos Que a v2.1.90 Corrigiu
A v2.1.90 do Claude Code trouxe três melhorias de performance que atacam exatamente esse padrão:
1. SSE Transport: De Quadrático Para Linear
O Claude Code usa Server-Sent Events (SSE) para receber respostas do modelo em tempo real — é o que permite aquele efeito de “digitando” enquanto a resposta vai aparecendo. Cada “frame” SSE é um pacote de dados que chega do servidor.
O problema: quando esses frames eram grandes (respostas longas, blocos de código extensos), o parser processava cada frame de uma forma que escalava quadraticamente com o tamanho. Um frame de 10KB era rápido. Um frame de 100KB não era 10x mais lento — era 100x mais lento.
A correção: o transport SSE agora processa frames grandes em tempo linear. Frame 10x maior = 10x mais tempo. Proporcional, previsível, sem surpresas.
2. SDK Sessions: Transcript Writes Sem Degradação
Para quem usa o Claude Code via SDK ou API (automações, pipelines, agent teams), existe um mecanismo de transcript — um log de tudo que aconteceu na conversa. Cada turno novo escrevia o transcript inteiro.
O problema: conversas longas acumulavam transcripts enormes. E a cada turno, a operação de escrita precisava processar todo o histórico acumulado, não só o turno novo. Resultado: quadrático. Sessão com 10 turnos? Rápido. Sessão com 200 turnos? Rastejando.
A correção: transcript writes não degradam mais com o tamanho da conversa. A operação agora é proporcional ao turno novo, não ao histórico completo.
3. MCP Schema Lookup: Overhead Eliminado
O Claude Code suporta MCP (Model Context Protocol) — servidores externos que adicionam ferramentas ao modelo. Cada MCP server declara suas ferramentas com um schema JSON que descreve parâmetros e formatos.
O problema: a cada turno da conversa, o Claude Code fazia JSON.stringify de todos os schemas de todas as ferramentas MCP para calcular uma cache key. Se você tinha 5 MCP servers com 30 ferramentas no total, essa serialização acontecia toda vez que o modelo pensava. Em sessões com centenas de turnos, o overhead acumulado era significativo.
A correção: o lookup de cache key foi eliminado por turno. Zero overhead recorrente.
O Bug Documentado Que Ninguém Viu
O que torna isso mais real é o Issue #10881 no GitHub do Claude Code. Um usuário reportou exatamente o sintoma: “After long sessions with several autocompacts, Claude Code becomes slower and slower to the point that it takes several minutes between requests.”
A análise de root cause feita pela comunidade identificou o problema no renderer: um buffer chamado fullStaticOutput que nunca era limpo. A cada output, o buffer crescia via concatenação de strings (+=). Em JavaScript, strings são imutáveis — cada += copia o buffer inteiro. Buffer de 10KB? Rápido. Buffer de 1MB? Cada operação copia 1MB.
E pior: o método reset() limpava outros estados mas esqueceu de limpar esse buffer. Resultado: O(n) por operação × n operações = O(n²) total. Quadrático clássico.
Esse é um padrão que se repete em software complexo: cada operação individual parece rápida, mas o acúmulo cria degradação que só aparece depois de uso prolongado. Exatamente o tipo de bug que um dev não consegue diagnosticar porque “funciona bem quando testo rapidamente”.
A Matemática Que Afeta Seu P&L
Agora vamos falar de dinheiro. Porque degradação de performance em AI coding tools não é só UX — é custo.
Segundo a Morph LLM, que analisou 42 sessões reais de coding agents:
Um estudo independente comparou quatro AI tools resolvendo o mesmo bug e encontrou um gap de eficiência de 5x entre a mais econômica e a mais cara — não pelo modelo, mas pela estratégia de busca. O Claude Opus usou 23K tokens. O Gemini 2.5 Pro? 118K tokens. Mesmo bug.
Agora adiciona degradação quadrática nessa conta:
Para uma SH com 20 devs em sessões de 2-4 horas:
A Redis estima que otimizações combinadas de token management entregam 40-70% de redução de custo. Os três fixes da v2.1.90 são uma camada importante dessa stack.
Por Que Sessões Longas São o Campo de Batalha Real
Segundo o LogRocket, performance de LLMs cai 39% em média quando benchmarks são transformados em conversas multi-turn. E capacidade efetiva de context window é 60-70% do máximo anunciado — ou seja, um modelo com 200K tokens de contexto funciona bem até ~130K.
Isso significa que sessões longas são duplamente penalizadas:
Os fixes da v2.1.90 eliminam o segundo problema. O primeiro é inerente à arquitetura de transformers — mas pelo menos agora a ferramenta não piora a situação.
E tem outro dado relevante: com 1M tokens de contexto, 1 em cada 4 retrievals falha. A sessão longa não é só mais lenta — é menos confiável. Manter performance constante da ferramenta é o mínimo para que o dev possa confiar no output.
O Que Eu Penso
Na minha experiência com 300+ software houses, o padrão que mais vejo é este: o time adota Claude Code, os primeiros dias são mágicos, e depois de duas semanas começa o “ah, ficou lento” e “não é mais tão bom quanto antes”. Em muitos casos, não é o modelo que piorou — é a sessão que acumulou degradação.
É o tipo de problema que não aparece em demo de 5 minutos. Aparece quando o dev está no meio de um refactoring de 3 horas num módulo legado com 50 arquivos. Exatamente quando ele mais precisa que a ferramenta funcione bem.
Esses três fixes da v2.1.90 são daqueles que ninguém vai postar no Twitter. Não tem screenshot bonito, não tem feature nova pra mostrar. Mas pra quem usa Claude Code 8 horas por dia em projetos reais — que é o caso dos devs nas SHs que mentoro — é a diferença entre uma ferramenta confiável e uma ferramenta que “às vezes trava”.
E o melhor: o dev não precisa fazer nada. Basta estar na v2.1.90 ou superior. Sem config, sem flag, sem variável de ambiente. Atualiza e pronto.
O Stack Completo de Performance do Claude Code
Esses três fixes não existem isolados. Eles fazem parte de uma stack de otimização que a Anthropic vem construindo nas últimas versões:
| Versão | Otimização | Impacto |
|---|---|---|
| v2.1.86 | Read tool compact format | Menos tokens de input por leitura |
| v2.1.89 | Hook output cap 10K chars | Contexto não poluído por outputs de hooks |
| v2.1.90 | SSE linear + SDK fix + MCP schema | Sessões longas sem degradação |
| v2.1.91 | Edit tool shorter anchors | Menos output tokens por edit |
| v2.1.92 | Write tool diff 60% faster | Menos tempo de processamento em writes |
Combinadas, essas otimizações atacam o problema de todos os ângulos: input tokens, output tokens, tempo de processamento e overhead interno. A Morph LLM calcula que o potencial de economia combinada é de 55-70% em custo de tokens para quem aplica todas as otimizações disponíveis.
E Agora?
Se você roda uma software house e seu time usa Claude Code:
claude --version. Se está abaixo de v2.1.90, atualize. Cada versão a partir da v2.1.86 traz otimizações de performance e custo./cost pra ver o breakdown por modelo e cache hits. Sessões degradadas queimam mais tokens — e tokens são dinheiro.Se você quer implementar esse nível de visibilidade e otimização na sua software house, é exatamente o tipo de coisa que trabalho com os times que mentoro. Não é sobre a ferramenta — é sobre como seu time usa a ferramenta.
Sou Thulio, mentoro 300+ SHs desde 2016.
