Claude Code ficou lento? Como descobrir se o problema é o seu projeto ou o serviço

Fala aí, beleza? Aquele momento em que você manda um pedido bobo, fica encarando o cursor piscar e tem certeza que o agente virou lesma no meio da tarefa…

Lentidão no Claude Code costuma ter duas famílias de causa, e elas não se resolvem do mesmo jeito

De um lado tem o que está no SEU lado: contexto entupido, pedido gigante sem recorte, um monte de customização carregada na sessão

Do outro tem o que está fora do seu alcance: serviço com problema ou o seu limite de uso batendo no teto

O problema é que quase todo mundo chuta. Reescreve o CLAUDE.md, apaga plugin, troca de modelo, tudo junto, e no fim não sabe o que resolveu (nem se resolveu)

Bora fazer diferente: uma hipótese por vez, com teste que dá pra repetir

Roteiro de diagnóstico: como isolar a causa em quatro testes

Antes de mexer em qualquer coisa, uma regra: muda UMA variável por vez

Se você altera cinco coisas juntas e melhora, você não aprendeu nada, só teve sorte 🙂

Ah, e antes do passo 1, uma parada rápida pra alinhar o vocabulário

Que contexto? É tudo que o Claude sabe da sessão: as instruções, os arquivos que ele leu, as respostas dele e conteúdo que nunca chegou a aparecer no seu terminal

Ou seja: o que você vê na tela é a ponta do iceberg

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

1. Rode /context antes de adivinhar. Ele mostra uma leitura ao vivo do uso de contexto por categoria, com sugestões de otimização, e ainda revela quais arquivos CLAUDE.md e de memória automática foram carregados. O erro comum deste passo: olhar o terminal e achar que o contexto é só aquilo que está escrito ali
2. Repita o MESMO pedido numa sessão limpa, com /clear. Ele reseta a conversa pra contexto vazio, e o que vem depois começa sem histórico nenhum. Se o pedido que arrastava volta a andar, a causa é acúmulo de contexto, não é o seu projeto. O erro comum deste passo: tentar /compact numa conversa recém aberta, sendo que ele precisa de pelo menos duas trocas anteriores pra funcionar
3. Suba com claude --safe-mode (ou defina CLAUDE_CODE_SAFE_MODE). Nesse modo, CLAUDE.md, skills, plugins, hooks, servidores MCP, comandos e agentes customizados não carregam, enquanto autenticação, escolha de modelo, ferramentas nativas e permissões continuam funcionando normalmente. Se o problema some aqui, a causa está em uma dessas superfícies. O erro comum deste passo: já sair mexendo em cinco configurações ao mesmo tempo em vez de cortar tudo de uma vez e religar depois
4. Separe limite de uso de incidente do serviço. O /usage abre o diálogo de conta e uso, com a conta logada, o plano, barras de uso da sessão e da semana e o tempo até cada limite resetar. Se estiver tudo tranquilo por ali, sobra a página pública status.claude.com. O erro comum deste passo: trocar de modelo achando que isso devolve acesso, quando os limites de sessão e semanais são compartilhados entre todos os modelos

Os quatro testes, na sequência:

# dentro da sessão
/context
/clear
/usage

# no terminal, sem nenhuma customização carregada
claude --safe-mode

Quatro comandos e você já sabe em qual metade do problema está pisando

Sintoma: cada resposta demora mais que a anterior na mesma sessão

A causa provável:

Contexto cheio

A sessão vai engordando com arquivo lido, saída de ferramenta, resposta longa, e o peso só cresce

Tem um caso específico que vale conhecer: a mensagem de que o autocompact está "thrashing", ou seja, a compactação automática até funcionou, mas um arquivo ou uma saída de ferramenta reencheu o contexto até o limite várias vezes seguidas

É enxugar gelo, e você sente isso como lentidão

A solução:

A documentação recomenda usar /compact regularmente como primeira medida de performance: ele resume as mensagens mais antigas preservando o contexto importante

Se a conversa já virou um monstro, /clear zera de vez

E dá pra rodar /autocompact com uma contagem de tokens, definindo o quanto o contexto enche antes da compactação automática entrar (o exemplo citado na própria documentação é /autocompact 500k)

/compact
/autocompact 500k
/clear

Como prevenir:

Se o aviso de thrashing apareceu, compactar de novo não adianta: tem que cortar a fonte que reenche o contexto

