HAVESOME MEMORY

AI MEMORY / WHY IT MATTERS

You told your AI yesterday. Will it know today?

An AI agent works with the information supplied for its current task—not automatically every past conversation.

Memory means keeping useful information beyond a conversation and bringing it back when it matters.

Compare simple files and dedicated memory systems: what they keep, how they find it, and how they handle change.

Compare memory approaches
ONE DECISION. TWO CONVERSATIONS.
  1. 01 / YESTERDAY · YOU DECIDE

    “Use a 30-second timeout.”

  2. ↓ save beyond the conversationBETWEEN TASKS · A FILE OR MEMORY SYSTEM

    The decision + where it came from

  3. ↓ retrieve for the next task 02 / TODAY · YOU ASK

    “Which timeout should I use?”

Saved is not enough. It must be found—and still apply.

01 / THE SHORT VERSION

Memory at a glance.

Evidence reviewed 14 September 2026

Capability profiles rate documented features on a 0–3 scale. Scoring rubric ↓

Provider names open the official site in a new tab. Select Scores & details to explore an approach.
PinApproachA basic pattern or memory provider.Saved informationWhat is kept for future tasks.Recall methodHow the agent finds it again.Published testsReported results and test conditions.Runs onDevice, server, or cloud service.
Built-in notesAlways-on notesBuilt-in notesScores & details
Stable facts and user preferencesSession-start prompt snapshot No standardized scoreA pattern, not a tested product Local files
Files + skillsOn-demand filesLocal documentsScores & details
Knowledge and reusable proceduresFind → read the relevant file No standardized scoreDiscovery and upkeep are application work Local / your storage
CompactionWorking contextDefault compressorScores & details
A summary of earlier conversationRetained summary + recent messages No standardized scoreNot automatically cross-session memory Agent / model stack
Vector RAGRetrieval patternBasic dense RAGScores & details
Embedded source passagesQuery → nearest passages No universal RAG scoreDo not inherit a vendor’s RAG-baseline score Your index / service
HindsightStructured memorySelf-hosted APIScores & details
Facts, entities, time and observationsSemantic + lexical + graph + temporal BEAM 10M · 64.1 / 100Mean rubric score · April 2026 report Cloud / local service
HonchoPeer / user modelingManaged serviceScores & details
Peer representations and conclusionsContext + semantic search + reasoning BEAM 10M · 0.406 / 1Own dashboard: 0.409; not an identity-modeling test Cloud / self-hosted
Mem0Fact memoryPlatform v3 · managedScores & details
Compact facts, scoped to identitiesRetrieve and rank relevant facts LoCoMo · 92.5%Managed platform; not the OSS/Hermes score Platform / HTTP / OSS
OpenVikingContext filesystemSelf-hosted coreScores & details
Resources, memories and skillsHierarchy + semantic search; tiered reads Hermes LoCoMo · 82.86%Vendor reports 33.38% native baseline Self-hosted server
SupermemoryEvolving memory graphManaged APIScores & details
Facts, relationships and profilesSemantic recall + profile context xAFS · SMFS tradeoff53.8% fewer tokens; pass rate 92.7→91.4%. SMFS ≠ Hermes API adapter. Cloud / configured endpoint
ByteRoverCurated knowledge treeLocal CLI · V3Scores & details
Portable project knowledgeQuery a curated context tree LoCoMo · format experimentHTML 90.77% / Markdown 90.51% Local CLI / optional sync
RetainDBManaged memory APIManaged APIScores & details
User, session, task and project recordsHybrid search + reranking LongMemEval · 79%Oracle input + full timeline; in-progress report Cloud service
Facts, entities and feedback trustFTS5 + lexical / optional HRR ranking No comparable score foundReviewed plugin source; not a separate vendor Local SQLite
MemoriAgent execution memoryCloud adapterScores & details
Semantic triples, summaries and tracesExplicit recall of structured context LoCoMo · 87.0%721 mean context tokens; pre-generated assets Hermes Cloud plugin

Four basic patterns · eight bundled Hermes plugins + the separately installed Memori integration. Built-in memory stays active by default alongside one selected external provider. Hermes integration scope ↗

Editorial capability coverage — not a benchmark ranking

These editorial scores are not our own benchmarks.

Six evidence-grounded ordinal judgments describe documented mechanisms in one explicitly named scope per approach. They measure capability coverage and editorial operating burden, not how well a system performs. Basic patterns are useful low-complexity tradeoffs, not deliberately weakened competitors. There is no total, average, winner, or universal recommendation.

0–3 are criterion-specific anchors, not equal intervals or measured quantities. null means Unknown: evidence is insufficient or the generic pattern leaves the implementation unspecified. Missing evidence is never zero. Read each score with its rationale, deployment scope and first-party excerpts; larger radar area is not a quality metric.

Unknown is not zero. Unknown points are omitted; incomplete profiles have no connecting shape.

Source scope: A working single-user agent, its normal model access and host are assumed. Simplicity counts the additional setup/maintenance of the named route: managed API rows do not include self-hosted operations; self-hosted/local rows do. Managed convenience is not evidence of local control, privacy, security, latency or monetary savings. Optional enterprise, cloud sync, alternate engines and adapters receive no automatic parity.

Per-axis level anchors

Retrieval

How can an agent find the relevant stored context for a question?

0
Context is supplied as a whole snapshot or summary; this mechanism does not select stored items for a query.
1
Explicit file/item lookup, browsing, or unranked/basic lexical search selects context.
2
A documented ranked retrieval pipeline selects query-relevant stored context using similarity, lexical matching, or other explicit relevance signals.
3
Documented multi-path retrieval, query-driven reasoning, or staged hierarchy traversal selects context beyond a single ranked lookup.

Organization

How is knowledge structured beyond a chronological conversation?

0
A transcript or rolling summary is the organizing unit, without a durable structured knowledge collection in the assessed mechanism.
1
Separate notes, passages, or broad buckets provide lightweight organization.
2
Typed records with metadata/scopes or a named topic/file hierarchy organize reusable knowledge.
3
Explicit cross-record/entity relationships or synthesized peer/knowledge representations connect information across records.

Change / history

What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

0
Rebuilding a working summary is the change mechanism; it is not a durable fact-editing lifecycle.
1
An agent/operator can explicitly add, edit, replace, remove, or rebuild stored content.
2
Automatically synthesizes or curates knowledge, reconciles overlapping content beyond exact-duplicate validation, or reprocesses changed source content. Routine index maintenance alone does not qualify.
3
Provides explicit historical/versioned state or event-time interpretation beyond creation/update timestamps. This does not establish correct conflict resolution or guarantee an answer valid at a past date.

Traceability

What can you inspect to understand where recalled knowledge came from?

0
Only a lossy generated representation is exposed in the assessed mechanism, with no retained inspectable record or recovery reference.
1
You can inspect memory records/files or follow a general session recovery reference; claim-level source lineage is not established.
2
Retrieval identifies original source documents/passages or links a memory to its originating material.
3
In addition to source references, documented derivation links, contributing facts, or version history let you follow how knowledge was formed or changed.

Portability

What documented path lets you take the stored knowledge into another tool?

0
The assessed surface explicitly prevents reading or extracting the stored knowledge outside its own interface.
1
A documented API/tool reads memory objects or files, but migration requires application-side reconstruction.
2
A documented structured export or operator-accessible local database allows bulk possession; schema/index conversion may still be needed.
3
The knowledge is natively ordinary reusable files or an open document format, readable by other tools without the provider service.

Simplicity

Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

0
The assessed route requires substantial custom infrastructure or model/pipeline engineering, beyond configuring published components.
1
You operate or assemble a memory/retrieval service and its storage/model dependencies.
2
You install/configure a client or CLI with credentials/provider choices, or maintain a curated document hierarchy; no separately operated memory server is required in this scope.
3
The mechanism is built in or dependency-light local storage, with minimal additional configuration and no separate memory service to operate.

Assessed scopes

  • builtin-memory-files: Hermes built-in MEMORY.md + USER.md only; profile-local curated text, default bounded stores and session-start snapshot. Separate session_search and external providers are not included.
  • files-and-skills: Hermes local SKILL.md documents with referenced text files and progressive disclosure; a curated knowledge/procedure library, not arbitrary executable skill dependencies or automatic event ingestion.
  • compaction: Hermes default lossy ContextCompressor, including in-place archived-turn recovery through the separate session_search facility; not LCM or a cross-session fact database.
  • vector-rag: Basic operator-assembled dense-passage RAG: source passages, embeddings/index, top-k retrieval and an existing generator. Original RAG authors anchor the pattern; no specific database, managed stack, model training or added agentic/graph pipeline is assumed.
  • hindsight: Self-hosted Hindsight API with local PostgreSQL and a configured structured-output LLM; current retain/recall API, including optional source-fact/chunk expansion. Hermes adapter is cited separately; Hindsight Cloud is not the simplicity scope.
  • honcho: Managed Honcho service for peer-centric memory, representations, conclusions and reasoning; Hermes Cloud adapter setup. Self-hosted FastAPI/local-stack operations are explicitly excluded from simplicity.
  • mem0: Mem0 managed Platform v3 memory add/search/read APIs, with optional managed reranking; no automatic credit for OSS-only explain fields, optional graph editions, or the self-hosted dashboard. Hermes Platform adapter configuration is a separate integration boundary.
  • openviking: Self-hosted OpenViking core context database with viking:// hierarchy, tiered reads and session memory extraction; configured server/model dependencies. Optional VikingBot compilation and hosted Studio convenience are excluded.
  • supermemory: Managed Supermemory memory/document API and profiles, including /v4/memories/list history/source fields. Excludes SMFS filesystem/cache reconciliation and the self-hosted local binary; Hermes integration may expose only a subset of API options.
  • byterover: Catalogue-aligned local-first ByteRover CLI/Markdown context tree: V3 root docs plus the CLI 2.0 curation/retrieval description, BYOK and no cloud sync. Not V4 Desktop/spaces, cloud version control or the later proposed HTML format.
  • retaindb: Managed RetainDB user/session/agent/project memory as described by its memory-model docs and pinned Hermes adapter. Hybrid search is integration-documented; Company Brain-wide features and benchmark-only chronological full-context retrieval are not generalized.
  • holographic: Pinned bundled Hermes Holographic plugin with local SQLite/FTS5, default auto_extract=false, and optional NumPy HRR algebra; no learned embedding service or external memory server.
  • memori: Memori Cloud through separately installed hermes-memori at the pinned repository snapshot: completed-turn/tool-trace capture and structured recall. Not Memori OSS/BYODB, local database ownership, or benchmark pre-augmented assets.

02 / READ THE TEST, NOT JUST THE NUMBER

Same benchmark name ≠ same experiment.

Results published by each provider, with the dataset, setup and limitations alongside.

Hindsight / Vectorize · 21 April 2026

BEAM · 10 million-token histories

The linked article compiles this published 10M comparison. Values are mean rubric scores on a 0–100 scale, not percentages of questions answered correctly.

BEAM mean rubric score · 0–100 scale, not pass rate

This is Hindsight’s published comparison, not a new matched rerun. Exact answer model, judge, system versions and retrieval budgets are unresolved. Baseline labels refer to the tested implementations, not every RAG or lightweight-memory system.

Read this publisher’s evaluation ↗

Honcho / Plastic Labs · 19 December 2025

BEAM · Honcho’s own report

Honcho frames recall as one part of modeling identity. Its article reports these mean rubric scores (converted from 0–1 to 0–100); tiers are different workloads, not competing systems.

BEAM mean rubric score · 0–100 scale, not pass rate

Gemini 2.5 Flash Lite deriver; Claude Haiku 4.5 chat. Dreaming ON / 8,192-token batches at 100K; OFF / 4,096 at larger tiers. Judge model unresolved. Its dashboard instead reports 0.646 / 0.618 / 0.409 at 500K / 1M / 10M. The discrepancy remains unresolved.

Read this publisher’s evaluation ↗

Mem0 · Reviewed 14 September 2026

LoCoMo · Mem0 Platform

The same managed-platform experiment, with two retrieval budgets. This is not the OSS library or a Hermes integration benchmark.

LLM-judged accuracy · %

1,540 questions / 10 dialogues; one retrieval call, no agentic loop. Answer and judge models unresolved in the selected result. Separately, the same README reports LongMemEval 94.4% (Top 200) and 94.8% (Top 50). Do not mix datasets into one score.

