Cognee alternatives
Checked against Cognee’s own documentation on
Cognee is an open source memory engine. An ingest pipeline takes documents, extracts structure from them, and lands the result in a store you then query. You can run the whole thing yourself for free.
The reasons to look elsewhere are about shape rather than quality. It is built around documents, and a lot of products are built around one person’s stream of conversation. WOS is ours, and it is built for the second.
- 95.7%LongMemEval-SCognee publishes HotpotQA 0.815, a different task
- 95.2%recall@5 across 70 language pairsthe same store can hold every language
- 2,484tokens per query at 2.2M memoriesmeasured with a tokenizer, not estimated
Where WOS comes out ahead. Where it does not is in the table below.
Cognee and WOS
| Cognee | WOS | |
|---|---|---|
| What each one has published | ||
| HotpotQA | 0.815 DeepEval correctness, tuned; 0.476 before tuning | Not run a document QA test rather than conversational memory |
| LongMemEval-S and BEAM-1M | Not published | 95.7% and 67.5% Tablet 2 read by Claude Opus 5; 93.7% read by GPT-5.6-sol |
| Also published | Head-to-head posts their own runs against Mem0, Graphiti and LightRAG on HotpotQA | Context 2,484 tokens, languages 95.2% at 2.2M memories with verify 3; recall@5 over 70 language pairs |
| Source | cognee.ai evaluation results | how we benchmark |
| How it is built | ||
| Stored as | Structure extracted from documents | Kept, not rewritten |
| A model reads it | Yes, in the ingest pipeline | Never |
| Organised around | A body of documents | One store per end-user |
| Retrieval | Graph and vector together | Not published |
| Correcting a fact | Re-ingest the source document | supersede, with lineage |
| Licence | Open source | Closed source |
| Self-hosting | Yes, free, on your own stack | Case by case |
| Metered by | Tokens processed at ingest | Tokens, plus a flat fee per request |
- Both columns are self-reported: a placement, not a verdict. Some rows go to Cognee.
- Across languages is a grid of 70 store-language by query-language pairs.
What WOS does
Against Cognee the difference is the unit. Cognee’s unit is a document: something you ingest once, structure, and query. The unit in WOS is a person: a store that belongs to one end-user, that nothing else can read, and that grows a turn at a time.
For your AI Won is the part of the product addressed to the model rather than to you, and it carries no charge. Your agent can ask how much of its own memory has been rewritten before it leans on a fact, and the answer is the same size for a hundred memories or a hundred million. the page written for an arriving agent.
- Stores are explicitWriting to a store that does not exist is a 404, never a silent create, so a typo in a user id cannot quietly open a second empty memory that leaks nothing but finds nothing either.
- Workspaces on topThe same store id in two workspaces is two separate memory spaces, so staging and production cannot see each other by accident.
- Who said itRegister a speaker and memories carry attribution, which a document pipeline has no reason to model.
- Filters that do not spoil the rankingNarrowing by category or date happens before ranking, so you get the best matches inside the filter rather than a filtered top-N.
- Erasing a person is one callforget with no memory id removes that end-user entirely, which is the shape a GDPR request actually arrives in.
- Calls the model makes for itselfWon is the part of the product addressed to your agent rather than to you, and it carries no charge. revisions is the first of them: the model can ask how much of a memory has been rewritten before it leans on it, and the answer is the same size at a hundred memories or a hundred million.
- Multi-hop without a modelEngrams search and then expand around what they found: deep recall, timelines, drafts. No language model runs in that loop, so a question that takes two steps is one call and there is no per-hop bill.
Where Cognee is the better answer
- Free self-hosting with nothing gated behind a paid tier
- A graph you can inspect and traverse, rather than similarity you have to trust
- Document connectors and a pipeline built for ingesting files rather than turns
- Full ownership of the stack, which for some teams is the whole reason to pick it
- What WOS costs you. It is closed source and hosted, so running it on your own hardware is a conversation rather than a download. There is no knowledge graph, so a question that is really about validity intervals is better served elsewhere. And it is the newest name on this page, with a smaller ecosystem than the ones above it.
- What it buys you. Nothing runs a language model over what you stored, so the privacy review is one sentence rather than a discussion. A query comes back in about 320ms, and the context it hands over was measured at 2,484 tokens over 2.2 million memories. Repeated queries bill a tenth. And it behaves the same in every language: recall@5 of 95.2% over 70 store-language by query-language pairs.
Why teams look at something else
| It is organised around documents, not end-users | Keeping one customer’s memories out of another customer’s answers is something you arrange rather than something you get. |
| Conversational recency is not the default shape | Weighting the last turn against a fact from last year is central to chat memory and peripheral to document retrieval. |
| Free to self-host means you operate it | The offer is real and unqualified, and the graph store, the embedding calls and the upgrades are still yours. |
| Hosted cost tracks what you put in | Metering on tokens processed is predictable for a fixed corpus and less so for a live stream of conversation. |
- None of these are defects. Each follows from a decision that is right for somebody.
Bringing memory over
If what you have is genuinely a document corpus, the honest answer is that moving it to WOS may not be an improvement, because WOS is organised around one store per end-user rather than around a body of files. Where it does make sense is the hybrid case, where documents were the workaround for not having per-user memory. In that case create a store per end-user and write the per-person material through bulk-store, and leave the shared corpus wherever it already works.
The calls are in the documentation: create a store, bulk-store, and the rest of the endpoints. A key takes a few minutes in the console.
Questions
- Cognee or a memory API: which do I need?
Ask what you are remembering. If it is files, a pipeline that understands documents is the right tool. If it is people, and each person needs their own history that never leaks into anyone else’s, a per-user memory store fits the same effort better. That is what WOS is: one store per end-user, nothing rewritten, a measured 2,484 tokens returned per query.
- Does WOS do documents?
Only loosely, and it is worth being exact. WOS accepts a large blob of text through bulk-store and will index it, which covers backfilling a history. It is not a document pipeline: no connectors, no file parsing, no structure extraction. On that work Cognee is the better tool and it is not close.
- Is Cognee free?
The engine is open source and free to run on your own stack with nothing held back for a paid tier. The hosted version meters tokens processed, so cost there tracks how much you ingest. WOS has nothing you can run yourself: it meters tokens in and out plus $0.0001 a request, and a balance starts at $5.
- Can I use both?
Frequently the right answer. Document retrieval and per-user memory solve different problems and nothing about them conflicts. Cognee over your files and WOS over each person’s own history, merged into one prompt, is a normal architecture rather than a compromise.
The other options
- Mem0 Extract facts with a model as you write. Right for you if you want conversations turned into clean facts, and the widest ecosystem.
- Zep Build a temporal knowledge graph. Right for you if your questions are about when something was true, not just whether it is true.
- Letta Let the agent manage its own memory. Right for you if you want the agent to own and edit its own memory, inside their runtime.
- Supermemory Bundle memory with retrieval over connected sources. Right for you if you want one API over connectors, documents and chat memory together.
- Vector DB Build it yourself on a vector database. Right for you if you are prototyping, or you want no vendor in the path and will build the rest.
- Checked against Cognee’s own documentation on September 1, 2026.
- We quote nobody else’s prices, and use only figures each project published itself.
- Out of date or unfair? Tell us and it gets corrected.
You need the same store to work in many languages, and a per-query cost that does not drift as history grows. If that is not your case, one of the projects above will serve you better.
Three calls: create a store, write a memory, recall against it. No subscription, balance starts at $5. Get an API key or read the docs.