Let the model edit its own context
How self-editing differs from keeper, summaries and state files.
CLM gives the model an editable conversation. Here CLM means Context Language Model: the model can replace obsolete parts of its live transcript with useful state, rather than only appending new messages.
The model here is Qwen3.8-27B. CLM versus files explains the storage rules; model setup and prompts shows how the application makes each approach work.
CLM and keeper divide the work differently
CLM gives the working agent control over its context. Keeper gives that responsibility to the surrounding software. Both can use the same model. Keeper still uses a model to write notes; the working agent no longer has to choose when and how to make room.
| Aspect | CLM / self-editing | Keeper |
|---|---|---|
| Who acts? | The task agent requests edits. | The application makes room before the window overflows. |
| What changes? | Selected parts of the next prompt: messages, state or quotations. | Old turns become a short RULES / STATE / OPEN note plus recent turns. |
| What survives? | What the agent retains, plus any archive it is allowed to use. | Exact archived turns, refreshed notes and protected rules. |
| Rules | Depends on the agent and its safeguards. | Omitted rules are restored and repeated beside new questions. |
| Tradeoff | Flexible edits, with management work for the agent. | A fixed memory policy, with extra note-taking and search calls. |
In this lab, revised self-editing is more constrained than the paper's general CLM idea: update a protected state, then drop the processed batch. Adding an archive preserves the source. Keeper goes a step further by moving the memory-maintenance routine out of the working agent.
Keeper is not summary-free. It rewrites notes at each cut. The difference from a summary-only baseline is the searchable original history, protected rules and reminders at the point of use.
See the keeper workflow · Compare the keeper with agent-managed memory
What a CLM edit looks like
For example, the agent can replace “10 apples; add 3” with “apples: 13.” That keeps the current total. To answer who added them later, it must also keep that detail or save the original passage in an archive.
Summaries, notes and live edits
A periodic summary replaces a large portion of the conversation at a chosen threshold. Original CLM can make smaller, targeted edits: update a counter, delete a superseded log, or keep an exact quotation. In both cases, information removed without a saved copy is gone.
An ordinary plan file lives outside the live conversation. The model sees it when the application loads it. The CLM mirror is different: an accepted edit changes the message history sent on the next call. Merely saving a transcript file does not make this happen.
Measured results
With external data files forbidden, the first revision was faster but only one of its two runs was fully correct. A later revision checked the update script and reduced unnecessary thinking; it answered all 24 questions on both ledger seeds in 6.6 and 5.7 minutes.
121K ledger, seed 0; 24 final questions. Original self-editing lost five batches in a harness rollback. External data files were allowed only in the files arm. Different permissions and harnesses are part of this comparison.
Earlier CLM runs and their scores
| Self-editing agent | Correct | Time |
|---|---|---|
| Self-editing (CLM) | 19/24 | 64 min |
| Revised self-editing, run 1 | 24/24 | 15 min |
| Revised self-editing, run 2 | 21/24 | 21 min |
In the original run, the surrounding software discarded five batches after delivering them, and they could not be fetched again. That explains its five wrong answers. The model’s own state edits did not cause those misses.
The revised agent retained every batch. Its second run made a different mistake: the model rewrote its update script and stopped applying deletes from batch 17. That caused three wrong totals. Keeping data available and computing the answer correctly are separate requirements.
Later tests check every saved balance as well as the final answers. See the bookkeeping and historical-question results.
Related optimizations: old thinking and text cleanup
Why not just delete old thinking?
The model may have stored its working state there. Removing earlier thinking left one run repeatedly rebuilding its state, without a final answer after 2.6 hours. Keep explicit task state before attempting this optimization.
How much room did earlier reasoning use?
A median 9.9% of input across 277 calls in the initial key-value comparison, reaching 55.8% on one call. The stuck trial was a separate large-window ledger run. Measurements and outcome.
Can a small CPU cleaner solve the problem?
Conservative cleanup removed 1.83% of roughly five million tokens. That is too little to turn a 32K window into 100K. Moving large outputs to files saved more visible space, but later questions can require reading them back. Cleanup measurements.
Revised-agent details
Runs 1 and 2 used ledger seeds 0 and 1. They took 15 and 21 minutes, generated 67K and 91K tokens, and peaked at 20K and 15K active context. The harness protects delivered batches, checks room before reading and keeps explicit state visible.
The later verified-fold revision retains one update script and checks its self-test and handled-line count. With thinking only when needed, it scored 24/24 on both 121K seeds in 6.6 and 5.7 minutes. The earlier revision scored 24/24 on the separate 478K ledger in 8.2 minutes; code processed most of its batches.
Two-seed results and script-bug analysis · Original comparison · Run instructions
Paper and wider research
The Context Language Models paper introduced this editable-context approach and evaluated it on other models and workloads. The lab’s key-value generator and running ledger are local experiments, not the paper’s released benchmark or a reproduction of its headline scores.
Context Language Models paper · Authors’ implementation · CPU-cleaning census