Ela tenta, não funciona. Tenta de novo quase igual, não funciona. Tenta uma terceira vez.
Você fica olhando a tela sem saber se interrompe ou se dá mais um minuto — porque interromper parece jogar fora o trabalho que já foi feito.
Não joga. E a documentação oficial tem uma sequência para isso.
A sequência, na ordem
Cada passo preserva mais coisa que o seguinte. Comece pelo primeiro; só desça se não resolver.
1. Esc — para no meio, sem perder nada
A tecla Esc interrompe a ação em andamento. A frase da documentação é o que importa aqui:
Context is preserved, so you can redirect.
Não é cancelar a sessão. É pausar a ação para você dizer outra coisa. Tudo que já foi feito e conversado continua ali. Este é o passo que mais gente deixa de usar por achar que vai perder o trabalho.
2. Esc Esc ou /rewind — volta no tempo
Pressionar Esc duas vezes (ou rodar /rewind) abre o menu de retorno: ele restaura o
estado anterior da conversa e do código.
O mesmo menu oferece resumir a partir de uma mensagem escolhida, ou resumir até ela. O primeiro condensa dali para frente mantendo o começo intacto; o segundo condensa o começo mantendo o final em detalhe.
3. "Desfaz isso" — ela reverte as próprias mudanças
Escrito em português mesmo, como pedido normal. Serve quando o problema não é a conversa, é o que ela escreveu no arquivo.
4. /clear — zera e recomeça
O último recurso, e o mais poderoso. Some com tudo e começa do zero.
O número que diz a hora de parar
Aqui está o item mais útil de toda a página, e ele é um número:
If you've corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches.
Duas. Corrigiu a mesma coisa duas vezes sem resolver, pare de corrigir. O que acontece da terceira em diante é que cada tentativa fracassada continua no contexto sendo lida como se fosse informação útil — e é ela que empurra a próxima resposta para o mesmo erro.
A instrução oficial é rodar /clear e reescrever o pedido incorporando o que você aprendeu.
A frase que fecha:
A clean session with a better prompt almost always outperforms a long session with accumulated corrections.
Por que ela entra em círculo
Um dos padrões de falha nomeados na documentação explica boa parte dos loops: a exploração infinita. Você pede para investigar algo sem limitar onde, ela lê centenas de arquivos, o contexto enche — e a partir daí a qualidade cai justamente enquanto ela tenta resolver.
As duas correções declaradas:
- Limitar o escopo: diga em qual pasta, qual arquivo, qual camada.
- Delegar a um subagente: a investigação roda numa conversa separada e só o resumo volta para a sua. O que ela leu não entra no seu contexto.
Modelo de pedido para depois do /clear
Limpar sem melhorar o pedido devolve você ao mesmo lugar em quinze minutos. O que aprendeu nas tentativas fracassadas é justamente o que torna o novo pedido melhor. Um modelo:
Objetivo: [o que precisa funcionar no fim, em uma frase]
Contexto que importa:
- Arquivo/função: [onde mexer]
- Já tentei: [abordagem A] — falhou porque [motivo observado]
- Já tentei: [abordagem B] — falhou porque [motivo observado]
Restrições:
- Não mexer em [o que não pode mudar]
- [Padrão do projeto que precisa ser respeitado]
Como saber que funcionou: [o teste, o comando, o comportamento esperado]
As duas linhas de "já tentei" são o coração do modelo. Elas transformam as tentativas fracassadas — que estavam ocupando espaço como entulho — em instrução útil de meia linha.
O contraintuitivo que vale levar
A documentação abre a seção com isto:
The best results come from tight feedback loops. Though Claude occasionally solves problems perfectly on the first attempt, correcting it quickly generally produces better solutions faster.
Interromper cedo não é impaciência, e não desperdiça o trabalho. Deixar rodar "para não perder o que já foi feito" é o que custa tempo — porque o que está sendo produzido enquanto você espera é justamente o entulho que vai piorar a próxima tentativa.