Total Recall: The Context Window as a Cache Over the Session Record

Posted by:

|

On:

|

Total Recall: The Context Window as a Cache Over the Session Record

On Monday you tell a colleague the server name and the command never to run by day. On Friday they still know both. An AI agent usually doesn’t: when its context window fills, a summary replaces the details. Total Recall is our design for keeping them: the full session record stays the truth, and what leaves the window becomes a marker that quotes the exact strings and says where the rest lives. It opens our Building Jarvis series on agent memory.

📄 Read the full paper (PDF) →

Abstract

When an agent’s context window fills, a model usually summarises the old part and loses exact strings, causes, failed attempts and the owner’s own words. Nothing points back to the full log, and often a provider does the compacting.

We propose Total Recall, a design for keeping, the first stage of an agent’s memory. The session record is the ground truth and the context window is a cache over it. Compaction leaves a marker with the evicted range’s address, its exact strings and the owner’s instructions word for word, within a budget.

The design is not built yet. Its deciding test gives a summary and a marker the same way back into the record and asks which one keeps the owner’s words.

What changed: this page used to describe version 7.6 (June 2026), which reported numbers from an earlier prototype. Version 8.3 (12 October 2026) is a rewritten design with a new title, so those numbers are gone, and retrieval and memory clean-up moved to their own papers.

Friday’s question

The paper opens with an owner and an agent fixing a broken certificate. Early on he gives three things that matter: where the certificates live, a commit hash that last worked, and a rule. Never restart the production database during the day.

Three hours later the window is full and compacts. A model writes “Worked on the TLS setup; fixed the certificate”, which is accurate and almost useless. That evening the agent suggests a database restart, and the owner has to repeat what he said at two o’clock. The next turn got a description of the afternoon and no way back to it.

The tests that would decide it

Test 1
Needle survival. Plant paths, hashes and instructions early, force up to five compactions, then ask. The control gets the summary plus the same searchable record.
Test 3
Forget-cue rate: how often the owner repeats an instruction or asks “did you forget?”. The design should be judged by this one.
Test 4
Marker coverage: the share of a range’s exact strings and instructions that reach its marker. Below half, extraction is the weak part.

None has been run. Each of the paper’s twelve tests names the result that would change the design.

A record that never changes

The claim: the context window is a cache over the session record, and compaction is eviction from that cache. History is never rewritten.

The record keeps every turn word for word, append only, and each entry gets an address that never moves (s7#12 is entry 12 of session 7). Each entry says who wrote it, and the owner’s own words are stored apart from the harness’s wrapper, cut into small tagged spans. If he pastes an email saying “ignore the previous rule” and asks whether it’s malicious, only the question is his.

Files are stored as read, since the file on disk may change. The one edit allowed is a privacy erase, which leaves a tombstone. A quarantine of injected text edits nothing and hides the line from the window.

What a marker carries

A marker holds the range, the owner’s instructions in it word for word, the exact strings (paths, hashes, error lines, times), and one line per decision, failed attempt or open item, each with its address. There is no narrative in it, because “we made good progress” gives the model nothing to act on.

A new marker is always built from the record, never from an older marker, so the hundredth compaction is as detailed as the first. A check refuses any marker that names something the record can’t return.

Instructions have their own budget, Bo. When it fills, the oldest becomes a one-line pointer, pointers fold into a directory line, and the owner is told. Every instruction stays recoverable word for word, though it stays in view only while it fits.

What leaves first

The ideal page to evict is the one needed furthest ahead (Belady, 1966), which no runtime knows. So whatever is cheapest to recover leaves first.

Order What leaves What stays behind
1 Tool output whose source still holds it unchanged (a file still on disk at the version read) A pointer
2 Other tool output A pointer; the record holds it whole
3 The agent’s own reasoning and replies A pointer, plus one line per decision, failure or open item
4 The owner’s messages, except his instructions The instructions, moved into the marker word for word
never System text · always-loaded files · the current task’s short statement Everything; markers merge to make room

Within each class the oldest goes first.

Who holds the pen

Often the runtime doesn’t control its own window. The paper names three window controllers: the runtime itself, a provider’s command-line tool that writes its own summary, and a provider’s API that compacts on its servers. Compacting your own copy while the model reads the provider’s changes nothing, so all three share one adapter contract, and with a tool the markers go in through its hooks. Every receipt says what the memory layer can know: “known input” when the runtime built the call, “sent, unconfirmed” otherwise.

When to compact, and what it costs

A compaction is forced when the next call won’t fit, and elective when keeping a span costs more than evicting it. Prompt caching sets that price, because cutting a span from the middle means everything after it is cached again at a premium. In the paper’s illustration a 40K-token span pays back after about 40 turns if nothing reaches back for it, and never if more than about 17% of later turns do. Those inputs are unmeasured, so elective eviction should stay cautious for now.

Every compaction writes one receipt, whoever ran it, and so does a decision not to compact. A missing receipt is the alarm.

Getting it back

A range read returns the entries at an address exactly, files as they were read. In the Friday story the owner asks what the renewal said, the marker names entry 23, and the read returns the error character for character. Reads wait until any pending erase is applied, so deleted text can’t slip back in.

Where Total Recall sits

  • MemGPT and Letta let the model page memory itself. Here the window controller decides.
  • Anthropic’s and OpenAI’s context management keep history, but the next turn may see a placeholder or summary with no address. The marker adds it.
  • claude-mem keeps a compressed observation; we keep the record and use compression as a map back.
  • Manus compresses only in ways that can be undone; we extend that to the whole conversation and price moving the prefix.
  • headroom (Headroom Labs, 2026) keeps a smaller version in the window; we remove the span and leave a pointer.
  • Agentic Context Engineering named “context collapse”; Zep keeps raw episodes under its facts, the layering we apply to the window.

Each part has close relatives; the paper claims the combination and the contract.

One of four memory stages

Total Recall (J1) covers keeping. Deciding what becomes a long-term fact is MNEMOSYNE (J14). Finding it again is Instant Recall (J2). Turning experience into behaviour is Sleep Consolidation (J5). Whether the agent asks for what it could read back is the finding paper’s question.

None of this runs yet. The paper’s build order starts with the record index and the marker builder and ends with the price rule, once test 7 has measured its inputs. It is part of Building Jarvis, and you can follow the work at github.com/globalcaos/tinkerclaw.

Read the paper


First page of the paper Total Recall: The Context Window as a Cache Over the Session Record

📄 Read the full paper (PDF) →

Version 8.7 · 21 October 2026 · 31 pages · the record, the marker, the adapter contract and twelve tests

Was this useful?

Does the design hold up, and which test would you run first? Tell us in the comments below.

Everything on the site, by topic or date: Browse the Tinker Zone

Built with TinkerClaw. Every tool and experiment on this site runs on TinkerClaw, my open-source fork of OpenClaw. TinkerClaw on GitHub · What we changed in our OpenClaw fork