graph-memory

Compaction asks “how much of this conversation still fits?”; Graph Memory asks “which past knowledge is worth recalling now?”

What problem it solves

Conversational agents usually keep context by compacting and replaying history: compaction loses detail, replay makes the context ever longer and more expensive. graph-memory takes a different path — it distills reusable conversation knowledge into a typed knowledge graph, then retrieves only the relevant local subgraph for each new question instead of stuffing the whole history back into the prompt. In a seven-turn benchmark (installing, authenticating, and querying bilibili-mcp), turn 7 tokens dropped from 95,187 to 23,977 — roughly 75% in that scenario, not a universal guarantee.

It splits conversation into three node types — TASK (goals and execution), SKILL (validated reusable methods), EVENT (errors, fixes, decisions, changes) — and links them with typed edges such as USED_SKILL, SOLVED_BY, REQUIRES, PATCHES, and CONFLICTS_WITH. Every memory keeps its source session and graph edges, so recall is explainable: you can see why it was remembered.

Key features

• Native host integration: loaded through the DSH/Cordis plugin lifecycle (no MCP side channel), wiring Session, Tool, Agent Loop, Prompt Assembly, LLM, and Credentials seams without forking or modifying DSH core
• Durable cross-session memory: knowledge from Session A is recalled automatically in Session B, survives restarts, and stable event IDs keep resume / HMR ingestion idempotent
• Dual-path recall: semantic vector retrieval with an FTS5 lexical fallback, plus community detection, PageRank, and bounded graph traversal — only a relevant subgraph enters the prompt
• Local-first and lightweight: SQLite by default with no graph database; embeddings are optional (OpenAI-compatible: DashScope / OpenAI / local), falling back to FTS5 without them
• Observable and verifiable: gm_status reports store path, graph counts, vector coverage, and dimensions; model or dimension changes trigger re-embedding
• Explicit tools: gm_search for long-term graph search, gm_record for deterministic critical knowledge, gm_stats for node / edge / community statistics

Quick start

The beta is not yet on npm, so build a tarball from source (Node 22.19+ or 24+):

git clone https://github.com/adoresever/graph-memory.git && cd graph-memory

npm ci && npm test && npm run build && npm pack

npx @deepseek-ai/dsh plugin —profile web add /absolute/path/to/graph-memory-1.6.0-beta.1.tgz

Then verify graph-memory/dsh is enabled under Settings → Plugins and restart dsh web. The default store is $DSH_HOME/graph-memory/graph-memory.db (normally ~/.dsh/graph-memory/). Automatic recall needs no explicit tool call; to enable vectors set the GRAPH_MEMORY_EMBEDDING_* environment variables (see the README’s DashScope example).

Who it is for

• Users who want long-term memory that survives session switches and recalls on demand
• Knowledge workers and teams who need explainable, traceable RAG-style memory
• Heavy DSH users watching context-token costs and wanting a relevant subgraph instead of full history replay
• Privacy-minded users who want data kept local without deploying a graph database