name: superlocalmemory description: "AI agent memory with mathematical foundations. Store, recall, search, and manage memories locally with zero cloud dependency." version: "3.4.22" author: "Varun Pratap Bhardwaj" license: AGPL-3.0-or-later homepage: https://superlocalmemory.com repository: https://github.com/qualixar/superlocalmemory triggers:

• remember something
• recall memory
• search memories
• memory status
• store fact
• agent memory
• local memory
• memory health

SuperLocalMemory

AI agent memory that runs 100% locally. Four-channel retrieval (semantic, graph, BM25, temporal) with mathematical similarity scoring. No cloud, no API keys, EU AI Act compliant.

Installation

pip install superlocalmemory
# or
npm install -g superlocalmemory

Quick Start

slm remember "Alice works at Google as a Staff Engineer" --json
slm recall "Who is Alice?" --json
slm status --json

Commands

All data-returning commands support --json for structured agent-native output.

Memory Operations

slm remember "<content>" --json           # Store a memory
slm remember "<content>" --tags "a,b" --json
slm recall "<query>" --json               # Semantic search
slm recall "<query>" --limit 5 --json
slm list --json -n 20                     # List recent memories
slm forget "<query>" --json               # Preview matches (add --yes to delete)
slm forget "<query>" --json --yes         # Delete matching memories
slm delete <fact_id> --json --yes         # Delete specific memory by ID
slm update <fact_id> "<content>" --json   # Update a memory

Diagnostics

slm status --json                         # System status (mode, profile, DB)
slm health --json                         # Math layer health
slm trace "<query>" --json                # Recall with per-channel breakdown

Configuration

slm mode --json                           # Get current mode
slm mode a --json                         # Set mode (a=local, b=ollama, c=cloud)
slm profile list --json                   # List profiles
slm profile switch <name> --json          # Switch profile
slm profile create <name> --json          # Create profile
slm connect --json                        # Auto-configure IDEs
slm connect --list --json                 # List supported IDEs

Services (no --json)

slm setup                                 # Interactive setup wizard
slm mcp                                   # Start MCP server (for IDE integration)
slm dashboard                             # Open web dashboard
slm warmup                                # Pre-download embedding model

JSON Envelope

Every --json response follows a consistent envelope:

{
  "success": true,
  "command": "recall",
  "version": "3.0.22",
  "data": {
    "results": [
      {"fact_id": "abc123", "score": 0.87, "content": "Alice works at Google"}
    ],
    "count": 1,
    "query_type": "semantic"
  },
  "next_actions": [
    {"command": "slm list --json", "description": "List recent memories"}
  ]
}

Error responses:

{
  "success": false,
  "command": "recall",
  "version": "3.0.22",
  "error": {"code": "ENGINE_ERROR", "message": "Description of what went wrong"}
}

Operating Modes

Dual Interface

SuperLocalMemory works via both MCP and CLI:

• MCP: 24 tools for IDE integration (Claude Code, Cursor, Windsurf, VS Code, JetBrains, Zed)
• CLI: 18 commands with --json for scripts, CI/CD, agent frameworks (OpenClaw, Codex, Goose)

Part of Qualixar | Author: Varun Pratap Bhardwaj (qualixar.com | varunpratap.com)

Why SuperLocalMemory?

Agent-memory systems make different storage, model-provider, and deployment trade-offs. SuperLocalMemory starts with a local runtime and makes provider-backed enrichment, cloud backup, connectors, and proxy use explicit choices.

SuperLocalMemory V3 combines conventional dense and lexical retrieval with graph, temporal, associative, and Fisher-informed scoring. The default local runtime does not require Docker, a separately operated graph database, or an API key.

Published benchmark evidence carried into V3.7: the architecture evaluated in the V3 paper remains the foundation of this release. The figures below keep their original LoCoMo protocol, answer-construction, model, and sample scope; they are not a claim of a newly rerun 3.7 package benchmark.

How SLM fits beside other memory systems

Different products solve different boundaries. SLM is for developers who want one local-first operating control plane—not only an SDK, managed context API, or agent runtime. It combines dated evidence, graph-aware retrieval, cache and compression controls, trusted-peer Mesh, and MCP/CLI/hooks/dashboard/IDE surfaces in one install.

See the source-linked market comparison for current primary sources and protocol-scoped benchmark evidence. A LoCoMo percentage is comparable only when the dataset scope, answer model, judge, retrieval stack, and release artifact match.

The V3.7 capability architecture

SuperLocalMemory is one local control plane for persistent agent context. It is not just a vector store: the same runtime can accept evidence, build and govern memory, retrieve bounded evidence for an agent, and expose cache, compression, and peer-coordination controls through a CLI, MCP, dashboard, and supported IDE integrations.

Architecture boundary: SQLite + sqlite-vec remain canonical; CozoDB and LanceDB are parity-gated projections; Mesh coordinates trusted peers rather than replicating a distributed memory database; connectors are opt-in.

Memory boundaries: profiles isolate workspaces by default. Every memory is personal, shared with named profile readers, or global; cross-profile recall is default-deny and must be explicitly enabled. This scoped sharing is local authorization, not SLM Mesh synchronization. See shared-memory.md.

 IDEs, agents, scripts, connectors, and humans
             │  CLI · MCP (HTTP/stdio) · hooks · dashboard
             ▼
 ┌────────────────────────── SLM CONTROL PLANE ──────────────────────────┐
 │  1. Admission       identity, scope, idempotency, raw evidence         │
 │  2. Queryable core  SQLite facts + FTS durable receipt                  │
 │  3. Enrichment      facts, entities, scenes, time, provenance, graph   │
 │  4. Memory brain    feedback, patterns, rewards, consolidation          │
 │  5. Retrieval       semantic · BM25 · temporal · Hopfield · activation │
 │  6. Context safety  policy, trust, provenance, redaction, budgets      │
 │  7. Operations      lifecycle, audit, cache/compress, mesh, backups    │
 └───────────────────────────────────────────────────────────────────────┘
             │
             ▼
 SQLite + sqlite-vec canonical store  ──► optional graph/vector projections

The seven stages are an execution model, not a promise that every optional enricher or retrieval channel runs for every request. The receipt, trace, and health surfaces expose the stages actually completed by the installed runtime.