LeapMemory

Permanent memory for Grok Bot, Claude, Cursor and any MCP client. Your own physically isolated store. Memories never expire.

Hosted MCP Server

npx add-mcp 'https://api.leapmemory.com/mcp'

Installs into Claude Code, Codex, Cursor and more

Documentation

Open app

Permanent memory for AI assistants and applications. Save what was said, recall it years later, in the exact words.

What is LeapMemory

A memory layer that sits between your application and its language model.

Language models forget. Context windows evict, summaries blur details, and every new session starts from zero. LeapMemory gives an AI a permanent memory: you send it conversation turns as they happen, it distills them into structured memories, and it returns the relevant ones whenever asked, whether that is one minute or three years later.

It works two ways. Personally, you connect it to an AI assistant like Claude through an MCP connector, and your assistant remembers you across every chat. As a developer, you call two HTTP endpoints, and every user of your application gets their own permanent, isolated memory.


Core concepts

Three words carry the whole API.

Tenant

One isolated memory store

Typically one per end user. Its own databases, its own credentials, physically separate from every other tenant.

Turn

One thing that was said

A role, the verbatim content, and optionally who said it and when. The raw material every memory is made from.

Memory

What a turn becomes

The exact words, plus the extracted facts, entities, and relationships, stored permanently and ready to recall.


Shaped like human memory

One memory, stored the way a mind stores it.

Human memory is not one system. You remember what happened (episodic memory), what things mean and how they relate (semantic memory), and you recognize who is who the moment a name comes up (recognition). LeapMemory stores every conversation turn the same three ways, and recall uses all of them together. A turn sent with context_only, or a document uploaded without extract: true, is kept word for word and is searchable, but no facts are drawn from it.

episodic memory what happened, verbatim chunks the exact words, kept forever semantic memory what things mean and relate to facts + knowledge graph entities and their relationships recognition knowing who is who, instantly anchors entities spotted in every query

the same shape human memory has

This is why recall answers with three sections instead of a similarity list: a question like "where does Sam work?" is recognized (anchors_found spots Sam), answered from meaning (facts carry the relationship), and grounded in what was actually said (chunks hold the verbatim sentence). No single store could do all three.


How a memory forms

The words are stored instantly. The meaning forms in the background.

When a turn arrives, the verbatim content is written immediately; nothing waits and nothing is lost. Extraction then runs asynchronously, typically completing within seconds: entities are recognized, relationships are mapped into a knowledge graph, and the meaning is indexed for search. A context-only turn stops after the words are indexed: no entities or relationships are drawn from it.

your words stored instantly the words the relationships the meaning the recognition background a memory recall, any time forever

one turn in, one permanent memory out

Memories never expire. There is no time limit, no summarizing away, no context window doing quiet evictions.


Isolation

Every memory lives in its own physically separate databases.

Most memory systems keep everyone's data in one shared pool and separate customers with filters: a tenant_id column, a row-level policy, a WHERE clause that must never be forgotten. That works until it does not; one missed filter, one injection, one bug, and someone reads someone else's memory.

LeapMemory takes the structural route. Every tenant is provisioned its own databases, across every layer a memory touches: the verbatim words, the knowledge graph, the semantic index, and the working data each live in stores that belong to that tenant alone, created when the tenant is created and dropped when it is hard-deleted (DELETE with ?hard=true). A default delete is soft: it keeps the data so the tenant can be restored. No shared tables, no row-level policies, no tenant_id columns, no shared credentials. A query against one tenant cannot reach another, structurally: there is nothing to filter because there is nothing shared.

This is not a feature bolted onto LeapMemory; it is the platform it stands on. Tenant provisioning and isolation are enforced by TenantsDB, our database orchestration platform built for exactly one job: giving every customer their own physically separate databases. LeapMemory inherits that guarantee for every memory it stores.

elsewhere: one shared pool kept apart by filters here: separate rooms one person per database, walls not filters

isolation by architecture

This is also the deletion story: erasing a user means dropping their databases entirely, not scanning shared tables for rows and hoping nothing was missed. When a GDPR request or a compliance review asks how you erase a user, you have a structural answer, and one hard-delete call is the whole procedure.


What recall returns

Ask in natural language, in any language. Three things come back.

SectionWhat it is
factsDistilled subject-verb-object statements with confidence, mention count, a short plain-language sentence stating the fact, and the turn_ids of the turns it was drawn from (the newest five; turn_count gives the total). The words as actually said are in chunks.
chunksThe verbatim words as they were said, ranked by relevance score.
anchors_foundEntities detected in your query, with type and position, that steered retrieval.

Recall is free, always, for everyone. You pay when a memory is saved, never when it is used. It is also multilingual by structure: save and recall in any of the 19 languages we test. A question in one language can also find memories saved in another. Our ranking tests cover that case for questions in other languages against English memories.


When memories change

People correct themselves. The memory keeps up without rewriting history.

Restated

Said again, counted again

The same fact stated twice becomes one fact mentioned twice, not two facts.

Replaced

A new value takes over

Where only one value can hold at a time, such as where someone lives, "I live in Lisbon" and later "I live in Porto" closes Lisbon at the moment Porto was said.

Rejected

A correction closes what it rejects

"No, that's wrong, the clinic is in Porto" closes the clinic in Lisbon and stores Porto, whatever kind of fact it is.

A correction closes only the link it rejects. "Priya doesn't work at Halden anymore" closes that Priya works at Halden and keeps that she runs the Halden onboarding. "I have nothing to do with the bakery" closes every link between the person and the bakery. A rejection with no replacement closes the old fact and stores nothing new. The correction is read against the last few messages and the names the memory already knows, so it works the way people speak.

What arrivesCan it close a fact?
A turn with role exactly "user" and no sourceYes. These are the person's own words.
A note your assistant saves through the Claude connectorYes. It counts as the person's own words.
An assistant turnNo.
A document, or a turn sent with a sourceNo.
A turn with any other role, such as "human" or "customer"No.

The same rule decides who reopens a closed fact: only the person, by saying it again. A document or an assistant turn that repeats it leaves it closed.

Changes take effect as soon as the turn is indexed, usually within seconds. Order follows when things were said, not when they arrived, so an older statement sent late never overrides a newer one.

Nothing is deleted. A closed fact keeps its sentence and its history, with status: "superseded" and the date it stopped being current; a rejected one also records the sentence that rejected it. From that moment recall stops returning it. The briefing is rewritten in the background about once a day, so a change reaches it at that rewrite; its written_at shows when. Deleting is a separate act: removing a turn removes its words, its chunks, and every fact that came only from that turn.

Every fact also knows who put it there. The sources tally on each fact counts how many of its mentions came from the person and how many from the assistant, so an application can tell a memory the person stated from one the assistant produced, and present them differently.


Two ways in

Same engine, two doors.

Next steps