Read this publisher’s evaluation ↗

OpenViking · Reviewed 14 September 2026

LoCoMo · inside Hermes

OpenViking compares native Hermes memory with its own integration. This is an implementation-specific baseline, not a verdict on every file-based memory setup.

Reported task success · %

Same publisher experiment. Exact answer model, judge and suite details unresolved in the report. The source also reports lower latency and token use; this guide has not reproduced the run.

Read this publisher’s evaluation ↗

Supermemory · Reviewed 14 September 2026

xAFS · the SMFS tradeoff

Supermemory’s filesystem product reduces token consumption, but its aggregate pass rate is slightly lower. SMFS is not the Hermes Supermemory API adapter.

Aggregate benchmark pass rate · %

Source reports 53.8% fewer tokens. xAFS combines AgentFS, FS-Research and StateFS tasks; it is not a LoCoMo or LongMemEval test. Do not apply this result to every Supermemory product.

Read this publisher’s evaluation ↗

ByteRover · Reviewed 14 September 2026

LoCoMo · HTML versus Markdown

ByteRover changes the memory representation in its own pipeline. Accuracy is close; the latency tradeoff is not.

Reported answer accuracy · %

1,982 questions / 11 conversations. HTML p95 latency: 4,311 ms versus 259 ms for Markdown. Small accuracy differences lack an uncertainty interval here. This tests file formats, not ByteRover versus other providers.

Read this publisher’s evaluation ↗

RetainDB · Reviewed 14 September 2026

LongMemEval · oracle input

RetainDB reports an overall result while its category coverage is still marked in progress. The answer model receives the full chronological memory dump.

Reported overall accuracy · %

Oracle split and full-timeline input—not a measured production retrieval pipeline. The page conflicts on extractor-model labels. Published competitor values on the page are not new matched reruns; they are deliberately not charted here.

Read this publisher’s evaluation ↗

Holographic (Hermes plugin) · Reviewed 14 September 2026

A plugin, not a leaderboard entry

The Hermes plugin stores local memory and supports SQLite/FTS5 retrieval, with optional holographic associations and trust scoring.

No comparable benchmark found

Local recordsSQLite / FTS5Recall

Reviewed plugin implementation, not a measured accuracy result. Verify relevance, update behavior and latency on your own workload.

Read the plugin source ↗

Memori · Reviewed 14 September 2026

LoCoMo · memory-to-context

Memori’s current results pair answer accuracy with a compact supplied context. The benchmark repository uses pre-generated memory assets.

Reported overall accuracy · %

721 mean context tokens reported. Public evaluation does not measure a complete new-ingestion-to-answer Hermes journey. Current origin and pinned source agree; an extraction cache still returns older 81.95% / 1,294-token figures, which are not used here.

Read this publisher’s evaluation ↗

Compare like with like.Check dataset revision, history size, system version, answering model, judge, retrieval budget, latency and cost. Unknown conditions remain unknown. A recall score does not test permissions, deletion, reliability or your workflow.

03 / EACH APPROACH, ON ITS OWN TERMS

What is each one trying to solve?

Explore each approach’s strengths, limits and memory flow.

Always-on notesBuilt-in MEMORY.md + USER.mdA small set of durable notes and user preferences stays always available.

Why use this pattern

A small set of durable notes and user preferences stays always available.

Keeps: Stable facts and user preferences · Finds it through: Session-start prompt snapshot · Runs on: Local files

Editorial capability profile

Assessed scope: Hermes built-in MEMORY.md + USER.md only; profile-local curated text, default bounded stores and session-start snapshot. Separate session_search and external providers are not included.

Rubric and level anchors

Editorial capability profile: Retrieval: 0/3; Organization: 1/3; Change / history: 1/3; Traceability: 1/3; Portability: 3/3; Simplicity: 3/3Clockwise from the top: Retrieval, Organization, Change / history, Traceability, Portability, Simplicity. Center is 0; rings are 1, 2, 3. Unknown values have no plotted point or connecting shape. Retrieval: How can an agent find the relevant stored context for a question? Organization: How is knowledge structured beyond a chronological conversation? Change / history: What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness. Traceability: What can you inspect to understand where recalled knowledge came from? Portability: What documented path lets you take the stored knowledge into another tool? Simplicity: Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?0123Retrieval: 0/3Retrieval0/3Organization: 1/3Organization1/3Change / history: 1/3Change /history1/3Traceability: 1/3Traceability1/3Portability: 3/3Portability3/3Simplicity: 3/3Simplicity3/3

Upsides

  • Essential preferences are always in context.
  • Ordinary local text is easy to inspect, edit and reuse.

Limits

  • Capacity is intentionally bounded; the agent must consolidate when full.
  • The prompt snapshot is frozen until the next session; tool responses show live edits.
Why these scores? Criteria and sources
  1. Retrieval 0/3

    How can an agent find the relevant stored context for a question?

    Both complete note stores are injected at session start; the notes mechanism does not perform query-selective retrieval. This favors always-available essentials, not corpus search.

    Sources: 1. raw.githubusercontent.com

  2. Organization 1/3

    How is knowledge structured beyond a chronological conversation?

    Two purpose-specific stores separate agent notes from user preferences; entries remain lightweight curated text.

    Sources: 1. raw.githubusercontent.com

  3. Change / history 1/3

    What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

    The memory tool explicitly adds, replaces and removes entries. Exact-duplicate rejection is useful but is not semantic reconciliation of changing facts.

    Sources: 1. raw.githubusercontent.com

  4. Traceability 1/3

    What can you inspect to understand where recalled knowledge came from?

    The actual text entries can be inspected and edited. The documented note format does not establish links back to the conversation that produced each fact.

    Sources: 1. raw.githubusercontent.com

  5. Portability 3/3

    What documented path lets you take the stored knowledge into another tool?

    The knowledge itself is MEMORY.md and USER.md in a named local directory; another text tool can read/copy it without a provider service.

    Sources: 1. raw.githubusercontent.com

  6. Simplicity 3/3

    Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

    These stores are built into Hermes and require no additional memory service; their bounded capacity still calls for occasional curation.

    Sources: 1. raw.githubusercontent.com

  1. 01WriteKeep a small set of durable notes.
  2. 02StoreMEMORY.md and USER.md remain readable files.
  3. 03SupplyA session-start snapshot enters the prompt.

What changes

Profile-local text files, agent-managed add/replace/remove, frozen session-start prompt snapshot; documented defaults 2,200 / 1,375 characters.

What you still own

Readable and correctable, but capacity forces curation. Writes persist immediately while prompt snapshot stays frozen. Not a full archive.

In Hermes

Profile-local text files, agent-managed add/replace/remove, frozen session-start prompt snapshot; documented defaults 2,200 / 1,375 characters.

Sources & published results

Published results

No comparable benchmark result shown. Conceptual baseline, not benchmarked here. Provider overview says always active, but detailed configuration allows disabling both built-in stores while retaining an external provider; additive is the default, not an absolute constraint.

Primary sources

Conceptual baseline, not benchmarked here. Provider overview says always active, but detailed configuration allows disabling both built-in stores while retaining an external provider; additive is the default, not an absolute constraint.

↑ Back to comparison
On-demand filesFiles + skillsExplicit, inspectable knowledge and procedures loaded on demand.

Why use this pattern

Explicit, inspectable knowledge and procedures loaded on demand.

Keeps: Knowledge and reusable procedures · Finds it through: Find → read the relevant file · Runs on: Local / your storage

Editorial capability profile

Assessed scope: Hermes local SKILL.md documents with referenced text files and progressive disclosure; a curated knowledge/procedure library, not arbitrary executable skill dependencies or automatic event ingestion.

Rubric and level anchors

Editorial capability profile: Retrieval: 1/3; Organization: 2/3; Change / history: 1/3; Traceability: 1/3; Portability: 3/3; Simplicity: 2/3Clockwise from the top: Retrieval, Organization, Change / history, Traceability, Portability, Simplicity. Center is 0; rings are 1, 2, 3. Unknown values have no plotted point or connecting shape. Retrieval: How can an agent find the relevant stored context for a question? Organization: How is knowledge structured beyond a chronological conversation? Change / history: What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness. Traceability: What can you inspect to understand where recalled knowledge came from? Portability: What documented path lets you take the stored knowledge into another tool? Simplicity: Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?0123Retrieval: 1/3Retrieval1/3Organization: 2/3Organization2/3Change / history: 1/3Change /history1/3Traceability: 1/3Traceability1/3Portability: 3/3Portability3/3Simplicity: 2/3Simplicity2/3

Upsides

  • Loads detailed procedures only when needed.
  • Readable, reusable documents support deliberate knowledge curation.

Limits

  • Usefulness depends on discovery descriptions and maintained instructions.
  • Document loading alone does not capture every conversation or reconcile changing facts.
Why these scores? Criteria and sources
  1. Retrieval 1/3

    How can an agent find the relevant stored context for a question?

    A catalogue names skills; the agent explicitly loads a skill or reference file. Progressive disclosure is targeted lookup, not a documented ranked memory search engine.

    Sources: 1. raw.githubusercontent.com

  2. Organization 2/3

    How is knowledge structured beyond a chronological conversation?

    Named skills, categories and reference directories structure reusable knowledge and procedures.

    Sources: 1. raw.githubusercontent.com

  3. Change / history 1/3

    What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

    The agent can modify or delete a skill and revise files. In this curated-library scope, keeping instructions current remains an explicit authoring task.

    Sources: 1. raw.githubusercontent.com

  4. Traceability 1/3

    What can you inspect to understand where recalled knowledge came from?

    Knowledge is inspectable in the document that supplies it. A referenced file is not automatically a citation to the original event or a verified derivation history.

    Sources: 1. raw.githubusercontent.com

  5. Portability 3/3

    What documented path lets you take the stored knowledge into another tool?

    Local documents follow the Agent Skills open standard; their text and references can be reused without a memory provider.

    Sources: 1. raw.githubusercontent.com

  6. Simplicity 2/3

    Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

    Loading is built in, but maintaining useful names, descriptions, references and current procedures adds editorial upkeep beyond two small note files.

    Sources: 1. raw.githubusercontent.com

  1. 01CodifyTurn a useful method into a file or skill.
  2. 02OrganizeKeep a small catalogue with inspectable references.
  3. 03LoadRead the relevant procedure when needed.

What changes

Documents and SKILL.md plus references; small catalog, full skills and individual files loaded when relevant. Procedural/curated knowledge rather than an automatic event store.

What you still own

Supports browsing and correction, but requires organization, discovery and upkeep; stale procedures can persist.

In Hermes

Documents and SKILL.md plus references; small catalog, full skills and individual files loaded when relevant. Procedural/curated knowledge rather than an automatic event store.

Sources & published results

Published results

No comparable benchmark result shown. Conceptual baseline; no universal tested score or standardized implementation.

Primary sources

Conceptual baseline; no universal tested score or standardized implementation.

↑ Back to comparison
Working contextContext compaction / summarizationKeep a long active conversation within a useful context budget.

Why use this pattern

Keep a long active conversation within a useful context budget.

Keeps: A summary of earlier conversation · Finds it through: Retained summary + recent messages · Runs on: Agent / model stack

Editorial capability profile

Assessed scope: Hermes default lossy ContextCompressor, including in-place archived-turn recovery through the separate session_search facility; not LCM or a cross-session fact database.

Rubric and level anchors

Editorial capability profile: Retrieval: 1/3; Organization: 0/3; Change / history: 0/3; Traceability: 1/3; Portability: 1/3; Simplicity: 3/3Clockwise from the top: Retrieval, Organization, Change / history, Traceability, Portability, Simplicity. Center is 0; rings are 1, 2, 3. Unknown values have no plotted point or connecting shape. Retrieval: How can an agent find the relevant stored context for a question? Organization: How is knowledge structured beyond a chronological conversation? Change / history: What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness. Traceability: What can you inspect to understand where recalled knowledge came from? Portability: What documented path lets you take the stored knowledge into another tool? Simplicity: Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?0123Retrieval: 1/3Retrieval1/3Organization: 0/3Organization0/3Change / history: 0/3Change /history0/3Traceability: 1/3Traceability1/3Portability: 1/3Portability1/3Simplicity: 3/3Simplicity3/3

Upsides

  • Keeps an active conversation usable within its context budget.
  • Original archived turns remain recoverable rather than being deleted.

