Provedores de memória

O Hermes Agent vem com 8 plugins de provedor de memória externa que dão ao agente conhecimento persistente, que atravessa sessões, além do MEMORY.md e do USER.md embutidos. Só um provedor externo pode estar ativo por vez — a memória embutida fica sempre ativa junto com ele.

Início rápido

hermes memory setup      # seletor interativo + configuração
hermes memory status     # veja o que está ativo
hermes memory off        # desliga o provedor externo

Você também pode escolher o provedor de memória ativo por hermes plugins → Provider Plugins → Memory Provider.

Ou definir na mão no ~/.hermes/config.yaml:

memory:
  provider: openviking   # ou honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

Como funciona

Quando um provedor de memória está ativo, o Hermes automaticamente:

1. Injeta o contexto do provedor no prompt de sistema (o que o provedor sabe)
2. Pré-busca memórias relevantes antes de cada turno (em segundo plano, sem travar)
3. Sincroniza os turnos da conversa com o provedor depois de cada resposta
4. Extrai memórias no fim da sessão (nos provedores que suportam isso)
5. Espelha as escritas da memória embutida no provedor externo
6. Acrescenta ferramentas específicas do provedor para o agente buscar, guardar e gerenciar memórias

A memória embutida (MEMORY.md / USER.md) continua funcionando exatamente como antes. O provedor externo é um acréscimo.

Provedores disponíveis

Honcho

Modelagem de usuário nativa de IA, que atravessa sessões, com raciocínio dialético, injeção de contexto no escopo da sessão, busca semântica e conclusões persistentes. O contexto base agora inclui o resumo da sessão, junto com a representação do usuário e os cartões de peer, dando ao agente noção do que já foi discutido.

Melhor para	Sistemas multiagente com contexto entre sessões, alinhamento entre usuário e agente
Precisa de	pip install honcho-ai + chave de API ou instância auto-hospedada
Armazenamento dos dados	Honcho Cloud ou auto-hospedado
Custo	Preço do Honcho (nuvem) / grátis (auto-hospedado)

Ferramentas (5): honcho_profile (ler/atualizar o cartão de peer), honcho_search (busca semântica), honcho_context (contexto da sessão — resumo, representação, cartão, mensagens), honcho_reasoning (sintetizado por LLM), honcho_conclude (criar/apagar conclusões)

Arquitetura: injeção de contexto em duas camadas — uma camada base (resumo da sessão + representação + cartão de peer, atualizada conforme contextCadence) mais um suplemento dialético (raciocínio de LLM, atualizado conforme dialecticCadence). O dialético escolhe automaticamente entre prompts de partida a frio (fatos gerais do usuário) e prompts quentes (contexto no escopo da sessão), conforme exista ou não contexto base.

Três ajustes ortogonais de configuração controlam custo e profundidade de forma independente:

• contextCadence — de quanto em quanto tempo a camada base se atualiza (frequência de chamadas de API)
• dialecticCadence — de quanto em quanto tempo o LLM dialético dispara (frequência de chamadas de LLM)
• dialecticDepth — quantas passadas de .chat() por invocação dialética (1–3, profundidade do raciocínio)

O dialético injetado automaticamente também escala o nível de raciocínio conforme o tamanho da consulta (consulta mais longa → raciocínio mais fundo, com teto em reasoningLevelCap); veja Nível de raciocínio adaptado à consulta.

Assistente de configuração:

hermes memory setup        # escolha "honcho" — roda o pós-setup específico do Honcho

O comando antigo hermes honcho setup continua funcionando (agora ele redireciona para hermes memory setup), mas só é registrado depois que o Honcho vira o provedor de memória ativo.

Máquinas remotas ou sem interface gráfica: para autenticar na nuvem em uma máquina sem navegador (SSH, VM remota), escolha device na pergunta de método de autenticação do assistente. A CLI imprime um código curto e um link de verificação; abra o link no navegador de qualquer outra máquina, aprove, e a configuração termina — sem copiar e colar chave de API. O assistente já usa essa opção por padrão quando não detecta um navegador local utilizável.

