heropen

A local AI memory system. Your memories live on your own machine — never uploaded, never synced, never taken away; it automatically organizes and trims them, so the more you use it, the more accurate it gets.

Name origin

The name comes from two places: her is taken from Hermes (the agent you're talking to right now), and open is taken from OpenClaw (open). her + open together make heropen.

Looked at separately, heropen starts with hero — echoing the imagery of Marvel superheroes. It's a memory layer: it remembers you, and keeps track of things for your agent.

Related MCP server: NeuralVaultCore

Installation

pip install heropen

Restart your agent, and you're done.

On first launch, it automatically detects your agent (Claude Code, Cursor, Windsurf, or any MCP client), creates the database, and registers the memory tools. Your agent will notice the new installation and walk you through setup.

30-second quick start

# 存一条记忆
heropen add "项目使用 FastAPI + SQLAlchemy，测试用 pytest"

# 搜索记忆
heropen search "项目技术栈"

# 查看状态
heropen status

# 诊断问题
heropen diagnose

Connect your agent (MCP)

Compatible with any MCP-capable agent. v1.8+ auto-detects and configures, no manual steps needed.

You can also add it manually to your agent config:

{
  "mcpServers": {
    "heropen": {
      "command": "heropen",
      "args": ["mcp"]
    }
  }
}

Restart the agent, and it has memory. Save a bug fix once, and it's remembered permanently across sessions.

Privacy promise

Your data stays on your machine. No telemetry. No heartbeat pings. All memories are stored in a local SQLite database. Vector retrieval uses a local embedding model by default (fastembed — just run pip install heropen[embedding]) — fully offline, zero cost. You can also point the EMBEDDING_ENDPOINT and EMBEDDING_API_KEY environment variables at your self-hosted embedding endpoint (OpenAI-compatible /v1/embeddings), so you never pay any third-party cloud. Memory text is used only to generate vectors and is never reported anywhere.

If neither the local embedding model nor a self-hosted endpoint is configured, search automatically falls back to fast full-text (FTS) matching — still fully offline, zero cost. So pip install heropen works with zero configuration; embeddings only improve retrieval quality, they never block basic usage.

Local capabilities will not be taken away (currently): the current version's local memory read/write, retrieval, and panel capabilities will not be migrated into cloud services that require a network connection; capabilities available in the free tier will not be cut in later versions. Optional network-accelerated features (such as your self-hosted embedding endpoint) are outside the scope of this promise — they're off by default, and whether to enable them is entirely up to you.

Why local

When memory is made into a cloud primitive, your conversation history and work context end up stored on someone else's servers. heropen takes the opposite approach: memories are written to ~/.heropen/, one SQLite file per agent, and the data physically never leaves your machine.

heropen doesn't upload memory content, doesn't sync to the cloud, doesn't collect usage data; the current version's core capabilities have no outbound connections and won't be turned into cloud services that require a network. What the cloud gives you is convenience; what local gives you is something only you can take away.

Your memory belongs to you

Memories are stored in the ~/.heropen/ directory on your machine, one SQLite file per agent. You can at any time:

• Back up / export: heropen export exports all memories to a local JSON file (heropen import can re-import them);

• Delete / clear: heropen delete <id> deletes a single entry, rm ~/.heropen/*.db clears the entire database — no need to go through us, no network required.

A friendlier Markdown + YAML export (human-readable, lossless round-trip, re-importable) is on the roadmap. The goal is "readable, portable, and returnable," not "interoperable with anyone."

Compliance statement

heropen is a local-first memory and context tool; your data is always stored on your machine and fully under your control. We comply with the relevant requirements of the "Interim Measures for the Administration of AI Anthropomorphic Interactive Services." The local-first architecture naturally satisfies its provisions on user data control and transparency, and the operation process is transparent and controllable for you.

Open source scope

The free version is fully open source (Apache-2.0). The commercial tier (Plus / Enterprise) is closed source.

Why choose heropen

Free = full core functionality, no feature stripping.

What makes heropen different

Local-first isn't a selling point unique to heropen — a dozen or so similar projects already use SQLite + MCP. The three positions heropen actually holds, and that no one else has taken yet, are:

• Multi-agent private domain / shared domain layering. The free tier gives you 2 fully private agents (high-frequency resident agents like Hermes / WorkBuddy each get an isolated database), plus an optional shared domain (_shared) for agents to exchange knowledge on demand. Most competitors have only a single flat namespace.

• Time awareness before conversation (since v1.8.7). At every opening, the agent automatically gets the local time, time-of-day words, the interval since the last conversation, and whether a sleep cycle was crossed — a time baseline for the interaction side that nobody else does.

• Zero-dependency installation surface. A single pip install heropen line — no Docker, no Postgres, no Ollama required. Few in the category can claim "runs with no prerequisite dependencies."

How to choose

When picking a memory solution, don't just look at recall rate — look at five things:

1. Deployment barrier: Can a one-line pip install get it running, or do you need Docker / Postgres / Ollama / API keys to start?

2. Dependencies and cost: Does the write path burn LLM tokens? Is it zero external dependencies?

3. Portability: Can memories be exported to readable files, taken away, and re-imported?

4. Secure defaults: Does the listening port bind to loopback by default or 0.0.0.0? Is it zero telemetry?

5. Engineering tax: Are write discipline and invalidation mechanisms clear? Does it conflict with Prompt Cache? How are cross-model capacity limits handled? Is there a data tax on embedding migration?

Run heropen doctor once, and the five items above will each give you a three-state self-check of "pass / warning / alert."

Links

• Website: heropen.net

• Docs: heropen.net/heropen/docs

• GitHub: github.com/Koradji77/heropen

Roadmap

• Currently focused on desktop local use. Mobile / cross-device sync is out of scope for now — it conflicts with the default promise of "data never leaves your machine," and we won't ship a half-baked product just to make a statement. If we ever do it, it will necessarily be user-owned storage + end-to-end encryption + off by default.

• Markdown + YAML memory export (lossless round-trip).

• More productized capabilities for agent private / shared domains.

License

Apache-2.0