Release History

Changelog

Release notes for the SuperLocalMemory 4.x line, newest first. The latest entry is the launch release. Each entry says what you get, with the real numbers, and what stays on your computer.

4.2.0 Current release CURRENT
01

Recall that says “That isn’t in SuperLocalMemory”

Every recall now comes back in one of three tiers, and a recall that runs before SLM is ready says so.

  • Three tiers. Supported; the closest memories (up to three, labelled “I don’t have this exactly — here are the closest memories”); or “That isn’t in SuperLocalMemory.” for nonsense. Over MCP and REST an agent gets the closest memories when it asks with include_related.
  • Warming up, said plainly. For a few minutes after a start, recall shows the keyword finds it has under “SuperLocalMemory is still warming up — results may be incomplete” and never says the memory is empty.
  • Layered recall. depth 0 (ids, tier and a one-line preview), 1 (the facts, the default) and 2 (adds the source, session neighbours, related entities and the replacing correction), a hard max_tokens cap, and an expand tool. slm recall --depth 2 --max-tokens 1500.
  • The on-device answer check, Laya, is installed by default where it can run. On Apple Silicon, setup installs it (about 1.1 GB). It works in every mode. Opt out with slm setup --no-laya or SLM_SKIP_LAYA=1. The online option, Jev, stays off until you choose it and tick its consent.
  • Recall stays fast while you write, entity matching is exact, and every extracted statement is checked against its source before it is stored.
  • The learning loop learns from real outcomes. slm outcome success|partial|failure <fact_id> tells SLM whether a recall helped.
  • Upgrade memory engine (preview, opt-in): slm embedder upgrade or the Settings card re-reads memories with the one-model engine in the background, with one-click rollback.
02

Memory that looks after itself

A Memory health card and background worker improve older memories without touching what you wrote.

  • Add-only. While the computer is idle, event dates, names, tags, a project and a kind are filled in on older memories. The text you saved is never edited and a value you set is never replaced.
  • Fix and Undo. Anything that deletes or moves something waits for your explicit Fix, and every run that changed something has an Undo. Stubs (session receipts and similar) carry a stub badge but never become answers.
  • slm enrich (status, pause, resume, undo, fix) and slm doctor report the same state, including a Failed saves row.
03

Pictures and documents

Save screenshots, photos and PDFs and find them by describing them.

  • Google’s EmbeddingGemma 2 runs on your computer; OCR reads the text inside pictures; each PDF page is indexed by its picture and its text; no generative model looks at your files. Off by default: slm media enable, the dashboard, or the npm installer. Needs 16 GB of memory and downloads about 1.5 GB.
  • slm sources add mirrors folders and Obsidian vaults read-only. Recall finds pictures and pages beside text memories. Erasing a memory erases its picture.
  • A Documents & Images pane in the dashboard, with progress, a drop zone, Find a picture and connected folders.
04

Privacy, erasure, access control, backup

Governance gaps closed across the stores SLM keeps.

  • Erasing a person leaves no readable copy. The bytes of the data folder are checked after an erasure: queued saves, the request journal, caches, reversible compression originals, side-database free pages, the vector index itself, an erased picture’s backup mirror and two prompt logs. slm gdpr erase --json reports success: false for an incomplete erasure, and a backup keeps its erasure obligation until it is deleted or found clean.
  • Export works on a real store: plain JSON, embeddings left out unless you ask, and an export_manifest listing what it omits.
  • Company mode checks a role on every change and every data route; slm team keeps the owner from being locked out; skill approvals are scoped to the workspace; a connected web app cannot see or change what it may not read.
  • A restore is all or nothing, with a safety copy, and backups include picture and PDF originals.
05

Bots that talk to each other, and a reliable install