Configuração: $HERMES_HOME/honcho.json (local ao perfil) ou ~/.honcho/config.json (global). Ordem de resolução: $HERMES_HOME/honcho.json > ~/.hermes/honcho.json > ~/.honcho/config.json. Veja a referência de configuração e o guia de integração do Honcho.

Referência completa de configuração

Chave	Padrão	Descrição
apiKey	--	Chave de API de app.honcho.dev
baseUrl	--	URL base para o Honcho auto-hospedado
peerName	--	Identidade do peer do usuário
aiPeer	chave do host	Identidade do peer de IA (uma por perfil)
workspace	chave do host	ID do espaço de trabalho compartilhado
contextTokens	null (sem teto)	Orçamento de tokens do contexto injetado automaticamente por turno. Corta em fronteira de palavra
contextCadence	1	Mínimo de turnos entre chamadas de API de context() (atualização da camada base)
dialecticCadence	2	Mínimo de turnos entre chamadas de LLM de peer.chat(). Recomendado 1–5. Só vale nos modos hybrid/context
dialecticDepth	1	Número de passadas de .chat() por invocação dialética. Limitado a 1–3. Passada 0: prompt frio/quente, passada 1: autoauditoria, passada 2: reconciliação
dialecticDepthLevels	null	Vetor opcional de níveis de raciocínio por passada, por exemplo ["minimal", "low", "medium"]. Sobrepõe os padrões proporcionais
dialecticReasoningLevel	'low'	Nível de raciocínio base: minimal, low, medium, high, max
dialecticDynamic	true	Quando true, o modelo pode sobrepor o nível de raciocínio em cada chamada, por parâmetro da ferramenta
dialecticMaxChars	600	Máximo de caracteres do resultado dialético injetados no prompt de sistema
recallMode	'hybrid'	hybrid (injeção automática + ferramentas), context (só injeção), tools (só ferramentas)
writeFrequency	'async'	Quando descarregar as mensagens: async (thread em segundo plano), turn (síncrono), session (em lote, no fim), ou um inteiro N
saveMessages	true	Se as mensagens devem ser persistidas na API do Honcho
observationMode	'directional'	directional (tudo ligado) ou unified (pool compartilhado). Sobreponha com o objeto observation
messageMaxChars	25000	Máximo de caracteres por mensagem (fatiado se passar)
dialecticMaxInputChars	10000	Máximo de caracteres da consulta dialética enviada a peer.chat()
sessionStrategy	'per-directory'	per-directory, per-repo, per-session, global
pinUserPeer	false	Só no gateway. Quando true, todo usuário do gateway que não seja agente colapsa em peerName; o pin sobrepõe todos os aliases
userPeerAliases	{}	Só no gateway. Mapeia IDs de runtime para peers ({"7654321": "alice"}). Muitos para um
runtimePeerPrefix	""	Só no gateway. Coloca em namespace os IDs de runtime desconhecidos (telegram_7654321) quando nenhum alias casa

honcho.json mínimo (nuvem)

{
  "apiKey": "sua-chave-de-app.honcho.dev",
  "hosts": {
    "hermes": {
      "enabled": true,
      "aiPeer": "hermes",
      "peerName": "seu-nome",
      "workspace": "hermes"
    }
  }
}

honcho.json mínimo (auto-hospedado)

{
  "baseUrl": "http://localhost:8000",
  "hosts": {
    "hermes": {
      "enabled": true,
      "aiPeer": "hermes",
      "peerName": "seu-nome",
      "workspace": "hermes"
    }
  }
}

Migrando do hermes honcho

Se você usava o hermes honcho setup antes, a sua configuração e todos os dados do lado do servidor continuam intactos. Basta reativar pelo assistente de configuração de novo, ou definir na mão memory.provider: honcho para reativar pelo sistema novo.

Configuração com vários peers:

O Honcho modela conversas como peers trocando mensagens — um peer de usuário mais um peer de IA por perfil do Hermes, todos compartilhando um espaço de trabalho. O espaço de trabalho é o ambiente comum: o peer de usuário é global entre perfis, e cada peer de IA tem identidade própria. Cada peer de IA constrói uma representação e um cartão independentes a partir das próprias observações, então um perfil coder segue orientado a código enquanto um perfil writer segue editorial, diante do mesmo usuário.

