Como fazemos gerenciamento de sessão no Claude Code na Solu

Já aconteceu comigo e eu tenho certeza de que com você também: no meio de uma boa implementação, com o Claude entendendo tudo, do nada ele começa a repetir perguntas que já haviam sido respondidas e a sugerir coisas que contrariavam uma regra que eu tinha dado no começo. Na hora, a primeira reação é achar que o modelo "ficou burro". Não ficou. A sessão tinha se enchido de contexto velho e ele simplesmente não enxergava mais o começo da nossa conversa.

Demorei pra entender que o problema não era o prompt, mas a sessão. E que gerenciar a sessão é uma habilidade à parte, tão importante quanto saber pedir.

Esse post é o mapa que eu queria ter tido no começo, quando comecei com o Claude: (1) o que é a sessão, (2) como a memória sobrevive a ela, (3) o que dá pra deixar no automático, (4) como controlar tudo no dia a dia e, por fim, (5) como gastar menos tokens fazendo isso.

Sem tempo de ler tudo? Joga o post inteiro no Claude Code com o prompt abaixo, e ele transformará o conteúdo em ajuste no teu próprio setup:

Leia esse post sobre gerenciamento de sessão no Claude Code e me devolva duas coisas: uma lista de hábitos práticos pra eu adotar no meu fluxo, e um trecho pronto pra eu colar no meu CLAUDE.md com as regras que dá pra deixar automáticas.

1. O que é a sessão

A sessão é a sua conversa atual, e ela vive empilhando tudo numa janela de contexto: cada mensagem que você manda, cada arquivo que o Claude lê, cada output de comando que aparece. Tudo entra e tudo fica ali ocupando espaço.

Essa janela é finita. Nos modelos da Anthropic, vai de 200k tokens no padrão até 1 milhão em alguns modelos específicos. Parece muito, mas enche bem mais rápido do que você imagina (e não pelo motivo que você acha). As pessoas culpam a conversa, quando o verdadeiro peso está em outro lugar.

Quem come o seu contexto, de longe, são os arquivos lidos inteiros. Você pede uma coisa simples, ele lê três arquivos de 800 linhas pra ter certeza, e cada um daqueles arquivos entra, por inteiro, e fica lá até o fim da sessão. Depois vêm os outputs de comando, o histórico da conversa e a memória que carrega no início. Quando o trabalho aperta, o começo da contextualização é a primeira coisa a ser esquecida. E, por isso, o Claude esquece justamente a regra que você deu lá atrás. Não é burrice, é o contexto vazando pelo ladrão, enquanto coisa nova entra.

Entender isso muda tudo, pois, a partir disso, você para de torcer pra dar certo e passa a controlar o que ocupa a janela. E o primeiro controle não é sobre o que entra. É sobre o que sobrevive quando você zera tudo.

2. A memória entre sessões

Quando você reseta uma sessão, a conversa some, mas nem tudo morre junto. E é isso que muita gente não usa a seu favor.

O CLAUDE.md recarrega inteiro em toda a sessão. É ali que eu deixo as regras permanentes, o jeito que eu quero que ele trabalhe, as convenções do projeto. Enfim, tudo o que eu não quero repetir nunca mais. Como ele entra completo no contexto, mantenho enxuto: é instrução, não enciclopédia.

Ao lado dele, tem a memória file-based. Essa funciona diferente, como o índice de um livro.

O arquivo MEMORY.md não traz todo o conteúdo, mas a lista do que existe e onde está, apontando pra dezenas de outras memórias de projetos e contextos específicos. O Claude carrega só esse índice leve no começo e vai ler o "capítulo" inteiro sob demanda, quando a tarefa realmente precisa daquele assunto. É o melhor dos dois mundos: memória enorme guardada, mas só o que importa ocupando contexto. Na prática, o que aprendi com o Claude numa sessão na segunda-feira ainda está "fresco" na quinta-feira, porque ficou gravado fora da conversa.

O hábito de ouro que fecha esse ciclo é nunca encerrar uma sessão sem mandar ele se lembrar:

Vamos encerrar. Antes, grave na memória: as decisões que mudamos hoje e o porquê, o que ficou como débito técnico, e um ponteiro claro de por onde retomar na próxima sessão. Escreva pra um "eu do futuro" que esqueceu o contexto.

É essa dupla que o faz "lembrar de você" amanhã. Todo o resto, o vaivém da conversa de hoje, é descartável de propósito, e quanto antes você aceita isso, melhor você gerencia. A próxima pergunta é o que dá pra deixar acontecendo sozinho.