Limits

  • Summarization is lossy; details may require an explicit recovery search.
  • It manages working context rather than replacing cross-session curated memory.
Why these scores? Criteria and sources
  1. Retrieval 1/3

    How can an agent find the relevant stored context for a question?

    The summary is supplied as working context, while archived original turns remain searchable through session_search. This credits the documented recovery path, not semantic memory retrieval.

    Sources: 1. raw.githubusercontent.com

  2. Organization 0/3

    How is knowledge structured beyond a chronological conversation?

    The organizing unit remains the current conversation: a summary plus retained turns, not a durable collection of typed knowledge.

    Sources: 1. raw.githubusercontent.com

  3. Change / history 0/3

    What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

    Compaction rewrites the live message list and swaps in a summarized middle. This refreshes working context, not individual durable facts with a correction lifecycle.

    Sources: 1. raw.githubusercontent.com

  4. Traceability 1/3

    What can you inspect to understand where recalled knowledge came from?

    The same session ID retains searchable pre-compaction turns. That provides a recovery route, but not a source link for every statement in the generated summary.

    Sources: 1. raw.githubusercontent.com

  5. Portability 1/3

    What documented path lets you take the stored knowledge into another tool?

    Documented recovery, recall or read tools expose stored content. This is limited portability under level 1: complete enumeration, bulk export and a reliable migration contract are not established in the assessed scope.

    Sources: 1. raw.githubusercontent.com

  6. Simplicity 3/3

    Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

    The lossy engine is the built-in default and fires automatically within an existing agent. Alternate plugin engines and separate memory servers are outside scope.

    Sources: 1. raw.githubusercontent.com

  1. 01AccumulateA conversation fills the working window.
  2. 02SummarizeCompress old content; retain a recent tail.
  3. 03ContinueWork from the summary and recover sources if needed.

What changes

Default lossy summary engine reduces old context while retaining a recent tail, identifiers and recovery pointers; pluggable engines may differ. Working-context management, not automatically a cross-session fact database.

What you still own

Summary omission/distortion and repeated summarization costs; transcript recovery is separate and still requires retrieval.

In Hermes

Default lossy summary engine reduces old context while retaining a recent tail, identifiers and recovery pointers; pluggable engines may differ. Working-context management, not automatically a cross-session fact database.

Sources & published results

Published results

No comparable benchmark result shown. Conceptual baseline; no universal tested score or standardized implementation.

Primary sources

Conceptual baseline; no universal tested score or standardized implementation.

↑ Back to comparison
Retrieval patternVector retrieval-augmented generation (RAG)Retrieve external evidence for a query instead of replaying a whole corpus.

Why use this pattern

Retrieve external evidence for a query instead of replaying a whole corpus.

Keeps: Embedded source passages · Finds it through: Query → nearest passages · Runs on: Your index / service

Editorial capability profile

Assessed scope: Basic operator-assembled dense-passage RAG: source passages, embeddings/index, top-k retrieval and an existing generator. Original RAG authors anchor the pattern; no specific database, managed stack, model training or added agentic/graph pipeline is assumed.

Rubric and level anchors

Editorial capability profile: Retrieval: 2/3; Organization: 1/3; Change / history: 1/3; Traceability: 2/3; Portability: Unknown; Simplicity: 1/3Clockwise from the top: Retrieval, Organization, Change / history, Traceability, Portability, Simplicity. Center is 0; rings are 1, 2, 3. Unknown values have no plotted point or connecting shape. Retrieval: How can an agent find the relevant stored context for a question? Organization: How is knowledge structured beyond a chronological conversation? Change / history: What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness. Traceability: What can you inspect to understand where recalled knowledge came from? Portability: What documented path lets you take the stored knowledge into another tool? Simplicity: Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?0123Retrieval: 2/3Retrieval2/3Organization: 1/3Organization1/3Change / history: 1/3Change /history1/3Traceability: 2/3Traceability2/3PortabilityUnknownSimplicity: 1/3Simplicity1/3

Upsides

  • Retrieves external passages rather than replaying an entire corpus.
  • The source index can be replaced without retraining the generator.

Limits

  • Chunking, indexing and updates remain implementation responsibilities.
  • A basic passage retriever is not automatically a user model or temporal fact lifecycle.
Why these scores? Criteria and sources
  1. Retrieval 2/3

    How can an agent find the relevant stored context for a question?

    A neural query retriever selects top-k passages from a dense index; this is ranked retrieval, without assuming hybrid or agentic extensions.

    Sources: 1. arxiv.org

  2. Organization 1/3

    How is knowledge structured beyond a chronological conversation?

    The index organizes knowledge as retrievable document passages; richer categories, entity graphs or lifecycle schemas are not part of this minimal pattern.

    Sources: 1. arxiv.org

  3. Change / history 1/3

    What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

    The authors explicitly describe replacing the non-parametric index to update knowledge. Automatic conversational fact reconciliation is not assumed.

    Sources: 1. arxiv.org

  4. Traceability 2/3

    What can you inspect to understand where recalled knowledge came from?

    The generator is conditioned on selected source passages from an explicit document index. Those passages provide inspectable evidence, not a guarantee of faithful answer citations.

    Sources: 1. arxiv.org

  5. Portability Unknown

    What documented path lets you take the stored knowledge into another tool?

    The generic pattern does not select a storage/export format. Portability depends on the chosen source store, index and embedding implementation.

    Sources: 1. arxiv.org

  6. Simplicity 1/3

    Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

    The operator must connect a passage corpus/index, a query retriever and a generator. Existing components can be used, but this is more assembly than configuring a managed memory client.

    Sources: 1. arxiv.org

  1. 01IndexSplit sources into passages and embed them.
  2. 02RetrieveFind relevant passages for a query.
  3. 03GroundSupply selected passages with the question.

What changes

Conceptual baseline: passage embeddings in an index, query embedding, top-k retrieval and context-conditioned generation. Original RAG combines a neural retriever/dense Wikipedia index with parametric generation.

What you still own

Known-question lookup and source inspection depend on chunking, embeddings/ranking and budget. Basic vector retrieval alone does not specify temporal updates, contradictions, user modeling, synthesis or exploration navigation.

In Hermes

Conceptual baseline: passage embeddings in an index, query embedding, top-k retrieval and context-conditioned generation. Original RAG combines a neural retriever/dense Wikipedia index with parametric generation.

Sources & published results

Published results

No comparable benchmark result shown. Conceptual baseline; no universal tested score or standardized implementation.

Primary sources

Conceptual baseline; no universal tested score or standardized implementation.

↑ Back to comparison
Structured memoryHindsightMemory should retrieve structured knowledge and higher-order observations from histories too large to put in a context window; BEAM at 10M is its chosen proof point.

Why choose it

Memory should retrieve structured knowledge and higher-order observations from histories too large to put in a context window; BEAM at 10M is its chosen proof point.

Keeps: Facts, entities, time and observations · Finds it through: Semantic + lexical + graph + temporal · Runs on: Cloud / local service

Editorial capability profile

Assessed scope: Self-hosted Hindsight API with local PostgreSQL and a configured structured-output LLM; current retain/recall API, including optional source-fact/chunk expansion. Hermes adapter is cited separately; Hindsight Cloud is not the simplicity scope.

Rubric and level anchors

Editorial capability profile: Retrieval: 3/3; Organization: 3/3; Change / history: 3/3; Traceability: 3/3; Portability: 2/3; Simplicity: 1/3Clockwise from the top: Retrieval, Organization, Change / history, Traceability, Portability, Simplicity. Center is 0; rings are 1, 2, 3. Unknown values have no plotted point or connecting shape. Retrieval: How can an agent find the relevant stored context for a question? Organization: How is knowledge structured beyond a chronological conversation? Change / history: What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness. Traceability: What can you inspect to understand where recalled knowledge came from? Portability: What documented path lets you take the stored knowledge into another tool? Simplicity: Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?0123Retrieval: 3/3Retrieval3/3Organization: 3/3Organization3/3Change / history: 3/3Change /history3/3Traceability: 3/3Traceability3/3Portability: 2/3Portability2/3Simplicity: 1/3Simplicity1/3

Upsides

  • Multiple retrieval strategies and linked facts support broad recall workflows.
  • Optional original chunks and contributing facts make synthesis inspectable.

Limits

  • Self-hosted operation adds service, database and model configuration.
  • Source expansions are optional; replacing a document reprocesses it rather than preserving that document version.
Why these scores? Criteria and sources
  1. Retrieval 3/3

    How can an agent find the relevant stored context for a question?

    Recall combines semantic, BM25, graph and temporal strategies, then fuses/reranks them. This is documented retrieval coverage, not evidence of superior answer accuracy.

    Sources: 1. hindsight.vectorize.io

  2. Organization 3/3

    How is knowledge structured beyond a chronological conversation?

    Retain extracts facts and links entities in a knowledge graph; observations synthesize contributing facts across memories.

    Sources: 1. hindsight.vectorize.io; 2. hindsight.vectorize.io

  3. Change / history 3/3

    What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

    Document replacement reprocesses facts; recall also distinguishes event dates from retention time and supports historical query timestamps and temporal windows. Windows influence ranking, not strict date filtering. Replaced document versions are not a complete archive.

    Sources: 1. hindsight.vectorize.io; 2. hindsight.vectorize.io

  4. Traceability 3/3

    What can you inspect to understand where recalled knowledge came from?

    Recall can return document/chunk IDs, original chunks and observations’ contributing source facts. This exposes source and derivation paths when the optional expansions are requested.

    Sources: 1. hindsight.vectorize.io

  5. Portability 2/3

    What documented path lets you take the stored knowledge into another tool?

    The assessed local route stores data in operator-controlled PostgreSQL. This provides database possession, not a provider-neutral schema or a verified lossless migration.

    Sources: 1. raw.githubusercontent.com

  6. Simplicity 1/3

    Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

    The self-hosted route runs an API/database and requires a structured-output LLM. A packaged local setup reduces assembly but does not remove service/model maintenance.

    Sources: 1. hindsight.vectorize.io; 2. raw.githubusercontent.com

  1. 01RetainExtract facts, entities and temporal links.
  2. 02ConnectKeep structured memories and derived observations.
  3. 03Recall / reflectRetrieve with several strategies; synthesize if requested.

What changes

Retain structured facts, resolve entities and temporal information; recall with semantic search, BM25, graph traversal and temporal retrieval, fuse and cross-encoder rerank. Reflect generates responses over recalled memory.

What you still own

A richer retention/retrieval pipeline brings an LLM and service/database operation requirement. Local storage does not establish that inference is local: the quickstart requires a structured-output LLM and illustrates hosted API keys. The benchmark article does not disclose enough run-level configuration to isolate architecture from model and token budgets.

In Hermes

Cloud or local embedded PostgreSQL; retain/recall/reflect tools; automatic full-turn retention includes tool calls and session document tracking. Default hybrid mode, recall_budget mid, auto_retain/auto_recall enabled, retain_async enabled.

Sources & published results

Published results

BEAM64.1 / 100

mean rubric score, presented on a 0–100 scale (not binary pass rate)

Tier: 10M · Edition: Hindsight; exact run edition/version unresolved · Model: not reported · Judge model: not reported · Configuration: not reported · Comparability: Article compiles published results, not proof of identical model/judge/harness budgets. Compare only with matched configuration and subset; do not promote as universal best.

Published by Vectorize / Hindsight. Read the result ↗

Primary sources

Exact model, judge model, model revision, ingestion settings, retrieval budget, dataset subset IDs and run commit for the April BEAM scores were not established from retrieved article pages. Null fields are intentional, not a claim that the vendor has never published them. The live Agent Memory Benchmark landing view is mutable, defaults to 100K and now shows additional Hindsight RAG results. It does not validate a matched multi-provider 10M rerun. No Hermes end-to-end benchmark, latency/cost test, security audit or unfamiliar-corpus exploration test was performed.

↑ Back to comparison
Peer / user modelingHonchoRecall is a means to continual identity modeling: infer what a person or other peer wants, believes and may do, rather than merely replaying stored facts.

Why choose it

Recall is a means to continual identity modeling: infer what a person or other peer wants, believes and may do, rather than merely replaying stored facts.

Keeps: Peer representations and conclusions · Finds it through: Context + semantic search + reasoning · Runs on: Cloud / self-hosted

Editorial capability profile