E o hábito que mais ajuda é simples: uma sessão por tarefa, em vez de arrastar aquela sessão eterna que já viu três features nascerem 😀

Sintoma: o agente lê meio projeto antes de escrever a primeira linha

A causa provável:

Pedido sem escopo

Quando você manda o Claude "investigar" alguma coisa sem delimitar, ele faz exatamente isso: lê centenas de arquivos e enche o contexto

A lentidão aqui é consequência, não doença

A solução:

A correção que a documentação aponta tem duas saídas: delimitar a investigação, ou usar subagentes pra que a exploração não consuma o contexto principal

O subagente faz o trabalho pesado no contexto dele e devolve só o resumo

Busca, log e conteúdo de arquivo ficam fora da conversa principal, que é justamente o que você quer preservar

Se a sua praia é deixar o agente rodando tarefas sozinho, essa separação de contexto vale ainda mais

Como prevenir:

Recorte a tarefa ANTES de mandar. "Investiga o bug" é convite pra leitura geral, "olha só esses dois módulos" não é

E cuide das instruções: a recomendação é mirar em menos de 200 linhas por arquivo CLAUDE.md, porque arquivos mais longos consomem mais contexto e ainda reduzem a aderência às regras

Quando as instruções crescem mesmo assim, a saída indicada são regras com escopo de caminho, que carregam só quando o Claude está trabalhando em arquivos que casam com o padrão

Tome cuidado com um detalhe: .claudeignore NÃO é recurso oficial do Claude Code

O pedido é uma issue aberta no repositório do Claude Code, e a documentação oficial não descreve esse arquivo

Ou seja: criar o arquivo e achar que resolveu é se enganar bonito

Sintoma: sumiu a lentidão no modo seguro, então a culpa é da sua configuração

A causa provável:

Se o --safe-mode andou rápido, a causa está numa das superfícies que ele desligou: CLAUDE.md, skills, plugins, hooks, servidores MCP, comandos e agentes customizados

Agora é só descobrir qual

A solução:

Religar uma de cada vez, testando o mesmo pedido depois de cada religada

Chato? É. Mas é o único jeito de saber

Começa pelos MCPs, que costumam ser os mais gordos: /mcp checa o status dos servidores e /mcp disable <nome> desativa os que não estão em uso, tirando as definições de ferramentas deles do contexto

/mcp
/mcp disable nome-do-servidor

Tem um atalho ótimo aqui pra quem é Pro, Max, Team ou Enterprise: nesses planos o /usage mostra atribuição do uso recente por skills, subagentes, plugins e servidores MCP individuais, cada um como porcentagem do total

Ele ainda sinaliza comportamentos como contexto longo ou cache miss quando um deles responde por 10% ou mais do uso recente

As teclas d e w alternam a janela entre as últimas 24 horas e os últimos 7 dias

Como prevenir:

Manter ligado só o que você usa de verdade

Aquele MCP que você instalou pra testar num sábado continua cobrando pedágio de contexto em toda sessão, se liga nisso

Sintoma: tarefa simples pensando demais (ou troca de modelo que custou caro)

A causa provável:

Nível de raciocínio desproporcional ao tamanho da tarefa

E, no meio do caminho, aquela troca de modelo feita na pressa

A solução:

O /effort ajusta quanto raciocínio o modelo aplica, e os níveis são low, medium, high, xhigh, max e ultracode

Esforço mais baixo é mais rápido e mais barato pra tarefas diretas, esforço mais alto entrega raciocínio mais profundo pra problema complexo

O nível high equilibra uso de tokens e inteligência e é o padrão em todos os modelos, com exceção do Opus 4.7, que tem xhigh como padrão

O low é reservado pra tarefa curta, delimitada e sensível a latência

Vale saber onde cada escolha gruda:

Pro modelo, o /model <alias|nome> troca na hora, e sem argumento ele abre o seletor

Repare num detalhe que explica muita lentidão inexplicada: o seletor pede confirmação quando a conversa já tem saída anterior, porque a próxima resposta relê o histórico inteiro sem contexto em cache

Trocar de modelo no meio de uma conversa longa não é de graça, beleza?

Dá pra definir logo na largada com claude --model <alias|nome>, pela variável de ambiente ANTHROPIC_MODEL, ou de forma permanente pelo campo model no arquivo de settings

/effort low
/model nome-do-modelo

# ou já na largada
claude --model nome-do-modelo

