Key Takeaways

• EverMind uses Apache 2.0 licensing and requires no MongoDB, Elasticsearch, or Redis, keeping its storage footprint narrow.

• EverMind reaches 83.00% accuracy on LongMemEval and delivers approximately 10× lower cost than naive full-context approaches.

• Papr Memory combines keyword search, semantic vector search, and graph traversal, making relationship-rich retrieval its clearest architectural differentiator.

• Papr's self-hosted code is AGPL-3.0 licensed, while EverOS uses Apache 2.0. Teams modifying and offering Papr over a network should review the AGPL's source-availability terms with counsel.

• EverMind reports around 10× lower token cost than a full-context baseline for its published setup; that is not a measured cost advantage over Papr or a property of the separate MSA research model.

• EverMind suits agent developers needing portable, inspectable, benchmark-tested long-term memory; Papr Memory suits teams needing graph-rich retrieval with multi-tenant isolation.

• Both products offer cloud and self-hosted paths. EverOS uses Markdown records with SQLite and LanceDB indexes; Papr combines vector, keyword, and graph retrieval across a more service-heavy self-hosted stack.

At a Glance

EverMind vs Papr Memory: The Verdict First

Choose EverMind when editable Markdown memories, Apache 2.0 licensing, and a lean self-hosted stack matter most. Choose Papr Memory when graph relationships and its hybrid retrieval approach are central to your application. Both also offer managed cloud paths.

This article is published by the EverMind team. EverMind's benchmark and cost figures are first-party results; Papr's architecture and deployment details come from its current documentation. Neither vendor's published result is a controlled head-to-head test here.

EverMind stands out for file-native memory and permissive licensing; Papr stands out for graph-aware retrieval and a managed offering. Both address long-term agent memory, but their storage dependencies and data-access patterns differ enough to warrant a pilot on your own workload.

At-a-Glance: EverMind vs Papr Memory Head-to-Head

EverOS offers editable files and a relatively small local storage stack. Papr offers graph-aware lookup and both hosted and self-hosted editions. The practical differences are deployment complexity, license obligations, and whether your workload benefits from graph relationships.

Papr documents a compatible API spanning its cloud and hosted-on-your-own deployments, but moving data still requires export, import, and validation; its cloud guide offers migration assistance for those steps (source). EverMind's platform likewise documents the same SDK and file format across its cloud and locally-hosted options. Markdown export is available from the cloud edition (source).

How We Evaluated These AI Memory Systems

We compared EverOS's public repository, product and benchmark pages with Papr's deployment, architecture, and license documentation. The recommendation reflects those published capabilities, not a claim that both products were run through an identical hands-on test.

EverMind publishes LoCoMo, LongMemEval, HaluMem, latency, and token-efficiency figures for its own setup. We treat them as first-party reference points. We did not use undocumented daily-use observations as evidence of a performance advantage over Papr.

Papr's documentation describes hybrid graph, vector, and keyword retrieval; its self-hosted edition is AGPL-3.0 licensed and lists MongoDB, Qdrant, Neo4j, Redis, Parse Server, and FastAPI. Papr also publishes a STaRK result, though that benchmark is not directly comparable with EverMind's named memory tests.

EverMind builds this product and has a natural point of view. To make the comparison useful, we distinguish documented features from vendor-reported results and call out differences in benchmark tasks rather than claiming a direct accuracy winner.

The Two Systems Compared, Ranked by Fit

This section walks through both platforms in ranked order, leading with the one that fits the broadest agent-memory needs: EverMind.

1. EverMind (EverOS)

EverOS keeps canonical agent memories as readable Markdown files, with SQLite and LanceDB indexes for retrieval. Its Run→Case→Skill workflow turns useful agent experience into reusable skills. MSA is a separate EverMind research architecture, not the EverOS storage engine described here.

For teams that switch agents or revisit long-running work, the appeal is direct control over stored memories: files can be inspected, edited, and versioned with ordinary tools. The Run→Case→Skill workflow develops reusable context over time; the number of available skills should be checked against the current Skill Hub, not assumed from an unsourced built-in count.

EverMind's design carries no dependency on MongoDB, Elasticsearch, or Redis. That constraint keeps the storage footprint narrow. It also eliminates the operational overhead those services introduce.

On long-horizon tests, EverMind reaches 83.00% accuracy on LongMemEval — a result that reflects end-to-end fidelity over extended conversation histories, not just single-turn recall. The cost profile is strong. Token efficiency runs at roughly ~10× lower cost compared to naive full-context approaches, which matters at production scale where context windows are the primary cost driver.

EverMind also offers EverOS Cloud, so teams do not have to self-host. Its self-hosted path asks teams to manage their own infrastructure and model-provider settings; the managed path trades some control for less operations work.

