The case, the mechanism,
and the file itself.

WITHOUT .dai
  [the benchmark's full-context arm]
  → feed the whole history into the window
  → model hunts for one detail in a haystack
  → 60.60%, the benchmark authors' own baseline

WITH .dai
  recall_memory("the aquarium question")
  → retrieval code picks the relevant facts
  → feed 10,065 tokens (measured mean)
  → model reads a page, not a library
  → 83.00% on the same questions, same judge

  +22.4 points, same answering model, measured

Bigger windows don't remember better.

As you stuff more history into a context window, the model's attention spreads thinner: details drown, dates blur, and it loses the thread silently. It does not say "my context is too full", it says "I don't have that information" while the answer sits right there in its window. We measured exactly that.

So on the chat-history benchmark accuracy is higher than feeding the raw text (83.00% against 60.60% on LongMemEval, GPT-4o answering in both arms, official scoring) while reading about 3.0× less context than Mastra's published run reads. At small sizes the window works fine, which is exactly why the decision layer routes small in-window jobs to the full-text default rather than retrieving. Everything above traces to the results page.

Where .dai sits, including who is above us

LongMemEval_S, all 500 questions, GPT-4o answering in every row. Our score comes from the benchmark authors' own official script, and the others are as published by each vendor, so protocols and dates vary. The table ranks systems whose configuration is reproducible: published in enough detail that somebody else could run it. One of them publishes a higher number than ours, and it is open source. We show it anyway, because the point of this table is what column three costs you. Runs that miss the criterion are listed directly underneath, including one that scores above every row in the table.

Our number is reproducible from three public things: LongMemEval-S, which is a public academic benchmark; the v4.4n engine that produced the score, which is Apache 2.0 in the public repository; and the benchmark authors' own evaluate_qa.py with the gpt-4o-2024-08-06 judge snapshot, which is their scorer rather than ours. We publish no run artifacts of our own for you to re-score. Instructions here. We are second among systems whose configuration is reproducible: 1.80 points (9 questions) behind Mastra OM on the same GPT-4o actor, and 22.4 points above raw full-context, with no service, no database and no account. The gap to Mastra is inside single-run variance, p≈0.44, but the point estimate is theirs and not ours. Column two is the micro (per-question) average for every row; where a system also publishes a task-averaged figure it sits underneath, and the two aggregations must never be read across rows.

Same benchmark, different setup: not in the ranking

These runs are on LongMemEval_S too, and the first of them scores above everything in the table above. They are out of the ranking because of the criterion, not because of where they land, and the numbers stay here with the reason attached.

Two things worth saying plainly. All three EmergenceMem configurations are listed together, including the open-sourced one that scores below us. Splitting the family so that only the rows beneath us stayed in the ranking would be exactly the move the criterion exists to prevent. And an unnamed judge on its own is flagged in column three of the ranking rather than used to keep a row out: Mastra RAG topK 20 stays ranked on exactly that basis. The EmergenceMem family is out because its headline configuration is not publicly reproducible and no configuration in the family names its judge; the family is treated as one, which is why the open-sourced row leaves the ranking with the rest of it. Supermemory's headline 95% is in neither table because it is Recall@15, a retrieval metric rather than answer accuracy; it has its own section below.

Why every row above uses GPT-4o, an older model

Because the answering model moves the score more than the memory system does, and a table that mixes models is ranking models rather than memory.

The same .dai store that scores 83.00% with GPT-4o answering scores 92.00% with Claude Fable 5 and 91.00% with Claude Opus 5. Nothing about the memory changed between those runs: identical files, one shared set of rendered prompts, identical retrieval, only the model reading them. Other systems see the same effect, and Mastra publishes 93.27% on gemini-3-pro-preview and 94.87% on gpt-5-mini against their 84.80% on GPT-4o.

So none of those figures can be set against each other. Our 92.00 does not beat their 84.80, and their 93.27 does not beat our 83.00. They are answers from different models.

Recall@k, at everyone else's metric

Supermemory headlines Recall@k=15 of 95% on LongMemEval_S. That is a retrieval metric, not answer accuracy. Fair enough. Here is the same metric for the .dai retrieval layer, taken from the v4.4n release run itself: retrieval surfaced the gold session on 94.6% of all 500 questions, session-level (the granularity the benchmark's own evidence labels use), at the depth the engine actually read, which is 5 files on 215 of the 500 questions and more where the source is larger. Theirs is a hosted pipeline; ours is deterministic code over a plain-text index.

This figure has moved, and the reconciliation that was outstanding is now done. We previously published 98.6% at k=5 from a separate retrieval-only harness on the v4.4d build, then withdrew it in favour of the 94.6% the engine's own per-question diagnostics record. A fixed-k sweep over the release run, k=1 to 15, now measures both definitions on the same build: counting only gold sessions the reader opened as documents gives 94.6%, and also counting gold sessions cited as the source of a fact or event row gives 98.0%. The gap was a difference in what counts as retrieved, not a difference in the engine. Both are published, and the stricter one stays the headline.

Every system's published k=5 figure, side by side

Recall is not comparable across rows without reading the unit column. Ours admits whole session documents, Supermemory's admits atomic memories, and MemPalace's row is measured with its own architecture disabled. LongMemEval_S, 500 questions, gold sessions as annotated by the benchmark.

Sources. Supermemory's 86% at k=5, with 91% at k=10 and 95% at k=15, is from their own research page. MemPalace's 96.6% is their own published claim; the independent analysis in arXiv:2604.21284 (Dey and Viradecha, April 2026) reproduces it and attributes it to verbatim storage plus ChromaDB's default all-MiniLM-L6-v2 embedder rather than to the palace structure, and notes it is recall_any@5, the most generous variant. Mastra publishes no retrieval figure because their design has no retrieval step: they carry a running compressed log, which is also why their per-question context is around 30k rather than around 10k.

The LongMemEval baseline is Table 3 of arXiv:2410.10813, best key design (K = V + fact) at Recall@5, round granularity, measured on LongMemEvalM. The same table reports a session-granularity figure of 73.2% at k=5, and since our own recall is session-level that is arguably the fairer row to set beside ours. We show the round figure because the paper leads with it for retrieval, and state the session figure here.

Why k=5 and not deeper. Our curve is flat: 96% at k=1, 98% from k=3, and nothing above k=5 moves it at all, with every column from k=10 to k=15 identical. Reading to k=10 buys 33% more context tokens for zero additional recall, which is why the engine stops at 5. Two structural reasons, not luck. 305 of the 500 questions are answered from the global facts and events indexes rather than from opened documents, so depth never enters them and they sit at 100% at every k; and the single-document path shortlists 10 candidates before it slices to k, so no k above 10 can reach further. The one category that responds to depth is preference, and only in which document gets opened rather than in whether the evidence is reachable.

Three things that stop this table being read too kindly. Our recall is measured at session level, the unit LongMemEval's own evidence labels use, while Supermemory's k admits atomic memories, so the two are not strictly like for like. Their 95% sits in a table beside Zep's 71.20 and full-context's 60.60, but those are answer-accuracy figures, a different metric. On answer accuracy, GPT-4o answering both sides, we score 83.00 on the official script against their 81.60 on a cleaned-dataset variant with a custom harness: close enough that the harness difference matters more than the gap.

How the sweep was run. It re-runs retrieval against the stores the release run already built, with the actor replaced by a stub and the network disabled, so it spends nothing: no actor call, no observer call, no embedding call. Its control column reproduces the published run on 500 of 500 questions across reading strategy, files read, context tokens to the token, and retrieval hit. .dai answers from its top 5 files rather than 15 because we measured that feeding models more retrieval hurts answers.

What the 5.4% miss actually is. On the strict definition it is where the gold session was never opened as a document, not where its content never arrived: outright, nothing from the gold session reached the model on 2.0% of questions. That is also why the weakest question types fail on synthesis rather than on search, since the evidence was present for 98.0% of questions while the score is 83.00%.

How memory products differ

Most memory products are good at what they do. The question is what you give up. Hosted memory APIs keep your memories in their cloud, behind their API, in their format. Graph and vector systems store your life as embeddings or graph edges, which are machine-queryable but human-unreadable. Some open-source frameworks land in neither column, and we do not claim these properties are ours alone. Here is the picture by category.

These are category descriptions rather than accusations. Hosted APIs are genuinely convenient, and if you want zero setup they are a fine choice. This table exists because most people do not realise what the trade is until they try to leave. Note what the columns do not claim: running with no account and no server is a property of .dai rather than something only we can do, and we make no claim to be the only readable format. This table carries no accuracy row: the scores live in the ranking above. Hosted pricing is as of July 2026 and typically runs from about $19/mo.

Your memory gets better over time, retroactively.

Because every original is kept byte-exact in _raw/, improved conversion is not just for new saves. Re-run indexing and your entire history is upgraded. This is not hypothetical, and it is how our own benchmark score moved without re-saving a single conversation.

The part that tells you not to use it.

Before answering, a built-in classifier routes each question to the cheapest strategy that will actually work. That routing is what produces the recommendation against converting:

Three zones. One file.

A .dai document is ordinary UTF-8 text. Open it in any editor and you can read the whole thing top to bottom. The zones are ordered so the cheap, structured part comes first and the full record is always underneath it.

---
title: Investigating intermittent build failures
source: claude-code
dates: YYYY-MM-DD
---

# Understanding
{
  "facts": [
    { "date": "YYYY-MM-DD",
      "fact": "deploy flakiness traced to cache step" },
    { "date": "YYYY-MM-DD",
      "fact": "decision: pin builder image at v2.4" }
  ],
  "open": [ "rollback alias not yet created" ]
}

# Content
[USER] our deploys keep failing about 1 in 5 times…
[ASSISTANT] Let's look at the pipeline definition…
…full conversation, unabridged…

Formats outlive companies.

The documents you can still open from twenty years ago are the ones written in formats somebody published. The ones you have lost were in a database owned by a company that changed its mind. AI memory is heading the same way, and it is early enough to choose differently.

Deploying .dai takes minutes.

One install and one setup command puts it on every surface you already use. If you build an assistant, an agent framework or a note tool, emitting .dai means your users' memory is portable the day you ship it. Three ways in, all free: