# Honcho vs Mem0 for Agent Memory

Honcho and Mem0 are both agent memory layers, but they differ fundamentally: Mem0 extracts and retrieves facts; Honcho reasons over conversation to build a user model. On implicit-preference tasks Honcho scores 90.0% vs a 23.3% no-memory baseline (LongMemEval). Retrieval is free and ~200ms.

Date: 2026-07-08
URL: https://honcho.dev/blog/blog/honcho-vs-mem0
Tags: honcho

---

Memory systems split into two camps. One extracts facts and retrieves them. The other reasons about the user. Mem0 is the strongest, most-adopted system in the first camp; Honcho is built on the second. That single architectural choice (store-and-retrieve versus reason-and-represent) is what everything below traces back to, and it’s the thing to decide first, because retrieval can only hand back what an LLM already chose to write down. It cannot surface what was never said.

Two camps of memory. Mem0 extracts and retrieves facts; Honcho reasons over conversation to build a model of the user. Retrieval can only return what was explicitly captured.
The gap shows up where facts were never stated: on LongMemEval, Honcho scores 90.0% on single-session preference vs a 23.3% no-memory baseline, and 85.0% vs 46.6% on multi-session reasoning.
Honcho’s .context() retrieval is free, unlimited, and ~200ms; ingestion (store + reasoning) is $2/M tokens with background reasoning included.
Both vendors self-report LLM-as-judge scores; small LoCoMo gaps (~91.6-92.5% Mem0 vs 89.9% Honcho) fall within judge variance on a saturating benchmark, so they don’t decide anything.
Normalized, Honcho is cheaper: illustratively a small app is ~$60 vs Mem0’s $79-249 tiers; a scaling app is ~$900 vs opaque Enterprise pricing (order-of-magnitude figures, not quotes).

Honcho vs Mem0 at a glance: which agent memory layer should you choose?
Which agent memory layer should you choose? The short version is in the table; the rest of this post argues what it asserts.


















