Assessed scope: Managed Honcho service for peer-centric memory, representations, conclusions and reasoning; Hermes Cloud adapter setup. Self-hosted FastAPI/local-stack operations are explicitly excluded from simplicity.

Rubric and level anchors

Editorial capability profile: Retrieval: 3/3; Organization: 3/3; Change / history: 2/3; Traceability: 1/3; Portability: 1/3; Simplicity: 2/3Clockwise from the top: Retrieval, Organization, Change / history, Traceability, Portability, Simplicity. Center is 0; rings are 1, 2, 3. Unknown values have no plotted point or connecting shape. Retrieval: How can an agent find the relevant stored context for a question? Organization: How is knowledge structured beyond a chronological conversation? Change / history: What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness. Traceability: What can you inspect to understand where recalled knowledge came from? Portability: What documented path lets you take the stored knowledge into another tool? Simplicity: Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?0123Retrieval: 3/3Retrieval3/3Organization: 3/3Organization3/3Change / history: 2/3Change /history2/3Traceability: 1/3Traceability1/3Portability: 1/3Portability1/3Simplicity: 2/3Simplicity2/3

Upsides

  • Models evolving people and peers rather than only storing isolated chunks.
  • Provides both prompt-ready context and explicit reasoning queries.

Limits

  • Derived representations remain interpretations, not a substitute for checking original messages.
  • Managed setup convenience does not describe the separate self-hosted stack.
Why these scores? Criteria and sources
  1. Retrieval 3/3

    How can an agent find the relevant stored context for a question?

    The documented surface combines semantic search/context with a reasoning query over peer knowledge. This earns the query-driven reasoning anchor, not a benchmark-quality claim.

    Sources: 1. raw.githubusercontent.com; 2. raw.githubusercontent.com

  2. Organization 3/3

    How is knowledge structured beyond a chronological conversation?

    Workspaces, peers, sessions and messages feed synthesized peer representations; multi-peer perspectives can model what one peer knows about another.

    Sources: 1. raw.githubusercontent.com

  3. Change / history 2/3

    What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

    Background processing updates peer representations from new messages/events. The inspected evidence does not establish a complete versioned history of every representation.

    Sources: 1. raw.githubusercontent.com

  4. Traceability 1/3

    What can you inspect to understand where recalled knowledge came from?

    Conclusions, peer cards, representations and session context are inspectable. This packet does not establish per-conclusion source-message lineage or a derivation audit trail.

    Sources: 1. raw.githubusercontent.com; 2. raw.githubusercontent.com

  5. Portability 1/3

    What documented path lets you take the stored knowledge into another tool?

    Conclusions and representations are exposed through documented APIs. That permits reading reusable knowledge, but does not establish a complete provider-neutral export/import.

    Sources: 1. raw.githubusercontent.com

  6. Simplicity 2/3

    Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

    The managed route uses a client and authentication rather than a user-operated database/server. Cadence and reasoning-depth settings still require application judgment.

    Sources: 1. raw.githubusercontent.com

  1. 01ObserveIngest messages exchanged by peers.
  2. 02ModelDerive representations and conclusions.
  3. 03ReasonUse context, search or the chat reasoning endpoint.

What changes

A server ingests peer messages, derives representations, optionally dreams over prior messages/reasoning to form conclusions, and exposes a tool-using research agent through its chat endpoint. Peers can represent humans, agents or other entities.

What you still own

Reasoning and tool overhead may consume as many or more tokens than full context on small datasets. Honcho explicitly says a few thousand tokens are usually better served directly in the context window. Temporal reasoning remains a weak point, and conventional recall benchmarks do not test the intended identity-modeling outcome.

In Hermes

Cloud or self-hosted. Base context includes session summary, representation and peer card; a separately paced dialectic adds reasoning. Default hybrid recall, asynchronous writes, contextCadence 1, dialecticCadence 2, dialecticDepth 1 and low base reasoning level.

Sources & published results

Published results

BEAM0.406 / 1

mean per-question rubric score (0–1)

Tier: 10M · Edition: published reproducibility configuration; result folder a1d689b · Model: claude-haiku-4-5 (chat endpoint, spelling as blog) · Ingestion model: gemini-2.5-flash-lite · Judge model: not reported · Judge protocol: BEAM paper rubric; per-question scores averaged, not binary pass rate · Configuration: {"dreaming": false, "message_batch_tokens": 4096} · Comparability: Historical own-blog series. Dashboard differs at larger tiers. Public reproducibility model stack is not managed-service stack.

Published by Plastic Labs / Honcho. Read the result ↗

BEAM0.409 / 1

mean per-question rubric score (0–1)

Tier: 10M · Edition: eval dashboard; footer updated December 2025 · Model: claude-haiku-4.5 (dialectic) · Ingestion model: gemini-2.5-flash-lite · Dreamer model: claude-haiku-4.5 · Judge model: not reported · Configuration: Dashboard says unless otherwise stated; exact run mapping and per-tier settings unresolved. Do not automatically apply blog settings to discrepant dashboard scores. · Comparability: Own dashboard series, preserved separately from own blog and Hindsight comparison. Not a new independent run.

Published by Plastic Labs / Honcho. Read the result ↗

LoCoMo89.9%

LLM-as-judge correct-answer percentage

Tier: 1,540 questions; average context about 16,000 tokens as described by Honcho · Model: claude-haiku-4-5 · Ingestion model: gemini-2.5-flash-lite · Judge model: not reported · Configuration: {"message_batch_tokens": 128, "dreaming": true} · Comparability: Uses LLM judging, not original LoCoMo token F1; category naming/distribution must be aligned before comparing with Mem0.

Published by Plastic Labs / Honcho. Read the result ↗

Primary sources

Own article and own eval dashboard disagree on 500K, 1M and 10M BEAM scores; record both rather than resolving silently. The Hindsight table matches Honcho’s article, not its dashboard. Exact BEAM judge model and dashboard run-to-commit mapping were not established. Blog links results folder a1d689b; individual configuration/result files were not inspected. The eval dashboard shows a LoCoMo Haiku baseline of 75.6 while the own blog states 83.9. Do not compute comparative uplift from these incompatible source views. Published benchmark configuration uses public models for reproducibility; managed Honcho uses a variety of models and tuning. No benchmark validates the exact Hermes defaults or broad identity-modeling thesis.

↑ Back to comparison
Fact memoryMem0Persistent memory should balance answer quality, context-token cost and latency, distilling compact facts rather than resending the whole conversation.

Why choose it

Persistent memory should balance answer quality, context-token cost and latency, distilling compact facts rather than resending the whole conversation.

Keeps: Compact facts, scoped to identities · Finds it through: Retrieve and rank relevant facts · Runs on: Platform / HTTP / OSS

Editorial capability profile

Assessed scope: Mem0 managed Platform v3 memory add/search/read APIs, with optional managed reranking; no automatic credit for OSS-only explain fields, optional graph editions, or the self-hosted dashboard. Hermes Platform adapter configuration is a separate integration boundary.

Rubric and level anchors

Editorial capability profile: Retrieval: 2/3; Organization: 2/3; Change / history: 3/3; Traceability: 1/3; Portability: 1/3; Simplicity: 2/3Clockwise from the top: Retrieval, Organization, Change / history, Traceability, Portability, Simplicity. Center is 0; rings are 1, 2, 3. Unknown values have no plotted point or connecting shape. Retrieval: How can an agent find the relevant stored context for a question? Organization: How is knowledge structured beyond a chronological conversation? Change / history: What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness. Traceability: What can you inspect to understand where recalled knowledge came from? Portability: What documented path lets you take the stored knowledge into another tool? Simplicity: Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?0123Retrieval: 2/3Retrieval2/3Organization: 2/3Organization2/3Change / history: 3/3Change /history3/3Traceability: 1/3Traceability1/3Portability: 1/3Portability1/3Simplicity: 2/3Simplicity2/3

Upsides

  • Structured facts, scoping and optional reranking provide configurable recall.
  • Additive storage preserves earlier facts rather than silently overwriting them during extraction.

Limits

  • Raw versus inferred inserts can duplicate facts; coexistence is not automatic contradiction resolution.
  • Platform behavior and convenience must not be projected onto OSS or self-hosted modes.
Why these scores? Criteria and sources
  1. Retrieval 2/3

    How can an agent find the relevant stored context for a question?

    Documented Platform search uses embeddings, scoped filters and optional reranking. Time-aware queries are also documented, but this conservative band does not infer a separate multi-path query planner from a feature name.

    Sources: 1. docs.mem0.ai

  2. Organization 2/3

    How is knowledge structured beyond a chronological conversation?

    LLM-extracted facts use user/agent/app/run identifiers and category metadata, forming scoped structured records rather than an untyped transcript.

    Sources: 1. docs.mem0.ai; 2. docs.mem0.ai

  3. Change / history 3/3

    What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

    Platform v3 keeps coexisting ADD-only facts and documents event-date interpretation, time-aware ranking and reference_date. These are historical/temporal mechanisms, not a guarantee of automatic correction or contradiction-resolution accuracy; temporal reasoning is not in the OSS SDK.

    Sources: 1. docs.mem0.ai; 2. docs.mem0.ai; 3. docs.mem0.ai

  4. Traceability 1/3

    What can you inspect to understand where recalled knowledge came from?

    Search returns memory text, metadata and timestamps; the Platform dashboard makes records inspectable. Those fields alone do not establish per-fact source-message lineage.

    Sources: 1. docs.mem0.ai; 2. docs.mem0.ai

  5. Portability 1/3

    What documented path lets you take the stored knowledge into another tool?

    Documented get_all/search surfaces expose stored memory objects. Moving them elsewhere still requires mapping the provider schema; managed API access is not OSS database ownership.

    Sources: 1. docs.mem0.ai; 2. docs.mem0.ai

  6. Simplicity 2/3

    Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

    The assessed route is a managed API with a client, credentials and identity/filter configuration. Operating an LLM/vector store in OSS mode is a different burden.

    Sources: 1. docs.mem0.ai; 2. raw.githubusercontent.com

  1. 01ExtractDistill messages into compact memories.
  2. 02ScopeAssociate facts with users, agents or runs.
  3. 03RetrieveReturn relevant facts under a chosen budget.

What changes

The April 2026 algorithm uses single-pass ADD-only extraction with deduplication and entity linking, then fuses semantic, keyword and entity signals. Current docs also describe asynchronously extracted temporal metadata and temporal scoring during retrieval. Old and new facts coexist instead of automatic replacement by extraction.

What you still own

Preserving history avoids destructive consolidation but leaves similar old/new facts competing at retrieval. Mem0 acknowledges long-range temporal reasoning, event ordering and multi-session reasoning weaknesses at 10M. Its published 2026 scores are managed-platform results with proprietary optimizations, not guaranteed OSS or Hermes scores.

In Hermes

Platform, HTTP self-hosted dashboard and in-process OSS modes; search/add/update/delete tools. Platform search reranking is off by default. OSS setup supports OpenAI/Ollama inference and embedding plus Qdrant/pgvector choices.

Sources & published results

Published results

LoCoMo92.5%

LLM-judged accuracy percentage

Tier: 1,540 questions, 10 dialogues · Edition: Mem0 managed platform, v3 memory pipeline; April 2026 algorithm series · Model: not reported · Judge model: not reported · Ingestion model: not reported · Configuration: {"retrieval_top_k": 200, "retrieval_calls": 1, "answers_per_query": 1, "agentic_loops": false, "mean_retrieval_context_tokens": 6956} · Methodology sources: ["https://docs.mem0.ai/core-concepts/memory-evaluation", "https://mem0.ai/blog/mem0-the-token-efficient-memory-algorithm", "https://raw.githubusercontent.com/mem0ai/memory-benchmarks/main/README.md"] · Uncertainty: Vendor states ±1 point confidence interval due to judge inconsistency; statistical construction not established here. · Comparability: Managed != OSS. Headline models/run revisions unresolved. BEAM 0.641/0.486 are average scores, while the same rows report pass rates 70.1%/50.5%.

Published by Mem0. Read the result ↗

LongMemEval94.4%

LLM-judged accuracy percentage

