No artigo anterior a gente atacou a alucinação de arquitetura, transformando o código em grafo com o Graphify. Hoje é outro vilão do Claude Code: a amnésia entre sessões.
Você conversa, o contexto enche, a barrinha fica vermelha, o Claude compacta o histórico — e volta tudo cinza. Só que a cada compactação, e a cada sessão nova, o agente precisa reler a documentação e redescobrir as regras do projeto. São milhares de tokens gastos para chegar de volta onde ele já estava.
O que é o Engram
O Engram é um cérebro persistente para o agente: um binário único em Go, rodando local, que guarda memória em SQLite com busca full-text (FTS5) e conversa com o Claude Code via MCP, em modo stdio.
Repare no que ele não é. Não é enfiar o projeto inteiro no CLAUDE.md — que estoura o contexto de novo na próxima leitura. E não é um vector store pesado na nuvem, que você paga por armazenamento e por consulta. É um executável local, sem Python, sem Docker, sem dependência pesada.
Detalhe importante de segurança: procure o projeto pelo repositório oficial. Existem outros produtos com nome parecido, e não têm relação nenhuma com esse.
O salvamento é proativo — você não fica pedindo
Essa é a parte que muda o uso na prática. Quando o Claude Code resolve um bug crítico ou toma uma decisão de arquitetura, ele chama o mem_save por conta própria e persiste três coisas: o quê, por quê e onde.
Na retomada — abertura de sessão nova ou logo após uma compactação — ele não fica cego: consulta o Engram com uma busca textual instantânea (mem_search) e recupera o que importa para aquela tarefa. Menos leitura repetida de arquivo, sessão mais rápida, e corte no consumo de tokens tanto na entrada quanto na saída.
Os números — e a ressalva honesta
A instalação que eu mostro no vídeo tem 60 sessões com memória, 635 observações salvas, 332 prompts registrados e 32 projetos rastreados. Esses são dados reais da minha base.
Já a comparação antes/depois é ilustrativa, e faço questão de dizer: para ter número auditável eu precisaria de um ou dois meses medindo com rigor. A ordem de grandeza que eu senti no uso, e que aparece no painel do vídeo:
- ~82% menos tokens de entrada por tarefa (média de 4 tarefas)
- Retomada de contexto 7,5× mais rápida — cerca de 90 s de releitura virando ~12 s
- Busca local respondendo em menos de 10 ms, sem nenhuma chamada de rede e sem vector store na nuvem
- Um caso concreto: retomar uma sessão relendo CLAUDE.md, docs e arquivos custava ~28.400 tokens; com a memória, ~3.100
A percepção prática é menos precisa e mais convincente: você trabalha uma semana inteira no mesmo ritmo de antes e, no fim, os tokens ainda não acabaram.
Os três momentos em que a diferença aparece
1. Pós-compactação
Era onde eu mais sentia demora e consumo exagerado. O agente reinicia, mas puxa das últimas sessões as decisões ativas e importantes em vez de reler tudo. Além da velocidade, some aquela alucinação típica entre uma compactação e outra.
2. Bug recorrente
O bug que você já resolveu dez sessões atrás e voltou. Sem memória, o agente relê uma dúzia de arquivos para redescobrir a causa. Com memória, ele recebe só o trecho relevante — ele já sabe onde consertar. No meu setup atual, bug recorrente praticamente deixou de ser problema.
3. Decisão de arquitetura que não pode ser reaberta toda semana
O clássico: “não coloque nada sensível no front-end”. Sem memória, isso vira uma regra que você repete toda sessão e que às vezes é ignorada. Com as decisões registradas, o agente pergunta por que isso está feito assim antes de alterar — e é aí que ele para de desfazer o que já tinha sido decidido.
A base é compartilhada entre as IAs
Cada ferramenta tem seu plugin — Claude Code, Gemini CLI, OpenCode, Antigravity — mas todos acessam a mesma base de conhecimento. Não é uma memória por tecnologia.
Isso resolve um problema real de quem não tem plano ilimitado e vai alternando entre modelos conforme a cota: normalmente trocar de IA no meio da tarefa custa caro, porque a próxima começa do zero. Com a base compartilhada, o que foi aprendido em uma continua valendo na outra.
Juntando as duas peças
Mapeamento estrutural (o grafo) mais memória persistente local é o que transforma agente de código em ferramenta realmente autônoma e econômica. Um sabe onde as coisas estão; o outro lembra o que já foi decidido sobre elas.
O Engram é open source, mantido pelo Gentleman Programming. E se a sua próxima pergunta for “então eu preciso de RAG para isso?”, a resposta está em RAG no Claude Code: quando vale a pena — memória entre sessões é justamente um dos três casos em que RAG compensa.
Deixe um comentário