What Is graph-memory? A Knowledge Graph Memory Plugin

graph-memory is a native knowledge-graph memory plugin for DeepSeek Harness (DSH) that turns conversation history into traceable, searchable, cross-session memory: it distills experience into TASK, SKILL, and EVENT nodes with typed edges, and during recall injects only a relevant local subgraph instead of replaying the full history, compressing context and cutting token usage. This article is based on the official README and covers what it is, its core features, installation, typical usage, and troubleshooting.

What Is graph-memory?

graph-memory solves the problems of context bloat and experience lost across sessions: it turns conversation history into a structured knowledge graph so that "which past knowledge is worth recalling now" replaces "stuff the whole history back into the prompt." The following facts come from the official README (source):

graph-memory is developed in TypeScript by adoresever and open-sourced under MIT. The README draws one line between it and compaction: "Compaction answers 'how much of this conversation still fits?' Graph Memory answers 'which past knowledge is worth recalling now?'" Reusable conversation knowledge becomes typed nodes — TASK (goals, execution, outcomes), SKILL (validated reusable methods), and EVENT (errors, fixes, decisions, changes, facts) — while typed edges such as USED_SKILL, SOLVED_BY, REQUIRES, PATCHES, and CONFLICTS_WITH preserve relationships. When a new question arrives, the plugin retrieves a relevant local subgraph instead of replaying the complete history. It is a native DSH Plugin (Cordis adapter) that stores data in SQLite by default with no graph database required, and needs Node.js 22.13+.

What Are the Core Features of graph-memory?

graph-memory's core capabilities are native host integration, durable cross-session memory, context compression, smart recall, and local-first storage: each conversation becomes reusable knowledge that later sessions recall on demand with traceable provenance. All of these come from the official README (source):

• Native host integration: loaded through the DSH/Cordis plugin lifecycle rather than simulated through an MCP side channel, hooking into Session, Tool, Agent Loop, Prompt Assembly, LLM, and Credentials seams without forking or modifying the DSH core.
• Durable cross-session memory: knowledge from Session A can be recalled automatically in Session B; memory survives DSH restarts; stable event IDs make resume and hot-reload ingestion idempotent; source sessions and graph edges explain why a memory was recalled.
• Smaller, cleaner context: keeps the newest real user turns verbatim (freshTurnCount, default 5); the older model-facing prefix is replaced by a rolling checkpoint via the DSH compaction service; only a relevant subgraph enters the prompt, bounded by recallTokenBudget (default 4096); a specific seven-turn workflow measured about 75% token reduction (scenario-level, not a universal guarantee).
• Smart recall: semantic vector retrieval with FTS5 lexical fallback, plus community detection, PageRank, and bounded graph traversal; automatic injection uses a high-precision semantic gate (autoRecallMinScore, default 0.6) and never falls back to query-independent community representatives.
• Local-first and lightweight: SQLite by default with no graph database deployment; embeddings are optional and recall falls back to FTS5 without them; data stays in the local profile; OpenAI-compatible embeddings support DashScope, OpenAI, and local providers.
• Observable and verifiable: gm_status reports store path, graph counts, vector coverage, mode, and dimensions; model or dimension changes trigger re-embedding; critical knowledge can be recorded deterministically with gm_record.

How to Install and Enable graph-memory?

Installing graph-memory takes a single command: the current beta (1.6.0-beta.9) is not yet published to npm, but the repository ships its prebuilt runtime and can be installed from the GitHub source without authorizing install scripts. The commands below come from the official README (source); the prerequisite is Node.js 22.13+:

1. Install graph-memory: run the install command in a DeepSeek Harness terminal to add the plugin to the current profile:

npx @deepseek-ai/dsh plugin --profile web add github:adoresever/graph-memory

Wait for the install to finish. Alternatively, build and install a tarball from a checkout: git clone → npm install → npm test → npm pack → then add /absolute/path/to/graph-memory-1.6.0-beta.9.tgz.

2. Update graph-memory: re-run the install command to overwrite it with the latest version:

npx @deepseek-ai/dsh plugin --profile web update github:adoresever/graph-memory

3. Remove graph-memory: when you no longer need it, run the removal command:

npx @deepseek-ai/dsh plugin remove graph-memory

4. Enable and verify: after installation, confirm the plugin is enabled and inspect the current configuration:

npx @deepseek-ai/dsh --profile web --dump-config
npx @deepseek-ai/dsh web

After installation, verify that graph-memory/dsh is enabled under Settings → Plugins → Plugin list. The default store is $DSH_HOME/graph-memory/graph-memory.db; without DSH_HOME it is normally ~/.dsh/graph-memory/graph-memory.db.