Tier: 500 questions · Edition: Mem0 managed platform, v3 memory pipeline; April 2026 algorithm series · Model: not reported · Judge model: not reported · Ingestion model: not reported · Configuration: {"retrieval_top_k": 200, "retrieval_calls": 1, "answers_per_query": 1, "agentic_loops": false, "mean_retrieval_context_tokens": 6787} · Methodology sources: ["https://docs.mem0.ai/core-concepts/memory-evaluation", "https://mem0.ai/blog/mem0-the-token-efficient-memory-algorithm", "https://raw.githubusercontent.com/mem0ai/memory-benchmarks/main/README.md"] · Uncertainty: Vendor states ±1 point confidence interval due to judge inconsistency; statistical construction not established here. · Comparability: Managed != OSS. Headline models/run revisions unresolved. BEAM 0.641/0.486 are average scores, while the same rows report pass rates 70.1%/50.5%.

Published by Mem0. Read the result ↗

BEAM0.486 / 1

mean rubric score (0–1), not pass rate

Tier: 10M; 200 questions · Edition: Mem0 managed platform, v3 memory pipeline; April 2026 algorithm series · Model: not reported · Judge model: not reported · Ingestion model: not reported · Configuration: {"retrieval_top_k": 200, "retrieval_calls": 1, "answers_per_query": 1, "agentic_loops": false, "mean_retrieval_context_tokens": 6914} · Methodology sources: ["https://docs.mem0.ai/core-concepts/memory-evaluation", "https://mem0.ai/blog/mem0-the-token-efficient-memory-algorithm", "https://raw.githubusercontent.com/mem0ai/memory-benchmarks/main/README.md"] · Uncertainty: Vendor states ±1 point confidence interval due to judge inconsistency; statistical construction not established here. · Comparability: Managed != OSS. Headline models/run revisions unresolved. BEAM 0.641/0.486 are average scores, while the same rows report pass rates 70.1%/50.5%.

Published by Mem0. Read the result ↗

Primary sources

Managed-platform answerer, judge and extraction model revisions are not identified for the headline runs in the retrieved pages. The runner README’s gpt-4o answerer/judge defaults are not evidence that headline runs used them; do not borrow the separate OSS table’s GPT-5 configuration. Live docs show LoCoMo category values 91.2/91.3/72.7/92.0; repository labels those averages across top_10/20/50/200, not the top_200 overall run. April article/research page instead display 94.6/95.4/82.3/92.5. Do not place these category rows under one supposedly matched score without checking run files. Own April 28 comparison article still reports LoCoMo 91.6 and LongMemEval 93.4, whereas current docs/research/runner report 92.5 and 94.4. Historical 66.88 and graph 68.44 from the 2025 paper are different algorithms and experimental setups, not current managed performance. Current product may include features introduced after the April algorithm; this bounded packet establishes that algorithm and retrieved current evaluation docs, not a complete latest feature audit. No independent reproduction or Hermes end-to-end testing was done.

↑ Back to comparison
Context filesystemOpenVikingTreat agent context as a browsable context database: resources, user memories and reusable experience belong in one filesystem-shaped hierarchy, loaded only when relevant.

Why choose it

Treat agent context as a browsable context database: resources, user memories and reusable experience belong in one filesystem-shaped hierarchy, loaded only when relevant.

Keeps: Resources, memories and skills · Finds it through: Hierarchy + semantic search; tiered reads · Runs on: Self-hosted server

Editorial capability profile

Assessed scope: Self-hosted OpenViking core context database with viking:// hierarchy, tiered reads and session memory extraction; configured server/model dependencies. Optional VikingBot compilation and hosted Studio convenience are excluded.

Rubric and level anchors

Editorial capability profile: Retrieval: 3/3; Organization: 2/3; Change / history: 2/3; Traceability: 1/3; Portability: 1/3; Simplicity: 1/3Clockwise from the top: Retrieval, Organization, Change / history, Traceability, Portability, Simplicity. Center is 0; rings are 1, 2, 3. Unknown values have no plotted point or connecting shape. Retrieval: How can an agent find the relevant stored context for a question? Organization: How is knowledge structured beyond a chronological conversation? Change / history: What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness. Traceability: What can you inspect to understand where recalled knowledge came from? Portability: What documented path lets you take the stored knowledge into another tool? Simplicity: Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?0123Retrieval: 3/3Retrieval3/3Organization: 2/3Organization2/3Change / history: 2/3Change /history2/3Traceability: 1/3Traceability1/3Portability: 1/3Portability1/3Simplicity: 1/3Simplicity1/3

Upsides

  • A browsable hierarchy makes resources and memories deliberately navigable.
  • Session extraction can merge knowledge and support selective tiered loading.

Limits

  • Self-hosting and derived summaries introduce operational upkeep.
  • Virtual paths are not proof of native-file portability or fact-level provenance.
Why these scores? Criteria and sources
  1. Retrieval 3/3

    How can an agent find the relevant stored context for a question?

    Vector search finds candidate directories and explores within them; session-aware search planning and L0/L1/L2 reads provide staged context selection.

    Sources: 1. raw.githubusercontent.com; 2. raw.githubusercontent.com

  2. Organization 2/3

    How is knowledge structured beyond a chronological conversation?

    Resources, memories and skills live under a named hierarchy with per-directory abstracts/overviews and typed memory categories. Optional compiled knowledge graphs are outside this score.

    Sources: 1. raw.githubusercontent.com; 2. raw.githubusercontent.com

  3. Change / history 2/3

    What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

    Session commits start extraction; candidates are compared with existing memories for creation, merging or skipping. This is explicit automated curation, not a claim of guaranteed factual consistency.

    Sources: 1. raw.githubusercontent.com

  4. Traceability 1/3

    What can you inspect to understand where recalled knowledge came from?

    Stable viking:// URIs and tiered reads expose stored knowledge. The inspected core evidence does not establish a fact-by-fact link to its originating session passage.

    Sources: 1. raw.githubusercontent.com; 2. raw.githubusercontent.com

  5. Portability 1/3

    What documented path lets you take the stored knowledge into another tool?

    Browse/read tools expose knowledge by virtual URI. That supports extraction through the interface, but a virtual filesystem is not evidence of directly reusable native files or a full export.

    Sources: 1. raw.githubusercontent.com; 2. raw.githubusercontent.com

  6. Simplicity 1/3

    Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

    The operator initializes, validates and runs an OpenViking server before connecting Hermes, and maintains its configured processing dependencies.

    Sources: 1. raw.githubusercontent.com

  1. 01IngestUnify resources, memories and reusable experience.
  2. 02OrganizeL0 abstracts → L1 overviews → L2 full content.
  3. 03ExploreLocate a directory, then selectively read its contents.

What changes

A virtual viking:// filesystem unifies resources, memories and skills. L0 abstracts and L1 overviews guide selective L2 reads. Vector search locates directories then explores within their scope. Session commits trigger background extraction; candidate memories can be created, merged or skipped.

What you still own

Analyst inference: inspectable hierarchy and selective loading buy control at the cost of operating a context server plus embedding/VLM dependencies and maintaining derived summaries. Vendor HotpotQA results expose a budget tradeoff: higher top-K increases both reported accuracy and returned tokens; that is not a universal free accuracy improvement.

In Hermes

Self-hosted server connection; semantic search, tiered read, hierarchical browse, explicit remember/forget and resource ingestion.

Sources & published results

Published results

LoCoMo82.86%

Hermes + OpenViking accuracy (%)

Publication date: 2026-05-29 · Run date: not reported · Edition: OpenViking 0.3.22 (version and memory models from current README; not commit-pinned to report) · Dataset: LoCoMo; exact scored subset not specified in report. Current Hermes runner references locomo10.json. · Agent: Hermes Agent · Answer model: not reported · Memory model: Doubao 2.0 Pro VLM · Embedding model: Doubao-embedding-vision-251215 · Judge model: not reported · Baseline: Hermes native memory · Retrieval budget: not reported · Repetitions: not reported · Warning: Report does not identify whether Hermes OpenViking result used e2e or preingest path. Current runner documents both; do not infer either.

Published by OpenViking Team. Read the result ↗

LoCoMo33.38%

Hermes native memory accuracy (%)

Publication date: 2026-05-29 · Run date: not reported · Edition: OpenViking 0.3.22 (version and memory models from current README; not commit-pinned to report) · Dataset: LoCoMo; exact scored subset not specified in report. Current Hermes runner references locomo10.json. · Agent: Hermes Agent · Answer model: not reported · Memory model: Doubao 2.0 Pro VLM · Embedding model: Doubao-embedding-vision-251215 · Judge model: not reported · Baseline: Hermes native memory · Retrieval budget: not reported · Repetitions: not reported · Warning: Report does not identify whether Hermes OpenViking result used e2e or preingest path. Current runner documents both; do not infer either.

Published by OpenViking Team. Read the result ↗

Primary sources

No benchmark was run independently. Published Hermes LoCoMo answer model, judge, precise subset, suite, context budget, repetitions and run date remain unresolved. Current README supplies VLM/embedding names and version, but was not pinned to the May report. Report has some inconsistent secondary percentage claims (for example ClawWork hourly token reduction); those were not promoted to comparison claims. Provider documentation describes capabilities beyond the Hermes adapter. License, hosting cost, privacy and deployment suitability were not audited.

↑ Back to comparison
Evolving memory graphSupermemoryMake memory an evolving understanding of users and entities, not a pile of retrieved chunks: track changing facts and relationships while retaining source context, independently of the answer model.

Why choose it

Make memory an evolving understanding of users and entities, not a pile of retrieved chunks: track changing facts and relationships while retaining source context, independently of the answer model.

Keeps: Facts, relationships and profiles · Finds it through: Semantic recall + profile context · Runs on: Cloud / configured endpoint

Editorial capability profile

Assessed scope: Managed Supermemory memory/document API and profiles, including /v4/memories/list history/source fields. Excludes SMFS filesystem/cache reconciliation and the self-hosted local binary; Hermes integration may expose only a subset of API options.

Rubric and level anchors

Editorial capability profile: Retrieval: 2/3; Organization: 3/3; Change / history: 3/3; Traceability: 3/3; Portability: 1/3; Simplicity: 2/3Clockwise from the top: Retrieval, Organization, Change / history, Traceability, Portability, Simplicity. Center is 0; rings are 1, 2, 3. Unknown values have no plotted point or connecting shape. Retrieval: How can an agent find the relevant stored context for a question? Organization: How is knowledge structured beyond a chronological conversation? Change / history: What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness. Traceability: What can you inspect to understand where recalled knowledge came from? Portability: What documented path lets you take the stored knowledge into another tool? Simplicity: Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?0123Retrieval: 2/3Retrieval2/3Organization: 3/3Organization3/3Change / history: 3/3Change /history3/3Traceability: 3/3Traceability3/3Portability: 1/3Portability1/3Simplicity: 2/3Simplicity2/3

Upsides

  • Version/history fields and source references expose evolving knowledge.
  • Profiles and document retrieval can share one scoped context pool.

Limits

  • API-visible graph relationships do not alone establish graph-traversal retrieval.
  • SMFS behavior and local deployment control are separate from the assessed managed API.
Why these scores? Criteria and sources
  1. Retrieval 2/3

    How can an agent find the relevant stored context for a question?

    The API offers semantic memory/document search and profile context; the Hermes adapter documents hybrid memory/document selection. This is not credited as a graph-traversal query planner merely because storage is a graph.

    Sources: 1. supermemory.ai; 2. raw.githubusercontent.com

  2. Organization 3/3

    How is knowledge structured beyond a chronological conversation?

    Memory relationships explicitly include updates, extends and derives; container-scoped profiles connect information beyond independent chunks.

    Sources: 1. supermemory.ai; 2. supermemory.ai

  3. Change / history 3/3

    What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

    Memory entries expose versions, latest/forgotten state, update/extend/derive links and history. This directly supports the versioned/historical-state anchor.

    Sources: 1. supermemory.ai

  4. Traceability 3/3

    What can you inspect to understand where recalled knowledge came from?

    The list API explicitly includes source documents and update history, with memory relation fields. This supports inspecting source references and how a memory changed, without claiming every inferred statement is correct.

    Sources: 1. supermemory.ai

  5. Portability 1/3

    What documented path lets you take the stored knowledge into another tool?

    Paginated document and memory APIs expose records, history and source references. An application can read them for migration; the assessed API is not an ordinary filesystem or a documented neutral export format.

    Sources: 1. supermemory.ai; 2. supermemory.ai

  6. Simplicity 2/3

    Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

    Managed use requires a client, API key and container/profile configuration, not operating a local memory server. SMFS and self-hosted setup are deliberately not blended into this judgment.

    Sources: 1. raw.githubusercontent.com

  1. 01IngestExtract memories from new information.
  2. 02EvolveRelate, update and extend facts and profiles.
  3. 03RecallRetrieve relevant memories for the answer model.

