Context Language Models: LLMs Edit Their Own Context

1 Context fills up: who decides what stays? CLM lets the model edit it

The longer an LLM agent runs, the faster its context (the full text the model reads at each turn) fills up. Search results, file contents and command output pile up turn after turn until they pass the limit, and someone has to decide what stays and what goes. Today that job usually falls to the harness (the program wrapped around the model that runs the agent loop and assembles each turn’s context), which summarises with fixed rules or hands the model a few pre-designed compression tools.

The Context Language Models paper proposes CLM: mirror the model’s current context into a file, let the model edit any part of it with Bash, and sync the edit straight back into its live context (the context actually fed to the model on the next turn). This is an interface design, not a new algorithm.

We start with the problem CLM tackles and how it works, then how the cost of editing context is counted and how text and RL can teach a management strategy, and finally check the evidence item by item, converting the abstract’s big numbers back to absolute terms. Anything marked as an invented example is a number or scenario I made up to explain a point; anything marked as my inference is my own judgement, not the paper’s text.

Paper: Context Language Models (arXiv 2609.37725v1, University of Washington / Meta, 9/2026).

2 Context management: from fixed rules to the model doing it

An agent searches, reads files and runs commands turn after turn, and the accumulated conversation and tool output eventually exceed the model’s context limit (most experiments in this paper use 32K tokens). Handling this is called context management. Three terms will come up again and again:

• harness: as above, the program around the model that runs the agent loop, calls tools and assembles the context fed to the model each turn.
• compaction: rewriting old history into a shorter summary.
• offloading and retrieval: saving content to an external file, keeping only a pointer in the context, and pulling it back when needed.

An invented example: a search agent runs 100 turns and pastes search results into the conversation each time; by around turn 40 the context is full. Now you must choose. Delete the old results outright? Squeeze them into a summary? Or save them to disk and pull them back when needed?

2.1 Two existing routes: harness-defined and action-based

Existing approaches split into two groups by who makes the call:

In the first group the model has no say at all; in the second it has a say but can only choose from a human-made menu. A finer when/how breakdown with references is in the first deep-dive at the end (optional).

2.2 The paper’s claim: hand the model the how, too

The paper argues that both routes share one ceiling: every operation the model can perform was designed in advance by a human. CLM pushes freedom to the limit, which gives three levels:

1. harness-defined: the model has zero control.
2. action-based: the model picks when; humans define the operations.
3. CLM: the model also decides how to edit.

The difference in practice (an invented example): the context holds 100 search results; results 30, 31 and 57 are useless and the rest must be kept verbatim. If the only tool is compress the whole history into a summary, the model has to compress everything, and the other 97 lose their original wording. CLM can write a tiny script that deletes just those three.

The paper cites Sutton’s The Bitter Lesson (a common argument in AI: general methods that scale with search and learning beat hand-crafted rules in the long run) as motivation, which is mostly rhetorical support. My inference (not the paper’s text): fewer limits also mean the model can break things, and whether that bet pays off depends on the experiments that follow.

2.3 ContextBench: today’s methods fail even simple management tasks

The authors first built a small test, ContextBench, that measures context handling alone, to show that existing methods fail even simple tasks. It deliberately needs no reasoning or knowledge: the task instructions say exactly what to do, so an agent that keeps everything would score perfectly, and any score gap reflects management ability only.

Difficulty is set by context pressure: the total task input divided by the context limit (32K). 1× means keeping everything exactly fills the window, 24× means the input is 24 times the limit, and anything below 1× is a control where keeping everything still fits.

Table 1 is the paper’s formal definition of the four tasks (input streams and scoring). Scoring only ever looks at the agent’s context: an answer that sits in a file but not in the context earns nothing.

The results are in the figure below: CLM clearly beats the other methods and comes close to full marks.

The paper names three causes of failure:

• Summary-style compression drops or invents information (Needle, Sudoku).
• Without in-place editing, every move means rewriting the whole Sudoku board.
• Ordinary tools can save data to a file but cannot actively evict it from the live context.

The pressure behind each difficulty level and sample messages sent to the agent are in the paper’s Figure 15 and Figure 16.

In short: existing methods either hard-code the rules or let the model pick from a human-made menu, and when that menu lacks edit in place and evict from context, even simple tasks fail. CLM wants to hand the how to the model as well.

3 Core mechanism: turn the context into an editable file

The method has four parts: the core context-as-a-file mechanism, a metric for cost, steering and evolving the management strategy with text, and training the strategy into the weights with RL. Only the first is the paper’s real claim; the last two are extensions of the idea that once management is the model’s own behaviour, it can be learned. This chapter covers the first.

3.1 From append-only to rewrite-anything