Web apps join SLM-Mesh and save real files.

  • SLM-Mesh for web bots. ChatGPT, Claude on the web, Grok Bot, Muse and Composio can see peers, message a named bot, wait for a reply and read shared state. Each app needs two yeses: a box on the approval page and a switch in Connected apps. Messages arrive labelled as data.
  • Web apps save real files through a one-time upload link that expires in 10 minutes.
  • Editor and framework setup writes each host’s current schema; npm install says plainly when the Python it found cannot work; Windows reads and writes SLM’s own files as UTF-8; every plugin teaches this release, with a new slm-media skill.

Upgrading never moves or deletes memory, and an update that changes the store takes a restore point first. Full notes: CHANGELOG.md on GitHub.

4.1.24 Release notes
01

Connecting ChatGPT, Grok Bot, Muse and dots works the first time

One setup prompt and step-by-step guides for each web app.

  • One setup prompt for bots and web apps. The connection gives an app the tools, not the judgment to use them. Paste the setup prompt into a chat once the app is connected: it asks the app to keep the SuperLocalMemory skill, then tests saving and recall, showing the raw tool output at each step.
  • Step-by-step guides for ChatGPT, ChatGPT dots, Grok Bot, Composio and Muse, with what to do when something goes wrong.
  • Web apps were offered reading only. The server now advertises reading, saving and session tools; saving and session tools stay unticked on the approval page until you tick them. A ChatGPT plugin created read-only stays read-only: remove it and create it again.
  • A repeat visit to a finished approval page now says the sign-in already finished, and a re-connected app’s older approval is marked “Replaced by a newer approval”; nothing is removed for you.
4.1.23 Release notes
01

Your web apps and bots use the same memory, and it stays on your computer

ChatGPT, Claude on the web, Claude Code on the web, Muse and Composio can now use the memory on your computer, with no port to open and no tunnel to set up.

  • Web access. Turn it on from the new Connected apps page, sign in with GitHub, and choose per app whether it may only read, also save, and use session tools. Each connection has a free daily allowance of tool calls.
  • The memory database never leaves your computer, and SLM works fully without Web access. Your computer keeps one outbound link to SLM's connection gateway.
  • Connected apps lists every app that can reach your memory and removes any of them with immediate effect. Your memory and local configuration are kept.
  • Copy-paste instructions for web agents (a full block, a short block and an Agent Skill folder) tell a connected app when to recall, when to say it has no answer, and what to save. The dashboard copies the short block for you.
  • The new slm-web-access skill ships in every editor plugin, so a local agent can help you set up Web access and diagnose a connection.
  • slm db repair brings the two vector indexes back in line with your memories. It rewrites sqlite-vec rows that no longer match their memory's embedding and removes LanceDB rows for memories that are gone, withheld or soft-deleted. slm db integrity reports both counts.
  • If you run 4.1.22, upgrade. That release could corrupt memory.db or lose saves because the start-up cache read dropped SQLite's locks inside the daemon. 4.1.23 runs that read in a child process.
# Upgraded from 4.1.22 and `slm doctor` reports a malformed database? $ slm db restore-points $ slm db restore <id> # newest restore point $ slm db integrity
4.1.22 Release notes
01

Faster recall from the first second, memories that stay findable, deletes you can trust

Recall is about 2.6 times faster with the same answers, and erasing a memory now removes its words everywhere.

  • Recall about 2.6 times faster. On a copy of a real store, typical recall went from 849 ms to 321 ms. Every speed change returns the same top ten memories as before on all 184 test questions.
  • Fast from the first second after a start, and while you save. The store is read into memory once at start, and background work yields to a running recall.
  • Every recall says whether its answer was checked: supported, unsupported or unjudged, and why.
  • Filter by exact tags on recall, search, list and the CLI. An empty result tells you why it is empty.
  • Switch the embedding model without losing recall. slm embedder re-indexes in the background, keeps the previous vectors and can roll back.
  • slm db integrity and slm db repair show store health in five parts and fix leftover rows, with receipts and undo. A repair never brings back anything you erased.
  • Erasing a memory removes its words everywhere: keyword index, journal, event previews, entity summaries, logs and vectors kept for a model switch.
4.1.21 Release notes
01