What changes

Contextual atomic memories retain links to raw chunks, temporal grounding and update/extend/derive relationships. Profiles summarize durable and recent knowledge. The broader SMFS product exposes a Supermemory container as a filesystem with semantic path search, a local cache and asynchronous cloud reconciliation.

What you still own

Analyst inference: automated extraction, profiles and inferred relations reduce manual organization but require inspection of derived facts and update semantics. The newer SMFS report itself records a token-efficiency/accuracy tradeoff: lower aggregate pass rate despite gains at the largest corpus. Filesystem writes and cloud search visibility are eventually consistent; a local-looking mount is not proof of local-only processing.

In Hermes

Graph API integration with semantic recall, profiles, explicit memory tools and session-boundary /v4/conversations ingest; cloud or configured self-hosted endpoint. No claim that this mounts SMFS.

Sources & published results

Published results

xAFS53.8%

Total-token reduction versus filesystem-only (%)

Publication date: 2026-05 · Run date: not reported · Date precision: month, from report BibTeX · Dataset: xAFS, vendor-created synthetic cross-context personal corpora; 110 questions, 13 corpora, 5–9,988 files as reported · Models: ["Claude Code / claude-opus-4.7 [max]", "Codex CLI / gpt-5.5 [xhigh]"] · Judge model: Gemini 2.5 Pro, temperature 0, semantic-equivalence judging · Protocol: Same base prompt; filesystem-only shell vs SMFS mount plus semantic smfs grep and tool-discovery hint in CLAUDE.md / AGENTS.md · Repetitions: Report says each harness run twice; 440 trials per condition. Figure caption instead says 220 per condition; unresolved. · Cost scope: Agent input/output tokens across answering turns including tool payloads; full ingestion/subscription infrastructure cost not established · Integration scope: SMFS filesystem product evaluation, not Hermes Supermemory plugin · Retrieval budget: Interactive tool use; fixed top-K/context cap not given in retrieved protocol

Published by Supermemory Research. Read the result ↗

xAFSfilesystem only 92.7% / SMFS 91.4%

Aggregate pass rate (%)

Publication date: 2026-05 · Run date: not reported · Date precision: month, from report BibTeX · Dataset: xAFS, vendor-created synthetic cross-context personal corpora; 110 questions, 13 corpora, 5–9,988 files as reported · Models: ["Claude Code / claude-opus-4.7 [max]", "Codex CLI / gpt-5.5 [xhigh]"] · Judge model: Gemini 2.5 Pro, temperature 0, semantic-equivalence judging · Protocol: Same base prompt; filesystem-only shell vs SMFS mount plus semantic smfs grep and tool-discovery hint in CLAUDE.md / AGENTS.md · Repetitions: Report says each harness run twice; 440 trials per condition. Figure caption instead says 220 per condition; unresolved. · Cost scope: Agent input/output tokens across answering turns including tool payloads; full ingestion/subscription infrastructure cost not established · Integration scope: SMFS filesystem product evaluation, not Hermes Supermemory plugin · Retrieval budget: Interactive tool use; fixed top-K/context cap not given in retrieved protocol · Rounding note: Preserve displayed rates; vendor reports -1.4pp, which is not the subtraction of displayed rounded values.

Published by Supermemory Research. Read the result ↗

Historical report · mixed/ambiguous metric labeling

The original report URL now redirects. Its metric labels conflict; current SMFS results above concern a different product and benchmark.

LongMemEval_s95%

Overall score in LLM-as-Judge table (%)

Historical report; mixed/ambiguous metric labeling. Original URL now redirects and extraction versions disagree. The report calls its headline “95% overall Recall@15” but labels the table “LLM-as-Judge Evaluation”; we do not resolve that contradiction. Publication date: not reported · Run date: not reported · Dataset: LongMemEval_s, 500 questions; 115k+ token histories · Ingestion: Session-by-session rather than the paper’s round-by-round ingestion · Answer model: gpt-4o · Judge model: gpt-4o, question-specific prompts from LongMemEval · Retrieval budget: Recall@15 with aggregation; report says about 720 mean tokens · Repetitions: not reported · Source status: Extraction returned full report, but isolated live browser redirects this URL to https://supermemory.ai/#research. Treat as previously published vendor report of unresolved currency, not current live benchmark page. · Metric warning: Narrative calls 95% Recall@15 while table is headed LLM-as-Judge Evaluation. Metric equivalence is not established.

Published by Supermemory Research. Original report (now redirects) ↗

LongMemEval_s84.6%

Overall score in LLM-as-Judge table (%)

Historical report; mixed/ambiguous metric labeling. Original URL now redirects and extraction versions disagree. The report calls its headline “95% overall Recall@15” but labels the table “LLM-as-Judge Evaluation”; we do not resolve that contradiction. Publication date: not reported · Run date: not reported · Dataset: LongMemEval_s, 500 questions; 115k+ token histories · Ingestion: Session-by-session rather than the paper’s round-by-round ingestion · Answer model: gpt-5 · Judge model: gpt-4o, question-specific prompts from LongMemEval · Retrieval budget: Recall@15 with aggregation; report says about 720 mean tokens · Repetitions: not reported · Source status: Extraction returned full report, but isolated live browser redirects this URL to https://supermemory.ai/#research. Treat as previously published vendor report of unresolved currency, not current live benchmark page. · Metric warning: Narrative calls 95% Recall@15 while table is headed LLM-as-Judge Evaluation. Metric equivalence is not established.

Published by Supermemory Research. Original report (now redirects) ↗

LongMemEval_s85.2%

Overall score in LLM-as-Judge table (%)

Historical report; mixed/ambiguous metric labeling. Original URL now redirects and extraction versions disagree. The report calls its headline “95% overall Recall@15” but labels the table “LLM-as-Judge Evaluation”; we do not resolve that contradiction. Publication date: not reported · Run date: not reported · Dataset: LongMemEval_s, 500 questions; 115k+ token histories · Ingestion: Session-by-session rather than the paper’s round-by-round ingestion · Answer model: gemini-3-pro · Judge model: gpt-4o, question-specific prompts from LongMemEval · Retrieval budget: Recall@15 with aggregation; report says about 720 mean tokens · Repetitions: not reported · Source status: Extraction returned full report, but isolated live browser redirects this URL to https://supermemory.ai/#research. Treat as previously published vendor report of unresolved currency, not current live benchmark page. · Metric warning: Narrative calls 95% Recall@15 while table is headed LLM-as-Judge Evaluation. Metric equivalence is not established.

Published by Supermemory Research. Original report (now redirects) ↗

Primary sources

LongMemEval publication/run dates absent, report URL now redirects, and 95% is labeled differently in narrative versus judge table; preserve all model-specific rows rather than a single score. xAFS report says 440 trials per condition while its figure caption says 220; dataset family counts and displayed rounded deltas also need reconciliation before downstream recomputation. xAFS is vendor-authored synthetic evidence, not independent validation; personas change with corpus size, so it is not a fully controlled scaling experiment. SMFS and Hermes graph-API plugin are different integration surfaces. Do not apply filesystem benchmark gains to Hermes by default.

↑ Back to comparison
Curated knowledge treeByteRoverPay the cost of understanding once: curate persistent, inspectable project knowledge before storage, then reuse and share the structured context instead of reconstructing it from raw files every turn.

Why choose it

Pay the cost of understanding once: curate persistent, inspectable project knowledge before storage, then reuse and share the structured context instead of reconstructing it from raw files every turn.

Keeps: Portable project knowledge · Finds it through: Query a curated context tree · Runs on: Local CLI / optional sync

Editorial capability profile

Assessed scope: Catalogue-aligned local-first ByteRover CLI/Markdown context tree: V3 root docs plus the CLI 2.0 curation/retrieval description, BYOK and no cloud sync. Not V4 Desktop/spaces, cloud version control or the later proposed HTML format.

Rubric and level anchors

Editorial capability profile: Retrieval: 3/3; Organization: 2/3; Change / history: 2/3; Traceability: 1/3; Portability: 3/3; Simplicity: 2/3Clockwise from the top: Retrieval, Organization, Change / history, Traceability, Portability, Simplicity. Center is 0; rings are 1, 2, 3. Unknown values have no plotted point or connecting shape. Retrieval: How can an agent find the relevant stored context for a question? Organization: How is knowledge structured beyond a chronological conversation? Change / history: What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness. Traceability: What can you inspect to understand where recalled knowledge came from? Portability: What documented path lets you take the stored knowledge into another tool? Simplicity: Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?0123Retrieval: 3/3Retrieval3/3Organization: 2/3Organization2/3Change / history: 2/3Change /history2/3Traceability: 1/3Traceability1/3Portability: 3/3Portability3/3Simplicity: 2/3Simplicity2/3

Upsides

  • Local Markdown knowledge is inspectable and reusable with ordinary tools.
  • Curation plus tiered file search supports persistent project context.

Limits

  • Curation still depends on a configured model/provider and maintained knowledge.
  • Live docs differ between V3 CLI and V4 Desktop surfaces; these scores apply only to the named CLI scope.
Why these scores? Criteria and sources
  1. Retrieval 3/3

    How can an agent find the relevant stored context for a question?

    Documented CLI retrieval escalates from cache/full-text lookup to LLM-powered file search, using the structured tree rather than one similarity lookup.

    Sources: 1. www.byterover.dev; 2. raw.githubusercontent.com

  2. Organization 2/3

    How is knowledge structured beyond a chronological conversation?

    LLM curation organizes modular Markdown files by domain, topic and subtopic. This is an explicit reusable hierarchy without assuming a typed knowledge graph.

    Sources: 1. www.byterover.dev

  3. Change / history 2/3

    What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

    The curator synthesizes and arranges incoming knowledge into the existing context-tree representation. Cloud version-control history is not credited to this local-only scope.

    Sources: 1. www.byterover.dev

  4. Traceability 1/3

    What can you inspect to understand where recalled knowledge came from?

    The curated Markdown files are human-readable and inspectable. The retrieved evidence does not establish source-event citations for every synthesized statement.

    Sources: 1. docs.byterover.dev; 2. www.byterover.dev

  5. Portability 3/3

    What documented path lets you take the stored knowledge into another tool?

    The actual context tree is ordinary local Markdown described as human-readable and git-friendly; its text can be used without the ByteRover service.

    Sources: 1. docs.byterover.dev

  6. Simplicity 2/3

    Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

    The CLI and a chosen LLM provider/model must be configured; the local route does not require a ByteRover cloud account or a separately managed memory server.

    Sources: 1. docs.byterover.dev

  1. 01CurateExtract useful project knowledge upfront.
  2. 02KeepMaintain a local, inspectable knowledge tree.
  3. 03QueryLoad curated context; inspect original sources as needed.

What changes

LLM-enabled curation synthesizes a domain → topic → subtopic context tree. The CLI searches structured files using cache/full-text paths before LLM search when needed. Vendor docs describe local Markdown storage, BYOK or built-in LLM use, and optional cloud collaboration/version control. A separate later experiment proposes HTML typed memory elements.

What you still own

Analyst inference: portable, editable files and optional cloud sync improve owner control, but curation quality and freshness become dependencies and local storage does not imply local LLM inference. The HTML experiment improves average reported accuracy/cost yet substantially worsens p95 query latency; a format experiment is not proof of current release behavior.

In Hermes

brv CLI adapter with query/curate/status, profile-scoped local tree and extraction before context compression; optional vendor cloud sync.

Sources & published results

Published results

LoCoMo (ByteRover HTML vs Markdown format experiment)HTML 90.77% / Markdown 90.51%

Accuracy (%)

Publication date: 2026-05-29 · Run date: not reported · Dataset: LoCoMo; vendor reports 1,982 questions across 11 conversations, every category · Answer model: not reported · Curation model: not reported · Judge model: not reported · Protocol: Same agent queries two isolated context trees, HTML versus Markdown · Retrieval budget: not reported · Repetitions: not reported · Edition: HTML-format experiment; post says HTML default will be released soon, not evidence it is already default · Integration scope: Vendor format comparison, not Hermes plugin benchmark · Warning: Model, judge and exact dataset revision not disclosed in retrieved article; no variance.