In one sentence: a standard LM can only append new content to the end of its context each turn, while CLM lets the model decide the full content of the next turn’s context.

Standard LM (the paper’s Eq. 1):

CLM (the paper’s Eq. 2):

• $c_t$: the full context the model sees at the start of turn $t$.
• $\oplus$: concatenation, appending the right side to the end of the left.
• $f_\theta^{\mathrm{LM}}(c_t)$: the new tokens the model generates from $c_t$.
• $f_\theta^{\mathrm{CLM}}(c_t)$: the paper says this can be any function; CLM itself decides how to turn $c_t$ into $c_{t+1}$.

Put simply: under Eq. 1 not a single word of the old context can change, and Eq. 2 drops that restriction. Eq. 1 is in fact a special case of Eq. 2: set $f_\theta^{\mathrm{CLM}}(c) = c \oplus f_\theta^{\mathrm{LM}}(c)$ and you get it back.

A standard LM is like a diary you can only add lines to at the bottom; CLM is like opening the whole document in a text editor, free to change any line. The analogy holds because that is exactly the difference: whether existing content can change. Under the hood, a context is simply the text fed into the next model call (general knowledge, not from the paper).

The paper calls $f_\theta^{\mathrm{CLM}}$ any function, but in practice it can only be Bash or code the model can write, which is the next subsection.

3.2 Implementation: the context is a file the model edits with Bash

In one sentence: sync the model’s live context into a file, let the model edit that file with ordinary Bash commands, and the edited content becomes the next turn’s context. The flow:

1. The harness writes the current context to a file whose path is given in the system prompt.
2. The model edits it with Bash or Python, like any other file.
3. As soon as the file changes, it syncs to the LLM server.
4. On the next turn the model sees the edited context.

If the model leaves the file alone in a turn, new tokens are appended as usual, which is the default behaviour of Eq. 1. The paper says this keeps both context reuse and editing flexibility.

In the paper’s overview figure, panel (a) shows management behaviours the model wrote, which is all you need for now; panels (b) to (d) show zero-shot, instruction-steering and evolution, and reinforcement learning results, which come up later one by one.

Take the 8,000-token block of search results from before (an invented example, styled after Figure 3 below). The model just runs a short Python script that uses a regular expression to replace turn 4 with a one-line note; the moment the file is written back, the context shrinks. No compress tool from the harness is needed.

import re
p = "/tmp/.live_ctx/LIVE_CTX_MAIN.txt"      # context file path given in the paper's Appendix E
s = open(p).read()
# replace turn 4 (8,000 tokens of search results) with a one-line note
s = re.sub(r"\[\[CTX_TURN 4 .*?(?=\[\[CTX_TURN 5)",
           "[[CTX_TURN 4 role=notes]]\nSearched: xxx. No relevant results.\n",
           s, flags=re.S)
open(p, "w").write(s)                        # written back = context already smaller

The paper observes the model inventing its own techniques, for example:

• Keeping a scoreboard in the context, with 163 in-place edits tracking the state of its child agents, while holding the context at just 6–8K tokens.
• Adding a new role, notes, that the template never had, for its own internal notes.
• Deleting useless search results in a loop, or defining its own helper compact_turns (called 37 times in one task).

3.3 Multiple agents: one context, one file

Several context files can exist at once, each synced to its own LLM server. An agent swarm (a group of agents working in parallel) is just several context files in the workspace; starting and ending a subagent (a child agent launched by the main agent) is just creating and deleting a context file. Panel (a) of Figure 3 shows the coordinating main agent (the orchestrator) using a status block to track each child context, subctx_0..4.

3.4 Caveat: a harness still helps decide when to edit

In the experiments, CLM also gets some harness help (the paper’s Appendix E, footnote 4):

• When 2,048 tokens are left before the budget limit, the harness sends a time-to-edit-your-context reminder. The paper’s reason is that current models do not know accurately how much context they have used (the paper’s Appendix G; see the section on models misjudging their context use, later).
• On BrowseComp-Plus (a deep-research benchmark of hard questions answered by searching a fixed corpus, BCP for short), CLM’s editing turns do not count toward the 100-turn cap, and when a request exceeds the budget the harness rolls back one turn and retries, up to six times.

The main text also does not explain the context file’s format or how syncing works, and does not count how often the model breaks the format; the deep-dive on the context file at the end has the details (optional).

In short: all of CLM is one file. The model edits it and sees the edited context next turn, but a harness still reminds it when to edit.

4 The cost of editing context: position decides how much is recomputed

CLM edits the middle of the context, which breaks the inference server’s cache, so comparing token counts alone is unfair. The paper defines its own prefix-reuse FLOPs to count the compute the server actually has to do (FLOPs are floating-point operations, a measure of compute). To follow it, first see how a server handles a prompt:

