Hermes Local Memory

What Hermes Local Memory does

Hermes Local Memory stores everything in one SQLite file, by default ~/.hermes/memory/local_memory.sqlite, and needs no FastAPI, Docker, Redis, Postgres or daemon. Its LocalMemoryProvider exposes memory_get_card and memory_set_card for compact peer cards, memory_search for full-text search over active durable facts through SQLite FTS5, memory_context to show exactly what would be injected into the prompt, memory_conclude to add facts with evidence links, and memory_consolidate for deterministic maintenance.

Identity is treated as data: aliases such as telegram:1001 or honcho:Alice point to canonical peers, and scheduled peer review lets the agent map new platform identities or escalate ambiguous ones. Raw history is preserved, consolidation runs as conservative dry-runs before writes, and Honcho API import is additive and idempotent and never mutates Honcho. The project is inspired by Honcho, ships CLI inspection and repair tools with JSON output, and is marked alpha.

Key features

• Single local SQLite database with no memory server
• Tools for cards, search, context preview, conclusions and consolidation
• Alias-to-peer identity mapping across platforms
• Hermes markdown import and idempotent Honcho API import
• Deterministic consolidation with dry-run plans
• CLI inspection and repair tools with JSON output

When to use it

• Replacing a server-based memory backend with one local, inspectable database
• Migrating existing memory from Honcho into a local SQLite store
• Auditing exactly what memory would be injected into the next prompt

Who it is for: Hermes Agent users who want auditable, local-first agent memory that they can inspect and correct.

How it fits with Hermes Agent

Built as a memory provider for Hermes Agent, with a plugin shim and tools that Hermes calls during normal operation.

Note: The README marks the project alpha and advises a trial import and inspection before switching a production Hermes setup.

FAQ