Published by ByteRover. Read the result ↗

LoCoMo (ByteRover HTML vs Markdown format experiment)HTML 4311 ms / Markdown 259 ms

p95 query latency (milliseconds)

Publication date: 2026-05-29 · Run date: not reported · Dataset: LoCoMo; vendor reports 1,982 questions across 11 conversations, every category · Answer model: not reported · Curation model: not reported · Judge model: not reported · Protocol: Same agent queries two isolated context trees, HTML versus Markdown · Retrieval budget: not reported · Repetitions: not reported · Edition: HTML-format experiment; post says HTML default will be released soon, not evidence it is already default · Integration scope: Vendor format comparison, not Hermes plugin benchmark · Warning: Model, judge and exact dataset revision not disclosed in retrieved article; no variance.

Published by ByteRover. Read the result ↗

Primary sources

CLI 2.0 release advertises 92.19% overall retrieval accuracy, 95.4% single-hop, 94.4% temporal and 85.1% multi-hop, but retrieved text does not identify the benchmark, models or protocol. Kept as an underspecified vendor headline, not a comparable result and not a zero. The fuller HTML/Markdown LoCoMo experiment provides numbers and dataset size, but not answer/curation/judge models, run date, repetitions or exact cost boundary. Current docs describe Markdown, while May HTML experiment says a default change is forthcoming. Actual shipped default was not verified. Custom Next.js evaluation is a four-query author-run workflow comparison, not a standardized memory benchmark. Headline 83% is token reduction, not 83% API-cost savings. No retrieved benchmark evaluates ByteRover through the Hermes adapter.

↑ Back to comparison
Managed memory APIRetainDBPersistent user/agent memory can grow into an askable company brain backed by connected source material.

Why choose it

Persistent user/agent memory can grow into an askable company brain backed by connected source material.

Keeps: User, session, task and project records · Finds it through: Hybrid search + reranking · Runs on: Cloud service

Editorial capability profile

Assessed scope: Managed RetainDB user/session/agent/project memory as described by its memory-model docs and pinned Hermes adapter. Hybrid search is integration-documented; Company Brain-wide features and benchmark-only chronological full-context retrieval are not generalized.

Rubric and level anchors

Editorial capability profile: Retrieval: 3/3; Organization: 2/3; Change / history: 1/3; Traceability: 1/3; Portability: 1/3; Simplicity: 2/3Clockwise from the top: Retrieval, Organization, Change / history, Traceability, Portability, Simplicity. Center is 0; rings are 1, 2, 3. Unknown values have no plotted point or connecting shape. Retrieval: How can an agent find the relevant stored context for a question? Organization: How is knowledge structured beyond a chronological conversation? Change / history: What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness. Traceability: What can you inspect to understand where recalled knowledge came from? Portability: What documented path lets you take the stored knowledge into another tool? Simplicity: Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?0123Retrieval: 3/3Retrieval3/3Organization: 2/3Organization2/3Change / history: 1/3Change /history1/3Traceability: 1/3Traceability1/3Portability: 1/3Portability1/3Simplicity: 2/3Simplicity2/3

Upsides

  • Distinct user, session, task and project scopes fit different continuity needs.
  • The adapter documents hybrid search alongside memory and file tools.

Limits

  • Async writes and pending visibility require attention when recalling fresh information.
  • Export, fact-level lineage and automatic reconciliation are not established by the inspected memory-model/adapter docs.
Why these scores? Criteria and sources
  1. Retrieval 3/3

    How can an agent find the relevant stored context for a question?

    The primary Hermes adapter documentation explicitly describes vector + BM25 + reranking. This is documented multi-path coverage, not independently verified backend behavior or the separate benchmark configuration.

    Sources: 1. raw.githubusercontent.com

  2. Organization 2/3

    How is knowledge structured beyond a chronological conversation?

    Official docs separate user, session, agent-task and project knowledge; the adapter adds typed remember operations. These are structured scopes rather than a documented cross-record reasoning graph.

    Sources: 1. retaindb.com; 2. raw.githubusercontent.com

  3. Change / history 1/3

    What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

    Remember/forget and file operations let an agent explicitly store or remove knowledge. The phrase delta compression alone does not establish automatic conflict reconciliation or historical validity.

    Sources: 1. raw.githubusercontent.com

  4. Traceability 1/3

    What can you inspect to understand where recalled knowledge came from?

    Memory/profile context and stored files can be inspected through documented tools. This packet does not establish a source link for every retrieved memory fact.

    Sources: 1. retaindb.com; 2. raw.githubusercontent.com

  5. Portability 1/3

    What documented path lets you take the stored knowledge into another tool?

    Documented recovery, recall or read tools expose stored content. This is limited portability under level 1: complete enumeration, bulk export and a reliable migration contract are not established in the assessed scope.

    Sources: 1. retaindb.com; 2. raw.githubusercontent.com

  6. Simplicity 2/3

    Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

    The managed Hermes route requires an account and API key, with no separate server/database for the user to operate.

    Sources: 1. raw.githubusercontent.com

  1. 01RememberSend scoped messages, records or files.
  2. 02MaintainOrganize durable memory for the project.
  3. 03RetrieveSearch or build context; benchmark instead dumps all memories.

What changes

Vendor docs separate user, session, agent-task memory and project knowledge. Hermes plugin advertises hybrid vector + BM25 + reranking, seven memory types and delta compression, with profile/search/context/remember/forget/file tools. Published LongMemEval run instead passes all extracted memories chronologically.

What you still own

Managed infrastructure reduces integration work but adds API, governance and plan dependencies. Oracle/full-memory-dump results do not establish production top-k recall or low-context cost.

In Hermes

Bundled cloud adapter with profile, hybrid search, context, remember, forget and file tools. Published oracle evaluation does not test these retrieval defaults.

Sources & published results

Published results

LongMemEval79%

overall accuracy

LongMemEval oracle split; up to 50 questions per category, six categories stated but five named categories displayed; overall labeled Published / in progress. March 2026. gpt-5.4 answer, temperature 0, full chronological memory dump; gpt-5.4-mini judge. Extractor conflict: methodology says gpt-5.4, pipeline says gpt-5.4-mini. Not a Hermes integration benchmark.

Published by RetainDB / Bad theory Labs Inc.. Read the result ↗

Primary sources

No independent reproduction or Hermes-specific evaluation. Six categories stated, five named categories displayed; up-to-50-per-category and in-progress wording prevent treating 79% as a verified complete standard 500-question run. Official extractor model conflicts: gpt-5.4 vs gpt-5.4-mini. Other vendors appearing on RetainDB comparison pages are not represented by those second-hand scores here. Delta compression entitlement differs between pricing cards and table; confirm desired plan.

↑ Back to comparison
Local Hermes pluginHolographic (Hermes plugin)Local structured recall through facts, entities, algebraic combinations and feedback-trained trust complements always-on notes.

Why choose it

Local structured recall through facts, entities, algebraic combinations and feedback-trained trust complements always-on notes.

Keeps: Facts, entities and feedback trust · Finds it through: FTS5 + lexical / optional HRR ranking · Runs on: Local SQLite

Editorial capability profile

Assessed scope: Pinned bundled Hermes Holographic plugin with local SQLite/FTS5, default auto_extract=false, and optional NumPy HRR algebra; no learned embedding service or external memory server.

Rubric and level anchors

Editorial capability profile: Retrieval: 2/3; Organization: 3/3; Change / history: 1/3; Traceability: 1/3; Portability: 2/3; Simplicity: 3/3Clockwise from the top: Retrieval, Organization, Change / history, Traceability, Portability, Simplicity. Center is 0; rings are 1, 2, 3. Unknown values have no plotted point or connecting shape. Retrieval: How can an agent find the relevant stored context for a question? Organization: How is knowledge structured beyond a chronological conversation? Change / history: What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness. Traceability: What can you inspect to understand where recalled knowledge came from? Portability: What documented path lets you take the stored knowledge into another tool? Simplicity: Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?0123Retrieval: 2/3Retrieval2/3Organization: 3/3Organization3/3Change / history: 1/3Change /history1/3Traceability: 1/3Traceability1/3Portability: 2/3Portability2/3Simplicity: 3/3Simplicity3/3

Upsides

  • Dependency-light local storage with inspectable facts and entity links.
  • Explicit corrections and helpful/unhelpful feedback expose agent control.

Limits

  • HRR token composition is not learned semantic embedding retrieval.
  • Automatic extraction is off by default; timestamps and trust scores do not supply source provenance.
Why these scores? Criteria and sources
  1. Retrieval 2/3

    How can an agent find the relevant stored context for a question?

    FTS5/BM25 candidates are reranked with Jaccard similarity, optional HRR similarity and trust weighting. This is scored lexical/compositional retrieval, not learned semantic search or an independently queried graph pipeline.

    Sources: 1. raw.githubusercontent.com; 2. raw.githubusercontent.com; 3. raw.githubusercontent.com

  2. Organization 3/3

    How is knowledge structured beyond a chronological conversation?

    The schema links multiple facts to explicit entities through fact_entities, alongside categories and tags. This credits cross-record entity organization, not a claim of semantic understanding.

    Sources: 1. raw.githubusercontent.com

  3. Change / history 1/3

    What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

    fact_store provides explicit update/remove/contradict operations and feedback changes trust. Default regex extraction is off; these controls do not establish automatic semantic reconciliation or version history.

    Sources: 1. raw.githubusercontent.com; 2. raw.githubusercontent.com

  4. Traceability 1/3

    What can you inspect to understand where recalled knowledge came from?

    Fact IDs, content, categories, tags and timestamps are inspectable locally. The shown fact schema does not carry originating transcript references or a derivation history.

    Sources: 1. raw.githubusercontent.com

  5. Portability 2/3

    What documented path lets you take the stored knowledge into another tool?

    Facts and entity links reside in a local SQLite database at a configured path. Bulk possession is straightforward, but HRR blobs and the provider schema still need interpretation for another system.

    Sources: 1. raw.githubusercontent.com; 2. raw.githubusercontent.com

  6. Simplicity 3/3

    Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

    The bundled plugin uses always-available SQLite with no required extra package/service; NumPy is optional. Enabling the provider is the documented setup.

    Sources: 1. raw.githubusercontent.com

  1. 01StoreKeep local facts with entities and metadata.
  2. 02RankFTS5 candidates, lexical / optional HRR similarity, trust.
  3. 03Use / rateRecall facts and feed back usefulness.

What changes

SQLite facts with FTS5/BM25 candidates, Jaccard + optional HRR similarity and trust weighting. HRR encodes deterministic token atoms, not learned semantic embeddings. fact_store and fact_feedback tools; optional session-end regex extraction defaults off; built-in add writes can be mirrored.

What you still own

Inspectable local data and no memory-service API; quality depends on lexical/entity representation and trust hygiene. NumPy is needed for HRR algebra but keyword fallback remains. HRR and named reason/contradict actions are not evidence of general semantic reasoning. Retrieved local facts may still be sent to a remote main model.

In Hermes

Bundled local plugin. fact_store and fact_feedback tools; optional session-end regex extraction defaults off. HRR uses deterministic token atoms, not learned semantic embeddings.

Sources & published results

Published results

No comparable benchmark result shown. No numerical LoCoMo, LongMemEval or comparable accuracy benchmark found in reviewed plugin README/source. This is not a standalone vendor: Hermes plugin source is the primary voice and credits original work to dusterbloom. No independent accuracy, scale or latency test performed.

Primary sources

No numerical LoCoMo, LongMemEval or comparable accuracy benchmark found in reviewed plugin README/source. This is not a standalone vendor: Hermes plugin source is the primary voice and credits original work to dusterbloom. No independent accuracy, scale or latency test performed.

↑ Back to comparison
Agent execution memoryMemoriRemember what agents do, not just what they say; structure history into compact assets for intentional recall.

Why choose it

Remember what agents do, not just what they say; structure history into compact assets for intentional recall.

Keeps: Semantic triples, summaries and traces · Finds it through: Explicit recall of structured context · Runs on: Hermes Cloud plugin

Editorial capability profile

Assessed scope: Memori Cloud through separately installed hermes-memori at the pinned repository snapshot: completed-turn/tool-trace capture and structured recall. Not Memori OSS/BYODB, local database ownership, or benchmark pre-augmented assets.