O mapeamento:

Conceito	O que é
Espaço de trabalho	Ambiente compartilhado. Todos os perfis do Hermes sob um mesmo espaço de trabalho enxergam a mesma identidade de usuário.
Peer de usuário (peerName)	A pessoa. Compartilhado entre os perfis do espaço de trabalho.
Peer de IA (aiPeer)	Um por perfil do Hermes. A chave de host hermes → o padrão; hermes.<profile> para os demais.
Observação	Chaves por peer que controlam o que o Honcho modela a partir das mensagens de quem. directional (padrão, as quatro ligadas) ou unified (pool de um observador só).

Perfil novo, peer novo no Honcho

hermes profile create coder --clone

O --clone cria um bloco de host hermes.coder no honcho.json com aiPeer: "coder", workspace compartilhado e peerName, recallMode, writeFrequency, observation etc. herdados. O peer de IA é criado de imediato no Honcho, para existir antes da primeira mensagem.

Perfis já existentes, criar os peers do Honcho depois

hermes honcho sync

Varre todos os perfis do Hermes, cria blocos de host para os perfis que não têm um, herda as configurações do bloco hermes padrão e cria os peers de IA novos de imediato. É idempotente — pula os perfis que já têm bloco de host.

Observação por perfil

Cada bloco de host pode sobrepor a configuração de observação de forma independente. Exemplo: um perfil focado em código, onde o peer de IA observa o usuário mas não modela a si mesmo:

"hermes.coder": {
  "aiPeer": "coder",
  "observation": {
    "user": { "observeMe": true, "observeOthers": true },
    "ai":   { "observeMe": false, "observeOthers": true }
  }
}

Chaves de observação (um conjunto por peer):

Chave	Efeito
observeMe	O Honcho constrói uma representação deste peer a partir das mensagens dele
observeOthers	Este peer observa as mensagens do outro peer (alimenta o raciocínio entre peers)

Presets via observationMode:

• "directional" (padrão) — as quatro chaves ligadas. Observação mútua completa; habilita o dialético entre peers.
• "unified" — usuário com observeMe: true, IA com observeOthers: true, o resto falso. Pool de um observador só; a IA modela o usuário mas não a si mesma, e o peer de usuário só modela a si mesmo.

Chaves definidas no lado do servidor, pelo painel do Honcho, ganham dos padrões locais — elas são sincronizadas de volta no início da sessão.

Veja a página do Honcho para a referência completa de observação.

Mapeamento de identidade no gateway

O modelo de peers acima cobre sessões de CLI, TUI e desktop, em que toda conversa resolve para peerName. O gateway acrescenta um segundo eixo: os usuários chegam com IDs de runtime nativos da plataforma (UID do Telegram, snowflake do Discord, usuário do Slack), e três chaves decidem para qual peer cada ID resolve.

Chave	Efeito
pinUserPeer: true	Todo usuário do gateway que não seja agente colapsa em peerName. O pin é checado primeiro, então ele sobrepõe todos os aliases — escolha só quando nenhuma identidade do lado do usuário precisa de peer próprio
userPeerAliases	Mapeia IDs de runtime específicos para peers ({"7654321": "alice"}). É o lugar de rotear identidades distintas — inclusive agentes que carregam cada um o seu peer
runtimePeerPrefix	Coloca em namespace qualquer ID de runtime não mapeado (telegram_7654321), para que plataformas com IDs de formato parecido não colidam

Fora do gateway, essas chaves não fazem nada. O hermes memory setup só pergunta por elas quando detecta uma plataforma de gateway conectada. Veja a página do Honcho para a escada do resolvedor e o fluxo de configuração.

Exemplo completo de honcho.json (com vários perfis)

