Every time a memory system is queried it has to decide how many memories to hand over in support of that answer. Almost every system does this with a fixed top-k: rank by vector search, by keyword search, or by a fusion of both, then inject the first k into the context.

That decision lands on every request, so it is not only an accuracy question but a latency and billing one: each injected memory has to pass through the model’s input.

The trouble is that k. It is a configuration value, fixed before any query arrives, and neither direction is safe. Set it large and most of what you inject is redundant, raising the input cost of every request and mixing unrelated memories into the context. Set it small and what comes back may not cover what the answer needs. The same k has to serve simple queries and complex ones.

This is not a problem with how retrieval ranks. Vector search, keyword search and hybrid ranking all surface relevant memories; the fixed injection budget is the bottleneck. “Which flight did we book for the second leg?” may need one memory. “Has anything changed about her dietary preference since March?” needs the state before and the state after, and those two need not sit next to each other in any single ranking. Real traffic mixes both, and one k cannot cover them, so it comes down to choosing between redundancy and insufficiency.

EverOS does not fix that budget. It retrieves in rounds and lets the model judge when it has enough, so how much a query costs is decided by that query. This post describes how, and reports what it does on four memory benchmarks.

The method

llm_multiround puts a small model (the decider) inside the retrieval loop rather than after it. Each round:

1. Search the store and return candidate episodes.

2. The decider reads them and marks which are core, meaning the ones that actually carry evidence for this query.

3. The decider then chooses: stop, or issue a follow-up query for what is still missing.

Two details are worth stating.

The decider reads full episode text, not snippets. A snippet is a summary of a summary; deciding whether an episode carries the evidence requires the episode. This is a token cost on the input side, and it buys the loop its judgement.

Stopping is a decision, not a round cap. The loop’s value is knowing when it has enough. Raising the round limit does not help a policy that cannot tell, it only makes every query slower; what helps is a policy that stops early when the evidence is in hand and continues when it is not.

What reaches the context is the core set, not the top-k. The budget follows the query rather than the other way round.

What fixed top-k costs at both ends

An injection-budget ablation on LongMemEval-S puts numbers on both of the ends named above.

Retrieval quality on that run: MRR 0.9768, MAP 0.9524.

Small k really does run short of evidence, and the second table measures it. At k=1, hit@1 is 0.9640: one episode almost always contains something relevant. But Recall@1 is 0.6199, so it rarely contains everything the answer needs. Recall only reaches 0.9854 at k=10, which is why accuracy climbs to 93.40 there and not before. To get enough evidence reliably from a fixed k, k has to be opened to at least 10, and then every query pays the k=10 bill.

Large k really is waste, and the first table prices it. Going from k=10 to k=20 doubles the episodes and adds 76% to the prompt (4,891 to 8,594 tokens) for exactly zero accuracy. Completion tokens grow too, 3,004 to 3,312, because a longer context makes the model produce more. Those extra ten episodes are redundancy, paid for on both the input and the output side.

Core selection sits outside that trade. It injects 1.95 episodes per query on average, one tenth of k=20’s budget, and scores 91.00: 97.4% of the peak accuracy on 23% of the prompt. In production that last column is the input bill on every request, so this is a quarter of the cost for 97.4% of the result. Against the fixed setting nearest its own size it wins outright, beating k=3 on accuracy (91.00 against 90.00) while using fewer episodes and fewer tokens.

The reason is that the decider is choosing rather than counting. A fixed k is a configuration value, too small for the complex queries or too large for the simple ones. Rounds let the budget follow the query: 1.95 episodes on average because most queries genuinely need one or two, with more spent only where the evidence is actually spread out.

Results

The section above is about spending less for the same accuracy. This one is about the accuracy itself. Four benchmarks, four different things they are good at measuring, all numbers accuracy in percent.

LoCoMo

Long multi-session dialogue. 1,540 questions, GPT-4.1-mini answering, LLM judge, adversarial category excluded.

Overall 94.42, 2.21 points above the next system. The multi-hop column is where rounds show up: 96.10, against 92.20 for the next system and 77.67 for the one after. Multi-hop questions are exactly the case where the evidence sits in two places, so a fixed k either misses one of them or drags in a pile of unrelated episodes to avoid missing it. Temporal at 92.21 is the same effect: answering when something changed means finding the state before and the state after.