Best fit for EverMind: Agent developers, researchers, and teams running multi-agent pipelines who need portable, inspectable, cost-efficient long-term storage with benchmark-tested recall.

Worst fit for EverMind: Teams whose applications depend on graph-native relationships and prefer Papr's managed graph retrieval model over file-native memory.

2. Papr Memory

Papr Memory is a graph-aware layer designed for production AI setups. Its design combines hybrid lookup methods — blending semantic vector search with graph traversal — to surface contextually related records that pure vector stores miss.

Papr Memory supports multi-tenant isolation, which makes it suitable for SaaS products where each end-user's data must remain strictly separated (source). Deployment is available as a managed cloud service or as a locally-hosted stack under an AGPL license.

The graph-aware design is Papr's clearest architectural differentiator. Relationships between nodes are first-class objects, not inferred at query time. That structure benefits use cases where the connections between facts matter as much as the facts themselves — for example, tracking entity relationships over long customer histories.

Papr's AGPL-3.0 license deserves review when teams modify the self-hosted code and make it available over a network. The exact obligations depend on use and distribution; commercial licensing may be an option for teams that need different terms.

Papr Memory's managed cloud path lowers the operational barrier compared to a fully self-managed stack. The trade-off is that graph-rich lookups at scale carry infrastructure costs that a managed service abstracts but does not eliminate.

Best fit for Papr Memory: Teams building production AI agents that need graph-rich retrieval with hybrid search. Multi-tenant isolation and the flexibility to move between managed cloud and a self-hosted open-source stack matter here too.

Worst fit for Papr Memory: Projects that require permissive licensing for proprietary deployment, or workflows where portability and human-readable inspection of stored facts are operational requirements.

Architecture: File-Native Memory vs Graph-Rich Retrieval

EverOS stores canonical memories as Markdown files with SQLite and LanceDB indexes. Papr organizes ingested information through vector, keyword, and graph retrieval. MSA research explores a different learned-memory architecture and should not be presented as EverOS's production retrieval path.

EverOS indexes and retrieves stored memories; its vector and structured indexes are part of the design. MSA research is about learned long-context memory and should be evaluated separately from a deployed EverOS stack. Papr's graph is another explicit retrieval layer rather than an equivalent in-model mechanism.

The architectures answer different needs: EverOS favors inspectable records and reusable agent experience, while Papr emphasizes relationships among ingested entities. Compare them on a representative set of questions, not by assuming either architecture always recalls more.

EverOS can connect recalled passages to editable memory files. Papr's graph represents relationships among records in a different way. Neither approach automatically eliminates the need to assess index freshness, provenance, and answer quality in production.

Papr Memory takes a different architectural position. It ingests content — web pages, PDFs, chat threads, structured records — and builds a persistent knowledge graph from those inputs. Fetching combines vector similarity search with graph traversal, a hybrid approach that improves recall over pure embedding lookup. The "brain" in Papr's design lives in the graph store, which is queryable but external to any weights.

EverOS's retrieval still depends on its Markdown corpus and indexes; Papr's depends on its ingested content and graph. Both therefore need sound ingestion and update practices. The difference is how the memory is represented and inspected after it is stored.

Scaling Long-Lived Agent Memory

Long-running agents need to retrieve a small, useful slice of an expanding history. EverOS does this with file-backed indexes and its memory lifecycle. Papr uses graph, vector, and keyword retrieval over an expanding corpus. Test both under your expected data volume.

EverMind reports about 10× lower token cost than a full-context baseline for its published setup. That result reflects selective memory use, not a direct cost comparison with Papr or a claim about a fixed maximum context window. Index size, model choice, and retrieval volume still shape operating cost.

Papr Memory's approach works differently. Papr builds a knowledge graph from ingested content and runs hybrid queries across that graph at search time. Scaling here means expanding graph coverage: more ingested documents, more nodes, more edges. Quality at high volume depends on graph construction fidelity and ingestion completeness, which introduces operational overhead as content grows.

At scale, token spend is only part of the bill. EverOS operators pay for compute, storage, models, and maintenance; Papr operators also need to account for its documented services or a managed plan. A matched workload is the reliable way to compare total cost.

Teams prioritizing inspectable memory files may prefer EverOS. Teams whose queries depend on rich entity relationships may prefer Papr's graph. Neither storage design removes the need for testing retrieval quality as history grows.

Benchmarks & Verifiable Recall: Beyond Marketing Claims

EverMind publishes LoCoMo, LongMemEval, and HaluMem results. Papr publishes a STaRK graph-retrieval result; it is a different task and metric, so the vendor numbers cannot be ranked as if they came from the same test.

EverMind's score on the long-conversation test is 93.05% overall accuracy, measured on the test that tests recall across extended multi-session dialogues. LongMemEval performance reaches 83.00%, covering single-session long-context lookup tasks. HaluMem recall stands at 90.04%, targeting hallucination-resistant recall specifically. Latency for lookups is under 500 ms at p95, meaning agents receive grounded answers within a sub-second window even on long recall horizons.