{
  "apiKey": "sua-chave",
  "workspace": "hermes",
  "peerName": "eri",
  "hosts": {
    "hermes": {
      "enabled": true,
      "aiPeer": "hermes",
      "workspace": "hermes",
      "peerName": "eri",
      "recallMode": "hybrid",
      "writeFrequency": "async",
      "sessionStrategy": "per-directory",
      "observation": {
        "user": { "observeMe": true, "observeOthers": true },
        "ai": { "observeMe": true, "observeOthers": true }
      },
      "dialecticReasoningLevel": "low",
      "dialecticDynamic": true,
      "dialecticCadence": 2,
      "dialecticDepth": 1,
      "dialecticMaxChars": 600,
      "contextCadence": 1,
      "messageMaxChars": 25000,
      "saveMessages": true
    },
    "hermes.coder": {
      "enabled": true,
      "aiPeer": "coder",
      "workspace": "hermes",
      "peerName": "eri",
      "recallMode": "tools",
      "observation": {
        "user": { "observeMe": true, "observeOthers": false },
        "ai": { "observeMe": true, "observeOthers": true }
      }
    },
    "hermes.writer": {
      "enabled": true,
      "aiPeer": "writer",
      "workspace": "hermes",
      "peerName": "eri"
    }
  },
  "sessions": {
    "/home/usuario/meuprojeto": "meuprojeto-main"
  }
}

Veja a referência de configuração e o guia de integração do Honcho.

---

OpenViking

Banco de dados de contexto da Volcengine (ByteDance), com hierarquia de conhecimento no estilo de sistema de arquivos, recuperação em camadas e extração automática de memória em 6 categorias.

Melhor para	Gestão de conhecimento auto-hospedada, com navegação estruturada
Precisa de	OpenViking inicializado, validado e em execução
Armazenamento dos dados	Auto-hospedado (local ou na nuvem)
Custo	Grátis (código aberto, AGPL-3.0)

