# Perpetuity compared

Below are Perpetuity's measured results, its limits, and how it differs from other memory systems.

Every number below has a run file behind it, per question, listed by run label on https://www.neuraweave.ai/perpetuity/benchmarks and available on request.

## What it is

Perpetuity is a memory proxy. An agent harness points its API base URL at it. On every call, the proxy replaces the conversation history with a frame of the relevant past (about 10k tokens in a coding session), retrieved from everything the agent has ever seen, and forwards the live turn unchanged. The context stays bounded as the session grows. At the 60th prompt of a coding session, each call read about 45k tokens, against 739k without the proxy.

No model runs on the memory path. Capture tokenizes the text and looks up two tables per token: a dense table of an embedding model's token vectors, used only to find chunk boundaries, and a sparse code table used for retrieval, which a sparse autoencoder made once from those vectors. Both ship as data. Retrieval scores the overlap of sparse codes, weighted by rarity, with an exact scan over every stored item. There is no embedding call, no approximate index, and no language model in the loop, at write or at read.

## What is measured

- 94.0 on LongMemEval-S, 500 questions, Opus 5 with thinking, the official GPT-4o judge, nothing excluded. One memory per question, the standard setting.
- 92.2 on the same 500 questions with one memory holding all 500 users' histories, 82M tokens searched per question, each user's own items given priority in the ranking. Retrieval takes about one second.
- Retrieval recall on the served frame, with no model on the path, on the 470 questions that have evidence. 97.4% of them have a relevant session in the frame the reader sees first, and 89.8% have every relevant session. One recall call away, the two numbers are 99.1% and 96.4%.
- A 120-prompt Claude Code session run twice at the same time, with and without the proxy, same model (Claude Opus 5.5, Claude Code on its default 1M-token window), every call priced in dollars at that model's list prices ($4 input, $20 output, $0.20 cache read, $8 cache write per million tokens, the one-hour cache write rate) as the harness's own cost readout totals it: $50.24 against $104.71, 52% less over the session, 64% less between prompts 61 and 90 (2.8x). The harness without the proxy compacted its history once, during prompt 82. Through the proxy every prompt starts at about 46k tokens per call, from prompt 10 to prompt 120, and only a prompt's own tool loop raises it until the next prompt. Without the proxy: 327k at prompt 30 and 965k before the compaction. At the end, 16 pre-registered questions about work from across the session, graded blind: 15.5 right through the proxy using its memory tools, 14 after the harness compacted, which lost details from early in the session.
- The same 120 prompts with the harness capped at a 200k-token window: it compacted 17 times and cost $57.05, so the proxy's $50.24 is 12% less, and the proxy cost more over the first 60 prompts. On the same 16 questions, graded blind in one packet: 15.5 through the proxy, 14 on the default window, 12.5 on the 200k window. One run per setup.
- Correction, 1 October 2026: the coding costs were first published at the previous Opus model's prices (65%, $76.60 against $220.18, and 63% for the 60-prompt pair). The figures here are at Claude Opus 5.5's list prices. Token counts, context sizes and recall scores did not change.
- An earlier 60-prompt pair: $26.40 against $50.93, 48% less, 60% less over its second half. By the last prompt the harness without the proxy re-sent 739k tokens on every call. 13 questions at its end: 13 through the proxy with its memory tools (the frame alone, tools blocked: 8.5), 13 with the whole 739k history in context, 11 after the harness compacted it. Two 30-prompt pairs the same day: 11% and 35% less.
- Recall pooled over five runs (the 120- and 60-prompt sessions above and three 200-prompt sessions on other projects), 77 questions about earlier work: 64.5 right through the proxy, 61.5 for the harness on its own, which compacted its history in every run. 84% against 80%.
- Estimated, not measured: over 192 real Claude Code sessions, each call priced at the list prices of the model it ran on (mostly Opus 4.8 and Fable 5), a pricing model gives about 60% less (a 10k frame, 1.3 times the calls, output equal), with 3 sessions costing more. The model was checked against an earlier 30-prompt pair: within 2% at the settings that pair ran, 11% off at 1.3 times the calls. On Claude Opus 5.5, whose cache reads cost a twentieth of input instead of a tenth, the saving is smaller, as the measured pairs above show. The saving follows context size. Short sessions with small contexts save little or nothing.
- Claude Code run through the proxy on a small open-source dashboard, the same task and prompt with and without it, six runs kept in full. Task quality and turn counts were level. Told facts about the person in an earlier session, the agent applied the relevant ones without being asked (a colour-blind-safe palette with a comment naming the reason, "committed, not pushed") and none of the irrelevant ones appeared in the code. A fresh session told only to continue restated the task from the memory and finished it. The same prompt without the proxy stopped with "I don't know what we were doing", because a new session has no transcript. In a separate run with the harness's compaction forced at 30k tokens, the proxy answered the compaction request in 0.6 seconds with the memory frame and no model.

## What is not claimed

- Not better than lexical retrieval on LongMemEval overall. A BM25 control over the same corpora scores level with the sparse codes, slightly ahead: round 0, 98.1% any / 91.3% all against 97.4% / 89.8%. The benchmark's questions name their targets, so this is expected, and the control is published beside the row.
- On questions that do not share terms with their evidence, the measured edge is narrow. All 500 questions were rewritten once so that names became descriptions (the share of a question's words found in its evidence fell from 0.744 to 0.490), and both retrievers were rerun with no model. Overall the two stay level: at round 0 ours finds some evidence for 94.3% of questions and all of it for 77.4%, BM25 for 93.0% and 79.6%. On the lowest-overlap quarter (118 questions sharing a third or less of their words with the evidence) the first frame holds some evidence for 83.9% of questions against 77.1%, and all of it for 72.0% against 61.0%. On high-overlap questions BM25 ranks it higher. Our claim over lexical retrieval is limited to that quarter.
- Model reasoning is not captured. Thinking blocks are signed to their conversation and carry no retrievable text.
- The pooled result tests retrieval at that size. Perpetuity ships one memory per agent, with no multi-user mode.

## How it differs from each family

- Systems that extract memories with a language model at write time (Mem0, Zep, Letta and similar): a model call per write, and what retrieval searches is what the model extracted. Perpetuity stores every message and runs no model.
- Lexical memories (files with grep, SQLite FTS5, BM25 memory servers): model-less, persistent, and equal on this benchmark overall. They sit beside a context that still fills up and gets compacted. Perpetuity's frame replaces that context, and when the harness does compact, Perpetuity answers the compaction itself with the frame instead of a model-written summary.
- Dense vector memories: an embedding call per write, a version of the memory tied to one embedder, and an approximate index at scale. Perpetuity's representation is a table lookup and the scan is exact at 82M tokens.
- Learned sparse retrieval in search infrastructure (SPLADE, ELSER): a model at write and query time. Perpetuity's codes are the same idea distilled into a lookup, so the runtime has no model.

## Summary

Perpetuity is a model-less store that supplies an unmodified agent harness's context. Every message is kept verbatim except model reasoning. No model runs at write or at read. Retrieval is measured at 82M tokens, and every run is kept per question. Each call carries a frame of the past plus the live turn in place of the conversation history.

## Where to look

- Runs and numbers: https://www.neuraweave.ai/perpetuity/benchmarks
- How it works: https://www.neuraweave.ai/perpetuity/how-it-works
- Setup for a harness: https://www.neuraweave.ai/perpetuity/setup.md
- Run files: available on request, per question, by the run labels on the benchmarks page