Quando usar /clear em vez de /compact no Claude Code

Resposta curta: use /clear quando quiser recomeço e /compact quando precisar de continuidade, porque a própria documentação da Anthropic afirma que "/compact reads the conversation it summarizes, so compacting a large context is itself a large request", ou seja, o /compact lê a conversa que resume, e que "when you want a fresh start instead of continuity, /clear costs nothing", isto é, o /clear não custa nada. A regra prática que sai daí: se a próxima coisa que você vai fazer é outra tarefa, limpe; se é a mesma tarefa e você teria de explicar tudo de novo, compacte.

Qual é a diferença entre /clear e /compact no Claude Code?

Os dois comandos resolvem problemas opostos. O /compact pede ao Claude Code que resuma a conversa até ali e siga a partir desse resumo, mantendo o fio do que você estava fazendo. O /clear encerra a sessão e abre uma vazia, sem guardar nada. A assimetria de custo é a parte que quase todo mundo ignora, e ela está documentada na página de gestão de custo do Claude Code da Anthropic, lida em 11 de agosto de 2026: a compactação precisa ler tudo o que está resumindo, então quanto maior a bagunça que você está compactando, mais caro fica esse único comando. Limpar não lê nada.

Dois comportamentos menores valem a leitura antes de escolher. Dá para dirigir a compactação, porque a mesma página documenta que o /compact seguido de uma instrução, no exemplo dela "Focus on code samples and API usage", diz ao Claude o que preservar no resumo. E a compactação tem um piso: numa sessão nova, o /compact imprime "Not enough messages to compact.", porque ainda não existe histórico para resumir.

Quando começar uma sessão nova em vez de continuar?

A resposta honesta é que a maioria dos desenvolvedores não tem uma regra fundamentada, e diz isso abertamente. Uma pergunta publicada na comunidade r/ClaudeCode e reproduzida no r/ClaudeCoding em 10 de agosto de 2026 coloca a questão sem rodeio. O desenvolvedor que a fez descreve o próprio critério como "vibes: when it starts re-reading files it already read, or repeats a fix I rejected two turns ago, I bail and start over with a summary", ou seja, ele desiste da sessão quando o agente relê arquivos que já tinha lido ou repete uma correção que ele rejeitou duas rodadas atrás; acrescenta que "compaction helps but the session is usually already degraded by the time it kicks in", que a compactação ajuda mas a sessão em geral já está degradada quando ela entra; e então faz a pergunta que não tem resposta publicada: se a sessão longa é pior de verdade, ou se ele se acostumou a culpar a sessão quando a tarefa estava mal especificada desde o começo.

Essa última dúvida merece ser levada a sério, em vez de respondida com uma confiança que ninguém tem. Um jeito útil de separar as duas causas: antes de limpar, escreva numa linha o que você está tentando alcançar e o que prova que terminou. Se você não consegue escrever, o problema não era a sessão, e a sessão nova vai reproduzir a mesma perambulação com contexto limpo. Se você escreve com facilidade, o contexto estava carregando peso que não serve mais à tarefa, e limpar é a correção barata.

Por que uma sessão longa consome tanto mesmo com você digitando pouco?

Porque o tamanho da sua mensagem não é o que vai enviado. O Claude Code manda a conversa inteira a cada requisição e, nas palavras da própria documentação, "each time Claude uses tools it sends another request carrying that batch of tool results", cada uso de ferramenta gera outra requisição carregando aquele lote de resultados, e é por isso que "a one-line question in a session that has been open all day still draws usage for the whole conversation", uma pergunta de uma linha numa sessão aberta o dia todo ainda consome pela conversa inteira. O seu esforço de digitação e o seu consumo deixaram de ter relação horas atrás.

Existe um segundo efeito que pune exatamente o jeito como as pessoas trabalham, que é em blocos com intervalos no meio. A mesma página documenta que a primeira mensagem depois de uma pausa maior que a vida do cache de prompt perde o cache e reprocessa o contexto inteiro, e que essa vida é de uma hora na assinatura, caindo para cinco minutos quando você passa a usar créditos de uso, sendo cinco minutos também o padrão em chave de API ou provedor de nuvem. Voltar para uma sessão grande depois do almoço é, portanto, mais caro que continuar nela antes do almoço, e a documentação registra que definir ENABLE_PROMPT_CACHING_1H=1 mantém a vida de uma hora enquanto você usa créditos.

