Window size isn’t the lever. JetBrains Research tested two ways of managing a coding agent’s context - observation masking and LLM summarization - on SWE-bench Verified, 500 real GitHub issues an agent must resolve end to end. Both cut cost over 50% versus letting context grow unmanaged; masking did it while also improving solve rate, not just holding it steady.
A bigger window doesn’t buy that on its own: models can still lose track of earlier details in a long run, and an agent’s own accumulated output becomes noise well before it hits any token cap.
Definitions
Observation masking - replacing the tool output (the “observation”) in older turns with a placeholder, so the record of what the agent tried stays but the raw output it saw doesn’t; some implementations drop specific turn types, like failed retries, outright. The older technique; used by SWE-agent with a rolling window.
LLM summarization - a separate model call that compresses past reasoning, actions, and observations into a short summary. Used by OpenHands, Cursor, and Warp. Newer and more sophisticated, and in principle scales indefinitely without ever hitting the context limit.
Effective context - the portion of a window actually carrying useful signal. JetBrains Research frames the problem directly: an agent’s effective context stays small even when the nominal window is enormous, because every generated output, dead ends and retries included, stays in the log.
A bigger window doesn’t fix this
Nominal context windows keep growing across vendors:
| Model | Context window | Source |
|---|---|---|
| Magic AI (dev) | 100M tokens | Coursera |
| Google Gemini 3.1 | 1M in / 64K out | Coursera |
| OpenAI ChatGPT-5 | 400K tokens | Coursera |
| Anthropic Claude Pro | 200K tokens | Coursera |
A 1M-token window holds roughly 750,000 words, on the order of 10 to 15 novels. Google already proved the payoff in an earlier generation: Gemini 1.5 Pro translated English into Kalamang, an endangered language with fewer than 200 speakers, using nothing but a grammar manual as in-context reference, at human-level quality. Scale alone clearly buys real capability.
But scale doesn’t fix the failure mode that matters for agents. Models can still forget things discussed earlier in a long conversation, and for a coding agent specifically, every turn adds its own output back into the log - successful edits, failed attempts, and retries alike. That accumulated noise doesn’t get cheaper just because the ceiling moved from 200K to 1M tokens - a bigger window only delays when the same failure mode kicks in.
Symptom, cause, solution
Symptom. Coding-agent cost climbs turn over turn, and task runs stretch longer without the solve rate improving to match.
Cause. The agent’s own generated history accumulates without pruning - reasoning, tool calls, every observation. Most of it stops being useful the moment the next action succeeds or fails, but it stays in context and gets billed on every subsequent turn regardless.
Solution. Manage what stays. JetBrains Research tested this directly: 500 instances of SWE-bench Verified, Qwen3-Coder (32B–480B) and Gemini 2.5 Flash, capped at 250 turns per task.
| Approach | Mechanism | Result on Qwen3-Coder 480B |
|---|---|---|
| Unmanaged | Full history retained | Baseline cost |
| Observation masking | 10-turn rolling window, older turns hidden | 52% cheaper, solve rate +2.6% |
| LLM summarization | 21-turn batches, 10 most recent kept, rest compressed | Over 50% cheaper than unmanaged, but runs ran 13% longer than masking |
| Hybrid | Masking by default; summarization only once context becomes unwieldy | 7% cheaper than pure masking, 11% cheaper than pure summarization, up to $35 saved across the full 500-task run |
Observation masking matched or beat LLM summarization in 4 of 5 settings JetBrains tested across model sizes (32B–480B parameters) and thinking modes (with/without extended reasoning). The reason masking usually wins: summaries can smooth over the signals that would tell an agent to stop, so summarization runs went 13% longer than masking on Qwen3-Coder 480B (15% longer on Gemini 2.5 Flash). Summarization also isn’t free to run - the summarizing calls themselves added more than 7% of total cost per instance.
Which to use
Start with observation masking - it’s simpler, cheaper than LLM summarization in most settings, and doesn’t need a second model call. Reach for the hybrid only once a task’s history genuinely outgrows a rolling window; pure LLM summarization on its own rarely won outright in JetBrains’ tests.
Both techniques still need tuning specific to the agent’s scaffold - the code that wires the model to its tools and prompts. SWE-agent’s masking goes further: it drops failed-retry turns entirely rather than just hiding them. OpenHands’s summarization does the opposite: it never drops a turn before summarizing, errors included. That means it needs a larger window - otherwise a run of failures alone would swamp what’s left to compress. Both techniques - masking and summarization - retrofit onto existing models, including GPT-5 and Claude, without any retraining.
Splitting work across dedicated subagents, each running in its own isolated context window, is a separate lever worth reaching for too - generally a solid way to keep effective context high without touching masking or summarization at all. See subagent context isolation for how that plays out in practice.
Bottom line
Treat context the way context engineering already argues for Claude Code sessions: as a budget to spend deliberately, not a ceiling to grow into. Context engineering beats a bigger context window makes the case for manually trimming context mid-session (Claude Code’s /compact and /clear commands) inside one harness; JetBrains’ numbers show the same principle holds model-agnostically, on a coding-agent benchmark. The price tag: over half the cost saved, with no drop in solve rate. It’s one of several cost levers worth stacking - prompt caching and batch processing are the other two with a fixed, guaranteed discount. More of the same cluster lives under Optimization.