The memory tax
An assistant that claims to know you has to store that knowing somewhere. The dominant answer today is a vector database sitting alongside the model. Conversations are split into fragments; each fragment is embedded — compressed into a vector, a few hundred numbers meant to stand in for its meaning — and written to a store. When you say something new, the store is searched for fragments whose vectors are nearby, and the top matches are pasted into the prompt. The model works from whatever the similarity search surfaced.
This architecture has a structural weakness that no amount of tuning removes: retrieval happens before the model reads your message, and it selects on surface similarity rather than relevance. A fact stored under different words than you now use is simply not retrieved, and the model cannot recover what it was never shown. The failure is silent, upstream, and invisible in aggregate metrics until you probe for it — which is exactly what the newer benchmarks below do.
A memory you have to search is a memory that has already forgotten you.
That is the standard we hold memory to, and retrieval cannot meet it by construction. So we refused the architecture entirely. Numa does not keep fragments of you in a store — it keeps an understanding of you, held in language, private to your account, carried into every conversation whole. How that understanding is formed and maintained is ours; what it does is yours to feel. There is no lookup moment. No similarity threshold deciding which parts of you are worth surfacing. No pause while something is fetched — none of that faint function-call stutter of an assistant visibly consulting its notes. When you speak, the knowing is simply already there, the way a friend does not rummage through records before answering you.
What Numa keeps, and what it refuses to
The contrast with a vector store is sharpest in what survives. A store retains everything and interprets nothing — every fragment preserved, surfaced later by resemblance. Numa keeps structure and interpretation: not that a sentence was said, but that a decision was reached, a value was fixed, an approach was ruled out and why. A project that began as a letter and became an article is recorded as that trajectory. A measurement, once you state it, is locked — a later turn cannot silently replace the number with a different one, a failure mode we found and closed explicitly. And some entries exist precisely so a topic is never raised again: things you closed, things that cost you to discuss.
Because the memory is language rather than vectors, it has properties a store cannot offer: it is legible and correctable; it moves with the account across chats and devices; and a standing instruction — “always answer in metric,” “never suggest that library again” — takes effect on the next turn, because it lives where Numa's attention lives — not behind a ranking function.
Evaluation
We evaluated the system against the two public benchmarks that specifically stress long-term memory, and are releasing the full protocol, the exact grader prompts, and the failure analysis. The first, LongMemEval, measures recall and reasoning across many prior sessions.
Each figure as reported by its own source; models and retrieval budgets differ. Numa's run used a markedly smaller model than the comparison systems, which isolates the memory design rather than model scale as the source of the result.
The second, BEAM, is harder and more diagnostic: conversations exceeding one hundred thousand tokens, with twenty questions apiece spanning ten memory abilities — recall, tracking a value that changed, reconstructing the order in which topics were raised, and correctly refusing when the answer was never given. It cannot be solved by a larger context window; the history is deliberately too large to hold.
BEAM exposes a measurement problem the field rarely states plainly. Results depend heavily on the grader. The lenient protocol — an LLM judge asking whether the answer conveys the correct information — is what published numbers use. The strict protocol — exact-match against every element of a reference rubric — is far more punishing and almost never reported. We report both, on identical answers.
The 37-point spread between the first two bars is the same system's same answers under two graders. It quantifies how much a headline BEAM number depends on the grading protocol — which is why we publish both prompts rather than a single figure.
Under the lenient protocol the field actually publishes, across all ten abilities — not the subset a system performs best on — the document-based approach is competitive with far heavier stacks.
Same grading philosophy across systems (LLM-judge). Tiers, base models, and disclosure differ by vendor — several report only a favorable subset of the ten abilities. We report all ten.
The memory tax
Here is the part of the memory business nobody itemizes. When a retrieval-stack assistant “remembers” an exchange, the chat call you see is not the whole bill. Per their own papers and documentation: mem0 runs a two-phase pipeline — an extraction model call, then an update model call — for each remembered exchange, plus an embedding pass; Zep runs model-based entity and edge extraction into a temporal graph per episode; Engrammic describes an ingestion model pass and a dedicated GPU embedding server. Every one of those is a separate invocation, billed on top of the conversation, before you count the vector database, the graph store, and the infrastructure keeping them consistent.
As described in each system's own paper or documentation; approximate — some pipelines batch or add further passes. Each nonzero bar also implies an embedding step and a hosted store (vector and/or graph) that Numa simply does not have. Numa's memory adds no separate pipeline: no extraction service, no embedding model, no database to keep in sync.
Because there is no second pipeline, the entire cost of Numa's memory is visible in one place: the tokens of the conversation itself. So we measured exactly that. We replayed a single relationship for 777 consecutive turns — every message, every reply, memory maintained throughout — and metered every token in and out, with provider prompt-caching on, at the flash-tier rates we ran ($0.27 per million input tokens, cached input at a tenth of that, $1.10 per million output).
Log scale. The full-transcript baseline climbs linearly and stops answering correctly around turn 254, lost in its own history. Numa's per-turn input grows slowly and sub-linearly — an order of magnitude lower deep into the relationship — because Numa carries understanding forward, not transcript.
The meter readings, in full. The 777-turn relationship — memory included, nothing billed anywhere else — cost $2.55 end to end with provider caching (we measured a 46% cache-hit rate on this run; 44–66% across our replays), or $3.82 with the cache benefit excluded entirely. That is about a third of a cent per remembered turn, and roughly thirty cents per hundred turns. The same 777 turns by brute force — resending the transcript each time, same price sheet — computes to $16.39 uncached, and the run does not even finish: it stops answering correctly around turn 254.
Measured token meters priced at the flash-tier rates we ran; the transcript column is computed from the same per-turn token counts. Aggressive prefix caching narrows the transcript's dollar gap at flash rates — but does not change the 5× input-token ratio, which scales the gap right back up on any premium model, and does nothing about the failure at turn 254. And none of these columns include what a retrieval stack adds before tokens: the extraction calls, the embedding service, the database.
Two things make this arithmetic hard for the incumbent architecture to escape. The token ratio is structural — it follows from consolidation versus accumulation, so it reappears at every price tier, and the premium tiers are where it hurts. And the memory-layer tax is structural too: a pipeline that must extract, embed, store, and search cannot bill zero for those steps. A memory that has no second pipeline can.
Why the shape matters
Memory is the component of an assistant a user is asked to trust most and can usually inspect least. A vector store cannot show you what it believes about you; it can only be queried, and it never forgets on request. A written document can be read, corrected, carried between devices, and — when you ask — set aside for a turn. That legibility is not a cosmetic preference; for a system meant to hold the details of a person's life, it is the difference between a memory you can govern and one you can only hope is behaving. That it is also the more efficient design is, for once, a case where the honest choice and the cheap one coincide.
It is live in Numa now, on desktop and phone, across every conversation.