Ferramentas (6): viking_search (busca semântica), viking_read (em camadas: resumo/panorama/completo), viking_browse (navegação no sistema de arquivos), viking_remember (guardar fatos), viking_forget (apagar um arquivo de memória pela URI viking:// exata), viking_add_resource (ingerir URLs/documentos)

Configuração:

# Prepare o OpenViking primeiro
openviking-server init
openviking-server doctor
openviking-server

# Depois configure o Hermes
hermes memory setup    # escolha "openviking"
# Ou na mão:
hermes config set memory.provider openviking

O hermes memory setup pode reaproveitar ou copiar os valores de conexão de ~/.openviking/ovcli.conf. A configuração manual usa o arquivo .env do perfil ativo; no perfil padrão, esse arquivo é o ~/.hermes/.env, e nos perfis nomeados use ~/.hermes/profiles/<profile>/.env.

OPENVIKING_ENDPOINT=http://127.0.0.1:1933
# OPENVIKING_API_KEY=...
# OPENVIKING_ACCOUNT=default
# OPENVIKING_USER=default
# OPENVIKING_AGENT=hermes

As configurações do servidor do OpenViking ficam no ov.conf (--config, OPENVIKING_CONFIG_FILE ou ~/.openviking/ov.conf). Os valores de conexão do cliente ficam no ovcli.conf (OPENVIKING_CLI_CONFIG_FILE ou ~/.openviking/ovcli.conf).

Principais recursos:

• Carregamento de contexto em camadas: L0 (~100 tokens) → L1 (~2 mil) → L2 (completo)
• Extração automática de memória no commit da sessão (perfil, preferências, entidades, eventos, casos, padrões)
• Esquema de URI viking:// para navegar pelo conhecimento de forma hierárquica

OPENVIKING_ACCOUNT e OPENVIKING_USER são usados no modo local/confiável. OPENVIKING_AGENT é o ID de peer do Hermes dentro do OpenViking, para memórias no escopo do peer. O Hermes envia User-Agent: openviking-memory-hermes/<version> nas requisições ao OpenViking. Esse identificador padrão do harness não contém nenhum identificador de usuário e não acrescenta uma requisição separada.

---

Mem0

Extração de fatos por LLM no lado do servidor, com busca semântica, reordenação e deduplicação automática. Três modos de conexão: Platform (Mem0 Cloud), painel auto-hospedado (um servidor Mem0 que você roda via Docker) e OSS (Mem0 no mesmo processo, com o seu próprio LLM + banco vetorial).

Melhor para	Gestão de memória sem esforço — o Mem0 cuida da extração automaticamente
Precisa de	pip install mem0ai + chave de API (platform), um servidor Mem0 em execução (painel auto-hospedado) ou um LLM + banco vetorial (OSS)
Armazenamento dos dados	Mem0 Cloud (platform), o seu próprio servidor Mem0 (painel auto-hospedado) ou no mesmo processo (OSS)
Custo	Preço do Mem0 (platform) / grátis (auto-hospedado ou OSS)

Ferramentas (4): mem0_search (busca semântica; reordenação opcional no modo platform, desligada por padrão), mem0_add (guardar fatos literais), mem0_update (atualizar por ID), mem0_delete (apagar por ID)

Configuração (Platform):

hermes memory setup    # escolha "mem0" → "Platform"
# Ou na mão:
hermes config set memory.provider mem0
echo "MEM0_API_KEY=sua-chave" >> ~/.hermes/.env

Configuração (OSS):

hermes memory setup    # escolha "mem0" → "Open Source (self-hosted)"
# Ou por flags:
hermes memory setup mem0 --mode oss --oss-llm openai --oss-llm-key sk-... --oss-vector qdrant

Pré-visualizar sem escrever arquivos:

hermes memory setup mem0 --mode oss --oss-llm-key sk-... --dry-run

Configuração (painel auto-hospedado): conecte-se a um servidor Mem0 que você roda via Docker (a API REST do painel):

hermes memory setup    # escolha "mem0" → "Self-hosted server"
# Ou por flags:
hermes memory setup mem0 --mode selfhosted --host http://localhost:8888 --api-key sua-chave-de-api-de-admin

Ou configure na mão — seja por variáveis de ambiente:

echo "MEM0_HOST=http://localhost:8888" >> ~/.hermes/.env
echo "MEM0_API_KEY=sua-chave-de-api-de-admin" >> ~/.hermes/.env

seja no mem0.json:

{ "host": "http://localhost:8888", "api_key": "sua-chave-de-api-de-admin" }

O plugin autentica com X-API-Key e usa as rotas /search / /memories do servidor. O api_key é opcional (omita apenas em servidores com AUTH_DISABLED). Não defina mode: oss — ele tem precedência sobre o host.

Configuração: $HERMES_HOME/mem0.json (ajustes de comportamento). Só o segredo MEM0_API_KEY pertence ao ~/.hermes/.env.

Chave	Padrão	Descrição
mode	platform	platform (Mem0 Cloud) ou oss (autogerenciado, no mesmo processo)
host	—	URL do servidor Mem0 auto-hospedado (painel do Docker). Roteia por HTTP com X-API-Key; não combine com mode: oss
user_id	hermes-user	Identificador do usuário
agent_id	hermes	Identificador do agente
rerank	false	Reordena os resultados de busca por relevância (só no modo platform)

Provedores suportados no OSS:

Componente	Provedores
LLM	openai, ollama
Embedder	openai, ollama
Banco vetorial	qdrant (local/servidor), pgvector

Trocar de modo: rode de novo hermes memory setup mem0 --mode <platform|selfhosted|oss> ou edite o mem0.json direto.

---

Hindsight

Memória de longo prazo com grafo de conhecimento, resolução de entidades e recuperação por várias estratégias. A ferramenta hindsight_reflect faz uma síntese entre memórias que nenhum outro provedor oferece. Retém automaticamente os turnos completos da conversa (inclusive chamadas de ferramenta), com rastreio de documentos no nível da sessão.

Melhor para	Recuperação baseada em grafo de conhecimento, com relações entre entidades
Precisa de	Nuvem: chave de API de ui.hindsight.vectorize.io. Local: chave de API de um LLM (OpenAI, Groq, OpenRouter etc.)
Armazenamento dos dados	Hindsight Cloud ou PostgreSQL embutido local
Custo	Preço do Hindsight (nuvem) ou grátis (local)

Ferramentas: hindsight_retain (guardar com extração de entidades), hindsight_recall (busca por várias estratégias), hindsight_reflect (síntese entre memórias)

Configuração:

hermes memory setup    # escolha "hindsight"
# Ou na mão:
hermes config set memory.provider hindsight
echo "HINDSIGHT_API_KEY=sua-chave" >> ~/.hermes/.env

O assistente de configuração instala as dependências automaticamente e só instala o que o modo escolhido precisa (hindsight-client para a nuvem, hindsight-all para o local). Exige hindsight-client >= 0.4.22 (atualizado sozinho no início da sessão, se estiver desatualizado).

Interface do modo local: hindsight-embed -p hermes ui start

Configuração: $HERMES_HOME/hindsight/config.json

Chave	Padrão	Descrição
mode	cloud	cloud ou local
bank_id	hermes	Identificador do banco de memória
recall_budget	mid	Minúcia da recuperação: low / mid / high
memory_mode	hybrid	hybrid (contexto + ferramentas), context (só injeção automática), tools (só ferramentas)
auto_retain	true	Retém os turnos da conversa automaticamente
auto_recall	true	Recupera memórias automaticamente antes de cada turno
retain_async	true	Processa a retenção de forma assíncrona no servidor
retain_context	conversation between Hermes Agent and the User	Rótulo de contexto das memórias retidas
retain_tags	—	Tags padrão aplicadas às memórias retidas; mescladas com as tags passadas na chamada da ferramenta
retain_source	—	metadata.source opcional anexado às memórias retidas
retain_user_prefix	User	Rótulo usado antes dos turnos do usuário nas transcrições retidas automaticamente
retain_assistant_prefix	Assistant	Rótulo usado antes dos turnos do assistente nas transcrições retidas automaticamente
recall_tags	—	Tags para filtrar na recuperação

Veja o README do plugin para a referência completa de configuração.

---

Holographic

Repositório local de fatos em SQLite, com busca de texto completo FTS5, pontuação de confiança e HRR (Holographic Reduced Representations) para consultas algébricas composicionais.

Melhor para	Memória só local, com recuperação avançada e sem dependência externa
Precisa de	Nada (o SQLite está sempre disponível). NumPy é opcional, para a álgebra de HRR.
Armazenamento dos dados	SQLite local
Custo	Grátis

Ferramentas: fact_store (9 ações: add, search, probe, related, reason, contradict, update, remove, list), fact_feedback (avaliação de útil/inútil que treina as pontuações de confiança)

Configuração:

hermes memory setup    # escolha "holographic"
# Ou na mão:
hermes config set memory.provider holographic

Configuração: config.yaml, em plugins.hermes-memory-store

Chave	Padrão	Descrição
db_path	$HERMES_HOME/memory_store.db	Caminho do banco SQLite
auto_extract	false	Extrai fatos automaticamente no fim da sessão
default_trust	0.5	Pontuação de confiança padrão (0,0–1,0)

Capacidades exclusivas:

• probe — recuperação algébrica de uma entidade específica (todos os fatos sobre uma pessoa ou coisa)
• reason — consultas composicionais com E entre várias entidades
• contradict — detecção automática de fatos conflitantes
• Pontuação de confiança com feedback assimétrico (+0,05 útil / -0,10 inútil)

---

RetainDB

API de memória na nuvem com busca híbrida (vetorial + BM25 + reordenação), 7 tipos de memória e compressão delta.

Melhor para	Times que já usam a infraestrutura do RetainDB
Precisa de	Conta no RetainDB + chave de API
Armazenamento dos dados	RetainDB Cloud
Custo	US$ 20/mês

Ferramentas (10): retaindb_profile (perfil do usuário), retaindb_search (busca semântica), retaindb_context (contexto relevante para a tarefa), retaindb_remember (guardar com tipo + importância), retaindb_forget (apagar memórias), mais as ferramentas de arquivo: retaindb_upload_file, retaindb_list_files, retaindb_read_file, retaindb_ingest_file, retaindb_delete_file

Configuração:

hermes memory setup    # escolha "retaindb"
# Ou na mão:
hermes config set memory.provider retaindb
echo "RETAINDB_API_KEY=sua-chave" >> ~/.hermes/.env

---

ByteRover

Memória persistente pela CLI brv — árvore hierárquica de conhecimento com recuperação em camadas (texto aproximado → busca conduzida por LLM). Local em primeiro lugar, com sincronização opcional na nuvem.

Melhor para	Quem desenvolve e quer memória portátil, local em primeiro lugar, com uma CLI
Precisa de	CLI do ByteRover (npm install -g byterover-cli ou script de instalação)
Armazenamento dos dados	Local (padrão) ou ByteRover Cloud (sincronização opcional)
Custo	Grátis (local) ou preço do ByteRover (nuvem)

Ferramentas: brv_query (buscar na árvore de conhecimento), brv_curate (guardar fatos/decisões/padrões), brv_status (versão da CLI + estatísticas da árvore)

Configuração:

# Instale a CLI primeiro
curl -fsSL https://byterover.dev/install.sh | sh

# Depois configure o Hermes
hermes memory setup    # escolha "byterover"
# Ou na mão:
hermes config set memory.provider byterover

Principais recursos:

• Extração automática antes da compressão (guarda os achados antes que a compressão de contexto os descarte)
• Árvore de conhecimento guardada em $HERMES_HOME/byterover/ (no escopo do perfil)
• Sincronização em nuvem com certificação SOC2 Tipo II (opcional)

---

Supermemory

Memória semântica de longo prazo com recuperação de perfil, busca semântica, ferramentas explícitas de memória e ingestão da conversa no fim da sessão, pela API de grafo do Supermemory.

Melhor para	Recuperação semântica com perfil de usuário e construção de grafo no nível da sessão
Precisa de	pip install supermemory + chave de API na nuvem, ou um servidor auto-hospedado
Armazenamento dos dados	Supermemory Cloud ou auto-hospedado
Custo	Preço do Supermemory (nuvem) / grátis (auto-hospedado)

Ferramentas: supermemory_store (salvar memórias explícitas), supermemory_search (busca por similaridade semântica), supermemory_forget (esquecer por ID ou pela consulta que melhor casar), supermemory_profile (perfil persistente + contexto recente)

Configuração:

hermes memory setup    # escolha "supermemory"
# Ou na mão:
hermes config set memory.provider supermemory
echo 'SUPERMEMORY_API_KEY=***' >> ~/.hermes/.env

Configuração auto-hospedada:

npx supermemory local

Antes de rodar o hermes memory setup, defina a base_url em $HERMES_HOME/supermemory.json:

{
  "base_url": "http://localhost:6767"
}

Depois rode o hermes memory setup e informe a chave de API impressa pelo servidor local. Configurar o endpoint antes garante que a sondagem de conexão da configuração também fique local.

Configuração: $HERMES_HOME/supermemory.json

Chave	Padrão	Descrição
base_url	https://api.supermemory.ai	Endpoint da API do Supermemory hospedado ou auto-hospedado. Tem prioridade sobre SUPERMEMORY_BASE_URL.
container_tag	hermes	Tag de contêiner usada na busca e nas escritas. Aceita o modelo {identity} para tags no escopo do perfil.
auto_recall	true	Injeta contexto de memória relevante antes dos turnos
auto_capture	true	Guarda os turnos limpos de usuário e assistente depois de cada resposta
max_recall_results	10	Máximo de itens recuperados a formatar no contexto
profile_frequency	50	Inclui os fatos do perfil no primeiro turno e a cada N turnos
capture_mode	all	Pula turnos minúsculos ou triviais por padrão
search_mode	hybrid	Modo de busca: hybrid, memories ou documents
api_timeout	5.0	Tempo limite das requisições do SDK e de ingestão

Variáveis de ambiente: SUPERMEMORY_API_KEY (obrigatória), SUPERMEMORY_BASE_URL (alternativa de compatibilidade quando a base_url não está configurada), SUPERMEMORY_CONTAINER_TAG (sobrepõe a configuração).

A precedência da URL base é supermemory.json → SUPERMEMORY_BASE_URL → https://api.supermemory.ai. As operações do SDK, as sondagens de configuração e status e a ingestão da conversa usam todas o endpoint resolvido.

Principais recursos:

• Cerca automática de contexto — remove as memórias recuperadas dos turnos capturados, para evitar poluição recursiva da memória
• Ingestão da sessão inteira — a conversa completa é enviada uma vez, nas fronteiras da sessão
• Ingestão da conversa no fim da sessão (para /v4/conversations), para um perfil e um grafo mais ricos no Supermemory
• Roteamento auto-hospedado de ponta a ponta — as requisições do SDK, da sondagem e da ingestão de conversa usam o mesmo endpoint configurado
• Fatos de perfil injetados no primeiro turno e em intervalos configuráveis
• Contêineres no escopo do perfil — use {identity} em container_tag (por exemplo, hermes-{identity} → hermes-coder) para isolar as memórias por perfil do Hermes
• Modo com vários contêineres — habilite enable_custom_container_tags com uma lista custom_containers para deixar o agente ler e escrever em contêineres nomeados. As operações automáticas continuam no contêiner principal.

Exemplo com vários contêineres

{
  "container_tag": "hermes",
  "enable_custom_container_tags": true,
  "custom_containers": ["project-alpha", "shared-knowledge"],
  "custom_container_instructions": "Use project-alpha for coding context."
}

Suporte: Discord · support@supermemory.com

Memori

Memória estruturada de longo prazo usando o Memori Cloud, com captura em segundo plano dos turnos concluídos, contexto de turno ciente das ferramentas e ferramentas explícitas de recuperação para fatos, resumos, cota, cadastro e feedback.

Melhor para	Recuperação controlada pelo agente, com atribuição estruturada de projeto e sessão
Precisa de	pip install hermes-memori + hermes-memori install + chave de API do Memori
Armazenamento dos dados	Memori Cloud
Custo	Preço do Memori

Ferramentas: memori_recall (buscar na memória de longo prazo), memori_recall_summary (contexto resumido), memori_quota (uso/cota), memori_signup (pedir e-mail de cadastro), memori_feedback (enviar feedback sobre a integração)

Configuração:

pip install hermes-memori
hermes-memori install
hermes config set memory.provider memori
hermes memory setup

---

Comparação entre provedores

Provedor	Armazenamento	Custo	Ferramentas	Dependências	Recurso exclusivo
Honcho	Nuvem	Pago	5	honcho-ai	Modelagem dialética do usuário + contexto no escopo da sessão
OpenViking	Auto-hospedado	Grátis	6	openviking + servidor	Hierarquia de sistema de arquivos + carregamento em camadas
Mem0	Nuvem/auto-hospedado	Grátis/pago	4	mem0ai	Extração por LLM no servidor + modos auto-hospedado/OSS
Hindsight	Nuvem/local	Grátis/pago	3	hindsight-client	Grafo de conhecimento + síntese com reflect
Holographic	Local	Grátis	2	Nenhuma	Álgebra de HRR + pontuação de confiança
RetainDB	Nuvem	US$ 20/mês	10	requests	Compressão delta
ByteRover	Local/nuvem	Grátis/pago	3	CLI brv	Extração antes da compressão
Supermemory	Nuvem/auto-hospedado	Grátis/pago	4	supermemory	Cerca de contexto + ingestão de grafo da sessão + vários contêineres
Memori	Nuvem	Grátis/pago	5	hermes-memori	Memória ciente das ferramentas + recuperação estruturada

Isolamento por perfil

Os dados de cada provedor ficam isolados por perfil:

• Provedores de armazenamento local (Holographic, ByteRover) usam caminhos em $HERMES_HOME/, que mudam de perfil para perfil
• Provedores com arquivo de configuração (Honcho, Mem0, Hindsight, Supermemory) guardam a configuração em $HERMES_HOME/, então cada perfil tem as próprias credenciais
• Provedores em nuvem (RetainDB) derivam automaticamente nomes de projeto no escopo do perfil
• Provedores por variável de ambiente (OpenViking) são configurados pelo arquivo .env de cada perfil

Construir um provedor de memória

Veja o Guia do Desenvolvedor: Plugins de Provedor de Memória para saber como criar o seu.

---