Recall that knows your project, and memories that stay findable

Recall now ranks the project you are working in first, and the same question returns the same memories every time.

  • Recall knows your project. Memories saved for your current project rank ahead of cross-project trivia, and a filter that matched nothing says so.
  • Saved views and summaries. Save a recall query as a named view and re-run it from the CLI (slm view), MCP or the dashboard. Daily, session and project summaries trace every line back to its memories.
  • slm provider set custom points Mode B or Mode C at your own OpenAI-compatible server (llama.cpp, vLLM, LM Studio), with or without a key.
  • Better first answers. On a large real store the right memory came first on 27 of 50 questions (was 23), and in the top 3 on 17 of 97 held-out questions (was 11).
  • Background maintenance no longer archives memories you still use. Questions about them stop coming back wrong or empty.
  • Measure answer quality on your own memories: label your questions and set each answer check's threshold from your own results.
4.1.20 Release notes
01

Answers you can check, from any computer

A dashboard tab shows how the answer check is doing, and a second computer can read your memory over an encrypted link.

  • Answer Check tab in the dashboard: which check is running, a Try it box that shows raw results next to the verdict, how often SLM said "I don't have that", and time against the 3-second limit.
  • Use SLM from another computer with slm remote: an encrypted listener that is off by default, a certificate helper, and named keys you can revoke. Each key is read-only or read-write and bound to one profile.
  • The same question gets the same answer. Learned ranking no longer reshuffles results between runs, and the answer check gives the same verdict on a repeat.
  • Recall right after a save finds it. On a fresh install, recall answers within 3 seconds while the embedding model is still loading.
  • Saves under heavy load are accepted and saved, never refused. Upgrades are faster because only the databases that change are copied.
  • Hermes can use an SLM on another computer, and a save that did not land says NOT SAVED.
# Return your data to 4.1.19 if needed; prints the exact install command $ slm db prepare-downgrade
4.1.19 Release notes
01

Memories know what kind they are

Nine memory kinds let recall answer "what did we decide" with decisions, and your standing rules reach every new agent session.

  • Nine memory kinds: fact, event, current status, opinion, standing rule, decision, how-to, plan and correction. Say which when saving (--kind), or SLM suggests one that changes nothing until someone confirms it.
  • Standing rules at session start. Confirmed rules and decisions go to every new agent session, up to ten rules and five decisions.
  • Ask for a kind of memory. Recall, search and list take a kind filter, and you can narrow by project, by the agent that saved a memory, or by who it is about.
  • Say which memory a new one replaces with --replaces. The old memory is kept, never deleted, and undoing it brings it back exactly.
  • Restore points before any upgrade that changes the store: a verified copy you can go back to (slm db restore-points | restore | prepare-downgrade).
  • Encrypted cloud backups to GitHub or Google Drive, encrypted on your machine before upload, with a recovery key (slm backup recovery-key).

Full notes for every release are in the GitHub CHANGELOG →

V4.0 Product generation
01

Release integrity and operator clarity

V4.0 is the SuperLocalMemory 4 product generation. It aligns the local runtime, Python and npm packages, supported client surfaces, dashboard identity, and operational status around one governed memory system.

  • Records the public SuperLocalMemory 4.0 arXiv preprint: arXiv:2608.08253, with companion Zenodo DOI 10.5281/zenodo.21853302.
  • Records the dashboard identity, operational status, package metadata, and dependency-audit maintenance required for a stable release line.
  • Keeps the SuperLocalMemory 4.0 research preprint correctly identified as a preprint, not a venue-reviewed publication.

Read the current GitHub release →

V4 foundation 2026-07-22 FEATURE FOUNDATION
01

Bounded loops

Agent iteration that terminates when an independent gate passes — not when the agent self-reports done. This is an AI Reliability Engineering primitive: the convergence condition is external, auditable, and queryable. Budget bounds (iteration cap, token budget, wall-clock limit) are enforced by the engine; the agent's self-report is recorded in the per-lap ledger and never consulted when deciding whether to stop.

