mirror of
https://github.com/supermemoryai/supermemory.git
synced 2026-07-30 11:24:08 +00:00
48167c3246
71 '<!-- CONFIRM -->' review markers across 19 files used HTML comment
syntax, which MDX cannot parse. One parse error breaks the whole
production build — this is why the deployed site 404'd on every page
while local dev limped along. All converted to {/* */} (code-fence
contents untouched). Also: remove the legacy source-'/' redirect,
replace the phantom architecture-diagram image with an ASCII diagram
until the real one lands.
Verified locally: mintlify broken-links parses all pages clean (one
known-good /api-reference tab link that 307s at runtime), and /,
/overview, /concepts/architecture, /quickstart, /patterns/*,
/versioning all render 200 with content.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
100 lines
3.8 KiB
Text
100 lines
3.8 KiB
Text
---
|
|
title: "supermemory docs"
|
|
sidebarTitle: "Overview"
|
|
description: "The context engine for AI apps — memories, a knowledge graph, and live profiles from everything you feed it."
|
|
mode: "center"
|
|
icon: "book-open"
|
|
---
|
|
|
|
Supermemory is a context engine. You feed it everything — chat sessions, files, URLs, connector data — and it derives memories, a knowledge graph, and live profiles. When your app needs context, supermemory serves the right slice back in ~300ms. {/* CONFIRM: publishable latency figure */}
|
|
|
|
The whole loop is two calls:
|
|
|
|
<CodeGroup>
|
|
|
|
```typescript TypeScript
|
|
await client.add({
|
|
content: "Sarah's being promoted to VP of Product",
|
|
containerTag: "user_4f8a",
|
|
});
|
|
|
|
const results = await client.search.memories({
|
|
q: "who's getting promoted?",
|
|
containerTag: "user_4f8a",
|
|
});
|
|
```
|
|
|
|
```python Python
|
|
client.add(
|
|
content="Sarah's being promoted to VP of Product",
|
|
container_tag="user_4f8a",
|
|
)
|
|
|
|
results = client.search.memories(
|
|
q="who's getting promoted?",
|
|
container_tag="user_4f8a",
|
|
)
|
|
```
|
|
|
|
</CodeGroup>
|
|
|
|
## Start here
|
|
|
|
<Columns cols={2}>
|
|
<Card title="Quickstart" icon="bolt" href="/quickstart">
|
|
Add four scattered memories, then watch supermemory connect them into an answer you never stated.
|
|
</Card>
|
|
<Card title="How it works" icon="brain" href="/concepts/architecture">
|
|
The custom memory model, the graph, and where the milliseconds go.
|
|
</Card>
|
|
</Columns>
|
|
|
|
## Pick your door
|
|
|
|
Every surface below is a door into the same engine — one store of memories, one graph, one set of profiles. Anything that goes in through one door comes out through all of them.
|
|
|
|
<Columns cols={3}>
|
|
<Card title="API & SDKs" icon="code" href="/concepts/surfaces">
|
|
Full control from your own backend. TypeScript, Python, REST.
|
|
</Card>
|
|
<Card title="MCP" icon="terminal" href="/supermemory-mcp/mcp">
|
|
Give Claude, Cursor, and ChatGPT your memory. No code.
|
|
</Card>
|
|
<Card title="Plugins" icon="puzzle" href="/integrations/claude-code">
|
|
Auto-inject memory into Claude Code, Codex, and OpenClaw.
|
|
</Card>
|
|
<Card title="Connectors" icon="plug" href="/connectors/overview">
|
|
Notion, Google Drive, Gmail, OneDrive, S3 — content flows in on its own.
|
|
</Card>
|
|
<Card title="SMFS" icon="database" href="/smfs/overview">
|
|
Mount memory as a filesystem for agents that think in files.
|
|
</Card>
|
|
<Card title="Self-hosting" icon="server" href="/self-hosting/overview">
|
|
From a free local binary to air-gapped enterprise deploys.
|
|
</Card>
|
|
</Columns>
|
|
|
|
## Go deep
|
|
|
|
<Columns cols={2}>
|
|
<Card title="Build on supermemory" icon="blocks" href="/patterns/overview">
|
|
Multi-tenant SaaS memory, AI companions, multi-agent systems, company brains — full patterns with code.
|
|
</Card>
|
|
<Card title="API Reference" icon="book-open" href="/api-reference">
|
|
Every endpoint, parameter, and response shape.
|
|
</Card>
|
|
<Card title="Permissioning & multi-tenancy" icon="lock" href="/concepts/permissioning">
|
|
Container tags, metadata, scoped keys — real isolation, designed in.
|
|
</Card>
|
|
<Card title="Memory vs RAG" icon="scale" href="/concepts/memory-vs-rag">
|
|
Why retrieval alone recommends Adidas to someone who switched to Puma two weeks ago.
|
|
</Card>
|
|
</Columns>
|
|
|
|
## Why supermemory
|
|
|
|
Most "memory layers" are a vector store that retrieves the nearest chunk. Supermemory understands what it stores: facts carry time, entities connect across sessions, contradictions resolve to what's true *now*, and irrelevant details fade.
|
|
|
|
- **State of the art** on LongMemEval and LoCoMo — and [MemoryBench](/memorybench/overview) lets you reproduce the numbers yourself. {/* CONFIRM: exact benchmark figures + ConvoMem */}
|
|
- **Fast enough for the hot path**: profile reads ~100ms, search P50 ~300ms. {/* CONFIRM: publishable latency figures */}
|
|
- **Yours to run**: the same engine powers the cloud API, a free local binary, and on-prem enterprise deploys.
|