DimensionHonchoMem0Core approachReasons over history to build a model of the user (social cognition); conclusions beyond what was stated. Memory that reasons.Extracts atomic facts, then hybrid retrieves them (semantic + keyword + entity). Still retrieval.What it storesA queryable reasoning tree of explicit/deductive/inductive/abductive conclusions, produced by purpose-built Neuromancer models; models any Peer (user, agent, NPC, group) + scoped relationshipsAtomic facts as vectors; scoped by user_id / agent_id / run_idRetrieval.context() ~200ms, free, unlimited, designed for every turnEnd-to-end p50 ≤1.1s; quota-meteredPricing$2/M tokens ingested (store + reasoning); .context() free; Dreaming included; .chat() $0.001-$0.50/querySeat/quota tiers: $19-$249/mo + custom EnterprisePublished benchmarksLoCoMo 89.9%, LongMem S 90.4% (evals.honcho.dev)LoCoMo ~91.6-92.5%, LongMemEval ~93.4-94.4% (self-reported)GraphNative relational/temporal reasoning + background DreamingDropped queryable graph store in SDK v2.0.0 (April 2026); now co-occurrence entity-linkingLicenseAGPL-3.0Apache-2.0ComplianceSOC 2 Type ISOC 2 Type I; neither has audited HIPAA
Methodology and data for Honcho’s numbers are open and reproducible at github.com/plastic-labs/honcho-benchmarks.
One thing is deliberately absent from that table: BEAM scores side by side. Honcho and Mem0 grade BEAM on different scales, so lining them up would be an apples-to-oranges error. More on that in the benchmark section.
Reasoning vs retrieval: why Mem0 can’t surface a preference the user never stated
Why can’t a retrieval system surface a preference the user never stated? Because retrieval returns stored facts, and a fact only gets stored if the extractor decided to write it down.
Fact extraction plus retrieval is a legitimate approach. It’s fast, it’s cheap, and for a lot of applications it’s all you need. Mem0 does it well, and its 2026 refresh made it faster still. But it is definitionally a retrieval system: its own current extraction prompt instructs the LLM to produce atomic factual statements, and its positioning treats memory retrieval as distinct from model reasoning (memory surfaces relevant facts before the model responds). The extractor can only store what a model chose to record at ingestion time.
Here’s the ceiling. Most of what matters about a person is inferable but never stated. Take a message from the thesis: “I’m picking up my daughter from soccer practice.” Explicitly, the user has a daughter who plays soccer. Implicitly, the user is likely a parent, likely has afternoon time constraints, likely values their child’s extracurriculars. If the conclusion “this user is risk-averse and defers decisions when stressed” was never extracted as an explicit fact, no amount of hybrid search (semantic, keyword, or entity) can surface it. It isn’t in the store.
Honcho front-loads the reasoning instead. When a message lands, Honcho’s Neuromancer models reason toward conclusions across a spectrum of certainty (explicit, deductive, inductive, abductive) and store those in a queryable reasoning tree. You get more context out than you put in. And because the inference happens at ingestion, conclusions are persisted, consistent, and inspectable, rather than re-derived ephemerally and opaquely inside the model’s head at every query.
The scope difference is a superset, not a trade. Honcho models any Peer (a user, an agent, an NPC, a group) and the scoped relationships between them, including each peer’s distinct perspective on another. Mem0 is scoped to fixed user_id / agent_id / run_id keys, the user-assistant world. Honcho’s abstraction contains that as a special case and reaches group chats, agents plus subagents, and adversarial NPC dynamics that fixed keys can’t express.
Retrieval can only return what was explicitly captured. Honcho reasons about the user, so it surfaces what no one ever typed. The longer argument is in Memory as Reasoning.
What the benchmarks actually show (and what “within the noise” means)
Lead with the categories that require inference, not the headline overall score. On LongMemEval, Honcho scores 90.0% on single-session preference against a 23.3% no-memory baseline, and 85.0% on multi-session reasoning against 46.6%. Those are precisely the tasks where the relevant “fact” was never written down (implicit preference and reasoning across sessions) and precisely where a flat fact-store hits its ceiling. A 27.8-point overall improvement over baseline concentrates right there.
Now the caveat that governs all of these numbers. Memory benchmarks are scored by an LLM-as-judge: a model reads the answer and the gold answer and decides correct or incorrect. The judge is itself non-deterministic--even at temperature 0, minor wording differences in the answer being graded can flip its verdict. So every published score carries variance, and a gap of one to four points on a self-judged eval is inside that variance. It doesn’t establish a ranking.
Read Mem0’s numbers with that in mind. Mem0 self-reports LoCoMo around 91.6-92.5% and LongMemEval around 93.4-94.4% (as of the research snapshot), scored by a GPT-4o judge, with a stated ±1 point confidence interval due to judge inconsistency. Honcho scores LoCoMo 89.9% and LongMem S 90.4%. The deltas fall within judge variance. A self-judged single-point lead is not a conclusion.
It matters even less on LoCoMo specifically, because LoCoMo is saturating. Per evals.honcho.dev, LoCoMo provides only ~16,000 tokens of context per question on average, so it’s no longer well suited to test memory systems today. A no-memory Claude Haiku 4.5 scores competitively just by dropping the whole conversation in the context window. Mem0’s own docs now agree LoCoMo is “a useful baseline, not a sufficient bar on its own.”
One hard rule for BEAM: the scores are not comparable. Honcho grades each BEAM question 0.5 = pass, 1.0 = ace, a scale with a much higher ceiling of excellence. Accuracy-percentage benchmarks use pass-rate scoring. Placing Honcho’s 0.630 next to a Mem0 accuracy percentage would be comparing two different measurements. Honcho’s BEAM results (100K 0.630, 500K 0.646, 1M 0.618, 10M 0.409) stand on Honcho’s own terms; notably, no drop-off in recall until ten million tokens, well past any model’s context window.
Independent work confirms the retrieval ceiling from the outside. The Convomem benchmark (arXiv 2511.10523, Salesforce AI Research, 2025) reports that RAG-based memory systems like Mem0 hit 30-45% on implicit user preferences, while simple full-context approaches reach 70-82% on conversation histories under 150 interactions. Read that carefully: the high-scoring side there is full context (raw conversation kept in the window), not reasoning, and full context is expensive and doesn’t scale. The point Convomem makes is narrower and sharper: fact extraction structurally loses implicit preferences that a plain read of the transcript preserves. Honcho’s reasoning win rests on Honcho’s own LongMemEval numbers above, not on Convomem.
The through-line: Honcho’s methodology and data are open and reproducible at github.com/plastic-labs/honcho-benchmarks. Anyone can rerun them.
Cost: what does Honcho vs Mem0 actually charge on top of retrieval?
Normalized, Honcho is cheaper. The retrieval-token cost of a query (roughly 7K tokens either way) is about the same across both systems, because both are far more efficient than dumping full context. So the real question is what the vendor charges on top of those tokens.
Honcho’s pricing is usage-based and transparent:

