There's a task in Terminal-Bench 2.0 called make-doom-for-mips. Several models that top the intelligence charts fail it outright. Cursor's Composer model reportedly solved it in 170 turns — and to get there it compressed a working context of more than 100,000 tokens down to roughly 1,000, more than once, without losing the thread. That single data point says something uncomfortable about how we've been thinking about agentic coding: the bottleneck isn't how much the model knows, it's how well it manages what it has already done.
I want to pull apart the mechanism behind that run, because it's a genuinely different design choice from the "bigger context window" arms race, and it changes how you should build long-horizon agents of your own.
The problem: trajectories outgrow the window
A coding agent doesn't answer a question, it runs a loop. Read a file, run a test, read the failure, grep for a symbol, edit, re-run. Each of those tool calls dumps output back into the context. A serious task — a real bug across a real codebase — is hundreds of these turns. The transcript blows past any context window long before the task is done.
The two standard fixes are both weak. Truncation — dropping the oldest turns — is amnesia by policy; the agent forgets a decision it made forty steps ago and re-litigates it. A bolted-on summarizer — a separate middleware pass that compresses the transcript when it fills up — is better, but it's a component the model was never trained to cooperate with. It compresses whatever it thinks matters, using a generic prompt, and the coding model downstream lives with whatever survived. In practice that means fat summaries (5,000+ tokens, with multi-thousand-token instruction prompts) that still drop the one detail the next step needed.
Both approaches treat context management as plumbing that sits outside the model. That's the assumption worth challenging.
The move: make summarization a trained action
The interesting idea in Cursor's approach is to stop treating summarization as preprocessing and make it a first-class action the policy is optimized for — trained directly into the model through reinforcement learning, inside the same agent harness real users run against.
Here's the shape of it. During RL training, a rollout isn't a single prompt-and-response. When the transcript hits a token trigger, the model is asked to summarize its own context, generates a condensed version, and the rollout continues from that summary. One training episode chains several of these generations together, stitched by the summaries the model wrote itself.
The reward is where it gets clever. The final task outcome — did the code work — is applied to every token in the chain, including the self-summaries. So a summary that preserved the critical detail gets upweighted alongside the actions it enabled; a summary that threw away something load-bearing gets downweighted because the run that depended on it failed. The model isn't told what a good summary looks like or when to write one. It learns both from outcomes.
# Training rollout, conceptually
state = initial_prompt
chain = []
while not done:
action = model.generate(state) # tool call, edit, or reasoning
chain.append(action)
if tokens(state) > SUMMARY_TRIGGER: # e.g. 40k or 80k
summary = model.summarize(state) # <-- a learned action, not middleware
chain.append(summary)
state = summary + recent_turns # keep going from compressed state
else:
state = state + observe(action)
reward = task_succeeded(chain) # 0/1 at the very end
apply_reward(reward, all_tokens_in(chain)) # summaries get graded too
Two consequences fall out of this that you don't get any other way.
First, you can train on trajectories longer than the context window. Because the chain is stitched by summaries, the learning signal can come from an episode of hundreds of actions even though no single forward pass ever holds all of it. The window stops being a ceiling on what the model can learn to do.
Second, summary quality co-evolves with coding ability. Because summarizing is scored by the same reward as coding, the model gets better at compression on exactly the tasks it's getting better at solving. A generic external summarizer can't improve this way — it has no idea whether its output helped the code compile.
The numbers that matter
Against a strong baseline summarizer, the trained-in approach cut errors by about 50% while using roughly one-fifth the tokens — ~1,000-token summaries from a minimal "please summarize the conversation" prompt, versus 5,000+ token summaries driven by heavy instructions. It also reuses the KV cache across the boundary, so the compression step is cheap rather than a full re-encode.
That efficiency is measured, not incidental. Cursor tested summary triggers at both 80k and 40k tokens; on their internal CursorBench the self-summary model produced significantly better results at both, and — the headline claim — held its accuracy roughly flat as context length grew. That's the property you actually want from a long-horizon agent: it doesn't quietly degrade the deeper it gets into a task.
The point isn't that the model has a bigger window. It's that the model was rewarded for being good at living within a small one.
This sits inside a broader bet Cursor has made on post-training. Composer's later revisions scaled reinforcement learning by roughly 20x on the same pretrained base, to the point where post-training compute reportedly exceeds what went into pretraining. Self-summarization is one skill that scaling buys you — and it only works because the skill is expressed as an action the RL loop can grade.
What to take from this if you're building agents
The transferable lesson isn't "add a summarizer." It's that the intermediate skills your agent relies on should be inside your optimization target, not stapled to the outside of it.
If you orchestrate an agent with a frontier API you don't train, you can't do RL on the summary. But you can steal the structure:
- Trigger compaction on a token budget, not a turn count — token pressure is the real constraint.
- Keep summaries small and let the model write them from a light prompt, then measure task success with and without your compaction step. If success drops, the summary is losing something; instrument what.
- Treat "did the summarized run still pass" as your evaluation metric, the way the RL reward does. That's the only signal that tells you whether compression is helping or quietly amputating context.
The next time an agent stalls on a long task, resist reaching for a bigger context window. Ask instead whether it was ever taught to forget well. Composer's result suggests that's the skill worth optimizing for — and that a model rewarded for compressing its own history will outrun a smarter model that was never asked to.
Sources: Training Composer for longer horizons — Cursor, How Kimi, Cursor, and Chroma train agentic models with RL — Philipp Schmid