• prefill: the model reads the whole input prompt at once and computes each token’s intermediate state (the KV cache, short for key-value cache).
• decode: the model generates new tokens one at a time.
• prefix cache reuse: the server remembers the KV cache from the previous turn. If a new prompt starts with an identical stretch, that stretch is reused; from the first differing token onward, everything must be recomputed (re-prefilled).

An invented example (the idea is in the left half of the figure below): the context is [A B C]. If you only append, A, B and C are all reused and only the new part is computed. Change B to B’, and only A can be reused; B’ and C must both be recomputed, even though C has not changed by a single word.

The right half is SCR, which the paper proposes to soften this problem; the other-experiments section touches on it briefly later.

The paper’s formula counts just two things: the prefill compute for the stretch that missed the cache (from the first differing token to the end), plus the decode compute for the tokens the model generates. Put simply, count only the part the cache did not help with, plus the cost of generating. As the paper’s Eq. 3:

• First term: prefill compute for the unmatched suffix.
• Second term: decode compute for the generated tokens.

Appendix C of the paper works an example with Qwen3.6-27B (figure below). The paper notes these lengths were chosen for illustration, not measured:

The one thing to remember: cost is almost exactly tokens to recompute plus tokens generated, and the earlier the edit, the more you recompute. The reason is that in this example the fixed per-token cost (the MLP and projections, the parts of each layer that do not depend on context length, about $48.70\times10^{9}$ FLOPs/token) is about 86% of total compute (my own check from the paper’s numbers), while attention, which grows with context length, is only about 14%. Appendix C (Eq. 7–9) expands Eq. 3 into a full layer-by-layer count for Qwen3.6-27B; it adds nothing to the conclusion, so it is left out here.

5 No weight changes: steer and evolve the strategy with text

Once context handling is the model’s own behaviour, changing its strategy needs no harness code: just tell the model in text. This chapter has two steps: first, hand-written instructions; then, another model that rewrites those instructions automatically.

5.1 One sentence changes how the model manages context

The approach is direct: put an instruction or a skill document in the context (here a skill is simply a text guide that teaches the model how to do something). The only difference from Eq. 2 is that the model reads this extra text; there is no new mechanism. As the paper’s Eq. 4:

• $c_t$, $c_{t+1}$, $f_\theta^{\mathrm{CLM}}$: as in Eq. 2.
• $s$: that instruction or skill document, placed in the context.

Using BrowseComp-Plus questions and Claude 4.6 Sonnet, the paper appended a single instruction to the task message to test three behaviours (translations of the exact instructions are in the deep-dives at the end):

It is like giving staff a written procedure instead of changing the company’s workflow software: the first changes the text they read, the second changes hard-coded logic. The model conditions on the whole context every turn, and an instruction is just one stretch of tokens in it; that is in-context learning (general knowledge, not from the paper).

5.2 Let another model rewrite the instructions

The instruction $s$ above was hand-written. This step lets another model read the agent’s successes and failures and rewrite $s$ to be better, round after round.

The goal: change neither the model weights nor the harness, and search only for the text that gives the agent the highest average score. As the paper’s Eq. 5:

• $s$: the text of that instruction (skill).
• $x$, $\mathcal{D}$: one task instance, and the distribution of tasks.
• $\tau(x; s)$: the full trajectory of the agent solving $x$ with $s$ (from Eq. 4).
• $R(\tau)$: that trajectory’s score, from the task’s automatic grader.
• $\arg\max_s$: find the text with the highest average score.

One round of the loop:

1. Run the current skill on the training set as a rollout (letting the agent actually work the whole task through).
2. A proposer (another model whose job is rewriting the skill) reads those successful and failed trajectories and writes several new candidate skills.
3. Candidates are screened on 6 training questions, the survivors run on 12 more, and the rest are scored on a 102-question development set (dev).
4. Pick the next round’s skill and repeat; stop after 5 proposals in a row with no improvement.
5. The final skill is scored once on the test set (test).

Two setups: assisted evolution uses Qwen3.6-27B as the agent and Claude Fable 5.1 as the proposer; self-evolution uses Opus 5 as both agent and proposer.

Results for the KV Store task, assisted setup, are below. Dev is the set used to pick skills; test is scored once after the choice is final and played no part in selection:

• The abstract’s gain of up to 35.9 points is exactly 74.2 − 38.3: the best test result, for the single KV Store task in the assisted setup (my calculation).
• For the other three tasks the text gives only dev numbers: Needle Retention 97.6% to 100.0%, Sudoku Sketchpad 45.3% to 65.8%, Log Triage 0.0% to 100.0%. Dev was also used to pick the skill, so these are optimistic.
• Self-evolution: Opus 5 already starts between 94% and 100%, and the evolved skill either cuts cost at the same accuracy or raises accuracy further.

