Produto
Pesquisa e fundamentos
Cada parte do ai-memory tem um motivo que você pode conferir: uma ideia de onde ela veio, um bug de uma ferramenta anterior que ela evita ou um número contra o qual ela foi medida. Esta página passa por eles em seis capítulos curtos.
Construa a wiki enquanto trabalha
Em abril de 2026, Andrej Karpathy publicou um “idea file” curto sobre o que ele chamou de LLM wiki. O ai-memory é essa ideia, adaptada para agentes de código que nunca param de produzir material.
“O conhecimento é compilado uma vez e depois mantido atualizado, em vez de ser derivado de novo a cada consulta.”
Três camadas
Fontes brutas que nunca mudam, uma wiki de páginas markdown mantida pelo LLM e um arquivo de schema que explica ao agente como a wiki funciona.
Três operações
Ingerir uma fonte e atualizar as páginas que ela afeta. Consultar a wiki. Rodar lint atrás de contradições e páginas órfãs.
Fontes brutas
Observações dos hooks
Wiki
Markdown no git
Schema
Bloco no AGENTS.md
O que o ai-memory manteve
- Arquivos markdown num repositório git como aquilo que uma pessoa consegue abrir, comparar com diff e ler.
- Compilar o conhecimento na hora em que ele chega, com uma sessão se desdobrando em várias páginas.
- Wikilinks entre as páginas fazendo o papel de grafo.
- Lint para contradições, páginas desatualizadas, órfãs e títulos duplicados.
- Um bloco de schema instalado no CLAUDE.md ou no AGENTS.md para o agente saber como usar a wiki.
O que ele mudou
No padrão do Karpathy, uma pessoa faz a curadoria, uma fonte de cada vez. Um agente de código produz material sem parar e ninguém está olhando.
| No gist | No ai-memory |
|---|---|
| Você entrega ao LLM uma fonte de cada vez | Os hooks de ciclo de vida capturam todas as sessões sozinhos |
| O agente lê o index.md primeiro | Um índice fundido: full-text, entidades, links e vetores |
| Um LLM faz toda a manutenção | Resumos baseados em regras por padrão. LLM é opt-in |
| Uma pessoa, uma wiki | Handoffs entre agentes, vários usuários, escopo por projeto |
| As páginas vivem para sempre | Camadas de memória, decaimento, substituição e TTLs tiram as páginas velhas do caminho |
Camadas de memória, decaimento e substituição não estão no gist do Karpathy. Vêm do agentmemory e dos textos sobre a “LLM Wiki v2” em volta dele. As notas de leitura completas estão no repositório.
Sua memória já está num formato aberto
O Open Knowledge Format é uma especificação que o Google Cloud publicou em junho de 2026. Ela descreve conhecimento como um diretório comum de arquivos markdown com frontmatter YAML, um conceito por arquivo e um único campo obrigatório: type. Não tem SDK nem runtime.
- Desde a 2.0 a wiki é nativamente um bundle OKF v0.2. Os arquivos em que o ai-memory trabalha são os próprios arquivos OKF, então não existe etapa de export que possa divergir da verdade.
- Um projeto é um bundle, com um
index.mdgerado na raiz. - Toda página tem frontmatter YAML com um
type, derivado da pasta em que ela fica. - O upgrade a partir da 1.x reescreve o frontmatter no lugar, depois de um backup verificado. Se o backup falha, a migração para.
ai-memory export-okf --project myproject -o myproject-bundle.tar.gz
Não existe comando de import. Descompacte um bundle no diretório da wiki de um projeto e o file watcher indexa. O mapeamento para OKF está documentado campo a campo, e a especificação fica no repositório knowledge-catalog do Google Cloud.
| Pasta | Tipo OKF |
|---|---|
sessions/ | Session Summary |
decisions/ | Decision |
gotchas/ | Gotcha |
procedures/ | Procedure |
concepts/ | Concept |
_rules/ | Rule |
notes/ | Note |
runbooks/ | Runbook |
_slots/ | Invariant ou State |
Um projeto
index.md
Decisão
Gotcha
Procedimento
Obsidian
grep
Outra ferramenta OKF
“Modelo e harness são alugados, a memória do projeto é sua.”
Oito decisões, e o motivo de cada uma
A maioria delas vem de uma issue específica de alguma ferramenta de memória anterior.
Escolhemos
Markdown em git como a verdade
porque ferramentas comuns de Markdown leem as páginas. Seu índice de busca pode ser reconstruído, mas sessões, handoffs e contas também exigem backup do banco.
Escolhemos
Um arquivo SQLite só
porque full-text, vetores compactados e tabelas de links ficam num único arquivo embutido. Os issue trackers de outros projetos mostraram quanto custa, em bugs de corretude, sincronizar três stores.
Escolhemos
Zero chamadas a LLM por padrão
porque os resumos de sessão são baseados em regras, então uma instalação nova não gasta nada. A lição veio de features com LLM ligadas por padrão em outras ferramentas, que surpreenderam os usuários com a conta de tokens.
Escolhemos
Um binário só
porque o SQLite vai embutido, o libgit2 vai vendorizado e o embedder é Rust puro. Um motor sidecar separado era a maior concentração de dor de usuário no projeto que este aqui sucede.
Escolhemos
Nada de banco de grafos
porque o grafo são tabelas SQL: uma tabela de links e consultas recursivas. Isso cobre expansão de um salto e arestas tipadas sem um motor de grafo embutido para manter vivo.
Escolhemos
Vetores são opcionais
porque os embeddings locais vêm ligados desde a 2.0 e continuam nunca sendo obrigatórios. A busca é cosseno por força bruta dentro do SQLite; uma extensão vetorial espera até a quantidade de páginas ou a latência pedirem.
Escolhemos
Handoff como protocolo tipado, assumido uma vez só
porque toda rodada de pesquisa apontou a transferência entre agentes como o ponto fraco das ferramentas anteriores. Um handoff é um registro tipado, casado por diretório, e só uma sessão consegue assumi-lo.
Escolhemos
Páginas em vez de linhas de fatos
porque uma página sobre uma decisão pode ser lida, editada e explicada em prosa. Uma tabela de fatos extraídos não abre no Obsidian nem passa por revisão num diff.
Sobre os ombros de quem veio antes
O projeto leu o código e os issue trackers das ferramentas que vieram antes, ficou com as ideias que se sustentaram e deixou de fora as partes que viviam quebrando.
Karpathy wiki
agentmemory
basic-memory
cognee
Hermes Agent
A-MEM
Hindsight
ai-memory
- Karpathy LLM Wiki
- Compile, não recupere. A wiki em disco é o artefato.
- agentmemory
- Captura automática por hooks, camadas de memória, substituição, decaimento como fórmula e ranking fundido. O ai-memory é o sucessor dele em Rust: as ideias ficaram, o substrato mudou.
- basic-memory
- Arquivos como fonte da verdade com um índice derivado, e links para páginas que ainda não existem.
- cognee
- O formato de pipeline de tarefas, carimbos de proveniência em toda página e feedback que ajusta o ranking.
- Hermes Agent
- O desenho do loop de autoaperfeiçoamento que revisa em background as sessões encerradas.
- A-MEM
- Notas atômicas no estilo Zettelkasten, que se ligam umas às outras automaticamente.
- Hindsight
- Rótulos tipados de redação, contagem de evidências por página e um briefing que começa pelas regras já estabelecidas.
- Honcho
- Respostas com citações, níveis de raciocínio e o agendamento da passada de sonho: gatilho por ociosidade, cancelamento quando há atividade, o mais inédito primeiro.
Nenhum desses projetos endossa o ai-memory. Para saber onde cada um deles está na frente, veja a comparação.
O que foi medido
A execução da versão 3.3.3 testou 470 perguntas respondíveis do LongMemEval-S com captura e busca reais. O texto completo atingiu 0.951 em hit@5; os embeddings locais atingiram 0.943. Esses números medem recuperação, não a exatidão das respostas. O hit@10 local voltou a 0.977, e o relatório acompanha a variação entre execuções no modo local.
- Só full-text, antes da 2.00,617
- Full-text com filtro de stopwords0,666
- Mais embeddings locais0,815
- 3.3.3: full-text, com o fluxo de observações0,951
- 3.3.3: embeddings locais, com o fluxo de observações0,943
O que foi cada passo
- Tirar as stopwords das consultas full-text somou 4,9 pontos de hit@5.
- O modelo de embeddings dentro do processo somou mais, sem chave de API.
- O fluxo de observações, ligado por padrão desde a 3.0, deixa as observações brutas de uma sessão votarem na página dela. Ele levou o full-text de 0,662 para 0,951.
- Nenhuma linha envolve chave de API ou LLM.
| Métrica | Antes da 2.0 | Full-text filtrado | Embeddings locais | 3.3.3, full-text | 3.3.3, embeddings locais |
|---|---|---|---|---|---|
| hit@5 | 0,617 | 0,666 | 0,815 | 0,951 | 0,943 |
| hit@1 | 0,449 | 0,532 | 0,536 | 0,857 | 0,760 |
Rode você mesmo
Acrescente --candidate-embeddings local ao segundo comando para rodar full-text e embeddings locais lado a lado. As execuções publicadas são de 3 de novembro de 2026, num Ryzen 9 7950X3D.
cargo build --release -p ai-memory-cli
cargo run --release -p ai-memory-eval -- retrieval --fetch
Resultados completos, por tipo de pergunta
A vazão de escrita também foi medida. Os números estão na página de arquitetura.
O que o fluxo de observações recuperou
Uma página de sessão guarda só um trecho curto de cada turno, então o detalhe que a pergunta procura muitas vezes só existe nas observações da sessão. Com o fluxo ligado, cada sessão que casa vota uma vez, pela melhor observação, na própria página. As mesmas 470 perguntas, o mesmo build, com o fluxo desligado e depois ligado.
| Métrica | Full-text, sem LLM | Embeddings locais |
|---|---|---|
| hit@5 | 0,662 → 0,951 | 0,796 → 0,936 |
| hit@1 | 0,511 → 0,857 | 0,536 → 0,757 |
| hit@10 | 0,687 → 0,972 | 0,881 → 0,970 |
| recall@5 | 0,533 → 0,893 | 0,657 → 0,871 |
| Tempo de consulta, percentil 95 | 90 ms → 112 ms | 264 ms → 234 ms |
| Tokens de contexto, cinco primeiros resultados | 256,3 → 266,1 | 225,7 → 264,1 |
- Esta comparação dos fluxos é o experimento de decomposição de 12 de outubro. A execução separada da versão 3.3.3 mediu 0,943 com embeddings locais. Ela não repete este experimento de ligar e desligar o fluxo.
- Com o fluxo ligado, o full-text sozinho marca um pouco acima dos embeddings locais. O vetor da página, como a linha full-text dela, ainda enxerga só o corpo que tem apenas o título.
- Dentro de uma execução o harness é determinístico. Entre execuções separadas, os tipos de pergunta menores variam até 0,03 para cima ou para baixo, então uma queda em um deles vista em uma única execução quer dizer pouco.
- Os números que outras ferramentas publicam neste dataset vêm dos harnesses delas, muitas vezes indexando sessões brutas inteiras, sem etapa de captura. Não são comparáveis diretamente, e nenhum ranking entre ferramentas é afirmado.
O que vem a seguir, e onde ele está atrás
Estas são recomendações documentadas no repositório. Nenhuma delas tem data.
Próximos passos recomendados
Acurácia das respostas em escala completa
O segundo harness já tem uma execução completa de recuperação, com acurácia, tempo de consulta e tokens de contexto. O modo de acurácia das respostas só tem uma amostra de 20 perguntas por enquanto, e os itens abaixo esperam por ele.
Um reranker local
Um cross-encoder que roda dentro do processo, sem LLM. No conjunto de 102 perguntas de um contribuidor, um adapter documentado para um modelo juiz local já igualou o reranker hospedado por uma fração da latência.
Padrões sustentados por números
Ranking por confiança, compactação de páginas frias, deduplicação e dream pass exigem configuração explícita. Retenção baseada em leituras já funciona por padrão. Outras mudanças de padrão precisam de evidência medida; links tipados ainda não têm peso extra no ranking.
Um começo mais fácil para quem usa Claude Code
Um importador para quem vem da memória embutida do Claude.
Fora dos planos: um banco de grafos, um sistema operacional de memória que se edita sozinho, conectores de nuvem, ou aumentar a quantidade de ferramentas só por aumentar.
Onde ele está atrás hoje
Ainda não existe reranker local, e o envelhecimento da memória não tem resultado medido. A lista completa está na página de comparação.
“A 1.x provou que a ideia funcionava. A 2.0 é a versão que eu recomendaria sem asterisco pra outra pessoa botar num time.”
Perguntas e respostas
O que é a ideia da LLM Wiki do Karpathy por trás do ai-memory?
O gist de abril de 2026 do Andrej Karpathy descreve um LLM que constrói e mantém uma wiki persistente de arquivos markdown entre você e as suas fontes brutas, de modo que o conhecimento é compilado uma vez e mantido atualizado. O ai-memory aplica isso a agentes de código, com captura automática pelos hooks de ciclo de vida e um caminho padrão que não faz chamadas a LLM.
O ai-memory é compatível com o Open Knowledge Format?
Desde a 2.0 todo projeto da wiki é nativamente um bundle OKF v0.2. Cada página tem frontmatter YAML com um type, cada projeto tem um index.md gerado, e o ai-memory export-okf empacota um projeto num tarball validado.
O que o benchmark LongMemEval-S mede no ai-memory?
Só recuperação: se uma sessão que contém a evidência aparece entre os primeiros resultados, em 470 perguntas. O hit@5 é 0,951 com full-text e o fluxo de observações, e 0,943 com embeddings locais. Ele não mede a acurácia das respostas.
Leia o raciocínio. Depois teste.
Gratuito e open source. A instalação padrão não faz chamadas a LLM e escuta só na sua máquina.