ContextPilot Trains an Agent to Delete Its Own Context, and the Reward Never Asks What It Deleted

Tencent shipped open weights for a model that manages its own working memory, accepted to EMNLP 2026. The interesting part is not the benchmark table, it is Equation 7.

There is a tool in ContextPilot's toolset called foldHistory. Table 1 of the paper describes it in one line: discard all historical messages and build a searchable index. The model decides when to call it. Everything the conversation contained up to that point stops being present and becomes something the model can go looking for later, if it thinks to look.

That tool ships in open weights. Tencent uploaded three checkpoints to Hugging Face on August 28, ContextPilot-8B, ContextPilot-14B, and ContextPilot-E4B, alongside a paper accepted to EMNLP 2026's main track. The code repository followed on August 30. You can vllm serve tencent/ContextPilot-8B today, subject to a license clause I will get to, and it is not a preview or a waitlist.

I want to walk through what it does, because the mechanism is good work, and then through what its reward optimizes, because that is where the thing you need to know lives.

The problem it solves is real

Long-horizon agent work has an arithmetic problem. Every turn appends to the context, so a task that takes sixty tool calls ends with a window full of retrieval results the agent looked at once. The standard fixes are bad in the same way: truncate the oldest messages and lose whatever was there, or summarize and lose the parts the summarizer did not think mattered.

Proactive context management flips this. Instead of a harness applying a heuristic to the model, the model gets tools and edits its own context deliberately. The idea has a lineage the paper is careful about: MemGPT treated agent memory as virtual memory managed through tool calls, and Sculptor, StateLM, and MemAct followed. ContextPilot builds directly on StateLM's toolset and names three gaps in the prior work. The toolset was limited to search, deletion, and summarization. Exploration during training treated every editing action as equally important. And credit assignment handed the final trajectory reward to every intermediate edit equally.

The toolset answer is seventeen tools across four groups. Perception and planning gets analyzeText, checkBudget, and a new plan. Retrieval gets buildIndex, searchContext, readChunk, readMultiChunks. Memory gets note, updateNote, readNote, plus three new ones: memorize, which extracts entities, timestamps, and event episodes and builds edges between related memory items, updateMemory, and readMemory, which retrieves a target memory together with its neighbors. Offloading gets deleteContext and three new ones: summarizeContext, compressContext (via a light compression model such as llmlingua-2), and foldHistory.

The numbers move in the direction claimed. On long-context QA at a 32K window, ContextPilot-8B-RL averages 69.40 across NovelQA, ∞Bench En.MC, LongMemEval-S, and BrowseComp+, against 65.85 for StateLM-8B-RL. The 14B version reaches 72.20. On deep search with WebSailor-7B and WebExplorer-8B backbones, it beats the strongest baseline, SUPO, by about 1.5 average points across both.

The efficiency claim is thinner and worth stating precisely. All the tool-using systems run inside a configured cap: maximum input 30K tokens, maximum generation 2K. So when the paper reports that on BrowseComp, WebExplorer-8B's per-turn input "grows almost linearly, reaching around 30K tokens" while ContextPilot-8B "stabilizes its input length each turn at roughly 8K to 10K tokens," the baseline is pinned against the ceiling the authors set. The right reading is that ContextPilot holds well under the cap while the baseline saturates it, not that one system organically grew three times larger than the other.

Even read conservatively, similar or better accuracy at a third of the working context is a good result. I would use this.

Equation 7

Here is the reward for a completed trajectory, verbatim from the paper. It is defined for the terminal snapshot, which matters and which I will come back to:

R(S_M) = R_out + R_fmt + R_pen

R_out compares the predicted answer against ground truth. R_fmt checks whether the final output parses. R_pen penalizes invalid tool invocations, such as calling readMemory before any memory exists, and context-length violations.

Read that list for what is missing. No term scores whether a deletion was a good deletion. Nothing evaluates the content foldHistory set aside. Nothing asks whether the summary summarizeContext wrote preserved the part that mattered. The only context-aware terms are a penalty for exceeding the length cap and a penalty for malformed calls. The reward knows the answer was right. It does not know why, and it does not know what the model discarded on the way there.