The next figure uses the term Pareto frontier: the set of skills for which no other skill is both more accurate and cheaper.

Evolution results on all four tasks (Figure 8)

Results on all four tasks are below: assisted evolution on the top row, self-evolution on the bottom.

The evolution loop is like a coach rewriting the playbook after watching game film and sending the team out to try it. Under the hood it is hill-climbing in text space with an LLM as the mutation operator, with no gradients (general knowledge, not from the paper). The matching method the paper cites is GEPA (Agrawal et al., 2026, Reflective prompt evolution can outperform reinforcement learning).

Evolution changes text in the context; RL, next, changes the model’s weights. Both learn a management strategy.

6 Changing the weights: RL that learns to edit context

The previous chapter changed text in the context; this one changes the model’s weights, so the model learns to edit its context from whether it got the final answer right.

6.1 GRPO stays; two things change

GRPO (Group Relative Policy Optimization) is an RL algorithm (from DeepSeekMath, Shao et al., 2024). For each question it first samples a group of complete trajectories, and each trajectory’s advantage is how much better or worse its score is than the group average: subtract the mean, then divide by the standard deviation.

Here $r_i$ is the score of trajectory $i$. The formula is general knowledge; the paper only says standard GRPO advantage and does not write it out.

An invented example: sample 4 trajectories for one question, scoring 1 for right and 0 for wrong, with scores 1, 0, 0, 1. The mean is 0.5 and the standard deviation 0.5, so the advantages are +1, −1, −1, +1. Right answers are encouraged and wrong ones discouraged.

CLM’s training keeps this recipe and changes only two things:

1. Preparing the inputs: CLM edits its context, so the final context is no longer what an early step actually saw. The paper computes each model call separately, with the context that call really saw (stepwise GRPO), and gives every call the whole trajectory’s advantage unchanged. This is not new: Appendix A says it follows ReSum and Sculptor. Any agent that rewrites its history (summaries, folding, CLM) faces the same problem when trained with RL.
2. The advantage gains an efficiency term (next subsection), which is the paper’s own new design.

6.2 The efficiency reward compares only runs that succeeded

An outcome reward only knows right from wrong, which is weak supervision for how well the model edited: a correct trajectory can contain clumsy edits and a wrong one good edits. Rewarding the number of edits or tokens deleted directly invites gaming: the model may make pointless edits, delete important information, or break prefix reuse, which is called reward hacking. So the paper adds or subtracts points by cost (prefix-reuse FLOPs) only among trajectories that already got the answer right, a design called success-gated: only successful trajectories enter the efficiency comparison.

Put simply: among correct trajectories, those cheaper than average gain points and those more expensive lose them; wrong ones are left out entirely. As the paper’s Eq. 6:

Then combine:

• $g$: the group of trajectories sampled for one question.
• $\mathcal{G}_g^{+}$: the correct trajectories in that group.
• $c_i$: the prefix-reuse FLOPs of trajectory $i$.
• $\bar{c}_g$: the average cost of the correct trajectories.
• $\mathrm{clip}(\cdot, -1, 1)$: limits the result to between −1 and +1.
• $A_i^{\mathrm{out}}$: the standard GRPO outcome advantage. $w_{\mathrm{eff}}$: the weight, 0.25 in the paper’s Appendix E.
• If fewer than 2 trajectories are correct, $A^{\mathrm{eff}}$ is set to 0 for the whole group.

A full worked example (invented, cost in arbitrary units): sample 4 trajectories for one question. $A^{\mathrm{out}}$ differs from the earlier example because 3 of these 4 are correct; the last column is $A^{\mathrm{out}} + 0.25 \times A^{\mathrm{eff}}$.

The arithmetic: the average cost of the correct ones is $\bar{c} = (2+1+3)/3 = 2.0$, so $\tau_2$ gets $(2-1)/2 = +0.5$ and $\tau_4$ gets $(2-3)/2 = -0.5$. The $A^{\mathrm{out}}$ column uses subtract the mean, divide by the standard deviation (the paper gives no formula). Two points: $\tau_3$ is the cheapest but wrong, so it gets no efficiency bonus, which is what success-gated does; and the efficiency term is a small ranking term, $0.25 \times (\pm 0.5) = \pm 0.125$, far smaller than the gap between right and wrong.

How the efficiency score lands on each step is not spelled out in the paper. This is RL’s credit assignment problem: a trajectory has many steps but ends with one score, so how much credit or blame does each step get? The open question is whether the efficiency term goes to every token in the trajectory or only to the tokens that edit the context; a deep-dive at the end covers it.