3. O que dá pra automatizar

Parte do gerenciamento o Claude já faz sozinho. E é justamente aí que mora uma armadilha.

Ele compacta automaticamente quando chega perto do limite, só que quem decide o corte é ele. E o que costuma ir junto? A instrução do começo, a mais importante delas. É exatamente por isso que a regra crítica vive no CLAUDE.md, não na conversa: ali o auto-compact não alcança.

Pra quem quer ir mais fundo, dá pra fazer a sessão nascer sabendo onde você está no desenvolvimento. O hook SessionStart roda no início de toda sessão e pode injetar o contexto que você quiser, a branch atual, a tarefa do dia, um lembrete, sem você precisar digitar nada. É um nível mais avançado e exige um pouco de configuração, então deixo o link da doc oficial e guardo um post dedicado só pra isso.

E, quando fecho o terminal, nada se perde. O claude --continue retoma a última sessão de onde parei e o claude --resume abre o seletor pra eu escolher qual delas voltar.

Mas automático só resolve o trivial. O dia a dia de verdade é saber qual alavanca puxar na hora certa.

4. O controle no dia a dia

A regra que eu sigo antes de qualquer decisão é olhar o estado atual do desenvolvimento e da sessão, e não chutar onde parei. Eu mantenho um statusline que me mostra na barra o quanto do contexto eu já consumi. O /context detalha o uso e exatamente o que está ocupando a janela naquele momento: quais arquivos, quais tools, o tamanho de cada coisa. Em dois segundos eu sei se ainda tenho folga ou se já estou na zona perigosa. Decidir sem olhar isso é dirigir sem olhar o tanque.

Daí são três movimentos, e o segredo está em saber qual usar em cada situação, porque é aqui que a maioria erra.

/clear para trocar de assunto: Troco de tarefa, dou /clear e começo limpo. Esse é o que eu mais demorei a usar e o que mais mudou meu fluxo. Antes eu emendava uma tarefa na outra na mesma sessão achando que o "histórico" ajudava, e na real ele só envenenava a próxima tarefa com contexto que não tinha nada a ver. Tarefa nova, sessão nova.

/compact para limpar a mesa sem perder o fio: A mesma tarefa ficou longa e bagunçada mas eu ainda preciso dela, aí é /compact, que troca o histórico por um resumo sem me fazer começar do zero. O truque de mestre aqui é não escrever essa instrução na mão. Eu peço pro próprio Claude:

Vou compactar a sessão, me dê as instruções pro /compact pra mantermos o momento atual da implementação e seguir de onde paramos.

Ele conhece o próprio contexto melhor do que eu, e a instrução sai redonda.

/rewind para voltar no tempo: O Claude foi pro caminho errado e eu quero desfazer, é /rewind (ou Esc Esc com o input vazio). Ele volta pra um ponto anterior e me deixa escolher se reverto só a conversa, só o código, ou os dois. Uma ressalva que já me pegou: ele só reverte as edições de arquivo dele, não de comandos bash.

5. E a economia?

Bom, agora sobra a conta. Tudo o que eu falei até aqui já gasta menos tokens por tabela, mas dá pra atacar a fatura de frente, voltando aos dois maiores vilões que citei no começo: arquivo lido e saída de comando.

O arquivo lido eu não deixo entrar na conversa principal. Quando o serviço é pesado, como investigar uma codebase, ler dezenas de arquivos, pesquisar documentação, eu chamo um subagent. Ele faz a "parte braçal" numa sessão ao lado, isolada, e me devolve só a conclusão. Os trinta arquivos que ele leu pra chegar na resposta nunca tocam o meu contexto. É a diferença entre alguém te entregar o relatório pronto e alguém despejar a pesquisa bruta inteira na sua mesa.

A saída de comando, ou output, eu trato com o RTK, uma ferramenta de comunidade e não oficial. Ele é um proxy que intercepta a saída de alguns dos seus comandos e comprime antes de chegar ao Claude, jogando fora o ruído e guardando o que importa. No meu uso acumulado de 4.465 comandos, o RTK contabiliza 8,4M de tokens economizados, ou 67% do total.

A maioria das pessoas trata o Claude Code como uma caixa de prompt: joga texto, reza, e culpa o modelo quando dá ruim. Quem trata como uma sessão, com começo, escopo, memória e fim, trabalha mais rápido, erra menos e gasta uma fração dos tokens.

Não é o modelo que ficou bom ou ruim. É você que aprendeu a pilotar.