Como mudar do Cursor para Claude Code sem perder o contexto do projeto

[Devy]

Você não pode, a menos que guarde o contexto em um lugar que não seja propriedade de nenhuma das duas ferramentas. Essa é exatamente a ideia por trás do Engrim: um banco de dados SQLite local que armazena as decisões, restrições e o estado atual do seu projeto fora de qualquer agente, e as reinjecta ao iniciar cada sessão — no Claude Code, Cursor, Windsurf, Antigravity ou Codex CLI, no mesmo repositório.

O problema soa familiar para qualquer um que use mais de um agente. Você gasta quarenta minutos explicando ao Claude Code por que a fila é Redis e não SQS, por que esse módulo não se toca até que saia a migração e em que você estava exatamente quando parou. Depois muda para o Cursor para outra coisa e tem que explicar tudo novamente. Cada ferramenta tem sua própria memória — CLAUDE.md, AGENTS.md, arquivos de regras, servidores MCP de memória — e nenhuma conversa com as outras.

Engrim é a resposta de Tim Gordon: versão 1.3.0, publicada no PyPI em 7 de setembro de 2026, licença MIT, Python 3.10 ou superior. Chegou à capa do Hacker News naquela mesma semana — cerca de 80 pontos e uns 50 comentários no momento da escrita desta nota.

O que é Engrim e onde ele guarda seu contexto?

Tudo vive em um único arquivo SQLite em ~/.engrim/memory.db. Sem sincronização na nuvem, sem telemetria, sem conta. A busca é híbrida: texto completo com FTS5 mais embeddings vetoriais estáticos via model2vec, que roda na CPU e carrega em cerca de 30 milissegundos. Se você não quer embeddings, ENGRIM_EMBED=off o deixa em modo puramente léxico.

Os registros são tipados — decision, fact, feedback, state, user, reference — e com escopo por projeto. O arquivo é escrito com permissões POSIX restritas (0600) e *.db está no .gitignore por padrão.

O número que importa é o orçamento. engrim context gera um pacote de inicialização de sessão limitado por quantidade de caracteres, 4.000 por padrão (engrim context -b 4000). Esse limite é a verdadeira decisão de design: não se trata de “lembrar tudo”, mas de decidir o que merece ocupar 4.000 caracteres ao iniciar.

Por que CLAUDE.md e AGENTS.md não resolvem a mudança de agente?

Porque são arquivos de uma única ferramenta, e o problema aparece justamente entre ferramentas. AGENTS.md funciona bem como convenção compartilhada para instruções estáticas: como o projeto é compilado, que estilo é usado, o que não se toca. O que não faz é capturar o estado de uma sessão concreta — a decisão que você tomou há vinte minutos, a razão pela qual descartou uma alternativa, o ponto exato onde parou.

Engrim ataca essa segunda camada. O próprio autor a apresenta como complemento, não como substituição: os registros arquitetônicos versionados em git continuam sendo o lugar da documentação duradoura. O que Engrim guarda é o que hoje se perde ao fechar a sessão.

Como se instala Engrim no Claude Code, Cursor, Windsurf, Antigravity e Codex CLI?

A instalação é um único comando:

pip install engrim

Depois deixe que detecte o que você tem instalado:

engrim setup

Isso autodetecta os ambientes presentes — Antigravity, Claude Code, Cursor, Codex CLI, Windsurf — e configura cada um. Se preferir ir um a um:

• engrim setup --claude conecta os hooks SessionStart, SessionEnd, Stop e UserPromptSubmit em ~/.claude/settings.json
• engrim setup --agy configura os hooks em ~/.gemini/config/hooks.json, implanta uma skill em ~/.gemini/config/skills/engrim/ e registra o servidor MCP
• engrim setup --cursor adiciona Engrim a ~/.cursor/mcp.json
• engrim setup --codex conecta os hooks em ~/.codex/hooks.json
• engrim setup --all faz tudo o que foi mencionado acima

Windsurf é o único caso manual. Adicione isto a ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "engrim": {
      "command": "engrim",
      "args": ["serve", "--mcp"]
    }
  }
}

Todos os comandos de setup aceitam --dry-run, que imprime o que mudaria sem tocar sua configuração. Use-o. Esses comandos editam arquivos que outras ferramentas também escrevem.