Every lap writes a durable ledger entry to your SLM data root. All loop run history appears in the dashboard Multi-agent memory page. When the gate is an SLM recall query, a bounded loop becomes a safe multi-agent coordination primitive: one agent waits, under strict bounds, for evidence another agent has written into shared memory.

# Run a gate-verified loop via CLI $ slm loop run my-loop --gate "tests passing confirmed" --max-laps 5
# Via MCP (any agent with MCP access) slm_loop_run { "loop_name": "my-loop", "gate_query": "tests passing confirmed", "max_laps": 5 }
  • Three surfaces: slm loop CLI · /slm-loop Claude Code command · MCP tools (slm_loop_run, slm_loop_history, slm_loop_show)
  • Per-lap ledger entries persist to your SLM data root — same path as all other memories
  • Loop history visible in the dashboard Multi-agent memory page without additional configuration

02

Nine framework adapters

Nine framework-specific adapters wire the framework's native memory interface to your local SLM data root. Each adapter is a thin binding — no new storage layer, no separate service. Memories written through any adapter appear in the dashboard, CLI recall, and MCP tools.

Framework Package What it wires
LangGraphlanggraph-superlocalmemoryBaseStore long-term memory
Semantic Kernelsemantic-kernel-superlocalmemoryVectorStore / RecordStore
Microsoft Agent Frameworkagent-framework-superlocalmemoryMemory + conversation history providers
LangChainlangchain-superlocalmemoryBaseChatMessageHistory + retriever
LlamaIndexllamaindex-superlocalmemoryChat store
CrewAIcrewai-superlocalmemoryExternalMemory storage backend
AutoGenautogen-superlocalmemoryMemory provider
Google ADKgoogle-adk-superlocalmemoryMemory provider
OpenAI Agentsopenai-agents-superlocalmemoryMemory provider
# Install the adapter for your framework $ pip install langgraph-superlocalmemory $ pip install crewai-superlocalmemory $ pip install openai-agents-superlocalmemory
  • Each adapter stores data in your local SLM data root
  • Optional SLM providers, backup, and connectors have separate, opt-in network behavior — adapters themselves make no outbound connections
  • Memories written through any adapter are visible via CLI recall, MCP tools, and the dashboard

03

Multi-agent memory dashboard

The dashboard gains a dedicated Multi-agent memory page. This is the operational layer for AI Reliability Engineering at the team level: trace which agent produced which memory, see whether loops converged or were stopped by a bound, and inspect the per-lap ledger without touching the CLI.

  • Per-agent attribution — which agent wrote each memory, retrievable by agent ID
  • Loop run history — all recorded bounded-loop runs, organized by loop name, with per-lap verdicts and terminal outcome
  • Agent registry — registered agents and their trust signals
  • Available without configuration at http://localhost:8765 (or your SLM daemon address) after upgrading to V4

04

Team workspaces with role-based access

A workspace (profile) now supports multiple users with explicit roles: admin, member, or viewer. Single-user setups are unchanged and require no login.

  • Admin: manage users and settings · Member: read and write · Viewer: read only
  • Team and access panel in the dashboard — add users, set roles, or remove members without config files
  • Enable "require sign-in" (company mode) and every action is attributed to a specific person
  • Tenant isolation: coordination between agents (peers, messages, shared state, file locks, activity log) is scoped per workspace
  • Optional PII redaction on save — strips email addresses, phone numbers, national IDs, payment card numbers, and IP addresses before storage
  • GDPR export and erasure built in

Also included in the V4 feature release

  • Skill-evolution now produces output — token-limit bug fixed
  • Dashboard landing page loads immediately on first open
  • Critical cross-profile recall leak fixed — profile switch isolation enforced
  • Daemon-aware profile switching with atomic rebind
  • LanceDB vector backend follows the configured embedding dimension
  • Loopback auth opt-in via SLM_REQUIRE_API_KEY_LOOPBACK
★ Star on GitHub