Ingestion (store + reasoning): $2 per million tokens.
.context() retrieval: free and unlimited, ~200ms, fast enough to call every turn.
Dreaming (background consolidation): included.
.chat() reasoning: priced by depth, from $0.001 (Minimal) to $0.50 (Max) per query, so you control cost per question.

No seat minimums. No feature gates on retrieval. Honcho’s own framing puts ingestion at 2.5-25x less expensive than other solutions across the board.
Mem0 charges seat/quota tiers (Mem0’s published tiers as of the research snapshot): Starter $19/mo (50K memories / 5K retrievals), Growth $79/mo, Pro $249/mo (advanced analytics gated to this tier), Enterprise custom. “Predictable” holds only until you hit a quota ceiling; the advanced features live in the higher tiers.
Worked out with the same ~7K-token retrieval budget both systems use, and ingestion at Honcho’s $2/M: a small application (tens of thousands of messages ingested, a few thousand .chat() queries at Low/Medium depth per month) lands around $60 on Honcho, since retrieval is free and only ingestion plus a modest reasoning tier is billed; on Mem0 you’re paying a $79-249 tier once you need real memory limits and analytics. A scaling application (millions of tokens ingested, heavier reasoning traffic) runs roughly $900 on Honcho’s transparent usage-based pricing, versus Mem0’s opaque custom Enterprise pricing where you’re quoting a sales team. Treat both figures as order-of-magnitude illustrations from those assumptions, not a quote.
The framing Mem0 uses (usage-based is “harder to forecast”) gets it backward. Free, unlimited retrieval makes per-turn memory cheap to call by default, and you pay only for the actual ingestion and reasoning work you request. Pricing is at honcho.dev.
Where Mem0 is genuinely strong--and where it stops mattering
Mem0 has real strengths, and pretending otherwise would be dishonest. Here they are, each next to the thing that prices it.
Community and license. Mem0’s open-source core is one of the most adopted memory layers going--roughly 59K GitHub stars, Apache-2.0. Apache-2.0 is more permissive than Honcho’s AGPL-3.0 if you intend to vendor the code into a closed commercial product. AGPL is strong copyleft: it blocks closed commercial forks (a feature, not a bug, for an open-source project) and, in practice, most developers consume Honcho as the hosted service at app.honcho.dev and never touch the network-disclosure clause.
Integration breadth. Mem0’s MCP and SDK surface is ahead today: OpenMemory local-first MCP plus hosted, wide framework coverage, an AWS Strands partnership. Honcho’s surface is solid and growing fast: an Agent Skill (npx skills add plastic-labs/honcho), the Claude-Honcho plugin for persistent memory in Claude Code, OpenClaw across WhatsApp/Telegram/Discord/Slack, and Hermes with built-in Honcho memory.
Compliance is parity, not a Mem0 lead. Both hold SOC 2 Type I (Honcho per trust.delve.co/plastic-labs, Mem0 per trust.mem0.ai). Mem0’s HIPAA is self-attested, not audited; neither vendor can claim audited HIPAA. For a regulated buyer, the real story is data control: Honcho supports self-hosting (Docker, K3s, Fly.io) and bring-your-own-credentials, including any OpenAI-compatible LLM/embedding endpoint, so inference and data can stay on your own infrastructure or on-prem.
The graph. Mem0 dropped its external queryable graph store in SDK v2.0.0 (April 2026). Relational and temporal reasoning that used to be a Mem0 talking point is now a co-occurrence entity-linking boost folded into ranking--it won’t record a typed “manages” edge. Honcho captures relationships and how understanding evolves over time directly in its reasoning representation, with Dreaming resolving conflicts and weighting conclusions in the background, no separate graph database to traverse.
Plenty of memory layers do fact extraction and retrieval well: open, well-integrated, fast, often all you need. The question that decides your architecture is what happens when the thing you need to know about a user was never said out loud. How much of your users are you leaving unmodeled by only remembering what they typed?