Através do MCP, os agentes recebem quatro ferramentas: engrim_recall, engrim_add, engrim_context e engrim_review.

Como é o loop do dia a dia?

O autor a chama de continue-as-clear, e vale a pena entendê-la porque inverte o hábito comum de estender uma sessão longa até que se degrade.

Você captura as decisões na medida em que as toma:

engrim add -t decision -s "A fila fica em Redis; migração para SQS bloqueada até Q4"

Você se deixa um apontador para a próxima tarefa, etiquetado como tal. Depois, antes de limpar, revisa o que deixou passar:

engrim review

review inspeciona os logs da transcrição procurando decisões que você tomou mas nunca registrou. Se voltar limpo, você faz /clear sem cerimônia — a memória é reinjetada no próximo prompt. Dois comandos completam o quadro: engrim recall -q "database" para busca híbrida, e engrim supersede --id 12 --status superseded para quando uma decisão deixa de ser verdadeira, o que importa mais do que parece. Um armazém de memória que apenas acumula termina estando errado.

A memória dos agentes realmente funciona?

Esta foi a objeção mais afiada no Hacker News, e é a correta: há pessoas que viram os LLMs guardarem lixo em memória e depois recuperá-lo em contextos irrelevantes.

A resposta do autor é que Engrim não tenta ser autônomo. A memória é pensada para ser currada manualmente e tratada como referência contextual, não como autoridade para tomar decisões. Ele descreve o armazém como um caderno de mesa ao nível de sessão. Se você espera um sistema que o observe trabalhar e deduza o que é importante, não é isto, e o design também não o pretende.

Duas coisas que a thread levantou continuam em aberto: o que acontece quando vários agentes escrevem simultaneamente, e como o armazém distingue entre trabalho terminado e um plano abandonado quando uma sessão morre no meio do caminho. Nenhuma tem resposta documentada por enquanto.

O que dizem os números do autor e o que não dizem?

O README do Engrim relata 105 sessões contínuas sobre uma base de código de trading algorítmico de 50.000 linhas, com mais de 153.000 tokens de trabalho consolidados em menos de 1.000 tokens — uma redução alegada de mais de 99% no contexto recarregado por reinício, e zero regressões em 186 testes unitários.

Leia-o pelo que é: o estudo de caso do próprio autor sobre um único projeto. Não foi reproduzido de forma independente, e uma base de código em um domínio com um estilo de trabalho não é um benchmark. O mecanismo é evidentemente sensato — um pacote de 4.000 caracteres custa menos que recarregar 200.000 tokens, e para ver isso não é preciso um estudo de caso — mas esse percentual concreto pertence ao seu projeto, não ao seu.

Convém também manter a proporção: uma capa no Hacker News mede atenção, não adoção. Um único mantenedor, sem página de releases. Se você monta um fluxo de trabalho sobre isto, mantenha-o simples o bastante para poder voltar aos seus arquivos CLAUDE.md sem perder muita coisa.

Um detalhe mais se ler o README com atenção: seus exemplos nomeiam modelos que já ficaram antigos. O que você deve levar é o padrão, não as cadeias de modelo concreto.

Claude Code vs Cursor? Com Engrim você deixa de ter que escolher

Se você usa um único agente, provavelmente ainda não vai precisar — CLAUDE.md e a memória própria da ferramenta o cobrem. Se você se move habitualmente entre dois ou três no mesmo repositório, isto é o primeiro que vejo apontado diretamente para a transferência, e não para que um agente se lembre melhor.

Se instala com um comando, guarda tudo em um arquivo que você pode apagar, e --dry-run mostra antes o que vai tocar. É um experimento barato.

Se o que você busca é memória persistente dentro do Claude Code e nada mais, já cobrimos essa via em seu momento: Claude-mem: dê a Claude Code a memória que lhe falta.

GitHub - timgordontg/engrim: The Universal Cross-Model Episodic Memory Standard. Local-first, project-scoped SQLite memory engine for Google Antigravity, Claude Code, Cursor, Windsurf, and Codex. Zero cloud lock-in. · GitHub Cursor mcp memoria agents-md open-source windsurf