Como prevenir:

Escolher esforço e modelo no começo da sessão, não no meio dela

Sintoma: travou de vez ou o consumo de memória não baixa

A causa provável:

Ou a sessão parou de responder, ou o processo está segurando memória demais

São coisas diferentes, e o caminho é diferente também

A solução:

Se o Claude Code ficou sem responder, pode fechar o terminal sem pânico: rodar claude --resume no mesmo diretório retoma a sessão e a conversa não se perde

O --continue retoma a conversa mais recente, e --resume <session-id> retoma uma específica

O bom é que o Claude Code encontra a sessão pelo ID em qualquer projeto da máquina

claude --resume
claude --continue
claude --resume <session-id>

Se o uso de memória seguir alto, existe o /heapdump: ele escreve dois arquivos em ~/Desktop, um snapshot de heap JavaScript chamado <session-id>.heapsnapshot e uma quebra de memória chamada <session-id>-diagnostics.json

Esse comando não aparece no menu de comandos, precisa ser digitado por extenso. No Linux sem pasta Desktop, os arquivos vão pro diretório home

E agora o aviso que você não pode ignorar: o arquivo .heapsnapshot contém TODAS as strings do processo, incluindo a conversa inteira e credenciais

Não anexe isso em issue pública e não compartilhe com ninguém

Pra fechar o diagnóstico de ambiente, o /doctor verifica a instalação e as configurações do Claude Code

Como prevenir:

Se você sabe que a sessão vai ficar horas aberta, já vá pensando nela como algo descartável e retomável, não como um bem precioso que você tem medo de perder

Quando a lentidão não é sua: o que já aconteceu do lado da Anthropic

Essa hipótese externa não é desculpa de dev preguiçoso, é histórico documentado

A Anthropic mantém a página pública de status em status.claude.com, e publicou um postmortem em 23 de abril de 2026 admitindo que os relatos de piora nas respostas vinham de três mudanças que afetaram o Claude Code, o Claude Agent SDK e o Claude Cowork. A API não foi impactada

Uma delas é quase irônica pro nosso tema: em 4 de março de 2026 a empresa mudou o esforço de raciocínio padrão do Claude Code de high pra medium justamente pra reduzir a latência muito longa que alguns usuários viam no high, a ponto da interface parecer travada

Depois classificou a troca como errada e reverteu em 7 de abril de 2026

Outra mudança, de 26 de março de 2026, limpava o raciocínio antigo de sessões paradas há mais de uma hora pra reduzir a latência ao retomar. Só que um bug fazia isso a cada turno em vez de uma vez só, e o Claude ficava repetitivo e esquecido

Os três problemas foram resolvidos em 20 de abril de 2026, na versão v2.1.116, e em 23 de abril de 2026 os limites de uso dos assinantes foram resetados

Moral da história: às vezes o CLAUDE.md que você passou a tarde reorganizando nunca foi o problema 😛

O que fazer quando a causa está fora do seu alcance

Primeiro, checar status.claude.com ANTES de refatorar o projeto

É um clique, e ele te poupa de uma tarde inteira arrumando algo que não estava quebrado

Segundo, conferir se você está rodando uma versão atual do Claude Code, já que correção de comportamento chega por versão nova (o postmortem acima é o exemplo)

Terceiro, distinguir incidente de limite de uso pelo /usage. Barra de sessão e de semana cheia é uma história, serviço com problema é outra

E segura o impulso de trocar de modelo pra fugir do teto: os limites de sessão e semanais são compartilhados entre os modelos, então trocar não devolve acesso

Se o assunto virou plano e teto de uso, aí a conversa é outra e passa por saber se o Max ainda compensa

E o que eu não consigo te afirmar aqui: se existe incidente rolando HOJE, no momento em que você lê isso

Só a página de status responde essa

Conclusão

Lentidão no Claude Code quase sempre cai em três baldes: contexto, escopo ou customização

O quarto balde, o do serviço, existe e é real, mas é o último a ser checado justamente porque não depende de você

A diferença entre resolver e chutar não é conhecer comando raro, é rodar os testes na ordem certa

Então, próxima vez que o agente arrastar: abre o /context e o /usage antes de qualquer refatoração

E guarda o --safe-mode como o teste que corta o problema no meio, porque ele responde a única pergunta que importa no começo: é a minha configuração ou não é?

Bora testar em vez de adivinhar… até o próximo post!