Typical graph-memory Usage

graph-memory needs almost no day-to-day intervention — the plugin recalls relevant memory automatically during Prompt Assembly; for deterministic recording or explicit retrieval, use the gm_record and gm_search commands. The commands below come from the official README (source):

1. Record critical knowledge: automatic extraction depends on auxiliary-model output stability, so in beta record important knowledge deterministically with gm_record:

npx @deepseek-ai/dsh gm_record

2. Search long-term memory explicitly: gm_search performs explicit, broad graph search (automatic recall is more precise; explicit search covers more ground):

npx @deepseek-ai/dsh gm_search

3. Inspect plugin state: gm_status reports store path, graph counts, vector coverage, mode, and dimensions:

npx @deepseek-ai/dsh gm_status

Note that automatic recall does not require an explicit gm_search call — the plugin injects relevant memory during Prompt Assembly; the tool list also includes gm_stats (node, edge, type, and community statistics).

4. Optional: configure vector embeddings: to use semantic vectors instead of FTS5 lexical retrieval, configure an OpenAI-compatible endpoint such as DashScope and start:

export GRAPH_MEMORY_EMBEDDING_API_KEY='replace-with-your-key'
export GRAPH_MEMORY_EMBEDDING_BASE_URL='https://dashscope.aliyuncs.com/compatible-mode/v1'
export GRAPH_MEMORY_EMBEDDING_MODEL='text-embedding-v4'
export GRAPH_MEMORY_EMBEDDING_DIMENSIONS='1024'
dsh web

Do not send secrets in chat — Cordis stores only a credential reference and DSH credentials resolve the real value for each embedding operation; without embeddings the plugin continues with FTS5 and does not block conversation.

graph-memory Troubleshooting

graph-memory issues usually fall into three groups: "installed but nothing is recalled," "old knowledge is not retrieved," and "embedding setup fails"; below are symptoms, causes, and fixes. The troubleshooting guidance follows the official README (source):

1. Symptom: no automatic recall after installation. Cause: the plugin is not enabled, or knowledge must first accumulate in the same store. Fix: confirm graph-memory/dsh is enabled under Settings → Plugins → Plugin list; knowledge from Session A must be extracted into the graph before Session B can recall it; inspect the store path and graph counts with gm_status:

npx @deepseek-ai/dsh gm_status

2. Symptom: critical knowledge is not remembered or extraction is unstable. Cause: automatic extraction depends on auxiliary-model output stability. Fix: persist critical knowledge deterministically with gm_record:

npx @deepseek-ai/dsh gm_record

3. Symptom: semantic vector recall matches poorly. Cause: embeddings are not configured, so recall falls back to FTS5 lexical search; or a model/dimension change has not been re-embedded. Fix: configure DashScope embedding environment variables per the README and restart (see Typical Usage), then check vector coverage with gm_status; model or dimension changes trigger re-embedding automatically.

4. Symptom: gm_update / gm_maintain report "not found." Cause: these two tools remain OpenClaw-entry tools and are not yet exposed by DSH. Fix: in DSH use gm_record to record and gm_search to retrieve; those commands are all you need.

Use Cases and Notes

graph-memory fits DSH workflows that need cross-session experience reuse and face ever-growing contexts; it is local-first by default, which brings a few limitations worth knowing. Facts come from the official README (source).

Good fits: long sessions and multi-session projects that reuse experience across sessions; token-sensitive workflows, with roughly 75% context compression measured in one scenario; memory that needs traceable provenance, since recall explains why a memory was retrieved.

Notes and limitations:

• The current beta is not published to npm; install from the GitHub source or a source-built tarball;
• Automatic extraction depends on auxiliary-model output stability; use gm_record for critical knowledge;
• Data stays in local SQLite by default; API keys come from host credentials or environment variables, never the database; rotate any secret that has appeared in chat, logs, or screenshots;
• Recalled history is marked as untrusted reference material and cannot override current user instructions;
• Vectors with different dimensions are never silently compared; model or dimension changes trigger re-embedding.

Project Links

graph-memory is an MIT-licensed open-source project maintained by adoresever, currently in beta (1.6.0-beta.9) on the DSH side.

Visit the plugin detail page for full information: graph-memory.

It is a good fit for DSH workflows that need durable, cross-session memory.

This page is an independent guide rewritten from the plugin's official README — for the authoritative documentation and the latest changes, defer to the source: adoresever/graph-memory. A plugin is third-party code that runs on your machine once installed; inclusion is not an endorsement — review the source before installing.