Updated on 3 November 2026 (version 9). Version 9 of the paper (Zenodo, DOI 10.5281/zenodo.23832288) counts the input tokens over the whole answer prompt, template and question included: 963.2 against 105,669.0 per question, a ratio of 1/109.7 (counted on the history block alone, it was 109.6×). It states the comparison result as version 9 does: against Letta and Mem0, the six comparisons show no significant difference. Text, table and calculation now carry these forms; the notes below keep their dates.
Corrected on 18 October 2026. We used to call the comparison arm a "long-context oracle" and the ratio a "token budget". Both were imprecise. In LongMemEval, "oracle" names the condition in which the model sees only the evidence sessions; our comparison arm reads the whole history. And only the input tokens in the answer step are counted, not the building of the memory. Text, table and calculation now carry these forms.
Re-measured on 15 September 2026. The printed comparison figures against Letta and Mem0 come from a run with two defects of ours, in those systems' adapters: the Letta adapter left 59 of the 500 tasks unserved, and per-question isolation did not work for Mem0. With repaired adapters and version-matched judges: three of the nine comparisons hold, all against A-Mem and significant; the six against Letta and Mem0 are ties at the paper's own criterion, and none is lost. The token ratio is 109.6×, not the printed 106 — that figure came from a thousand-token constant in a plotting script, not from a measurement. Both corrections are worked into the text below. Evidence: correction notice, DOI 10.5281/zenodo.22831087.
Corrected on 11 October 2026. Contrary to the sentence above, the table, the comparison section and the reproducibility note did not yet carry the corrections; now they do. Per the same notice, the measured arm is a Python port, not an import of the npm packages. The figure for TripleCopy strength at 30 days is removed; it did not follow from the printed formulas.
Added on 9 October 2026. The mechanism figures further down come from the paper's simulation. Per the same note, under stress 10 of 15 components reach the printed criterion (nine with a loss, PriorityMap with a gain), and the only run of the sleep loop on real data showed a loss in retrieval precision. Both are worked into the text below.
There is one sentence about the ZenBrain paper I know by heart, in its corrected form:
The measured ZenBrain arm reaches 91.3% of the accuracy of a full-context comparison arm (whose answer model reads the whole history) with 1/109.7 of its input tokens in the answer step.
That is the sentence that decides whether building a memory architecture is worth it at all — or whether we should just dump the entire conversation history into the context window every time and hope the LLM does the right thing.
Spoiler: in the answer step, it clearly is worth it.
What the full-context comparison arm is
LongMemEval-S Full-500 is a memory benchmark with 500 questions, each one bound to its own conversation context — about 494 conversation turns per question, averaging 105,577 tokens (median 105,744, max 107,740). It spans six categories: multi-session, temporal-reasoning, knowledge-update, plus three single-session variants.
The full-context comparison arm works like this: we take the entire conversation archive for each question — all 105,600 tokens — and stuff it into the context window of gpt-4o-mini. No memory system in between, no retrieval filter, no forgetting, no consolidation. The model reads the full history every time and answers from it.
That is not a theoretical upper bound: the information is all there, but among a lot that has nothing to do with the question. In LongMemEval, "oracle" names the condition in which the model sees only the sessions holding the evidence; this arm is something else.
What ZenBrain does instead
In the paper's model, ZenBrain receives the same 494 turns once at ingest, sorts them through the 7-layer architecture (Working, Short-Term, Episodic, Semantic, Procedural, Core, Cross-Context), writes a knowledge graph with two-factor synaptic edges, consolidates in idle time, and forgets along an Ebbinghaus curve. Per the correction notice, what was measured is a Python port whose hit lists equal plain cosine search. The open library @zensation/core keeps no knowledge graph and runs no sleep replay; nothing in its long-term memory fades on its own. At query time we return the 5 most relevant memories (k = 5) — about 963 tokens per question, measured on the prompts actually sent.
That is 1/109.7 of the input tokens the comparison arm gets in the answer step.
The result (per the paper and the correction notice)
| System | Accuracy | Input tokens in the answer step |
|---|---|---|
| Full-context comparison arm (gpt-4o-mini, whole history) | 52.2 % | ~105,600 |
ZenBrain (k = 5) | 47.7 % | ~963 |
A-Mem (k = 5) | 35.4 % | not reported |
The printed figures for Letta and Mem0 and the interval for ZenBrain are withdrawn (correction notice, sections 1 and 3); with repaired adapters both are level with ZenBrain.
The measured arm reaches 47.7 / 52.2 = 91.3 % of the comparison arm's accuracy. The comparison arm is ahead by 4.5 percentage points. Its answer model reads 109.7× more input tokens per query for that.
Among the k = 5 memory systems, ZenBrain holds a lead over A-Mem only. On the retrieved context, three of nine head-to-head comparisons hold, all against A-Mem, under all three LLM judges (Sonnet 4.5, Opus 4.6, GPT-4o), Bonferroni-corrected. Against Letta and Mem0 the remaining six comparisons show no significant difference.
What this means in practice
The discussion "do I even need a memory system, or can I just dump the whole archive into the context window?" has a quantitative answer.
If you pay for 109.7× more input tokens in the answer step, you gain 4.5 percentage points of accuracy. At one million queries, a typical price of ~0.15 €/1M input tokens for gpt-4o-mini, and a history of 105,600 tokens per query:
- Comparison arm, input in the answer step:
1,000,000 × 105,600 × 0.15 / 10⁶ = €15,840 - ZenBrain, input in the answer step (
k = 5, ~963 tokens):1,000,000 × 963 × 0.15 / 10⁶ ≈ €144
A €15,696 difference for 4.5 percentage points, per million queries. The calculation counts only the answer step: building the memory at ingest is not included.
Conversely, it leaves out latency (a 105 K-token prompt takes noticeably longer to the first token than a 1 K-token prompt), and the fact that the comparison arm has no memory concept at all: it cannot learn across sessions, and single memories cannot be deleted on purpose (in ZenBrain with forget()).
The comparison arm is a brute-force tool. ZenBrain is an architecture.
Where the ratio comes from
The paper attributes the 91.3 % mark to four mechanisms. The correction notice qualifies that: what was measured is a Python port whose hit lists, without the two hash-seeded mechanisms, equal plain cosine search. Whether the described architecture behaves that way is what the registered follow-up measurement is meant to settle. The four mechanisms as the paper describes them:
- Layer routing. A query with temporal markers gets boosted by the episodic layer (
w = 2.0); a procedural query goes to the procedural layer; an identity query hits Core Memory directly. On LoCoMo, the paper reports +181 % on temporal queries for layer routing versus flat-dense storage; per the correction notice, this rests on one of five query pools, and two pools show no lead. - Two-Factor Synaptic Consolidation. Edges in the knowledge graph carry not just a weight
w_ijbut also a consolidation varianceσ²_ij. Mature edges (σ² → 0) resist both decay and catastrophic overwriting — an EWC-style penalty (Elastic Weight Consolidation), with1/σ²standing in for the Fisher information. The importanceI_ij = 1/σ²_ijis reused as a retrieval boost. - Sleep consolidation. At idle, the simulation-selection loop runs: it generates replay candidates from real episodes + counterfactuals, scores them with
TAG = 0.34·|δ_TD| + 0.30·R + 0.21·N + 0.15·E(E = emotional weight), strengthens top candidates via LTP, prunes weak ones via LTD. Result in the simulation: +37 % stability, −47.4 % storage; on real data, retrieval precision dropped. - Predictive Memory Architecture (PMA). Reconsolidation opens a 10-minute window after retrieval where memories transition into one of four update modes (confirmed / selective_edit / integration / new_episode) depending on prediction error. TripleCopyMemory stores each event in three copies with divergent decay constants; as a memory ages, the deep copy takes the lead.
In the paper's 15-mechanism ablation, a simulation: under moderate conditions most algorithms are cooperatively redundant — sleep is the only single component that reaches the printed criterion. Under stress (60 days, decay = 0.25/day) 10 of 15 components reach the printed criterion, nine with a loss (ΔQ down to −93.7 %) and PriorityMap with a gain. That isn't a bug, it's the design: the algorithms form a cooperative survival network.
The honest framing
We do not claim 91.3 % is universally enough. For safety-critical applications (diagnostics, legal, financial transactions) the missing 4.5 pp may be too expensive — long-context is the right answer there, and the 109.7× input premium in the answer step is acceptable.
For the vast majority of knowledge-work applications — personal assistants, CRM, research agents, coding copilots, learning systems — k = 5 is the economically correct choice. That is precisely the regime memory-based systems were invented for.
And among memory systems on LongMemEval-500, ZenBrain holds three of nine head-to-head comparisons, all against A-Mem; the six against Letta and Mem0 show no significant difference.
More memory is not the answer. Better memory is.
Reproducibility
Per-question values and a recompute script ship with the correction notice. The 47.7 % accuracy (against 52.2 % for the full-context comparison arm) recomputes exactly from three genuine end-to-end runs. The earlier statement that the results sit in the repository and that the pipeline is deterministic is withdrawn.
- Paper: Zenodo DOI 10.5281/zenodo.19353663
- Code: github.com/zensation-ai/zenbrain
- Open library (npm):
npm install @zensation/algorithms @zensation/core. It does not reproduce the benchmark figures; what was measured is a Python port.