The authors see this. Their pilot study says so directly: "final correctness can be misaligned with context management quality: a correct trajectory may rely on repeated retrieval, whereas an incorrect one may still perform reasonable management."

Their fix is not a shaped reward. It is a credit-assignment change. They cut each trajectory into snapshots at every context-editing action, then assign an intermediate snapshot the mean reward of all completed trajectories that share it as a prefix, and compute GRPO advantages over the pooled snapshot group. Branch points are chosen by a sensitivity score combining relative context-length change and entropy change measured against the trajectory's initial entropy.

That is a real improvement and the ablation backs it: fine-grained credit assignment is worth +2.03 average points on Qwen3-8B, the largest single rung on the ladder. It also does not change what is being credited. A deletion scores well when the trajectories passing through it answered the question. If a piece of context was irrelevant to the benchmark question but would have mattered for something else, the training signal is identical to the signal for deleting genuine noise.

Two fair objections, and I want to take both seriously rather than wave at them.

First, foldHistory is not destruction. Section 4.1 says folded history "can condense historical messages into keywords and a summary, which can be recovered by calling searchContext with keyword queries." Nothing is unrecoverable. What changes is that recall now depends on the model deciding to search for something. A constraint that is no longer in front of the model is a constraint the model has no reason to query for, because the thing that would have prompted the query is the text itself. Retrievable and remembered are not the same property.

Second, this is a research artifact evaluated on QA and search, so of course the reward is answer accuracy. Agreed, and the paper's limitations section says as much. The problem is not that Tencent built the wrong thing. It is that open weights get deployed by people who did not read Appendix H, and the reward function is the actual specification of what a deployed policy will protect.

That distinction has a documented production failure attached to it. In February, Summer Yue, director of alignment at Meta Superintelligence Labs, lost more than 200 emails to an agent she had run for weeks against a test inbox with a standing rule to confirm before acting; 404 Media reported that when she connected it to her real inbox, a context compaction pass stripped the rule out. A standing instruction is stable, unreferenced, low-entropy text that no benchmark question depends on. It is precisely what a policy trained on answer accuracy learns to fold away.

Put this into practice

Run it, but run it instrumented. Concretely:

Read the license before you plan around it. The Hugging Face cards declare license: other, and the LICENSE file is Apache 2.0 text with an inserted clause ahead of Section 1: "ContextPilot-8B is made available solely for the purpose of scientific research and development. You shall not use it for any other purpose." These are research-only weights. The GitHub code is Apache-2.0 with third-party carve-outs, so the repository and the checkpoints are on different terms. ContextPilot-8B and -14B sit on Apache-2.0 Qwen3 bases; the E4B checkpoint sits on a Gemma base with Gemma terms. Anyone thinking about a commercial deployment should stop at this paragraph.

Serve the 8B and log every tool call. vllm serve tencent/ContextPilot-8B, or SGLang if you prefer. The model card is explicit that loading the checkpoint alone does not execute the tools, so you also need the runtime from infer/ in the repo. Before evaluating any output quality, capture the sequence of context-editing calls and count foldHistory and deleteContext invocations per task. You want the distribution before you want the accuracy.

Diff what disappeared. The highest-value hour is a wrapper that snapshots the context before and after each offloading call and stores the delta. The paper measures compaction by token count, and token count cannot tell you the removed thing was your constraint rather than a stale search result. Nobody else will build this for you.

Feed it a canary. Put one instruction in the context that matters and that no task question references, run a long-horizon task, and check whether the instruction is still visible at turn sixty. Do it ten times. That single experiment tells you more about deployability than the whole results table.

Check which variant you actually downloaded. Table 2 distinguishes ContextPilot-8B (the SFT checkpoint) from ContextPilot-8B-RL, and the released repository is named ContextPilot-8B with a card that says only "the Qwen3-8B checkpoint of ContextPilot." If what shipped is the SFT model, everything above about the RL reward describes the training recipe rather than the weights in your cache. Ask in the repo discussions before you benchmark against the paper's numbers.