Rubric and level anchors

Editorial capability profile: Retrieval: 2/3; Organization: 2/3; Change / history: 2/3; Traceability: 1/3; Portability: 1/3; Simplicity: 2/3Clockwise from the top: Retrieval, Organization, Change / history, Traceability, Portability, Simplicity. Center is 0; rings are 1, 2, 3. Unknown values have no plotted point or connecting shape. Retrieval: How can an agent find the relevant stored context for a question? Organization: How is knowledge structured beyond a chronological conversation? Change / history: What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness. Traceability: What can you inspect to understand where recalled knowledge came from? Portability: What documented path lets you take the stored knowledge into another tool? Simplicity: Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?0123Retrieval: 2/3Retrieval2/3Organization: 2/3Organization2/3Change / history: 2/3Change /history2/3Traceability: 1/3Traceability1/3Portability: 1/3Portability1/3Simplicity: 2/3Simplicity2/3

Upsides

  • Captures completed execution/tool context, not only conversational text.
  • Explicit recall and scoped summaries let the agent choose when to use history.

Limits

  • Capture is asynchronous and limited to completed, non-interrupted turns.
  • Cloud recall is not evidence of BYODB control, portable export or per-fact source citations.
Why these scores? Criteria and sources
  1. Retrieval 2/3

    How can an agent find the relevant stored context for a question?

    Recall uses documented multi-dimensional ranking over source/signal, recency, frequency, scope and importance, with explicit query/scoping tools. These ranking factors do not establish independent multi-path retrieval.

    Sources: 1. raw.githubusercontent.com

  2. Organization 2/3

    How is knowledge structured beyond a chronological conversation?

    Entity/project/process/session scopes and allowed source/signal pairs organize typed facts, decisions, constraints and outcomes. This adapter schema is not evidence of a traversable knowledge graph.

    Sources: 1. raw.githubusercontent.com

  3. Change / history 2/3

    What mechanisms update knowledge or use its history? 3 means history/time support—not automatic correctness.

    Completed turns are automatically captured into structured memory and asynchronously refreshed derived context. This credits automatic maintenance, not proven version retention or correctness of contradiction resolution.

    Sources: 1. raw.githubusercontent.com

  4. Traceability 1/3

    What can you inspect to understand where recalled knowledge came from?

    Structured memories and summaries can be inspected and filtered by source/signal classification. Here source denotes a memory type, not necessarily a link to the originating tool result.

    Sources: 1. raw.githubusercontent.com

  5. Portability 1/3

    What documented path lets you take the stored knowledge into another tool?

    Documented recovery, recall or read tools expose stored content. This is limited portability under level 1: complete enumeration, bulk export and a reliable migration contract are not established in the assessed scope.

    Sources: 1. raw.githubusercontent.com

  6. Simplicity 2/3

    Within the stated deployment, how much extra setup and maintenance does this add to an already working agent?

    The route requires installing/registering hermes-memori, an API key and an entity ID. No user-operated memory database is required for this Cloud scope.

    Sources: 1. raw.githubusercontent.com

  1. 01CaptureIngest completed turns and available tool context.
  2. 02AugmentBuild structured memories and summaries.
  3. 03RecallAgent explicitly requests memory within a chosen scope.

What changes

Advanced Augmentation creates semantic triples and summaries. Hermes integration captures completed, non-interrupted turns with available execution/tool context asynchronously and scopes by entity/project/process/session. Agent-controlled recall uses explicit tools; integration describes proprietary multi-dimensional ranking. Generic SDK/BYODB offerings are distinct from Hermes Cloud integration.

What you still own

Compact structured recall can reduce prompt size but extraction can omit/misclassify evidence. Background writes are not immediate, and agent-selected recall can be skipped. Cloud trace storage requires scope and privacy controls. Offline benchmark does not validate live tool-execution capture.

In Hermes

Separately installed hermes-memori plugin for Memori Cloud. Completed turns sync asynchronously; recall is agent-controlled. Its own README says it does not mirror or modify MEMORY.md / USER.md. Generic BYODB offerings are a different product surface.

Sources & published results

Published results

LoCoMo87.0%

overall LLM-judge accuracy

LoCoMo categories 1–4, adversarial excluded; average of three rounds per results page. Notebook defaults: GPT-4.1-mini answer and judge, temperature 0, EmbeddingGemma-300M, FAISS + BM25 with RRF, top_k 10. Pre-generated augmented memories and summaries. Not a Hermes execution benchmark; not run by this research.

Published by Memori Labs. Read the result ↗

LoCoMo721 tokens

mean tokens added to context

LoCoMo categories 1–4, adversarial excluded; average of three rounds per results page. Notebook defaults: GPT-4.1-mini answer and judge, temperature 0, EmbeddingGemma-300M, FAISS + BM25 with RRF, top_k 10. Pre-generated augmented memories and summaries. Not a Hermes execution benchmark; not run by this research. Full-context baseline: 26,031 tokens. Excludes ingestion, extraction, answer output and hosting costs.

Published by Memori Labs. Read the result ↗

Primary sources

Not independently reproduced; public notebooks start from pre-generated augmented assets, not an audited from-scratch extraction pipeline. Mean-context-token result excludes extraction, memory service and output-token costs. web_extract returned older 81.95% / 1,294-token text; direct origin HTML and pinned repository agree on 87.0% / 721. Retrieval discrepancy recorded; cause unknown. Hermes guide lists five tools; current integration README additionally lists memori_compaction. No installation performed to settle runtime version. Generic Hermes provider lifecycle mentions mirrored writes, but Memori explicitly says it does not mirror or modify MEMORY.md / USER.md. Plugin-specific docs govern.

↑ Back to comparison

04 / THE MECHANISM, IN ONE EXAMPLE

Keep the information.
Change what you carry.

“We changed the API timeout to 30 seconds.” Later: “Which timeout should the client use?” Here are three ways to carry that decision forward.

01 / KEEP IN CONTEXT

Carry the conversation

Earlier messagestimeout = 30 secondsMore conversationToday’s question

The fact is directly available while it remains in the supplied context. More history consumes more of the working window.

Constraint → context is bounded; a summary can omit a detail.

02 / WRITE IT DOWN

Save a file. Read it back.

timeout = 30 seconds↓ writeapi-decisions.md↓ find + readFact + today’s question

A durable file can be enough. The agent needs a rule for writing it and a way to locate the right passage later.

Work left → maintain the file and its retrieval instructions.

03 / USE A MEMORY LAYER

Represent. Retrieve. Recheck.

timeout = 30 seconds↓ retainFact · source · project · time↓ retrieve for this questionSelected fact + question

A provider may extract facts, build profiles, organize files or connect entities. Different representations help with different questions.

Work left → check scope, freshness and the answer against evidence.

When the timeout changes again, update the saved decision and check which version applies.

WANT THE WHY?

See what breaks
when knowledge changes.

The Morrow Works story follows one company through scattered files, conflicting rules, access boundaries and forgetting. Follow how each memory system handles those problems.

Read the story
Logo & icon sources

Logos are used for editorial identification only. Source and license notices are preserved below. These copyright terms do not imply general trademark rights or endorsement.

Mem0

Original asset ↗ · MIT ↗

Rendering only: removed fixed width/height; added accessibility attributes and CSS class; namespaced local IDs if present. Geometry and colors preserved.

MIT License

Copyright (c) 2023-2026 Taranjeet Singh

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Supermemory

Original asset ↗ · MIT ↗

Rendering only: removed fixed width/height; added accessibility attributes and CSS class; namespaced local IDs if present. Geometry and colors preserved.

MIT License

Copyright (c) 2025 supermemory

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

ByteRover

Original asset ↗ · Elastic-2.0 ↗

Rendering only: removed fixed width/height; added accessibility attributes and CSS class; namespaced local IDs if present. Geometry and colors preserved.

Elastic License 2.0 (ELv2)

Acceptance
By using the software, you agree to all of the terms and conditions below.

Copyright License
The licensor grants you a non-exclusive, royalty-free, worldwide, non-sublicensable, non-transferable license to use, copy, distribute, make available, and prepare derivative works of the software, in each case subject to the limitations and conditions below.

Limitations
You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.

You may not move, change, disable, or circumvent the license key functionality in the software, and you may not remove or obscure any functionality in the software that is protected by the license key.

You may not alter, remove, or obscure any licensing, copyright, or other notices of the licensor in the software. Any use of the licensor's trademarks is subject to applicable law.

Patents
The licensor grants you a license, under any patent claims the licensor can license, or becomes able to license, to make, have made, use, sell, offer for sale, import and have imported the software, in each case subject to the limitations and conditions in this license. This license does not cover any patent claims that you cause to be infringed by modifications or additions to the software. If you or your company make any written claim that the software infringes or contributes to infringement of any patent, your patent license for the software granted under these terms ends immediately. If your company makes such a claim, your patent license ends immediately for work on behalf of your company.

Notices
You must ensure that anyone who gets a copy of any part of the software from you also gets a copy of these terms.

If you modify the software, you must include in any modified copies of the software prominent notices stating that you have modified the software.

No Other Rights
These terms do not imply any licenses other than those expressly granted in these terms.

Termination
If you use the software in violation of these terms, such use is not licensed, and your licenses will automatically terminate. If the licensor provides you with a notice of your violation, and you cease all violation of this license no later than 30 days after you receive that notice, your licenses will be reinstated retroactively. However, if you violate these terms after such reinstatement, any additional violation of these terms will cause your licenses to terminate automatically and permanently.

No Liability
As far as the law allows, the software comes as is, without any warranty or condition, and the licensor will not be liable to you for any damages arising out of these terms or the use or nature of the software, under any kind of legal claim.

Definitions
The _licensor_ is the entity offering these terms, and the _software_ is the software the licensor makes available under these terms, including any portion of it.

_you_ refers to the individual or entity agreeing to these terms.

_your company_ is any legal entity, sole proprietorship, or other kind of organization that you work for, plus all organizations that have control over, are under the control of, or are under common control with that organization. _control_ means ownership of substantially all the assets of an entity, or the power to direct its management and policies by vote, contract, or otherwise. Control can be direct or indirect.

_your licenses_ are all the licenses granted to you for the software under these terms.

_use_ means anything you do with the software requiring one of your licenses.

_trademark_ means trademarks, service marks, and similar rights.

Hindsight

Original asset ↗ · MIT ↗

Cropped the complete symbol from the official wordmark image at [0,2,185,137]; decoded and re-encoded PNG without source metadata. Drawing and colors unchanged.

MIT License

Copyright (c) 2025 Vectorize AI, Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Lucide interface icons

Lucide icon library ↗ · Pinned ISC / MIT notices ↗

Selected static SVGs bundled inline; no runtime package or CDN. Official shapes retained, size/class and decorative accessibility attributes supplied by this website.

ISC License

Copyright (c) 2026 Lucide Icons and Contributors

Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

---

The following Lucide icons are derived from the Feather project:

airplay, alert-circle, alert-octagon, alert-triangle, aperture, arrow-down-circle, arrow-down-left, arrow-down-right, arrow-down, arrow-left-circle, arrow-left, arrow-right-circle, arrow-right, arrow-up-circle, arrow-up-left, arrow-up-right, arrow-up, at-sign, calendar, cast, check, chevron-down, chevron-left, chevron-right, chevron-up, chevrons-down, chevrons-left, chevrons-right, chevrons-up, circle, clipboard, clock, code, columns, command, compass, corner-down-left, corner-down-right, corner-left-down, corner-left-up, corner-right-down, corner-right-up, corner-up-left, corner-up-right, crosshair, database, divide-circle, divide-square, dollar-sign, download, external-link, feather, frown, hash, headphones, help-circle, info, italic, key, layout, life-buoy, link-2, link, loader, lock, log-in, log-out, maximize, meh, minimize, minimize-2, minus-circle, minus-square, minus, monitor, moon, more-horizontal, more-vertical, move, music, navigation-2, navigation, octagon, pause-circle, percent, plus-circle, plus-square, plus, power, radio, rss, search, server, share, shopping-bag, sidebar, smartphone, smile, square, table-2, tablet, target, terminal, trash-2, trash, triangle, tv, type, upload, x-circle, x-octagon, x-square, x, zoom-in, zoom-out

The MIT License (MIT) (for the icons listed above)

Copyright (c) 2013-present Cole Bemis

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.