# LongMemory

> Durable, temporal, governed memory for AI agents — local-first

- Category: Agents & Automation / Agent Memory
- Language: TypeScript
- Licence: Apache-2.0
- Repository: https://github.com/CaviraOSS/LongMemory
- Website: https://openmemory.cavira.app
- Canonical page: https://ai-tldr.dev/tools/longmemory/

## In short

LongMemory is a memory engine for LLM applications and autonomous agents. It sits in the Agent Memory category of the Agents & Automation tools and is open-source, written in TypeScript and licensed Apache-2.0. To get started: install as a library.

## Overview

LongMemory is a memory engine for LLM applications and autonomous agents. The pitch in its own README is that it is neither plain RAG nor a bare vector database: content is stored immutably with provenance and a temporal history, so the store can answer not just "what do I know" but "what was true when", and it can show the evidence it used to answer.

Everything runs local-first. The default store is SQLite on your own disk, and reopening the same database restores nodes, worlds, entities, edges, temporal history, grounding and lifecycle state. Recall is token-bounded and comes in several modes — strict, historical, associative, grounded and multilingual — so the caller decides how much context to spend and how literal the match must be.

One TypeScript engine is exposed through every surface a team is likely to want: an npm library, a global CLI, an HTTP service, an MCP server for agent hosts such as Claude Desktop, GitHub Copilot and Codex, a dashboard, and a VS Code extension. A zero-dependency Python SDK talks to the self-hosted service over HTTP. The project is Apache-2.0 licensed.

## What it does

- Durable local-first storage on SQLite, with immutable content, provenance and temporal truth rather than overwritten facts
- Five recall modes — strict, historical, associative, grounded and multilingual — with explainable evidence selection and token-bounded context
- One TypeScript engine across npm, a CLI, HTTP, MCP, a dashboard and a VS Code extension
- Governed project memory plus Skills, Chat Memory, LLM-Wiki and CodeGraph layers
- Zero-dependency Python SDK that calls the self-hosted service, keeping the engine in one place
- Optional answer_from_evidence adapter that validates cited excerpts and makes at most one model call, leaving ordinary recall untouched

## Getting started

The in-memory path needs no service and no external database, so you can ingest and recall inside a single Node process before deciding how to deploy.

1. Install as a library

```bash
npm install longmemory
```

2. Ingest and recall

   createMemory returns an engine; ingest writes a fact for a user, recall queries it with a mode.

```typescript
import { createMemory } from 'longmemory';

const memory = await createMemory();
await memory.ingest({
    user_id: 'alice',
    text: 'I prefer TypeScript for backend services',
});

const result = await memory.recall({
    text: 'What language does Alice prefer?',
    mode: 'strict',
});

console.log(result);
await memory.close();
```

3. Persist to SQLite

   Point the store at a file and the graph survives restarts, scoped by tenant and user.

```typescript
const memory = await createMemory({
    store: 'sqlite',
    db_path: './longmemory.db',
    tenant_id: 'acme',
    user_id: 'alice',
});
```

4. Use the CLI

   The same engine is available globally for shell use and scripting.

```bash
npm install --global longmemory
longmemory init
longmemory recall "current project priorities" --mode associative
```

5. Call a self-hosted server from Python

   The Python package is a thin HTTP client; the engine stays in the self-hosted TypeScript service.

```bash
pip install longmemory-sdk
```

## When to use it

- Give a chat assistant memory that survives sessions without pushing user data to a hosted memory service
- Answer questions that depend on when something was true, using historical recall over an immutable, provenance-tagged store
- Share one memory store across Claude Desktop, Copilot and Codex by pointing each at the same MCP server
- Keep a project's governed memory — decisions, skills, code graph — beside the repo instead of in a vendor account