Memory that infers, updates and forgets.
The engine, in one page.

What a memory is

Documents are what you send. Memories are what supermemory keeps.

One input becomes many memories. Each is atomic, carries enough context to stand alone, and is linked to what the graph already knew about that person, that project, that tenant. You define no schema and draw no edges.

Infers, updates, forgets

A living graph of facts on top of facts, not a folder of embeddings and not triples you maintain by hand. New content connects to old through three relationships, and the graph keeps working after the write.

Updates. When information changes.

A new fact replaces what was true before for retrieval, and the history stays for audit. “Alex just started at Stripe as a PM” supersedes “Alex works at Google”; searches land on the current fact without the past being erased.

Extends. When information enriches.

A new fact adds detail without invalidating the old one. “Alex focuses on payments and leads a team of five” sits alongside the role; both stay valid and the context gets richer.

Derives. When information infers.

Supermemory infers facts you never stated in one place, from patterns across memories: a PM at Stripe who keeps discussing payment APIs and fraud detection likely works on core payments. Low-confidence inferences can be reviewed, approved or declined.

Forgets. When information expires.

Facts carry time. “I have an exam tomorrow” is gone after the exam; “meeting with Alex at 3pm today” is gone after today; a superseded fact steps aside for the one that replaced it. And an agentic forget call removes everything matching a prompt when a user, a project or a policy asks for it.

Memories are typed on the way in, and the type sets how long they last.

Ingest is not a snapshot. After indexing, dreaming keeps building the graph: extracting facts, linking related memories, resolving updates and producing derivations, on coherent units of context rather than isolated writes. Ask for it instantly when the next call must see the new fact.

Underneath is an engine built for this, not a vector database with a schema on top: temporal metadata, ontology-aware relations and the raw chunks live in one place, and edges mean something more than a similarity score.

Profiles

A standing picture of each user, task or tenant, maintained for you and attached to every turn without a search.

Search is built for questions that resemble their answers. It is a poor fit for facts that should be known regardless of the question: the user's name, their timezone, that they want bullet points, their plan. A profile holds those as static facts, plus live ones that shift as they interact, and it is one call instead of three to five searches, in tens of milliseconds instead of hundreds. Buckets let you shape what a profile tracks for your product.

Recall

Search and traversal in one call.

Hybrid semantic search over memories, document chunks, or both, with the graph edges around each hit, filters and re-ranking. Sub-300ms at the p50, built for agent loops.

SuperRAG for the documents themselves.

Multimodal extraction, contextual chunking and retrieval for PDFs, images, audio, video and code. No embeddings or vector store of your own to run.

A filesystem the agent already knows.

SMFS mounts a container as a real directory. Agents ls, cat and grep it, grep is semantic by default, and a virtual profile.md at the root is a live digest of everything inside. For sandboxes and the edge, the same idea ships as a single bash tool.

What feeds it

Text, markdown and HTML. PDFs, images, audio, video and code. Conversation transcripts. URLs. And connectors that keep syncing on their own.

• Google Drive
• Gmail
• Notion
• OneDrive
• GitHub
• Granola
• Amazon S3
• Web crawler

A connector is one OAuth click per source. The first sync imports everything; after that, webhooks carry each change within seconds, a scheduled sync every four hours catches anything a webhook missed, and only changed content is processed again.

Extractors turn PDFs, web pages, images, audio and raw files into memory objects, with chunking that follows meaning across document boundaries rather than character counts. One provider instead of ten.

Everything lands in a containerTag, the hard isolation boundary for a user, a tenant or a project, with metadata for filtering inside it and API keys that can be scoped so a credential cannot cross a container.

Where it runs

Build on the API, or use it yourself through the tools you already have.

import Supermemory from "supermemory";

const client = new Supermemory({ apiKey: process.env.SUPERMEMORY_API_KEY });

// anything: a chat turn, a PDF, a URL, a Drive file
await client.add({
  content: "Alex mentioned he just started at Stripe as a PM",
  containerTag: "user_123",
});

// one call: hybrid search plus the graph around each hit
const results = await client.search({
  q: "where does Alex work?",
  containerTag: "user_123",
  include: { relatedMemories: true },
});

// the standing facts about this user, no query needed
const profile = await client.profile({ containerTag: "user_123" });

SDKs

TypeScriptPythonVercel AI SDKOpenAI SDKOpenAI Agents SDKREST

Plugins for coding agents and assistants

Claude CodeCursorCodexOpenCodeOpenClawHermes

Let the agent wire it up

npx supermemory setup detects the project and prints the integration flow, and a skill teaches a coding agent the real API surface, so it ships the right endpoints instead of invented ones.

MCP, for everything else

One remote server at mcp.supermemory.ai/mcp, OAuth instead of keys, shared spaces for a team. Works in ChatGPT, Claude, any MCP client.

For yourself

The personal supermemory: one memory across every AI you use, so what you teach one, the others remember.

Where it lives

Hosted anywhere, even locally. The same engine and the same API in all three.

Our cloud.

Globally distributed, scaling with your ingestion and query load, running supermemory's own models tuned for long-horizon understanding. Organizations, roles, scoped keys, and a console with usage, ingestion and request logs.

Your cloud, or a dedicated instance.

For committed spend and compliance needs: in your AWS, GCP or Azure account, on bare metal or your own Kubernetes, or on dedicated infrastructure we run for you, air-gapped where required. SOC 2, HIPAA and GDPR, custom contracts and a DPA.

Your machine.

Supermemory local is one open-source binary with the graph engine embedded, local embeddings and an API key printed on first boot. No Docker, no database, no config. Point it at Ollama or any OpenAI-compatible endpoint and nothing leaves the building.

curl -fsSL https://supermemory.ai/install | bash

# or, fully offline, against a model of your own
OPENAI_BASE_URL=http://localhost:11434/v1 \
OPENAI_API_KEY=ollama \
OPENAI_MODEL=gpt-oss:20b \
supermemory-server

Code written against the local server moves to the cloud by changing baseURL, and back again. Prototype on a laptop, ship on the platform.