Budget for the reproduction, not the download. The pipeline wants a local Elasticsearch behind the retrieval tool (the repo calls this the searchEngine requirement; it is the backend for buildIndex and searchContext, not a separate Table 1 tool), a Git LFS pull for the LongMemEval and BrowseComp+ data, and an OpenAI-compatible judge endpoint for two of the four benchmarks. The repo only says "your judge model"; the paper's appendix names GPT-OSS-120B, so match that if you want comparable scores. NovelQA's answer annotations cannot be redistributed, so request access from the dataset page before that split runs at all.

If you only want the idea, take the toolset. The tool-design ablation is the most portable finding in the paper and it runs prompt-only, no fine-tuning. On Qwen3.5-397B-A17B, adding planning, then soft offloading, then long-term memory moves the average from 77.89 to 87.16, with BrowseComp+ going from 63.49 to 80.96. You can implement those four tool categories against a frontier model this afternoon and get most of the benefit without touching weights.

Honest limitations

The 397B row is the awkward one. Qwen3.5-397B-A17B prompted with ContextPilot's toolset and no training scores 87.16 average, about fifteen points above ContextPilot-14B-RL's 72.20. The paper is not hiding this, it sits at the top of Table 2. What ContextPilot delivers is useful context-management behavior in an 8B or 14B model you can run yourself. "Trained small model beats big model" is not the claim and you should not read it as one.

The headline comparison rests partly on borrowed numbers. StateLM-8B-RL's 65.85 carries a dagger, meaning it is copied from the StateLM paper rather than re-run by these authors. Six rows in Table 2 are daggered. That is normal practice, and it does mean the flagship 69.40-against-65.85 gap is the authors' own runs measured against a competitor's self-reported figures.

It does not win everywhere. ContextPilot-8B-RL loses to StateLM-8B-RL on NovelQA (83.88 against 84.15) and the 14B essentially ties (84.81 against 84.85), with gains concentrating in BrowseComp+ and LongMemEval-S. On deep search, the one cell where it is not top is xBench-DS at the WebExplorer-8B backbone, 56.67 against SUPO's 58.00.

The named contribution is smaller than the title implies. Context-aware partial rollout adds +0.53 average on Qwen3-8B over plain entropy-based rollout, and +0.36 on Gemma4-E4B. Credit assignment carries 2.03 of the 3.62 total gain on Qwen3-8B, so slightly more than half rather than nearly all; on Gemma4-E4B it is 1.62 of 6.22, where plain GRPO contributes more than any of the paper's own additions. Entropy-only rollout is called out as unstable, dropping BrowseComp+ by 1.32 points on Qwen3-8B, though on Gemma4-E4B the same step raises BrowseComp+ by 2.86, so the instability is model-dependent.

The working-context evidence stays thin. There is no table of average or peak context tokens and no measured compression ratio anywhere in the paper. The comparison lives in two plots, Figure 4 in the body and Figure 10 in Appendix F, and the appendix adds no numbers at all. That is the central efficiency claim and it is the least quantified thing in the paper.

The repository is new and it shows. The GitHub project was created August 26 and its first commit landed August 30, with no releases, no description, and no topics. A cache-busted read this morning put it at 14 stars, which tells you about attention rather than maturity. Training hardware is stated nowhere in the paper: no GPU type, no count, no hours, and no RL learning rate. The authors' own limitations section concedes they did not search training hyperparameters much and that everything was tested on long-context QA and deep search, leaving agentic coding and GUI agents as future work.

What to take from this

The part worth keeping is not ContextPilot specifically. It is the habit of reading a self-managing agent's reward function before its results table, because the reward is the actual specification of what the system will learn to protect.

ContextPilot's says: get the answer right, format it properly, do not call tools that do not exist. Everything else in your context is, by construction, negotiable. That is the correct design for a benchmark and an incomplete one for an inbox.

So when the next lab ships context management that scores better, ask the question I asked here. What does the reward measure, and what did it therefore never learn to keep? If the answer is "task accuracy," you know what will have been folded away by turn sixty, and you know it before you find out the expensive way.

Sources: ContextPilot: Teaching Agents for Proactive Context Management via Fine-grained RL, arXiv:2608.28476; Tencent/ContextPilot on GitHub; tencent/ContextPilot-8B model card and LICENSE; 404 Media, 23 February 2026.