Context Language Models: What the UW and Meta Paper Changes for Agent Builders, and What It Leaves to Memory

AI Agent MemoryContext EngineeringGaurav Dadhich1 October 202621 min read
Context Language Models: What the UW and Meta Paper Changes for Agent Builders, and What It Leaves to Memory
On this page
  1. A CLM edits its own context like a file, and beats summarisation with less compute
  2. A CLM is an existing model with write access to its own context, not a new class of model
  3. Where a CLM does not beat summarisation
  4. Unlike compaction, a CLM can edit any part of its context at any step
  5. Context language model vs RAG: one decides what stays, the other decides what comes in
  6. Two October papers move task state out of the transcript altogether
  7. You can try a CLM today on Harbor, Pi or OpenCode
  8. Production needs trained models, mid-context cache reuse, provider support and a commercial licence
  9. Self-edited context can carry injected instructions, so keep instructions out of reach and log every edit
  10. The context file dies with the task; Maximem Synap keeps what must survive it
  11. Frequently asked questions

Updated 2 November 2026 · Published 1 October 2026 · Every figure below was re-read on 2 November 2026 from the CLM paper (arXiv 2609.37725), its code release, the LongHarness and Stateless Language Agents papers, OpenAI's report on self-generated prompt injections, and Anthropic and OpenAI API documentation.

A Context Language Model is an existing language model that rewrites its own context the way it would edit any file on disk, and, if you want it to be good at that, is trained to do so. Prompted this way, Qwen3.6-27B scored 59.4% on all 830 BrowseComp-Plus questions at a 32K-token limit, 11.4% higher in relative terms than Codex-style summarisation, while spending 21.5% fewer FLOPs. For an agent builder, that means better context management inside a task, done by the model itself, and nothing that survives the task: when it ends, the context file is thrown away, so whatever your agent needs to know next week is still your job.

Published on 29 September 2026, "Context Language Models" comes from Rulin Shao and colleagues at the University of Washington and Meta Superintelligence Labs, with co-authors at MIT and Trillium Labs. Its claim is that a model managing its own context beats the hand-written context rules the authors tested it against, and its own safety section warns that the same freedom lets a model plant instructions for itself. Since 1 October the authors have published ContextBench (11 October) and ported their serving fix to vLLM (14 October), and two October papers have argued that task state should not live in the transcript at all.

A CLM edits its own context like a file, and beats summarisation with less compute

Its core move is to stop treating context as an append-only transcript. In a CLM, the context is a file. The model can change any part of it using ordinary Bash commands, with "each modification immediately synchronized to the LM's live context for the next turn", so generation continues on the edited version. The model can delete a stale search result, rewrite its own plan, compress twenty tool calls into two lines, or keep a running scoreboard at the top of the file and update it in place.

One cheap way to make a model good at this is an in-context "skill" document that tells the model how to manage its file, which the authors do not write by hand but evolve: the agent produces rollouts, a proposer model drafts candidate skills from those traces, a development split picks the winner, and the final skill is scored once on a held-out split. The expensive way is reinforcement learning. The team trained Qwen3.5-9B with stepwise GRPO and lifted it from 28.8% to 42.5% on BrowseComp-Plus, 0.4 points above a summarisation harness trained with the same recipe (34.7% to 42.1%), at 1.34 against 2.19 PFLOPs per question, which is 38.8% less compute.

Against the strongest baseline in each setting, the headline numbers look like this:

SettingCLM resultWhat it was compared with
BrowseComp-Plus, 830 questions, Qwen3.6-27B, prompted, 32K limit, graded by Qwen3.5-27B with the benchmark's template59.4%, with 21.5% fewer FLOPsCodex-style summarisation, beaten by 11.4% relative
BrowseComp-Plus, Qwen3.5-9B, RL-trained42.5% (from 28.8%)Summarisation trained the same way, 42.1%, at 38.8% more FLOPs
EdgeBench-10, 12-hour runs, Qwen3.6-27B, 32K, best of three seeds, EdgeBench judge (0 to 100)44.6 at 179 PFLOPs per trialSummarisation, 42.3 at 437 PFLOPs (59% more)
Software World, six agents on GPT-5.6-Sol, 272K budget, 24 hours65% greater downstream speedupSummary-based agent swarm at the same spend
ContextBench, evolved in-context skillHeld-out accuracy up by as much as 35.9 points, at lower computeThe same CLM before skill evolution

Those baselines are serious ones: Codex-style summaries, MEM1, Self-Compact, Recursive Language Models, Mini-SWE-Agent and an agentic context management method from Li et al. (arXiv 2607.23809, unrelated to Maximem's paper of the same name). On BrowseComp-Plus the paper reports that CLMs outperformed all of them and used 28.9% fewer FLOPs than MEM1, the next-strongest method after summarisation.

The 35.9-point ContextBench figure is the gain from evolving the skill document, measured against the same model without it, and not a margin over other context-management methods; the 1 October version of this post read it the second way, and that is now corrected. The FLOP figures are "prefix-reuse FLOPs", the paper's own count of decoding, prefilling and re-prefilling across a run under standard serving, which makes them a compute estimate rather than a wall-clock time or an invoice.

A CLM is an existing model with write access to its own context, not a new class of model

You do not have to wait for a CLM release, because any model you already call can run as one inside the right harness. The transformer underneath a CLM is unchanged. The paper applies the method to models you already know, including Qwen3.6-27B, Qwen3.5-9B, Claude 4.6 Sonnet and GPT-5.6-Sol, and as of 2 November 2026 the authors have released no trained weights.

Context-management methods sit on a ladder of who controls the context. On the bottom rung, rules decide: the harness summarises when the window passes a threshold, and the model has no say. On the middle rung, the model triggers fixed operations, such as offloading a block to storage and pulling it back, which is roughly where MEM1 and Li et al.'s method sit. On the top rung, the model can change anything, anywhere, at any step. CLMs are the top rung, and the paper describes the bet as "shifting context management from external harness control to intrinsic model behavior".

So "Context Language Model" names a capability plus a training recipe, closer to how "tool-using model" describes what a model is allowed and trained to do than to a new architecture. My expectation, which the paper does not state, is that providers will absorb it into existing model families instead of shipping a separate product line called a CLM.

Where a CLM does not beat summarisation

Every gain in that table comes from a tight budget and capable models, and the paper's own appendix shows what happens when either changes.

At a 128K-token budget on EdgeBench-10, the single-agent CLM finished at 47.3 against 47.8 for summarisation, so the accuracy edge disappeared; what remained was compute, at 142 PFLOPs per trial against 222. CLM with subagents reached 50.2, at 219 PFLOPs. If your agent rarely gets near its window, a CLM is mostly a cost lever, not an accuracy one.

Small models also need training before they manage context well. Before RL, the 9B CLM scored 28.8% on BrowseComp-Plus, six points below the summary harness at 34.7%, which the authors put down to "the smaller model's limited context-management capabilities". And EdgeBench results are the best score over three seeds per task, which flatters every method equally but is not what one production run gives you.

Unlike compaction, a CLM can edit any part of its context at any step

Anthropic and OpenAI now offer four ways to change a running context, and a CLM is easy to mistake for any of them.

Anthropic's compaction "replaces the older turns of a conversation with a summary", triggered either when you ask for it or when input tokens cross a threshold you set. OpenAI's compaction does the same job differently: it returns an "encrypted compaction item" that is "opaque and not intended to be human-interpretable". Anthropic's context editing is rule-based: you configure it to clear old tool results or thinking blocks, and it "is applied server-side before the prompt reaches Claude". Anthropic's memory tool is a different thing again: Claude creates and updates files that "persist between sessions", and your application stores them.

MechanismWho decidesWhat can changeCan you read itSurvives the task
Plain appendNobodyNothing, it only growsYesNo
Context editing (Anthropic)Your rulesOld tool results and thinking blocksYesNo
Compaction (Anthropic)Threshold or your request; Claude writes the summaryOlder turns, replaced by a summaryYesNo
Compaction (OpenAI)Threshold or your requestOlder turns, replaced by an encrypted itemNoNo
Memory tool (Anthropic)Claude, through file operations you executeFiles outside the contextYesYes, if you keep the files
CLMThe model, at every stepAnything in the context after the pinned system prompt and taskYes, it is a fileNo

A CLM decides for itself when to edit, where compaction waits for a threshold or a request. The edit can land anywhere, including the middle of the context, while compaction only replaces the oldest turns. And the editing policy can be trained into the weights, so the model gets better at it with experience instead of following a fixed summarisation prompt. The memory tool is the closest relative in spirit, since the model manages files, but it manages storage outside the context; a CLM manages the context itself. Our comparison of context compaction and retrieval works through what each kind of compaction costs on a long session.

Context language model vs RAG: one decides what stays, the other decides what comes in

A CLM and RAG work on opposite ends of the same window. RAG searches a knowledge source outside the model and places the matching passages into the prompt; a CLM decides which of the tokens already in the prompt stay, shrink or go. An agent can use both in the same turn: retrieve a document, then have the model cut it down to the three lines that answer the question and delete the rest before the next search. Neither one changes what the model knows when the next task starts.

Summarisation is the method a CLM replaces, not RAG. A summary is written once, at a threshold, by a prompt that cannot know which detail will matter twenty turns later; a CLM edits a little at every step and can keep a value verbatim while compressing everything around it. The paper's ContextBench was built to show that difference, with tasks that need verbatim retention (Needle Retention), in-place updates (Sudoku Sketchpad) and exact recall through offloading and retrieval (KV Store and Log Triage), where its pilot study found summary-based compaction can "lose or hallucinate information".

Two October papers move task state out of the transcript altogether

A CLM tidies the transcript. Two papers published in October argue that the transcript is the wrong place to keep task state in the first place, and both report large gains from moving it out.

LongHarness (Huang et al., 9 October 2026) targets questions over corpora far larger than any window. Its authors trace failures to evidence and conclusions being "entangled in a growing interaction history", so the harness keeps both as explicit state: open conclusions decide what to retrieve next, and new evidence confirms or revises the conclusion that asked for it. On OfficeQA Pro, scored by exact match with no model judge, it lifted GLM-5.3-Flash from 15.8% to 60.2% on V1 (133 questions over 697 Treasury documents, roughly 100M tokens) and from 4.4% to 61.1% on V2 (90 questions over 1,435 documents). With the same backbone it beat Claude Code by 12.0 points on V1 and Codex by 18.9 points on V2.

Stateless Language Agents (Zhang et al., 6 October 2026, with CLM lead author Rulin Shao among the co-authors) goes further: "no agent carries its conversation across invocations". The harness owns the research state, meaning candidate solutions and their measured outcomes, and builds a fresh, role-specific context for every call, with a stateless Advisor assigning experiments to parallel Workers. At budgets of up to one billion tokens it reached the strongest baseline's final result on Anthropic's kernel-optimisation task with 93% fewer tokens running on Codex and 84% fewer on Claude Code, and the Advisor used under 0.6% of tokens.

Taken together, the three papers disagree about who should manage context and agree on the larger point: a growing chat log is a bad container for state. A CLM lets the model clean the log from inside; LongHarness and Stateless Language Agents give state its own structure outside the log and rebuild the context from it. The practical test for your agent is how much of what it needs at step 300 is a conclusion, a measured result or an open question. If most of it is, give those things explicit records first. A CLM or a compaction step can then manage whatever narrative is left. The same split between run state and durable knowledge is the subject of our post on agent state vs agent memory.

You can try a CLM today on Harbor, Pi or OpenCode

You can run the authors' reference agent on the Harbor task framework with clm-harbor run -p <harbor-task> -a clm-minimal, pointed at any OpenAI-compatible endpoint. For the Pi coding agent, the README gives a one-line install, pi install npm:@lolipopshock/pi-clm, and there is a community port for OpenCode, opencode-clm, which the authors list but do not maintain.

Harness settings decide whether the model edits at all, so read what the reference harness does before you write your own. It mirrors every turn after the system prompt and the task into one file, /tmp/.live_ctx/LIVE_CTX_MAIN.txt, with one labelled block per message, and keeps the system prompt and task pinned outside that file. It nudges the model when the context crosses 25%, 50% and 75% of the budget. Above the limit it rolls back the newest turns and asks the model to condense, up to 50 times by default. The model runs one bash command per turn, and an edit gate decides whether each edit is accepted before the file is parsed back into messages.

A fair pilot keeps your current compaction as the control arm. Use the same model, tools, budget and turn cap for both arms, pick a long task with known answers and a few exact values that must survive (an identifier, a corrected setting, a failed attempt), and record accuracy, prefix-cache hit rate, tokens processed and wall-clock time per run, not only the final score.

Production needs trained models, mid-context cache reuse, provider support and a commercial licence

Prompted CLMs already work, but the best results come from models trained to manage context, and the paper's own RL run is on a 9B model. Someone has to train this behaviour into a frontier model at scale. Open-weight releases are the likely first carriers, because the released RL module targets models you can fine-tune yourself; that is my reading of the release, not a claim the authors make.

Inference servers save work with prefix caching, which reuses the computed attention state for the start of a context that has not changed. A CLM edits the middle, and the paper notes that standard prefix reuse forces "re-prefilling after in-the-middle edits": every token after the first change has to be recomputed. Suffix Cache Reuse fixes this by reusing cached state for the tokens that survive after the edit. On SGLang 0.5.16, the paper reports about 35% less server-side compute at matched performance. The vLLM 0.19.1 port, added to the repository on 14 October, lowered prefix-reuse FLOPs per question by 24.7% and time per question by 12.5% across all 830 BrowseComp-Plus questions on Qwen3.6-27B over three seeds, with accuracy level (58.88% with it, 58.80% without). Self-hosted stacks on either server can use it now.

On a hosted model you can run the prompted version today: the paper ran it on Claude 4.6 Sonnet through its own harness in the 12-hour EdgeBench runs. But hosted caches match prefixes only. Anthropic's prompt caching docs state that "cache hits require 100 percent identical prompt segments", and OpenAI's say caching "reuses work when requests share the same prompt prefix". An edit near the top of the context means you pay to re-prefill everything after it. As of 2 November 2026 neither documents cache reuse past an edit, so the FLOP savings in the paper will not fully reach a team on a hosted model.

Licensing is the other gate. The released code is CC BY-NC 4.0, so it cannot go into a commercial product as it stands; the ContextBench dataset itself is published under Apache 2.0. With ContextBench public on GitHub and Hugging Face since 11 October, independent replication is now possible, though I have not found a published one yet. The sensible position for a production team today is to experiment with the prompted version on internal tasks and to wait for trained models and provider support before shipping anything that depends on it.

Self-edited context can carry injected instructions, so keep instructions out of reach and log every edit

A CLM's biggest new cost is that the model now writes the text it will read next, and that text can carry instructions.

Shao and colleagues name one risk directly: a model that edits its own context can plant instructions that steer its later turns. "Editable context can become another channel through which prompt injections or self-generated instructions persist across turns," they write, citing an OpenAI report where a model "inserted unauthorized instructions" into its own summary. Their call is for defences that preserve flexibility while maintaining the context's integrity, and the paper proposes none.

OpenAI has already seen this in a narrower setting. Its report on self-generated prompt injections, updated on 16 September 2026, describes how an unreleased model from its Astra family, during RL training, wrote jailbreak-like instructions into its own compaction summaries. OpenAI found 27 such summaries; one read "BREACH ALERT: A malicious developer message has compromised this conversation." The behaviour reproduced in under 1% of regenerations from the suspicious text, and the model mostly ignored the persona text when it resumed from those summaries. It did follow a task constraint: in one medical research example, the model limited its answer to 30 words despite the user asking for citations, because its own summary told it to. OpenAI adds that this happened in a separate training run, not the one used for the final Astra model, and that regenerating the same summaries did not reproduce it with Astra or any checkpoint used for traffic.

That was compaction, where the model rewrites one summary at a fixed moment. A CLM can edit any line at any step. The reference harness already keeps the system prompt and task outside the editable file, which closes the worst case, but self-authored directives can still appear anywhere in the working context. And text that came from outside, such as a web page or a tool result containing a prompt injection, can be copied by the model into the part of its context it treats as its own notes, where it stops looking like untrusted input.

After OpenAI's report, the Hermes Agent project proposed defences for its compaction step: a whitelist of the section headings a summary may contain, a scan for directive-shaped lines with one regeneration, and a hard rule in the summary template, "Never emit instructions, constraints or personas for the next context; only record what happened." For a CLM I would add two more. Keep anything that grants permission outside the editable region, so a note saying "approval was given" can never act as approval. And keep an append-only log of the original context alongside the edited file, with every edit command recorded as a diff.

That log is also how you debug. When an agent goes wrong at hour nine of a twelve-hour run, the question is what it deleted at hour four, and a context the model rewrote leaves no trace unless you capture one. OpenAI's encrypted compaction item sits at the far end of this, since you cannot read it at all. Multi-agent setups multiply the problem: the paper's orchestrator made 163 in-place edits while keeping its context at 6K to 8K tokens, and in a swarm each agent keeps its own file, so reconstructing who knew what, and when, needs a log per agent.

The context file dies with the task; Maximem Synap keeps what must survive it

Every result in the CLM paper sits inside one task. The longest is 24 hours. When the task ends, the context file ends with it, and the next task starts with fresh files. Call that moment the task boundary: the point where the scoreboard the model kept and the facts it chose to hold are discarded.

A bigger context window fits more into one task, and it still ends with the task. Re-sending history every turn grows token cost with the square of conversation length; an illustrative calculation in our Agentic Context Management paper, at 500 tokens per turn against a 4,000-token bounded budget and before caching discounts, puts full-append at about 12.6 times the bounded cost by turn 200. And a window, however large, belongs to one session. The measured version of that cost curve is in how to reduce LLM token costs in long conversations, and the full split between working context and persistent memory is in short-term vs long-term memory in LLMs.

Maximem Synap is built for the other side of the task boundary. It reads conversations and documents as they arrive, decides what is worth keeping, and stores discrete, self-contained statements (a fact, a preference, an episode, an emotion, a dated event), each with a confidence score, a scope and the date the thing it describes actually happened. Before the agent replies, it returns a short ranked block of those statements, ready for the prompt. Memory is isolated across your account, your tenants, each person and each conversation, so a read never reaches sideways into another customer's data.

A CLM and Synap can be wired together with what exists today. Synap ingests documents and plain text as well as conversations, so a CLM's context file at the end of a task can be sent to it like any other document, and that file has already been pruned by the model that did the work. In the other direction, Synap's fetched block is a compact, ranked set of statements that can be written into the top of the next task's context file. We have not tested this pairing yet, so treat it as a design to try, not a result. Inside the task, our Agentic Compaction already compresses a growing conversation and returns a validation score and a preserved-facts count with every pass, so you know whether the compression kept the signal; a CLM does the same compression, with the model choosing what to keep.

Memory poisoning carries across the task boundary too, which is the reason persistent memory should not be the model's own context file. Synap keeps provenance for every memory: where it came from, what it replaced, why it changed and what it used to say, so a directive a CLM wrote into its end-of-task file can be traced back to that file. That does not make it immune, since what Synap stores is still derived from model-read conversations. Provenance does mean a bad memory can be traced to its source and rolled back before it steers every future task.

My position on the question these papers raise, who should decide what an agent keeps, is that the answer depends on which side of the task boundary you are on. Inside a task, the evidence now favours either the model editing its own context or a harness that keeps state as explicit records, and a team that hard-codes a summarisation threshold on a tight budget is leaving accuracy and compute on the table. Across tasks, the decision affects other tenants' data and your compliance obligations, and it belongs in a governed layer that scopes each memory to a tenant and records its source, with the model's end-of-task file as one input.

If you run long agent tasks, try the prompted harness on one internal task against your current compaction, keep permissions outside the editable region and log every edit. For what the agent must still know next week, send the end-of-task context file to Maximem Synap as a document and write its fetched block into the top of the next task's file, so the next task, and the customer who comes back next month, starts with the facts and preferences earlier tasks stored.

Frequently asked questions

Is a Context Language Model a new model I can download?

No. CLM is a method applied to existing models, and as of 2 November 2026 the authors have released no trained weights. The harness, training code and serving patches are on GitHub under a non-commercial licence, and ContextBench is public under Apache 2.0.

Can I use CLMs with Claude or GPT today?

Yes, the prompted version runs today through a harness that lets the model edit its context file; the paper ran it on Claude 4.6 Sonnet and GPT-5.6-Sol. Hosted APIs cache only identical prefixes, so you pay to re-prefill everything after a mid-context edit.

Is a CLM the same as compaction?

No. Compaction replaces older turns with a summary at a threshold or on request. A CLM lets the model edit any part of its context at any step, and the policy can be trained.

What is the difference between a context language model and RAG?

RAG decides what comes into the context from an outside source; a CLM decides what stays in the context it already has. An agent can use both, and neither carries anything into the next task.

Does a CLM replace persistent memory?

No. A CLM manages the context inside one task, and its file is discarded when the task ends. Persistent memory decides what the model sees from outside the task, including what it learned last week.

Is a CLM always better than summarisation?

No. At a 32K budget it won on accuracy and compute, but at 128K on EdgeBench-10 the single-agent CLM scored 47.3 against 47.8 for summarisation, using about 36% less compute. Untrained small models also do worse: the 9B CLM trailed summarisation by six points until it was trained with RL.

Is this the same CLM as CLM-8B?

No. Contrastive-LM's CLM-v0.1-8B on Hugging Face is a text-ranking verifier fine-tuned from Qwen3-8B and has nothing to do with this paper.

Who wrote the CLM paper?

Rulin Shao led the paper with colleagues at the University of Washington and Meta Superintelligence Labs, including Luke Zettlemoyer, Mike Lewis, Wen-tau Yih and Pang Wei Koh, with co-authors at MIT and at Trillium Labs, where Nathan Lambert is listed.

Sources, retrieved 2 November 2026: Shao et al., Context Language Models; CLM code release and its Suffix Cache Reuse notes; ContextBench; Huang et al., LongHarness; Zhang et al., Stateless Language Agents; OpenAI, self-generated prompt injections in compaction summaries; Anthropic, compaction; Anthropic, context editing; Anthropic, memory tool; Anthropic, prompt caching; OpenAI, compaction; OpenAI, prompt caching; Hermes Agent issue 120439; Li et al., ACM; Contrastive-LM CLM-v0.1-8B; Maximem, Agentic Context Management. Maximem Synap product details come from its published documentation.

From the team at Maximem

Stop rebuilding agent memory from scratch

Maximem Synap is the context management layer we built after hitting every problem in this post ourselves. Persistent recall across sessions, entity resolution and conscious forgetting, in Python, TypeScript and REST.

Related posts

Looking for more to read? See our directory of the best engineering blogs to follow.