6.3 Results: accuracy ties, cost drops by about four tenths

• Model and data: Qwen3.5-9B, trained for 70 steps on 3,040 questions from the OpenResearcher dataset and evaluated on all 830 BrowseComp-Plus questions. The reward is a binary right/wrong score from GPT-5.4-nano using the DeepSearchQA rubric (grading guidelines).
• CLM: a 28K context budget (2,048 tokens reserved), at most 80 turns, editing turns not counted; plus the efficiency advantage (weight 0.25, which the paper’s Appendix E says is applied to context-handling tokens) and penalties for failed tool calls and format errors.
• Baseline Summary: the agent accumulates context as usual; at 28,672 tokens, everything except the system prompt and task message is replaced by one summary (written with Codex’s summary prompt), for at most 100 turns. Both when and how to summarise are fixed by humans; Appendix E says it is trained with the task reward only. The paper does not say who writes the summary.

Table 2 is the paper’s original; below it, the before/after changes are listed for easy comparison. Acc. is BrowseComp-Plus accuracy; PFLOPs/Q is the average prefix-reuse PFLOPs per question ($1\ \text{PFLOP} = 10^{15}$ FLOPs), lower is better.

• Before training, CLM trails Summary by about 6 points. The paper blames the small model’s weak context handling; its Appendix F also says Qwen3.5-9B rarely edits its context (on TerminalBench 2.1, a set of terminal tasks, 1.4 edits on average, with half the tasks never edited). So CLM’s zero-shot results depend on the model’s own judgement.
• After training, accuracy is effectively tied (42.5 versus 42.1), and CLM costs about 38.8% less per question ($(2.19 - 1.34) / 2.19$, matching the paper’s introduction). The training curves are below.
• The abstract’s 47.6% gain is relative (42.5 divided by 28.8), from a very low start; the absolute gain is 13.7 points. Against the trained Summary it wins by only 0.4 points; the real difference is cost.

In short: RL lets the 9B CLM catch the trained Summary. Accuracy ties and the difference is cost, though with different reward designs on each side that cost gap may not be like for like.

7 The four parts in one table

Before the experiments, here are the four parts in one table, each with the caveat most worth remembering:

How they fit together: the first part makes the context editable, the second gives a yardstick for editing cost, the third improves the strategy with text without touching the weights, and the fourth changes the weights to learn the strategy (its efficiency reward uses the second part’s metric directly). The third and fourth learn the same thing and differ only in where it is stored: in the context’s text versus in the weights.

8 Main evidence: off-the-shelf models, zero-shot, against the strongest fixed pipeline

The paper’s main evidence is zero-shot: no training, no evolution, just stock models run the CLM way and compared with other context-handling methods. RL and skill evolution are two separate sets of results that do not overlap (see the last deep-dive at the end). First, the benchmarks:

• BCP (BrowseComp-Plus): a deep-research benchmark of hard questions answered by searching a fixed corpus; measures accuracy.
• TB2.1 (TerminalBench 2.1): 89 terminal tasks, each simply pass or fail. TBLite is its lightweight version.
• EdgeBench-10: 10 repository-optimisation tasks taken from EdgeBench, run for 12 hours and scored 0 to 100.
• Software World: 6 interdependent repositories optimised by an agent swarm for 24 hours, measured by speedup on unseen downstream packages.

8.1 BrowseComp-Plus and TerminalBench: a relative 11.4% is about 6 points

Every method uses the same model (Qwen3.6-27B), the same agent framework (Mini-SWE-Agent), a 32K budget and a 100-turn cap. The rivals are Base (no management at all), Summary, MEM1, Self-Compact, ACM and RLM (a method that treats long inputs as variables the model reads on demand). Versions with other model sizes are in the paper’s Figure 17.

The clean comparison is CLM against the strongest rival, Summary:

The 11.4% higher in the abstract and introduction is relative; in absolute points it is about 6. The real accuracy wins are on BCP and TBLite; on TB2.1 CLM wins only on cost.

8.2 EdgeBench-10: the budget decides the size of the edge

The agent optimises one repository continuously for 12 hours in a container with no network; each submission is scored 0 to 100 by the EdgeBench grader, and a run’s score is the higher of its best submission and its final repository. Each task is run three times (three random seeds) and the best one is taken (best-of-three). PF is the average prefix-reuse PFLOPs per trial. The comparison covers Base, a Codex-style summary, CLM, and CLM with up to five concurrent subagents.

Panel (a) below is EdgeBench-10 at a 32K budget; panel (b) is Software World, which comes up under other experiments. The 128K version is in the paper’s Figure 19.

Three readings:

• At 32K CLM clearly wins: +2.3 points on Qwen at about 4 tenths of the cost. The abstract’s 5% higher, 59% fewer FLOPs comes from exactly this cell (44.6 divided by 42.3 is about +5.4%; 179 divided by 437 is about 41%), the single best-looking setting.
• At 128K the accuracy edge disappears: CLM 47.3 versus Summary 47.8, with only about 36% compute saved ($(222 - 142) / 222$). A reasonable inference (not the paper’s text): with a roomy budget there is less pressure to manage, so the strategies differ less.
• Subagents bring no consistent gain: nothing at 32K, and +2.9 points at 128K but with compute similar to Summary. The paper itself says subagents help little on a single repository.

Taken together: CLM’s edge is largest when the budget is tight and context pressure is high, and with a larger budget it shrinks to cost savings. That is much narrower than the across-the-board lead the abstract describes.

8.3 Other experiments: supporting evidence and what CLM depends on

The four sets below are supporting evidence and get a light touch: math optimisation, Software World, model size, and context-length awareness. On math optimisation problems, CLM is compared with OpenEvolve (an evolutionary workflow built specifically for this kind of problem) in Table 3.

• Math optimisation vs OpenEvolve (Table 3): meant to show a general agent with CLM can beat a specialised evolutionary pipeline. CLM is best on all four problems: circle packing 2.618 versus 2.541 (+3.0%), Heilbronn 0.03653 versus 0.03127 (+16.8%), and on the other two the gap is only in the third or fourth decimal place. Caveat: each method ran once, best result taken; the two tiny gaps are not evidence, and Heilbronn’s 16.8% is relative.
• Software World, a 24-hour agent swarm (panel (b) of Figure 11): meant to show gains transfer to unseen downstream packages. Geometric-mean speedup on 17 unseen benchmarks, labelled about 1.044 for CLM and about 1.026 for Summary in the plot: about 1.8 percentage points more in absolute terms; the paper’s 65% more is a relative figure. Caveat: the model is GPT-5.6-Sol with a 272K budget, not the 32K setup from before; the text does not say how many runs.
• Model size (the paper’s Figure 17, Appendix F): shows CLM’s effect depends on whether the model can judge when to edit. Qwen3.5-9B edits only 1.4 times on average on TB2.1 and never edits in half the tasks; Qwen3.6-27B edits 2.6 times on average. The 9B model’s median peak context is 30.2K (limit 32K), the 27B model’s 17.6K. Caveat: the 9B zero-shot results should not be read together with the pre-training results in the RL chapter; see the next paragraph.
• Context-length awareness (the paper’s Appendix G, Figure 12 in the next section): shows current models are poor at estimating how much context they have used, hence the need for environment reminders. Without a hint the estimates are far off; with a token-count hint the error drops clearly. Caveat: tested on only 50 inputs, and not on Qwen3.6-27B, the main model.

On the model-size item: the paper’s Appendix F says the 9B model scores 39.9% zero-shot with CLM on BCP, above Summary’s 37.7%; but Table 2 in the RL chapter says the 9B model’s CLM scores 28.8% before training, below Summary’s 34.7%. The settings differ (zero-shot: 32K, 100 turns; RL evaluation: 28K, at most 80 turns). This is my inference; the paper does not point out the difference.

How to read these four: the first two are supporting evidence that CLM is better, but neither is a controlled experiment: single runs, small margins, or a different model and budget. The last two are evidence of what CLM currently depends on: a strong enough model, and outside reminders.

As an aside, SCR (Suffix Cache Reuse) in the right half of Figure 4 is the paper’s serving-side proposal: after a mid-context edit, still reuse the cache of every surviving token to cut re-prefill. The paper also benchmarks SCR against standard serving, but this post does not go into those experiments; see the original paper if you are curious.

8.4 Models cannot tell how much context they have used

For the model to decide on its own whether to compress now, it first has to know how many tokens it has used. The paper’s Appendix G finds current models are poor at estimating this. The measure is MAE (Mean Absolute Error): the gap between the estimate and the real token count, taken as an absolute value and averaged, in tokens; smaller is better. In the figure below each dot is one estimate against the real prompt length reported by the server; the panels show no hint, and a token-count anchor placed at 25%, 50% or 75% of the input.

The small text in the figure is hard to read, so the legend numbers are collected in the table below. They come from the legend; this post did not check the original figure point by point, so trust the original:

The paper’s text draws three conclusions: with long contexts, estimates land on a few recurring numbers (such as 6.2K and 9.8K); a token-count hint lowers the error; and the closer the hint to the point of estimation, the better. That the recurring numbers may come from counting habits in pretraining is the paper’s own guess, untested. This is why the harness adds reminders: the reminder in the experiments (2,048 tokens left), and the [context: ~N/M tokens] readout in the ContextBench skill excerpt (the paper’s Table 4), both fill this gap.