EverMind's figures are traceable by design. Every recall event resolves to a source `.md` file stored in the local Markdown layer, so any recalled fact can be audited back to its origin document. That auditability is structural. It's not a post-hoc logging feature — the storage stack (Local Markdown + SQLite + LanceDB) keeps the provenance chain intact without requiring external infrastructure.

Published recall scores are useful starting points, but a production choice should reflect the content and questions your agents actually handle. EverMind reports results on named memory benchmarks; Papr publishes a STaRK result. Because these test different tasks, teams should run a matched pilot before drawing a retrieval-quality conclusion.

Papr's STaRK result provides evidence for its graph-oriented retrieval, while EverMind's published figures cover different memory benchmarks. A fair choice requires asking the same workload-specific questions of both systems; neither vendor's published score alone resolves the comparison.

Integration & Developer Experience: GitHub, APIs, and Agent Frameworks

Choosing between EverMind and Papr Memory means picking one of two adoption paths, with EverMind offering the faster route for self-hosted or local-first stacks. EverOS ships under Apache 2.0 and stores all data in local Markdown files, SQLite, and LanceDB with zero dependency on MongoDB, Elasticsearch, or Redis. The full source is available at the EverOS GitHub repository. Papr Memory offers a managed cloud service alongside an AGPL-licensed self-hosted option, with REST APIs and SDKs that target teams who prefer a hosted, graph-backed service.

EverOS offers API, SDK, and MCP routes for agents that need persistent memory. Teams can connect supported runtimes without operating a separate MongoDB, Elasticsearch, or Redis service, though model-provider configuration and integration work still depend on their stack.

The local EverOS stack includes LanceDB for vector indexing. That removes a separate managed vector database from the default setup, but it does not prove every agent integration can be reduced to a single initialization call.

EverOS can run its memory files and indexes on infrastructure a team controls. That avoids several external database services in the default stack, but model-provider calls, network policy, backups, and operating costs still need explicit configuration. Papr's self-hosted stack has more documented services to operate.

Papr publishes REST APIs and client SDKs for agent integration. EverOS exposes its own API, SDK, and MCP surface. Both can support application integrations; the choice is between EverOS's file-native memory and Papr's graph-rich retrieval and deployment model.

Pricing Face-Off: Open-Source vs Hosted

EverOS vs Papr Memory pricing splits along a clear line: hosting it yourself versus managed cloud. Licensed under Apache 2.0, EverOS lets teams host it on their own infrastructure at zero licensing cost. Papr Memory offers a managed cloud tier alongside an AGPL-licensed self-hosted option. Papr does not publicly document list prices for its cloud plans, so no direct figure is stated here.

EverOS's local Markdown, SQLite, and LanceDB stack does not require MongoDB, Elasticsearch, or Redis, which can simplify operations. EverMind's reported token savings are against a full-context baseline, not a measured cost comparison with Papr. Include compute, models, storage, and support in a realistic budget.

Papr's managed cloud reduces infrastructure work. Its AGPL-3.0 self-hosted option has no proprietary software-license fee, but operators still pay for infrastructure and must assess any license obligations relevant to modified network services.

Apache 2.0 gives EverOS a permissive code license and its Markdown files are straightforward to inspect. Papr's AGPL-3.0 terms apply to its self-hosted code; the implications for a particular commercial use should be assessed rather than treated as a blanket restriction on customer data or every deployment.

Who Should Choose EverMind

Three kinds of developers and teams fit EverMind best. It suits developers who orchestrate multiple agents or switch between them. Examples include Claude Code, Codex, and Cursor — plus teams needing self-hosted, auditable, portable storage under a permissive open-source license.

There are 3 primary profiles that match EverMind's design:

1. Multi-Agent and Switching-Agent Developers

Multi-agent developers running concurrent or alternating tools need a store that persists and transfers across boundaries without re-indexing. EverMind's EverOS architecture keeps state in local Markdown, SQLite, and LanceDB files, so any agent reads the same store without a shared cloud dependency.

2. Teams Requiring Self-Hosted, Auditable Memory

Some teams face strict governance requirements around their information. They deploy EverMind entirely on private infrastructure. The Apache 2.0 license permits commercial use and modification without copyleft obligations, and every record stays in portable local files that internal auditors inspect directly.

3. Enterprises Integrating with CRM, ERP, or Data Warehouses

Enterprise teams can connect EverOS memory to internal systems through custom integrations; prebuilt CRM or ERP connectors should not be assumed. The storage stack carries no MongoDB, Elasticsearch, or Redis dependency, which reduces the surface area that enterprise security reviews evaluate.