EverMemBench

Nine memory behaviours. 2,400 questions, GPT-4.1-mini answering, gemini-3-flash judge, top-20. Avg. is the unweighted mean over the nine types.

Average 57.40, 5.71 points above the next system, and highest on six of the nine types.

Update is the widest gap on any benchmark here, 84.70 against 58.96. Update questions ask what the current state is after it has changed, which requires finding the change and knowing it superseded something. Rounds help because the first query usually finds the old state, the decider can see that it is not the answer, and it searches again. Const (86.07) and Multi (28.11) are the same kind of gain.

One row here is worth reading on its own: Full Context is handed the entire context and still scores 2.41 on multi-hop and 7.00 on temporal. Opening k all the way is not the answer, because redundancy hurts accuracy by itself.

On comparability: RippleMem’s paper reports 54.75 as a size-weighted mean; computed as an unweighted mean over the same nine types it is 51.69, which is the figure in this table.

SubtleMemory

Evidence that has to be combined or reconciled. 1,522 instances, grouped by how the evidence relates. The + OpenClaw rows add an agentic reader on top of the memory system.

The Complementary block is this approach in its clearest form: evidence spread across instances that must be gathered before the question can be answered, and how many pieces is not something you can set in advance. Overall 73.41 against 66.5 for the next system, and on the hardest sub-column (Multi-evi., where more than one piece is required) 74.88 against 70.1, close to that column’s Oracle bound of 79.6. Nuanced overall at 87.88 is also the highest in the table.

Worth noting: + OpenClaw does not reliably help. It lifts Complementary for both MemOS and Mem0 and lowers their Contradictory numbers. An agentic reader on top of retrieval is not a substitute for retrieving the right thing.

LongMemEval-S

500 questions. This table varies something else: the model that writes the stored episode. Rows are extraction backbones, columns are answer models, everything else fixed. Oracle answers from gold evidence and bounds any retriever.

The parenthesised figure in each cell is that row’s own ceiling: the answer model is handed the extracted episodes corresponding to the gold evidence, so retrieval is effectively perfect and only the extraction backbone’s own quality limits the score. The bottom Oracle row is the harder bound, answering from the gold evidence itself with no extraction in the path.

Two ceilings means the remaining gap can be split. The first figure to the parenthesised one is retrieval loss; the parenthesised one to Oracle is extraction loss.

Retrieval loss is at most 1.64 points on any backbone, and on two of the four the retrieval path scores slightly above its own ceiling. That is not a contradiction: the ceiling row hands over only the episodes tied to the gold evidence, while the retrieval path returns its core set, which can carry adjacent detail the answer model finds useful. Read it as a reference point rather than a hard bound.

The split is the useful part. Almost all of the distance left to Oracle on this benchmark is extraction loss, between 2.84 and 7.04 points, while multi-round retrieval gives up about a point. Picking the extraction backbone is worth as much here as anything done at retrieval time, and DeepSeek-v4-pro is the one to pick: it leads both on retrieval (92.48) and on its own ceiling (93.64).

What it all says

Fixed top-k costs something at both ends, and not something a parameter sweep can remove: at k=1 Recall is 0.6199 and the evidence is short; at k=20 the prompt is 76% larger than at k=10 for no gain at all. And k is a configuration value, chosen before any query arrives.

Handing the budget to the model avoids both ends. Core selection averages 1.95 episodes and 23% of the prompt per query, reaches 97.4% of peak accuracy, and beats the fixed setting of comparable size outright. That is saved on every request, not once.

The accuracy is also the highest. The largest margins are all on the kinds of query where the evidence is spread out: multi-hop on LoCoMo (96.10), Update on EverMemBench (84.70), and Complementary multi-evidence on SubtleMemory (74.88). These are the same shape of question, where the answer needs two or more pieces of evidence that sit far apart in any single ranking.

EverOS is first overall on all four: LoCoMo 94.42, EverMemBench 57.40, SubtleMemory 71.75, and on LongMemEval-S the best configuration reaches 92.48, about a point off its own extraction ceiling.