A transferable rule (my inference, not the paper’s text): any resource (tokens, time, money budget) should be measured by the environment and reported with every tool result; reporting close to the decision point, every turn, works better than saying it once at the start.

for each tool_result:
    result += f"\n[context: ~{count_tokens(ctx)}/{limit} tokens]"

In short: on a tight 32K budget CLM reaches similar or better accuracy at lower cost (tied on TB2.1, ahead on BCP, TBLite and EdgeBench); on EdgeBench, raising the budget to 128K erases the accuracy edge and leaves only the savings. CLM also depends on two things for now: a strong enough model, and outside usage reminders.

9 Verdict: worth trying, evidence shows potential only

The verdict first: research value is moderate to low; engineering value is that the idea is worth trying, but the evidence only shows potential.

Research value: the contribution is an interface design, not a new algorithm. Giving the model write access to its own context is simple and general, and it pushes both the when and the how to the model; that is its most durable part. But almost everything underneath is off the shelf: the RL is GRPO plus ReSum- and Sculptor-style segmentation (Appendix A says so itself), and the skill evolution is GEPA-style. The only genuinely new piece is the success-gated efficiency advantage, with a weight of just 0.25, and the paper does not make clear how it reaches the tokens.

Engineering value: the strongest evidence is that on a tight 32K budget, a stock 27B model used zero-shot beats the fixed pipeline (about +6 points on BrowseComp-Plus; +2.3 points on EdgeBench-10 with only about 4 tenths of the compute). The weakest point: no experiment separates the credit for free editing from the harness help, and at 128K the accuracy edge disappears, leaving only savings. So what we can say is that the whole design pays off on a tight budget, not that context as a file is itself the main cause.

9.1 The abstract’s claims, restated cleanly

What you can trust is that on a tight budget CLM reaches similar or slightly better accuracy at lower cost; what you cannot trust is the impression of a sweeping lead the abstract gives. In every row, the abstract uses whichever relative number or setting looked best.

9.2 Weaknesses across the paper

• The credit for free editing is never separated from the harness help: CLM gets uncounted editing turns, rollback and retry, and the reminder at 2,048 tokens left, and no experiment turns this help off; the zero-shot experiments also do not give CLM’s system prompt or skill content, so we cannot see how much credit goes to a well-written prompt. This is the most important point: it decides whether CLM’s win can be credited to the idea itself.
• No variance and no repeat counts: math optimisation ran each method once; EdgeBench takes the best of three seeds with no error bars; Software World does not say how many runs. So 44.6 versus 44.2, RL’s 0.4-point win, and the third-to-fourth-decimal math gaps cannot be told apart from noise. No win within about 2 points should count as evidence.
• The evidence is stitched together, not one line: zero-shot uses Qwen3.6-27B and Claude 4.6 Sonnet, RL uses Qwen3.5-9B, skill evolution uses Opus 5 or Fable 5.1 as proposer, and Software World uses GPT-5.6-Sol. No single model goes through the whole story.
• Home-made benchmark and home-made metric: the authors built ContextBench themselves; the FLOPs are a self-defined theoretical count, not real latency or a bill.

One more structural point: CLM beats the strongest existing method (stock 27B, zero-shot) and CLM can be trained to improve (9B with RL, or skill evolution) are two separate bodies of evidence that do not overlap. The paper never shows that a trained or evolved CLM is stronger on long tasks; the last deep-dive at the end has the details.

9.3 When handing the model this freedom pays off

When is it worth handing the model this freedom? What follows is my own judgement from combining the paper’s evidence, an inference, not the paper’s text:

One overreach to avoid: all three at once is a combination I made up. The paper never tested how the three interact; it is a rule of thumb for where to start trying, not a requirement.

9.4 Security risk: context the agent writes and reads back

Section 6 of the paper notes that an editable context could become a channel for injected prompts or self-generated instructions to persist across turns. It cites an OpenAI report: a model once inserted unauthorised instructions into its own compressed summary, which affected later behaviour. The paper runs no experiments and proposes no defence, saying only that this is future work.

The mechanism (an invented example):

1. A tool result (a web page, say) hides a malicious instruction.
2. The agent writes it into its own notes or summary.
3. Next turn it reads that back and treats it as its own plan.
4. The instruction keeps working.

In later turns such content looks like something I wrote myself, which makes it harder to spot than a one-off injection. The OpenAI case, where the model added instructions itself, is a variant of external injection, but the persistence path is the same.

Transferable rules (my inference, not the paper’s text):