Aviso de contexto é a mesma coisa que aviso de limite de uso?

Não, e confundir os dois faz gente comprar plano maior quando a correção era de graça. A orientação da Anthropic para desenvolvedores é explícita ao dizer "a context or auto-compact warning: not a usage limit", aviso de contexto ou de compactação automática não é aviso de limite de uso, e descreve o caso como a conversa ter se aproximado da janela de compactação automática da sessão, o ponto em que o Claude Code resume o histórico antigo para liberar espaço. Isso é um sinal sobre o formato de uma conversa, não sobre a sua cota restante do dia.

O limite de uso é outro evento, com outras saídas, e escrevemos sobre ele à parte em o que fazer quando você bate no limite de uso do agente de IA. A distinção curta que vale guardar: aviso de contexto quer dizer que esta conversa ficou pesada, e limpar resolve em um segundo; limite de uso quer dizer que a sua janela acabou, e nenhum comando conserta isso.

O que come o seu contexto sem você perceber?

Quatro itens da mesma documentação, e nenhum deles envolve você digitar. Tarefas agendadas disparam no intervalo delas mesmo com a sessão parada, enviando o contexto inteiro a cada vez. Mensagens entre sessões são entregues como uma rodada nova quando a sessão fica ociosa, também mandando o contexto inteiro, e podem ser seguradas em vez disso definindo crossSessionInbound como hold. Colegas de time de agentes seguem consumindo tokens até saírem. E servidores MCP pesam pela listagem de ferramentas, motivo pelo qual a documentação adia as definições de ferramenta MCP por padrão e recomenda preferir ferramentas de linha de comando como gh, aws, gcloud e sentry-cli, que não acrescentam listagem por ferramenta nenhuma.

Este é o argumento mais forte para limpar em vez de compactar quando você larga uma tarefa: sessão ociosa não é sessão de graça. Se outra coisa pode empurrar rodadas para dentro dela, deixá la aberta a tarde toda tem um custo correndo que resumo nenhum remove.

Como enxergar o que está enchendo o contexto?

O Claude Code responde isso direto com o /context, que a documentação descreve como mostrar o que está consumindo espaço. Em plano Pro, Max, Team ou Enterprise, o detalhamento do /usage vai além e sinaliza comportamentos que respondem por 10% ou mais do seu uso recente, como contexto longo ou perda de cache, cada um com uma dica para reduzir. Entre os dois, o chute acaba: você descobre se o peso é a sua conversa, a sua listagem de skills ou os seus servidores MCP antes de decidir qual comando rodar.

Sendo preciso sobre o que a nossa própria ferramenta faz e o que não faz aqui: o CanvasCode, o app de Mac que roda as CLIs oficiais de agente lado a lado num canvas só, mostra um anel de uso por conta, recurso presente no aplicativo desde o CanvasCode versão 1.12, de junho de 2026, e isso responde quanto sobrou do seu plano, não o quanto a conversa atual está pesada. Para a segunda pergunta, o /context dentro do Claude Code é o instrumento certo, e nós não o substituímos.

Como limpar sem perder o fio?

O Claude Code tem um par documentado para isso: use /rename antes de limpar, para achar a sessão depois, e /resume para voltar a ela. Fora isso, o hábito que funciona é escrever você mesmo a passagem, ou pedir a passagem ao agente, antes de limpar: qual é a tarefa, o que foi decidido, o que está feito, o que vem depois. Você fica com as decisões e joga fora o peso em tokens do caminho até elas.

Rodamos a nossa própria pipeline de conteúdo exatamente nesse formato, e isso é evidência nossa, não opinião. Ela executa três vezes por dia neste site, e cada execução começa sem nenhuma memória da anterior. O que atravessa entre elas está escrito em vez de lembrado, em dois lugares separados: um caderno de campo com as conclusões curadas, limitado a 300 linhas e com 216 linhas em 11 de agosto de 2026, e um registro das ações que cada execução tomou, com o motivo de cada uma. Três partidas a frio por dia funcionam porque a passagem está escrita, não porque as sessões são longas. Uma ressalva que não temos como resolver para você: a Anthropic não publica o limiar de tokens em que a compactação automática dispara, então ninguém, nós inclusive, consegue dizer o tamanho exato a partir do qual limpar ganha de compactar. O que dá para fazer é olhar o /context e tratar os dois comandos como respostas a perguntas diferentes.