---
title: "past.dev vs Supermemory"
description: "Supermemory is broad context infrastructure with connectors and multimodal ingestion. past.dev is narrow: timestamped text, current-state answers, evidence and abstention. Where each fits."
canonical: https://past.dev/vs/supermemory
last-updated: 2026-08-26
---
# past.dev vs Supermemory

Source: https://past.dev/vs/supermemory

Supermemory is context infrastructure for agents with a wide ingestion surface: text, chats, files, PDFs, images and video through extractors and connectors, plus retrieval and user profiles, run as managed cloud or self-hosted. past.dev is deliberately narrow: timestamped text in, current-state answers out, with dated evidence, per-call cost and an explicit abstention. The choice is mostly about scope, whether you want one system covering everything an agent might read, or one system answering questions whose answers changed.

## What Supermemory is

[Supermemory](https://github.com/supermemoryai/supermemory) describes itself as the long-term and short-term context and memory infrastructure for agents. Its documentation lists memory, retrieval, profiles, connectors, extractors and evaluation as the building blocks, and it takes in raw data in many formats, text, chats, PDFs, images, video and code, through extractors and connectors. It offers a hosted API with SDKs, and the repository, which is MIT licensed, advertises running it yourself.

## What past.dev is

A smaller surface on purpose: five endpoints, one ingestion model. Send text with the timestamp it happened, backdated when you are loading history, and ask questions later. Extraction, entity resolution and graph maintenance run on our side. `/recall` returns ranked evidence with sources, `/answer` returns a grounded answer with its dollar cost and `abstained: true` when the evidence does not establish one.

There are no connectors. Ingestion is one HTTP call, which means you decide what enters the memory and when, and it means the integration to your mailbox or your CRM is yours to write.

## Scope differences

|  | Supermemory | past.dev |
| --- | --- | --- |
| Positioning | Context infrastructure for agents, broad | Memory API for timestamped history, narrow |
| Ingestion | Text, chats, files, PDFs, images, video, through extractors and connectors | Text plus a timestamp, one endpoint |
| Connectors to third-party sources | Yes | No, you call the API |
| Time | Facts update as new information arrives | A validity window per fact, previous values kept dated in the history |
| Evidence | Retrieval returns the matching material | Every answer carries dated sources |
| Abstention | Your code decides | `abstained: true` on `/answer` |
| Cost visibility | Plan-level | Reported per call in the response |
| Self-host | Advertised by the project | The same image we run, on your Docker |

> **Read it at the source**
>
> Supermemory's surface moves quickly and this table describes what its own documentation and repository stated in August 2026. Check their docs before making a decision on it, and tell us if anything here has gone out of date.

## How to choose

Both are reasonable choices and they are not built for the same job. The short version:

- **Choose Supermemory** if you want one system to ingest everything an agent might read, including files and multimodal content, and you want the connectors rather than writing the ingestion yourself.
- **Choose past.dev** if your problem is a specific one: history arrives as text with dates, the answer changes over time, and you need to show where an answer came from.
- **Documents you own** are worth keeping in your own index either way. [Choosing a vector database for RAG](/vector-database-for-rag) covers that half.

## What this page does not claim

No head-to-head numbers. We run LoCoMo on the community-corrected answer keys, LongMemEval and BEAM, with full-context and plain-RAG baselines and several judges, and the method is published on [benchmarks](/benchmarks). A comparison against another product is only worth reading if the other product was configured by someone who wanted it to do well, and if the harness that produced it can be rerun. Until we publish that harness, this page compares designs, not scores. The numbers land here when they can be reproduced.

## Related

- [Choosing a vector database for RAG](https://past.dev/vector-database-for-rag)
- [What is agent memory?](https://past.dev/what-is-agent-memory)
- [past.dev vs mem0](https://past.dev/vs/mem0)
- [Memory API overview](https://past.dev/docs/memory-api/overview)
- [How we measure memory](https://past.dev/benchmarks)