§6

Agent memory and context persistence

Agent memory tooling answers two questions a raw vector database does not: what is worth writing down from a conversation, and what small subset of that gets injected into the next prompt. Products in this category typically do some combination of fact extraction from message streams, conflict resolution when a stored fact goes stale, per-user/per-agent/per-session scoping, and a retrieval step that returns a bounded context block rather than a pile of chunks.

Data checked 2026-09-06

The designs split into three camps: extracted-fact stores over a vector index (Mem0, Memobase, Supermemory), temporal knowledge graphs that keep validity windows so old facts are invalidated rather than deleted (Zep/Graphiti, Cognee, MemMachine), and agent-managed memory where the model itself edits its own persistent context (Letta, Anthropic's memory tool). Underneath all of them sits a plainer layer — LangGraph checkpointers and stores, MongoDB, Redis, OpenAI Conversations — that persists state but extracts nothing. Choosing wrong here is expensive: extraction pipelines run LLM calls on every write, and their cost and latency profile is the thing teams discover late.

A How to choose

Start by deciding whether you need persistence or memory. If you only need a conversation to resume — same thread, same user, no cross-session synthesis — a checkpointer (LangGraph + Postgres/MongoDB/Redis) or OpenAI's Conversations API does it with zero extra LLM calls, and buying a memory product for this is pure overhead. Only reach for an extraction layer when you actually need facts to survive across threads and be retrieved without replaying transcripts.

Second axis: does your domain have facts that change and contradict each other? A user's job title, plan tier, or shipping address going stale is exactly what bi-temporal graphs (Graphiti/Zep, Cognee) are built for, and exactly where a flat "extract facts into a vector index" design quietly serves you a superseded fact forever; if your memories are mostly stable preferences, the graph's Neo4j/FalkorDB operational burden and slower ingest are not worth it. Third: write economics.

Almost every extraction product bills per ingested token or per "add" call and runs multiple LLM calls per message — Mem0's free tier is 10,000 adds/month, Zep's Flex starts at $125/month for 50,000 credits, Honcho charges ~$2.00/M ingested — so a chatty consumer app can cost more in memory writes than in generation. Model this before you commit, and consider ingesting only summaries or turn-batches rather than every message. Fourth: who owns the data.

Self-hosting is genuinely free and complete in Mem0, Cognee, Letta, Memobase, MemMachine and Honcho (note AGPL-3.0 on Honcho and Papr, which matters for closed-source products); with Zep it is not an option at all above Graphiti, and with Supermemory it is gated to the $399/month Scale tier. Two anti-defaults worth stating plainly. Do not default to Mem0 just because it has the most stars — if your product's core difficulty is contradiction and recency, you will rebuild temporal logic on top of it.

And do not adopt a hosted memory API for a coding or research agent that already has a filesystem: Anthropic's memory tool plus context editing gives the model a directory it curates itself, costs nothing beyond tokens, and is debuggable by reading files. Finally, prefer whatever gives you an eval harness — memory quality is not observable from unit tests, and every vendor's LOCOMO/LongMemEval numbers are self-reported.

B At a glance

Name	Memory model	Deployment	Storage backend	Interfaces / SDKs	Scoping unit	Pricing
Mem0	LLM-extracted facts + vector search (optional graph store)	Managed cloud, self-host (Apache-2.0), on-prem on Enterprise	Pluggable vector stores (Qdrant hosted option) + optional graph store	REST, Python, TypeScript, MCP	user_id / agent_id / run_id (session)	Free Hobby: 10,000 add + 1,000 retrieval requests/mo, 1 project. Starter $19/mo: 50,000 add + 5,000 retrieval. Pro $249/mo: 500,000 add + 50,000 retrieval, unlimited projects. Enterprise custom (on-prem, SSO, audit logs). Usage-based pricing available on request. Self-hosted OSS is free.
Zep	Bi-temporal knowledge graph with fact validity windows	Managed cloud, BYOK, BYOC (Enterprise) — no self-host	Zep-managed proprietary graph store	REST, Python, TypeScript, Go, MCP server	User graph / thread, plus graph-level (group) namespaces	Free: 10,000 credits/mo, 2 projects, 1 MCP seat. Flex $125/mo: 50,000 credits, $25 per additional 10,000, 600 req/min, 5 projects. Flex Plus $375/mo: 200,000 credits, $75 per additional 40,000, 1,000 req/min, adds Observations, webhooks, custom extraction. Enterprise custom with SOC 2 Type II and HIPAA BAA.
Graphiti	Bi-temporal knowledge graph, episode-sourced with provenance	Self-hosted Python library only	Neo4j 5.26+, FalkorDB 1.1.2+, Amazon Neptune, Kuzu (deprecated)	Python library, MCP server	group_id namespaces you define	Free (Apache-2.0). Costs are your graph database plus LLM and embedding API calls for ingestion.
Letta	Agent-edited memory blocks in-context + archival memory, sleep-time compute	Letta Cloud, self-hosted App Server, desktop/CLI	Postgres (self-hosted server); managed store on Cloud	REST, Python, TypeScript, CLI, chat channel integrations	Agent (each agent is the persistent unit); blocks shareable across agents	Free: limited agents, BYO API keys. Pro $20/mo: up to 20 stateful agents. API plan $20/mo base + $0.10 per active agent/mo + $0.00015/sec tool execution, unlimited agents. Teams Pro $20/seat/mo. Enterprise custom with SAML/OIDC. Self-hosted Apache-2.0 server is free.
Cognee	ECL pipeline into a knowledge graph + vector search; session distillation	Managed cloud, self-hosted (Apache-2.0), Enterprise BYOC	KuzuDB (default graph), Postgres relational, pluggable vector store	Python, REST, MCP server, Claude Code plugin	Dataset / workspace, with session-scoped memory	Free: $0/mo, 1M tokens included, 1 workspace, unlimited users and API calls. Standard: $2.50 per 1M tokens processed plus $5 per additional workspace. Enterprise: custom BYOC engagements (Startup, 6/12/24-month tiers) with bi-temporal memory, conflict resolution and provenance. Self-hosted OSS free.
Supermemory	Extracted memories + user profiles over hybrid search; document connectors	Managed cloud; self-host (MIT) supported on Scale/Enterprise, air-gapped option	Supermemory-managed store; local stack via npx supermemory local	REST, TypeScript, Python, MCP server, Vercel AI SDK / LangChain integrations	Per-user containers / spaces	Free $0/mo (~$5 usage included). Pro $19/mo (~$20 usage, 2 teammates). Max $100/mo (~$130 usage). Scale $399/mo (~$600 usage, up to 10 teammates, SOC 2, HIPAA BAA, self-host option). Enterprise custom/air-gapped. Metered: memory $0.005/1K SM tokens ($0.010 rich), SuperRAG $0.001/1K ($0.002 rich), search/traversal $0.005/1K queries, operations $0.10/1K.
Memobase	Structured topic-based user profiles + event timeline	Managed cloud, self-host via Docker (Apache-2.0)	PostgreSQL + Redis (FastAPI service)	REST, Python, TypeScript, Go	User, with blob/session grouping	unknown — Memobase Cloud advertises a free tier and paid plans, but no public pricing page with numbers was reachable at time of writing. Self-hosted Apache-2.0 is free apart from your LLM calls.
Honcho	Reasoned peer representations derived from message streams	Managed cloud (app.honcho.dev), self-host (AGPL-3.0)	PostgreSQL + pgvector	REST, Python, TypeScript, MCP	Workspace / peer / session (peer-to-peer representations)	Honcho Memory: ingestion (store + reasoning) $2.00/M; context() calls unlimited at no additional cost (~200ms); background 'dreaming' inference included. Honcho Reasoning per query: Minimal $0.001, Low $0.01, Medium $0.05, High $0.10, Max $0.50. Startups under $5M raised: $1,000 credits and 12 months subsidized. Enterprise custom.
Redis Agent Memory (Redis Iris)	Two-tier: session/working memory with TTL + async-extracted long-term facts	Managed (Redis Cloud / Iris); self-host the archived Apache-2.0 V0 server	Redis (vector search)	REST, client libraries, MCP server	session_id and user/namespace	unknown — Redis Iris lists a free trial and directs pricing to sales; no public per-unit pricing. The archived V0 open-source server is Apache-2.0 and free to run on your own Redis.
LangGraph Store	Namespaced key-value documents + optional embedding index (no extraction)	Self-hosted library or LangGraph Platform	Postgres, Redis, MongoDB, Oracle AI Database, in-memory	Python and JavaScript libraries	Namespace tuples (e.g. (user_id, "memories")); threads via checkpointer	Free (open-source packages). Cost is your database. LangGraph Platform deployments are billed separately by LangChain.
LangMem	LLM extraction into typed memories, plus background consolidation and prompt optimization	Self-hosted Python library (works in LangGraph Platform deployments)	Any LangGraph BaseStore (Postgres, Redis, MongoDB, in-memory)	Python library (agent tools + background manager)	Store namespace, typically per user or per agent	Free (MIT). You pay only for the LLM calls extraction and consolidation make.
MongoDB Store for LangGraph	Key-value store with vector index + TTL decay (no extraction)	MongoDB Atlas (managed) or self-managed MongoDB	MongoDB with Atlas Vector Search	Python (langgraph-store-mongodb ≥0.3.0, langgraph-checkpoint-mongodb ≥0.4.0); LangGraph.js separately	LangGraph namespace tuples; thread_id for checkpoints	The integration packages are free and open source; you pay Atlas cluster pricing (a free M0 tier exists) plus embedding costs if using the Automated Embedding Service.
Anthropic Memory Tool	Agent-curated files under /memories, just-in-time reads	Client-side — you host the storage; tool runs via the Claude API	Anything you implement: filesystem, database, object storage, encrypted files	Claude API tool; helpers in Python, TypeScript, Java, C# SDKs	Whatever directory your handler maps (e.g. per user or per project)	No separate charge — you pay only normal Claude API token usage for the tool calls and file contents read into context. Storage is your own infrastructure.
OpenAI Conversations API	Stored message history (no extraction or synthesis)	Managed by OpenAI only	OpenAI-hosted conversation objects	REST, Python, TypeScript (Responses API)	conversation_id (or previous_response_id chaining)	No separate storage line item published; you pay standard Responses API token pricing for whatever context is replayed into each request.
Mastra Memory	Message history + structured working memory + semantic recall + observational log	Self-hosted framework or Mastra Cloud	Pluggable storage adapters (e.g. @mastra/libsql, Postgres, others)	TypeScript/JavaScript framework	resourceId (user) and threadId	Free (Apache-2.0 core; some ee/ directories are source-available under the Mastra Enterprise License). Mastra Cloud is billed separately. You pay for your storage and LLM calls.
MemMachine	Three tiers: episodic graph memory, SQL profile memory, working memory	Self-hosted via Docker; managed cloud referenced	Neo4j (episodic) + SQL database (profiles)	REST, Python, TypeScript, MCP server	User / agent / session	Free (Apache-2.0). Costs are Neo4j and SQL infrastructure plus LLM calls for extraction.
Papr	Graph-aware memory + chat memory with automatic compression	Managed cloud, hybrid (AWS/Azure/GCP), self-hosted (AGPL-3.0)	unknown (managed store; knowledge graph + vector components)	REST API, SDKs, MCP	User / session	unknown — a free tier through enterprise plans is advertised, but no public pricing page with numbers was reachable at time of writing. Self-hosting under AGPL-3.0 is free.

C Entries

Mem0

Mem0 sits between your app and an LLM, running an extraction pass on each conversation turn to write durable facts, then retrieving a short set of them on read. The April 2026 algorithm does single-pass extraction with entity linking and combines semantic, BM25 keyword and entity matching at retrieval. Unlike a bare vector DB it handles add/update/delete of contradicting facts and multi-level scoping out of the box; unlike Zep it is a flat fact store by default rather than a temporal graph, though a graph store can be enabled.

Memory model	LLM-extracted facts + vector search (optional graph store)
Deployment	Managed cloud, self-host (Apache-2.0), on-prem on Enterprise
Storage backend	Pluggable vector stores (Qdrant hosted option) + optional graph store
Interfaces / SDKs	REST, Python, TypeScript, MCP
Scoping unit	user_id / agent_id / run_id (session)

Watch out: The default flat fact store has no notion of when a fact stopped being true — superseded facts are updated only if the extractor notices the contradiction, so recency bugs surface as the model confidently citing stale details. Retrieval quality depends heavily on the extraction LLM you configure, and the managed tier's add-request quotas are consumed per message, so a high-traffic chat app blows past the $19 tier quickly.

Free Hobby: 10,000 add + 1,000 retrieval requests/mo, 1 project. Starter $19/mo: 50,000 add + 5,000 retrieval. Pro $249/mo: 500,000 add + 50,000 retrieval, unlimited projects. Enterprise custom (on-prem, SSO, audit logs). Usage-based pricing available on request. Self-hosted OSS is free. · open source

Zep

Zep ingests messages and business data into a per-user Context Graph built on Graphiti, then returns a Context Block — a pre-assembled string of relevant facts — that you drop into the prompt. Facts carry validity windows, so when something changes the old edge is invalidated rather than overwritten, and you can query what was true at a past point. Compared with Mem0 you get temporal reasoning and custom entity/edge types; compared with running Graphiti yourself you get a managed graph store and no Neo4j to operate.

Memory model	Bi-temporal knowledge graph with fact validity windows
Deployment	Managed cloud, BYOK, BYOC (Enterprise) — no self-host
Storage backend	Zep-managed proprietary graph store
Interfaces / SDKs	REST, Python, TypeScript, Go, MCP server
Scoping unit	User graph / thread, plus graph-level (group) namespaces

Watch out: No self-hosting: cloud, BYOK, or BYOC on Enterprise only, so an air-gapped requirement rules it out. The credit model makes cost hard to forecast — extraction credits are consumed per ingested message and the entry paid tier is $125/mo, which is steep for a prototype. Custom entity and edge types are capped by plan (5 free, 10 on Flex), and the earlier open-source Zep Community Edition is no longer the supported self-host path; Graphiti is.

Free: 10,000 credits/mo, 2 projects, 1 MCP seat. Flex $125/mo: 50,000 credits, $25 per additional 10,000, 600 req/min, 5 projects. Flex Plus $375/mo: 200,000 credits, $75 per additional 40,000, 1,000 req/min, adds Observations, webhooks, custom extraction. Enterprise custom with SOC 2 Type II and HIPAA BAA.

Graphiti

Graphiti incrementally ingests episodes — chat turns, JSON, documents — and derives entities and relationships with explicit validity windows, so a changed fact invalidates the prior edge instead of deleting it, and every derived fact traces back to its source episode. You define custom entity and edge types with Pydantic models. It is the engine under Zep Cloud, offered as a library you run against your own Neo4j, FalkorDB, Neptune or Kuzu instance, which is the difference between owning the graph and renting it.

Memory model	Bi-temporal knowledge graph, episode-sourced with provenance
Deployment	Self-hosted Python library only
Storage backend	Neo4j 5.26+, FalkorDB 1.1.2+, Amazon Neptune, Kuzu (deprecated)
Interfaces / SDKs	Python library, MCP server
Scoping unit	group_id namespaces you define

Watch out: You operate a graph database and absorb the LLM cost of graph construction, which is materially slower and pricier per message than flat fact extraction — ingestion is the bottleneck, not retrieval. There is no built-in user/session management, auth or dashboard; Zep Cloud exists precisely because that layer is missing. Kuzu support is deprecated upstream, and Python 3.10+ with Neo4j 5.26+ is a real dependency floor.

Free (Apache-2.0). Costs are your graph database plus LLM and embedding API calls for ingestion. · open source

Letta

Letta (formerly MemGPT) is not a memory API you call — it is an agent server where the agent itself is the persistent object. Editable memory blocks live in the context window and the agent rewrites them with tools; older material moves to an archival store it searches on demand. Background 'sleep-time' processing reorganizes memory between turns. Choose it when you want the model to curate its own context rather than an external pipeline deciding what to extract.

Memory model	Agent-edited memory blocks in-context + archival memory, sleep-time compute
Deployment	Letta Cloud, self-hosted App Server, desktop/CLI
Storage backend	Postgres (self-hosted server); managed store on Cloud
Interfaces / SDKs	REST, Python, TypeScript, CLI, chat channel integrations
Scoping unit	Agent (each agent is the persistent unit); blocks shareable across agents

Watch out: You adopt Letta's whole agent runtime and its persistence model — it is not a memory layer you bolt onto an existing LangGraph or custom loop, which makes migration in and out costly. The project has recently reorganized around Letta Code (the main letta-ai/letta repo is now a landing page pointing at letta-ai/letta-code), so pinning to a stable API surface takes care. Agent-managed memory also means memory quality varies with model quality, and per-agent cloud pricing gets expensive at fleets of thousands.

Free: limited agents, BYO API keys. Pro $20/mo: up to 20 stateful agents. API plan $20/mo base + $0.10 per active agent/mo + $0.00015/sec tool execution, unlimited agents. Teams Pro $20/seat/mo. Enterprise custom with SAML/OIDC. Self-hosted Apache-2.0 server is free. · open source

Cognee

Cognee exposes four verbs — remember, recall, improve, forget — over an extract-cognify-load pipeline that turns text into entities and relationships and code into symbol graphs with dependencies. Session interactions can be distilled into permanent graph knowledge with improve. It is broader than a chat-memory layer: it ingests corpora and codebases as well as conversations, which makes it a fit when agent memory and document knowledge should live in one graph rather than two systems.

Memory model	ECL pipeline into a knowledge graph + vector search; session distillation
Deployment	Managed cloud, self-hosted (Apache-2.0), Enterprise BYOC
Storage backend	KuzuDB (default graph), Postgres relational, pluggable vector store
Interfaces / SDKs	Python, REST, MCP server, Claude Code plugin
Scoping unit	Dataset / workspace, with session-scoped memory

Watch out: Broad scope is the trade-off: it is a knowledge-graph platform with memory features rather than a tuned per-user conversational memory service, so per-user chat recall needs more assembly than Mem0 or Zep. Graph construction costs LLM tokens on every ingest and the $2.50/1M-tokens-processed meter maps directly to that. Some of the most memory-relevant features — bi-temporal memory, conflict resolution, provenance tracking — are listed under the Enterprise BYOC tier rather than the free plan.

Free: $0/mo, 1M tokens included, 1 workspace, unlimited users and API calls. Standard: $2.50 per 1M tokens processed plus $5 per additional workspace. Enterprise: custom BYOC engagements (Startup, 6/12/24-month tiers) with bi-temporal memory, conflict resolution and provenance. Self-hosted OSS free. · open source

Supermemory

Supermemory combines conversational memory extraction with ingestion connectors (Google Drive, Notion, OneDrive, Gmail, GitHub, S3, web crawler) so an agent's memory and a user's documents land in one hybrid search index. The whole stack — extraction engine, profile system, search, MCP server, plugins for Claude Code and other harnesses — is in the MIT repo and runs locally via npx supermemory local. Its metered pricing is unusually explicit compared with credit-based rivals.

Memory model	Extracted memories + user profiles over hybrid search; document connectors
Deployment	Managed cloud; self-host (MIT) supported on Scale/Enterprise, air-gapped option
Storage backend	Supermemory-managed store; local stack via npx supermemory local
Interfaces / SDKs	REST, TypeScript, Python, MCP server, Vercel AI SDK / LangChain integrations
Scoping unit	Per-user containers / spaces

Watch out: Officially supported self-hosting is gated to the $399/mo Scale tier and Enterprise even though the code is MIT, so the free path is community-supported. The token-metered pricing means a document-heavy connector sync can consume far more than the chat memory itself, and 'usage included' credits obscure what a workload actually costs until you run it. It is a newer project than Mem0 or Zep with correspondingly less production-hardening evidence.

Free $0/mo (~$5 usage included). Pro $19/mo (~$20 usage, 2 teammates). Max $100/mo (~$130 usage). Scale $399/mo (~$600 usage, up to 10 teammates, SOC 2, HIPAA BAA, self-host option). Enterprise custom/air-gapped. Metered: memory $0.005/1K SM tokens ($0.010 rich), SuperRAG $0.001/1K ($0.002 rich), search/traversal $0.005/1K queries, operations $0.10/1K. · open source

Memobase

Memobase departs from free-text fact stores: it maintains a typed user profile organized into topics and sub-attributes — basic info, demographics, education, interests, psychological traits, work — alongside a chronological event timeline. That structure makes memory inspectable and directly renderable in a UI, which matters for consumer apps where users expect to see and edit what the assistant knows. It runs on FastAPI, Postgres and Redis and is fully dockerized.

Memory model	Structured topic-based user profiles + event timeline
Deployment	Managed cloud, self-host via Docker (Apache-2.0)
Storage backend	PostgreSQL + Redis (FastAPI service)
Interfaces / SDKs	REST, Python, TypeScript, Go
Scoping unit	User, with blob/session grouping

Watch out: The profile schema is the whole design: memory that does not fit a user attribute or timeline event — project state, task history, cross-entity relationships — has nowhere natural to go, so it is a poor fit for enterprise or multi-agent workflow memory. The hosted service has no published pricing, which makes budgeting impossible without contacting them, and the project is early (v0.0.40) with a smaller community than Mem0 or Zep. Self-hosting means running Postgres and Redis yourself.

unknown — Memobase Cloud advertises a free tier and paid plans, but no public pricing page with numbers was reachable at time of writing. Self-hosted Apache-2.0 is free apart from your LLM calls. · open source

Honcho

Honcho models workspaces, peers, sessions and messages, then runs reasoning models over the message stream to derive conclusions about each peer — including what one peer knows about another — stored as representations you query. Its context() call returns a bounded block in about 200ms while heavier inference runs in the background. The bet is different from fact extraction: it aims at latent psychological inference rather than literal statements the user made.

Memory model	Reasoned peer representations derived from message streams
Deployment	Managed cloud (app.honcho.dev), self-host (AGPL-3.0)
Storage backend	PostgreSQL + pgvector
Interfaces / SDKs	REST, Python, TypeScript, MCP
Scoping unit	Workspace / peer / session (peer-to-peer representations)

Watch out: AGPL-3.0 is a real constraint for closed-source commercial products self-hosting it, and the network-use clause is the reason to read the license before adopting. The reasoning-based representations are inherently less auditable than an explicit fact row — you cannot always point at the message that produced a conclusion — and per-query reasoning at up to $0.50 makes deep queries something you budget for. Self-hosting requires Postgres with pgvector.

Honcho Memory: ingestion (store + reasoning) $2.00/M; context() calls unlimited at no additional cost (~200ms); background 'dreaming' inference included. Honcho Reasoning per query: Minimal $0.001, Low $0.01, Medium $0.05, High $0.10, Max $0.50. Startups under $5M raised: $1,000 credits and 12 months subsidized. Enterprise custom. · open source

Redis Agent Memory (Redis Iris)

Redis's two-tier design keeps session memory (active conversation state and metadata with configurable TTL) separate from long-term memory (extracted facts as text plus embeddings), promoting important items from the former to the latter asynchronously so extraction never sits in the request path. The original open-source Agent Memory Server is now archived as a V0 reference implementation; the supported product is Redis Agent Memory inside Redis Iris, a managed context engine on Redis Cloud that also bundles data integration, a context retriever and LangCache.

Memory model	Two-tier: session/working memory with TTL + async-extracted long-term facts
Deployment	Managed (Redis Cloud / Iris); self-host the archived Apache-2.0 V0 server
Storage backend	Redis (vector search)
Interfaces / SDKs	REST, client libraries, MCP server
Scoping unit	session_id and user/namespace

Watch out: The open-source path you may have bookmarked has moved: the repo's V0 directory is an archived reference implementation, not an actively supported server, so building on it means owning it. The supported route is a commercial managed product with no published pricing, and Iris bundles services (RDI, Context Retriever, LangCache) you may not want. Everything assumes Redis as the substrate, which is a poor match if you need graph-shaped memory or long-horizon analytical queries.

unknown — Redis Iris lists a free trial and directs pricing to sales; no public per-unit pricing. The archived V0 open-source server is Apache-2.0 and free to run on your own Redis. · open source

LangGraph Store

LangGraph separates two things most teams conflate: checkpointers persist a graph's state per thread_id (enabling resume, human-in-the-loop, time travel and fault tolerance), while the Store holds namespaced JSON documents shared across threads, optionally indexed for semantic search by supplying an embeddings model. It extracts nothing on its own — you decide what to write — which is why it costs no extra LLM calls and why it is the right floor to build on before buying a memory product.

Memory model	Namespaced key-value documents + optional embedding index (no extraction)
Deployment	Self-hosted library or LangGraph Platform
Storage backend	Postgres, Redis, MongoDB, Oracle AI Database, in-memory
Interfaces / SDKs	Python and JavaScript libraries
Scoping unit	Namespace tuples (e.g. (user_id, "memories")); threads via checkpointer

Watch out: It is persistence, not memory: no fact extraction, no contradiction handling, no decay, no temporal reasoning — you write all of that yourself, which is exactly the reinvention teams do badly. Backend maturity is uneven across Postgres, Redis, MongoDB and Oracle stores, and semantic search requires you to configure embeddings and dimensions correctly per namespace. It also ties your memory layer to LangGraph's abstractions.

Free (open-source packages). Cost is your database. LangGraph Platform deployments are billed separately by LangChain. · open source

LangMem

LangMem supplies the extraction layer LangGraph's Store deliberately omits: create_manage_memory_tool and create_search_memory_tool let an agent record and retrieve memories mid-conversation, while a background memory manager consolidates and updates knowledge out of band. It also includes prompt optimization that refines an agent's instructions from feedback. Choose it when you want extraction behavior you can read and modify in your own repo rather than a vendor endpoint.

Memory model	LLM extraction into typed memories, plus background consolidation and prompt optimization
Deployment	Self-hosted Python library (works in LangGraph Platform deployments)
Storage backend	Any LangGraph BaseStore (Postgres, Redis, MongoDB, in-memory)
Interfaces / SDKs	Python library (agent tools + background manager)
Scoping unit	Store namespace, typically per user or per agent

Watch out: It is a smaller, less battle-tested project (~1.6k stars) than the hosted alternatives and its API has moved around as LangChain's stack reorganized — pin versions and expect to read source. It gives you primitives, not a service: no dashboard, no managed store, no analytics, and you tune extraction prompts and schemas yourself. It is effectively LangGraph-shaped, so using it outside that ecosystem means porting the Store interface.

Free (MIT). You pay only for the LLM calls extraction and consolidation make. · open source

MongoDB Store for LangGraph

Two packages: langgraph-checkpoint-mongodb persists per-thread graph state for resume, human-in-the-loop and time travel, and langgraph-store-mongodb holds cross-thread memories with Atlas Vector Search. It supports both client-side embeddings and MongoDB's Automated Embedding Service (e.g. voyage-4) so documents embed server-side, plus ttl_config with refresh_on_read for memory that expires unless it keeps getting used — a decay primitive most stores lack.

Memory model	Key-value store with vector index + TTL decay (no extraction)
Deployment	MongoDB Atlas (managed) or self-managed MongoDB
Storage backend	MongoDB with Atlas Vector Search
Interfaces / SDKs	Python (langgraph-store-mongodb ≥0.3.0, langgraph-checkpoint-mongodb ≥0.4.0); LangGraph.js separately
Scoping unit	LangGraph namespace tuples; thread_id for checkpoints

Watch out: Like the base LangGraph Store it stores what you tell it to and extracts nothing — no fact distillation or contradiction resolution. Both packages are Python-only for the store and checkpointer; JavaScript teams get a separate, less complete LangGraph.js integration. It ties you to Atlas for vector search, and TTL-based decay is a blunt instrument compared with relevance-weighted forgetting.

The integration packages are free and open source; you pay Atlas cluster pricing (a free M0 tier exists) plus embedding costs if using the Automated Embedding Service. · open source

Anthropic Memory Tool

A client-side tool (type memory_20250818) that gives Claude six file commands — view, create, str_replace, insert, delete, rename — against a /memories path your handler maps onto real storage. The model decides what to write and reads files back on demand, so context stays small in long sessions. Paired with context editing and server-side compaction it is the native pattern for multi-session agents: memory is plain text you can open, diff and version, with no vendor between you and it.

Memory model	Agent-curated files under /memories, just-in-time reads
Deployment	Client-side — you host the storage; tool runs via the Claude API
Storage backend	Anything you implement: filesystem, database, object storage, encrypted files
Interfaces / SDKs	Claude API tool; helpers in Python, TypeScript, Java, C# SDKs
Scoping unit	Whatever directory your handler maps (e.g. per user or per project)

Watch out: You implement and secure the backend: path traversal validation, size caps, and expiry of stale files are explicitly your responsibility, and a naive handler is a directory-escape vulnerability. It is Claude-only, so it locks that part of your architecture to one provider. There is no retrieval index — the model finds things by listing and reading files, which degrades once the memory directory grows large or disorganized, and it does no per-user extraction unless you scope directories yourself.

No separate charge — you pay only normal Claude API token usage for the tool calls and file contents read into context. Storage is your own infrastructure.

OpenAI Conversations API

Used with the Responses API, a Conversation is a long-running object with its own identifier that stores messages, tool calls and tool outputs, so you resume a thread by ID instead of replaying transcripts. Unlike bare response objects — which are retained 30 days by default and can be disabled with store: false — conversation objects are not subject to that TTL. It is the cheapest correct answer when you need continuity rather than synthesis.

Memory model	Stored message history (no extraction or synthesis)
Deployment	Managed by OpenAI only
Storage backend	OpenAI-hosted conversation objects
Interfaces / SDKs	REST, Python, TypeScript (Responses API)
Scoping unit	conversation_id (or previous_response_id chaining)

Watch out: There is no automatic memory or fact extraction for developers — it persists the transcript, so a long conversation still costs full context tokens on every turn and eventually hits the model's context window. No cross-thread user profile, no scoping beyond the conversation object, no decay or contradiction handling. It is OpenAI-only and your conversation data lives on their servers, which rules it out where residency or ZDR requirements bind.

No separate storage line item published; you pay standard Responses API token pricing for whatever context is replayed into each request.

Mastra Memory

Mastra bundles four memory mechanisms into its agent runtime: bounded message history, working memory holding structured persistent user data injected as a system message, semantic recall that retrieves past exchanges by meaning across threads, and observational memory where background agents maintain a dense observation log that replaces raw history as it grows. For TypeScript teams this removes the need to wire a separate memory vendor into the agent loop.

Memory model	Message history + structured working memory + semantic recall + observational log
Deployment	Self-hosted framework or Mastra Cloud
Storage backend	Pluggable storage adapters (e.g. @mastra/libsql, Postgres, others)
Interfaces / SDKs	TypeScript/JavaScript framework
Scoping unit	resourceId (user) and threadId

Watch out: Memory is coupled to Mastra's agent abstractions — you cannot easily use it from a Python service or a non-Mastra loop, so it is a framework commitment, not a memory layer. Semantic recall and observational memory both add LLM and embedding calls whose cost is easy to underestimate at scale. Parts of the codebase sit under the Enterprise License rather than Apache-2.0, so check which directories your production use touches, and the memory features are younger than dedicated products like Zep or Mem0.

Free (Apache-2.0 core; some ee/ directories are source-available under the Mastra Enterprise License). Mastra Cloud is billed separately. You pay for your storage and LLM calls. · open source

MemMachine

MemMachine separates three stores rather than one: episodic conversational context in Neo4j, long-term user facts and preferences in SQL, and short-term working memory for the current session. Exposing all three behind REST, Python/TypeScript SDKs and an MCP server means an agent can query the right tier explicitly instead of hoping one retrieval blend surfaces the right thing. It is a self-hostable alternative for teams who want the graph plus profile split without a commercial contract.

Memory model	Three tiers: episodic graph memory, SQL profile memory, working memory
Deployment	Self-hosted via Docker; managed cloud referenced
Storage backend	Neo4j (episodic) + SQL database (profiles)
Interfaces / SDKs	REST, Python, TypeScript, MCP server
Scoping unit	User / agent / session

Watch out: It is young and small relative to the field (~3.2k stars, no long production track record), so treat it as an early-adopter choice rather than a safe default. Running it means operating both Neo4j and a SQL database, which is heavier ops than a single-store product. Documentation and the managed cloud offering are less developed than Mem0's or Zep's, and there is no published pricing for the hosted option.

Free (Apache-2.0). Costs are Neo4j and SQL infrastructure plus LLM calls for extraction. · open source

Papr

Papr's platform bundles graph-aware search, knowledge graphs, document intelligence and a Chat Memory & Compression product that stores conversations with automatic compression for long-running context. Components are usable standalone or combined, and it offers three deployment shapes — managed cloud, hybrid on your AWS/Azure/GCP, and fully self-hosted — which is a wider deployment range than most hosted memory vendors give you.

Memory model	Graph-aware memory + chat memory with automatic compression
Deployment	Managed cloud, hybrid (AWS/Azure/GCP), self-hosted (AGPL-3.0)
Storage backend	unknown (managed store; knowledge graph + vector components)
Interfaces / SDKs	REST API, SDKs, MCP
Scoping unit	User / session

Watch out: The company's public positioning has shifted toward a GTM applications product (Papr Work), which makes the developer memory API's roadmap priority harder to read — verify support commitments before building on it. No published pricing means no budget modeling without a sales conversation. AGPL-3.0 self-hosting carries network-copyleft obligations that many closed-source products cannot accept, and the platform is broader than a focused memory layer, so you inherit surface you may not use.

unknown — a free tier through enterprise plans is advertised, but no public pricing page with numbers was reachable at time of writing. Self-hosting under AGPL-3.0 is free. · open source