Eu dei ao Claude Code Memória Permanente — Aqui está o que Mudou

Eu tenho usado o Claude Code diariamente por meses. Eu construo com ele, depuro com ele, projeto com ele. É realmente brilhante para escrever código.

Mas toda manhã, o mesmo ritual: abrir uma nova sessão, esperar que Claude pergunte qual framework estou usando, re-explicar meu prefixo de banco de dados, reafirmar que uso Haiku para bate-papo casual e Sonnet para raciocínio complexo, re-descrever a estrutura de arquivos que já expliquei cinquenta vezes antes.

Depois de uma sessão particularmente frustrante em que Claude errou meu prefixo de banco de dados pela quarta vez naquela semana — é um prefixo personalizado, não o padrão, e isso importa — decidi consertar isso.

Eu construí um sistema de memória persistente para o Claude Code. Estou usando-o em produção há semanas. Aqui está o que realmente mudou.

O Antes: Morte por Mil Re-explicações

Meu projeto é um plugin do WordPress com cerca de 20 classes PHP principais, um frontend estilo React, múltiplas integrações de modelos de IA, faturamento Stripe e cinco linhas de produtos distintas compartilhando uma única base de código. Não é um projeto de brinquedo.

Antes da memória persistente, cada sessão do Claude Code começava mais ou menos assim:

Eu: Corrija o bug de faturamento no manipulador de assinaturas.

Claude: Vou olhar para a base de código. Qual sistema de faturamento você está usando?

Eu: Stripe. O manipulador está em class-stripe.php.

Claude: Entendi. Deixe-me ler esse arquivo... Vejo referências a diferentes níveis de assinatura. Você pode explicar a estrutura dos níveis?

Eu: [suspira, cola a tabela de níveis pela 30ª vez]

A compactação de contexto piorou as coisas. Eu estava profundamente em uma sessão de depuração, Claude compactava automaticamente, e de repente ele esquecia quais arquivos estávamos analisando. Eu tinha que restabelecer todo o modelo mental que havíamos construído juntos na última hora.

O MEMORY.md embutido ajudou um pouco, mas 200 linhas não são suficientes para um projeto complexo. E após a compactação, Claude às vezes ignorava completamente — um bug bem documentado que a Anthropic ainda não corrigiu completamente.

Eu estimei que estava gastando de 15 a 20 minutos por sessão apenas restabelecendo o contexto. Multiplique isso por 5 a 8 sessões por dia, e eu estava perdendo mais de uma hora diariamente devido à amnésia do Claude.

O Que Eu Construí

Eu construí CogmemAi — um servidor MCP baseado em nuvem que dá ao Claude Code memória persistente com busca semântica. A ideia central é simples:

1. Extrair — A IA analisa conversas e identifica fatos que valem a pena lembrar (decisões de arquitetura, correções de bugs, preferências, padrões)
2. Armazenar — Cada memória recebe uma incorporação semântica para recuperação baseada em significado, uma pontuação de importância e escopo do projeto
3. Superficializar — No início de cada sessão, as memórias mais relevantes são carregadas automaticamente com base em significado, importância e atualidade

O servidor MCP em si é um cliente HTTP leve — sem bancos de dados locais, sem armazenamentos vetoriais consumindo RAM, sem contêineres Docker. Todo o trabalho pesado acontece do lado do servidor. A configuração é um comando único:

npx cogmemai-mcp setup

Isso instala o servidor, configura o Claude Code e habilita a recuperação automática de compactação. Tudo leva cerca de 30 segundos.

O Depois: Claude Apenas Sabe

A diferença foi imediata. Aqui está como uma sessão se parece agora.

Eu digito claude no meu terminal. CogmemAi carrega o contexto do meu projeto — as memórias principais classificadas por importância e relevância. Claude vê coisas como:

• O banco de dados ao vivo usa um prefixo personalizado, não o padrão wp_
• Qual modelo de IA usar para diferentes tipos de interação — raciocínio casual vs. complexo
• Alterações em um subsistema devem ser espelhadas no sistema paralelo (eles compartilham lógica)
• Padrões específicos de sobrescrita CSS que requerem seletores especiais
• Quais funções de wrapper de criptografia usar em vez de chamadas de biblioteca bruta

Eu não digito nada disso. Eu não colo uma folha de dicas. Claude apenas sabe meu projeto porque ele lembra das últimas cem sessões de trabalho juntos.

Quando eu digo "corrija o bug de faturamento", Claude já sabe que usamos Stripe, já sabe a estrutura dos níveis, já sabe qual arquivo olhar. Nós pulamos direto para o trabalho real.

O Momento de Recuperação de Compactação

O verdadeiro momento "uau" veio na primeira vez que a compactação automática foi ativada com a recuperação de compactação ativa.

Eu estava profundamente em uma sessão — estávamos trabalhando em um recurso complexo por mais de uma hora, o contexto estava se preenchendo. Claude compactou automaticamente. Normalmente, é aí que a dor começa.

Em vez disso, isso aconteceu: o contexto foi automaticamente preservado antes da compactação e restaurado perfeitamente depois, incluindo meu contexto de projeto mais um resumo da sessão atual.

A próxima resposta de Claude começou com um resumo do que estávamos trabalhando e continuou exatamente de onde paramos. Sem "você pode me lembrar o que estávamos fazendo?" Sem contexto perdido. Funcionou perfeitamente.

Aquele foi o momento em que eu soube que isso era um divisor de águas.

O Que Eu Não Esperava

Algumas coisas me surpreenderam sobre ter memória persistente:

Conhecimento composto. Ao longo de dias e semanas, a compreensão de Claude sobre meu projeto se aprofunda. As memórias iniciais capturaram o básico — estrutura de arquivos, stack tecnológica, convenções de nomenclatura. Memórias posteriores capturaram padrões mais sutis — quais funções são frágeis, quais seletores CSS precisam de tratamento especial, quais endpoints de API têm limites de taxa. O contexto acumulado torna Claude dramaticamente melhor em tomar boas decisões sem ser informado.

Histórico de correções de bugs. Quando um bug semelhante aparece, Claude pode recordar a correção anterior. "Corrigimos um problema semelhante em class-tasks.php na semana passada — o problema era a lógica de auto-avançar tarefas recorrentes." Isso não é algo que o MEMORY.md poderia capturar em 200 linhas.

Continuidade entre máquinas. Eu trabalho de duas máquinas. Antes, cada uma tinha seu próprio MEMORY.md desconectado. Agora, as memórias estão na nuvem — eu retomo no meu laptop exatamente de onde parei no meu desktop. Mesmo contexto, mesmo conhecimento acumulado.

A "dopamina de que ele lembrou". Há algo genuinamente satisfatório em começar uma nova sessão e ter Claude referenciar uma decisão que você tomou três dias atrás sem ser solicitado. É como trabalhar com alguém que realmente presta atenção.

O Que Não Faz

Quero ser honesto sobre as limitações:

• Não é mágica. Claude ainda comete erros. A memória dá a ele um contexto melhor, mas ele ainda pode alucinar ou tomar decisões arquitetônicas erradas. Você ainda precisa revisar tudo.
• Precisa de rede. O sistema de memória é baseado em nuvem. Sem internet, sem memórias. Se você precisa de uma solução offline, um banco de dados vetorial local pode ser uma opção melhor.
• A população inicial leva tempo. Nas primeiras sessões, Claude ainda está aprendendo sobre seu projeto. Após uma semana de uso ativo, a memória se torna genuinamente útil. Após duas semanas, é indispensável.

Pelos Números

Após várias semanas de uso diário em uma base de código complexa e multi-produto:

• 200+ memórias acumuladas em decisões de arquitetura, correções de bugs, padrões, preferências e resumos de sessões
• ~15 minutos salvos por sessão em tempo de re-explicação
• 5–8 sessões por dia = aproximadamente 1–2 horas salvas diariamente
• Zero problemas de RAM — não