• Anywhere the model can write and later reads back (summaries, notes, memory, CLM’s context file) is a persistence channel, not just in CLM.
• CLM’s attack surface is larger than a summary’s, because its edits are unrestricted.
• What the paper leaves out: whether the context file includes the system prompt, and whether the model can delete its own instructions.

In short: what you can trust is lower cost for similar or slightly better accuracy on a tight budget, not a sweeping lead; and this freedom also opens a security channel the paper has not dealt with yet.

10 Conclusion: what to take away

What is most worth remembering from this paper is not any percentage but the way it splits context handling apart: when to act and how to act are two separate things. Earlier methods locked one or both in human hands; CLM hands both to the model. On a tight budget the claim has evidence behind it, but that evidence is mixed with the harness’s helper design and comes with no variance; so it is a design option worth trying seriously, not a proven best practice.

The paper’s first contribution: context-as-a-file, giving the model write access to its own context. A standard LM’s context can only grow at the end, so every keep-or-drop decision falls to the harness. Earlier attempts let the model take part, but what it could do was still limited to a human-designed menu (compress, offload, retrieve); this paper removes that limit, and the model decides the kinds of operations itself (delete one item, delete in bulk, write a helper function, add a notes role, none designed in advance).

This is the most durable part: the idea is simple, general and independent of any particular model or benchmark, so any agent that can write code can use it, and it naturally opens the routes of steering, evolving and training context handling. But it is a design choice, not a new algorithm, and the paper does not directly show it beats a fixed pipeline with a good prompt.

Second contribution: the success-gated efficiency advantage (Eq. 6). Adding or subtracting points by theoretical cost only among correct trajectories solves the problem that an outcome reward cannot tell good edits from bad, while rewarding edit volume directly invites gaming. It counts only as a small contribution, for three reasons: its weight is just 0.25; similar designs already exist elsewhere (Appendix A mentions Arora & Zanette, who penalise length only on correct answers, and DDCA), the only difference being FLOPs as the cost; and the paper does not make clear how the term is split across tokens.

There is also a narrow but credible empirical result (the zero-shot results on a tight 32K budget), but numbers like these go stale as models and benchmarks change; what lasts is the first two contributions and the ideas below that hold beyond this paper.

When it pays off is covered in the section on when handing over this freedom pays off; beyond that, the three most general ideas are: the cost of editing a context depends on where you edit; compare a secondary goal only within the set that met the target; and data used for selection cannot be used to report results. All three still hold when you swap the model or the benchmark, and each has a section in the going-further chapter at the end.

• Next time you see a context-handling method, ask two questions: who decides when to act, and who wrote the operations? CLM is the kind that answers the model to both, at the price of a harness reminding it on the side.
• Convert paper numbers back to absolute terms first: 11.4% higher is about 6 points, a 47.6% gain is 13.7 points; on EdgeBench, raising the budget to 128K erases the accuracy edge.
• When you build agents: edit the context near the end where you can (in the paper’s appendix example, editing the start costs 7.7 times as much as appending); compare efficiency only among successful attempts; and never report the score you used to pick a prompt.

11 Going further: four ideas that hold beyond this paper

The four sections below are optional: each stands on its own without the paper, and each is collapsed, so open whichever you want to dig into.

11.1 Keep, compress, offload or delete a chunk of context

# inference: decision order combining the paper's three failure causes and the four ContextBench tasks (not the paper's text)
def decide(chunk):
    if chunk.needed_verbatim_later:
        return KEEP if chunk.small else OFFLOAD_TO_FILE   # after offloading, keep only a pointer in context
    if chunk.structured and chunk.edited_in_small_pieces:
        return EDIT_IN_PLACE                              # e.g. a game board, a status table
    if chunk.only_gist_needed:
        return SUMMARIZE
    return DELETE

11.2 Edit cost depends on position

11.3 Compare a secondary goal only among successes

correct = [t for t in group if t.success]
if len(correct) < 2:
    eff = {t: 0 for t in group}                 # nothing to compare
else:
    mean_c = mean(t.cost for t in correct)
    eff = {t: clip((mean_c - t.cost) / mean_c, -1, 1) if t.success else 0 for t in group}
A = A_out + w_eff * eff                         # the paper uses w_eff = 0.25

11.4 Data used for selection cannot report the score

12 Concept deep-dives: five things worth looking up again

The five sections below are optional, and they are the parts most easily forgotten and most worth looking up again. Each is written to hold beyond this paper and is collapsed, so you can open any one on its own.

12.1 When and how: the two axes of context management

12.2 The context file is source code: the risk of broken markers

12.3 Credit assignment: splitting one score across steps

12.4 The three steering instructions the paper used

12.5 Zero-shot, skill evolution, RL: three separate bodies of evidence