Supermemory is a memory and context engine: you add conversations, documents and files, it extracts memories into a graph, and you search them or let a wrapper inject them into your prompt. Threadless AI solves a narrower problem differently: it decides what the model sees on every call of one conversation and hands you the request. This page compares the designs as each company documents them and says when Supermemory is the better choice.
We make Threadless AI, so weigh our description of it accordingly. Every claim about Supermemory links to Supermemory's own pages, checked on the date above; tell us at support@threadlessai.com if something has changed.
The difference in one line
- Supermemory stores what you add, extracts memories with its own models, and returns relevant memories and profile facts for you, or its wrapper, to place in the prompt (OpenAI integration).
- Threadless AI keeps one memory per conversation and returns the whole request, history included, ready to submit to OpenAI.
What happened to Infinite Chat
Supermemory once offered a proxy, Infinite Chat (later the Memory Router), that sat in front of your OpenAI base URL and managed a conversation's history. Its announcement is now marked as historical and not part of the current API, and the router's documentation pages redirect elsewhere (announcement). If you used it and want a request-shaped replacement that is maintained, that is what Threadless AI is.
Side by side
| Supermemory | Threadless AI | |
|---|---|---|
| Integration | Add content; search memories, or wrap your OpenAI client so memories are added to the system prompt (OpenAI integration) | decorate before the call, report after; submit what comes back |
| Scope | Namespaces you choose, typically per user, holding many documents and conversations (namespaces) | One memory per conversation; recall never crosses memories |
| Who writes the memories | Supermemory's models extract them from what you add (how it works) | Your model writes facts with a note tool, from the turns it was in |
| The context window | The rest of the history is yours to manage | Managed for the whole request: the latest messages word for word, facts from older messages in view, older messages that matter brought back; token use stays bounded |
| Sense of time | Updates win over older facts; temporary facts expire; episodes decay unless significant (graph memory) | Older messages that come back carry their dates; newer facts replace older ones |
| Content types | Documents, files, URLs and connectors as well as chat | The conversation itself |
| Model providers | Many, through SDK integrations | OpenAI's Chat Completions and Responses formats |
| Self-hosting | A self-hosted server built from a non-public codebase, free up to 10,000 documents (self-hosting) | Hosted only |
| Pricing | Credits: Free with $5 a month, Pro $19, Max $100, Scale $399 (billing) | Per user turn and stored GB-month; prices being finalised (pricing) |
| When the service is down | Your search call fails; what your code does is up to you | The SDK builds the request from a local tail; the model call goes ahead |
| MCP | A hosted MCP server (MCP) | No runtime MCP; memory is the context the agent runs in, not a tool it calls |
How the two designs work
Supermemory is a store organised by namespace, each with its own vector index. You add documents and chats; a background process it calls dreaming extracts facts into a graph with update, extend and derive relations, and keeps the latest version of a fact current while history remains (how it works). At answer time you search, read a profile, or let the withSupermemory wrapper inject relevant memories into the system prompt. The messages you send are still your own.
Threadless AI sits in front of the model call for one conversation. Your agent sends what is new to decorate and gets back the whole request. Inside it are your instructions, the facts from older messages, the latest messages word for word, and the older messages that matter to the new message, with their dates, placed just before it. As the conversation grows, older messages stop being sent word for word; just before they do, your model notes their key facts with the note tool, and those facts stay in view. The request is sized for a 200k-token context window, so token use stays bounded. See how it works.
Why people switch from Supermemory
Only if these match your situation:
- They relied on the proxy. Infinite Chat managed the conversation's history; the current API does not.
- The chat log keeps growing. The wrapper adds memories to the system prompt but does not trim the history you send (OpenAI integration).
- They want the model that was there to write the facts, rather than Supermemory's own models deciding what to learn.
- They want the agent to keep answering in an outage. Threadless AI's SDK falls back to a local tail; see what happens when memory is down.
The reasons to stay are just as real: documents, files and connectors in memory, memory that spans a user's conversations, several providers, and a self-hosted server.
Benchmarks
| System | Result | Who ran it | On what |
|---|---|---|---|
| Supermemory | LongMemEval-S 97% | Supermemory | Recall@20 with aggregation, not answer accuracy; judged with gpt-4o (research) |
| Threadless AI | None published | We are running LongMemEval and LoCoMo and will publish scores with the method |
Supermemory's figure is a retrieval metric it measured on its own system; it publishes the MemoryBench harness under MIT so others can rerun it (MemoryBench). We have no numbers to set beside it yet.
When to choose Supermemory
- Your agent should know a user's documents, files and connected apps, not only what was said in chat.
- Memory follows a user across many conversations and products.
- You use several model providers or a framework Supermemory integrates with.
- You want memory as a tool an assistant calls through MCP.
When to choose Threadless AI
- The conversation itself is the problem: it runs long, and what the model sees on each call has to be decided every time.
- You want the whole request managed, not memories to fit into a prompt you still have to size.
- Facts written by the model that was there, readable and exportable per conversation.
- Your agent must keep answering when the memory service is unreachable.
Moving from Supermemory
- Create a Threadless AI memory per conversation and keep its id beside your conversation id.
- Replace the search-and-inject step, or the wrapped client, with
decorate: send the new messages, submit what comes back. - Add
reportafter the model call and the note tool to your tools; answer note calls withnoted. - Durable facts about the user go in your system message, which is stored and always leads the request.
- To carry a live conversation over, send its recent history in the first
decorate. - Keep Supermemory for documents and connectors if you use them, and write what a conversation needs into its system message.
Questions people ask
What is the difference between Supermemory and Threadless AI?
Supermemory is a store for chat, documents and files that returns relevant memories for your prompt. Threadless AI returns the whole OpenAI request for one conversation with the history managed, and your own model writes the facts.
Is Supermemory's Infinite Chat still available?
Its current docs no longer describe it: the announcement is marked as historical and the router's pages redirect to an SDK integration. For a maintained service that manages a conversation's request, see how Threadless AI works.
Is Supermemory open source?
Its SDKs are; the self-hosted server binary is built from a separate, non-public codebase (self-hosting). Threadless AI is hosted only.
Can I use Supermemory and Threadless AI together?
Yes. Use Supermemory for a user's documents and long-lived facts, put what a conversation needs into its system message, and let Threadless AI manage that conversation's history.
Does Threadless AI store documents and files?
No. A memory holds one conversation: its messages and the facts written from them. For document search, use a store such as Supermemory or your own retrieval.