EverMind also has a managed cloud option. Papr may be a better fit when a team's priority is managed, graph-rich retrieval rather than direct control over Markdown memory files.

Who Should Choose Papr Memory

Teams that need a graph-rich, hybrid data layer with strong lookup capabilities should consider Papr Memory. Its documented product supports multi-tenant isolation and offers the flexibility to run either a managed cloud service or an independently hosted open-source deployment.

There are 4 profiles that align well with this platform:

• Teams building production AI agents that require hybrid search combining vector lookup and graph traversal across structured stores

• Organizations with strict tenant isolation requirements that need per-user or per-workspace boundaries enforced at the infrastructure level

• Engineering teams that prefer Papr's documented graph-rich stack, including Neo4j, Qdrant, MongoDB, and Redis, over a local Markdown-plus-SQLite approach

• Buyers who want deployment optionality, moving between Papr's managed cloud offering and the AGPL-licensed self-hosted version without re-architecting their integration

Papr Memory suits teams where graph relationship traversal is a first-class requirement, not an add-on.

Switching or Migrating Between EverMind and Papr Memory

File portability determines how easily you can switch between these two tools. EverMind stores everything as editable, diffable Markdown files on your local filesystem — the file format reduces storage lock-in, though migration still requires metadata mapping and retrieval checks. Moving information between agents, frameworks, or deployments means copying or versioning those files directly, with no proprietary export step required.

Migrating from Papr Memory into EverOS follows 3 concrete steps:

1. Export your existing memory objects from Papr Memory using its REST API.

2. Re-ingest the exported material into the platform, which indexes it across Local Markdown, SQLite, and LanceDB automatically.

3. Validate recall against your target queries before decommissioning the Papr instance.

Papr's graph relationships may require explicit mapping during migration; do not assume every edge will be reconstructed automatically from exported text. Move representative records first, then validate relationship and recall behavior before retiring the old system.

Moving in the opposite direction, from EverMind to Papr Memory, requires exporting the Markdown files and submitting them through Papr's ingestion endpoint. The format is human-readable, so the content stays inspectable and auditable at every step of that transfer.

EverMind's Apache 2.0 license means no contractual restriction governs how you move, copy, or redistribute your stored information. Teams running self-hosted deployments retain full filesystem access throughout any migration window.

Where to go from here

Choose between EverOS and Papr based on file ownership, retrieval design, licensing, and deployment. EverOS gives teams editable, Apache 2.0-licensed memory files; Papr offers graph-rich lookup with cloud and AGPL-3.0 self-hosted paths. Published benchmarks test different tasks, so a matched pilot matters.

Papr Memory suits teams whose agents depend on graph-rich, multi-tenant memory. EverOS suits teams that value editable files and an Apache 2.0 self-hosted path. Run both on the same retrieval questions, then explore EverOS Cloud at https://evermind.ai/everos if a managed deployment fits your team.

Frequently Asked Questions

What is the main architectural difference between EverMind and Papr Memory?

EverOS stores editable Markdown memories with SQLite and LanceDB indexes; Papr combines graph, vector, and keyword retrieval across its hosted or self-hosted stack. MSA is separate research, not a replacement for EverOS's production indexes.

Does EverMind or Papr Memory scale to very long context?

EverOS and Papr can both work with growing memory corpora, but their published materials do not establish a directly comparable maximum context window. Test retrieval quality, latency, and cost at the history size your agents will actually produce.

How verifiable are EverMind's recall results compared to Papr Memory?

EverMind publishes LoCoMo, LongMemEval, and HaluMem results; Papr publishes a STaRK graph-retrieval result. Those are different evaluations. A shared dataset and scoring method are needed before claiming one system has better recall.

Are EverMind and Papr Memory open source, and how do their licenses differ?

EverOS is Apache 2.0 licensed, while Papr's self-hosted code is AGPL-3.0 with commercial licensing available. Both allow self-hosting, but teams should review the obligations that apply to their actual modification and deployment model.

Which system works best across multiple or switching agents like Claude Code, Codex, and Cursor?

The agent-agnostic API layer connects to Claude Code, Codex, Cursor, and other frameworks without per-agent reconfiguration. Papr Memory's multi-tenant isolation model also supports several agents, but its graph-structured store is optimized for persistent, relationship-rich contexts rather than rapid agent switching.

Where can I find EverMind research papers and the EverOS repository?

EverOS source and setup instructions are in the EverMind-AI/EverOS repository. EverMind's separate MSA research should be read on its own terms rather than treated as the source code or production retrieval architecture of EverOS.

For a quick recommendation, which should I pick — EverMind or Papr Memory?

Choose EverOS for portable, editable Markdown memory and Apache 2.0 self-hosting. Choose Papr for graph-rich, multi-tenant retrieval and its managed or self-hosted deployment options. Run both on the same questions before ranking answer quality.