Context management strategies for coding agents, compared

Every coding agent runs out of room the same way. It reads a file, then another, runs the tests, reads the log, greps for a symbol, reads three more files, and forty turns in the window is mostly tool output from twenty turns ago. The model slows down, starts repeating itself, and then the harness compacts and something important disappears.

Context management is the set of techniques for keeping that window useful. There are about nine in common use, and they're not interchangeable: each one saves a different kind of token, loses a different kind of information, and works at a different scope. This post goes through them one at a time, then shows how they fit together. If you want the definitions first, start with What is context engineering?

The scope that matters

Before the list, one distinction that sorts all of them. A context strategy can work at four scopes:

• One turn: what's in the window for this call.
• One session: what survives from turn one to turn eighty.
• One person: what carries from your Monday session to your Thursday one.
• One team: what carries from your teammate's session to yours.

Almost everything on this list works at the first two scopes. That's where the window pressure is, so that's where the tooling went. The last scope is where the expensive mistakes happen, and we'll come back to it.

1. Instruction files

CLAUDE.md, AGENTS.md, .cursor/rules. Plain text in the repository, loaded into every session at start.

• What it saves: repeating yourself. Build commands, conventions, "never touch the generated folder".
• What it costs: every line is paid for on every turn of every session, whether the task needs it or not. Codex loads up to 32 KiB of AGENTS.md by default; past a few hundred lines, instruction files start crowding out the work.
• What it loses: anything nobody wrote down, and anything that changed since someone last edited the file.
• Scope: team, if it's checked in. But it's hand-maintained, so it holds rules, not history.

Use it for rules that must apply on every turn. A rule that only matters for one subsystem belongs in a nested file or a skill.

2. Just-in-time search

Instead of pre-loading the codebase, the agent keeps paths and names in context and pulls content with grep, glob and file reads when it needs it. This is how Claude Code and Codex explore by default. Cursor adds an embedding index of the repository on top.

• What it saves: loading files the task never touches.
• What it costs: turns. An agent searching from scratch spends the first several minutes of a session rebuilding a mental model of the codebase, and every file it reads lands in the window as a tool result.
• What it loses: nothing, as long as the answer is in the repository. The failure is when it isn't: a decision made in Slack, a database renamed in a cloud console. Search finds what's in the files, and the agent then treats what it found as the whole picture.
• Scope: one session.

3. Compaction

When the conversation nears the window limit, the harness summarizes it and starts a fresh window seeded with the summary. Claude Code does this automatically and on /compact; Codex and most other harnesses have an equivalent.

• What it saves: the session itself. Without it, long tasks just stop.
• What it costs: a model call to write the summary, and a cold start after.
• What it loses: whatever the summarizer decided didn't matter. Exact error messages, the approach that was tried and rejected, the reason a constraint exists. You usually find out what was dropped when the agent tries the rejected approach again.
• Scope: one session.

Compaction is the context strategy everyone uses and nobody trusts. Writing important state to a file before it happens (see scratchpads, below) is the usual hedge.

4. Tool-result clearing

A lighter form of compression: once the agent has acted on a tool result, replace it with a placeholder. The 4,000-line test log from turn twelve doesn't need to be in the window at turn forty. Anthropic shipped this as context editing in its API in late 2025, and several harnesses do a version of it themselves.

• What it saves: often the largest category of tokens in a coding session, since tool output dominates.
• What it costs: almost nothing, which is why it's the safest technique on this list.
• What it loses: the ability to re-read old output without re-running the tool.
• Scope: one session.

5. Sub-agents

Hand a self-contained piece of work, usually exploration, to a separate agent with its own clean window. It reads forty files and returns a one-page summary. The parent agent's window only ever sees the summary.

• What it saves: the exploration tokens, which never touch the main window.
• What it costs: the sub-agent's own tokens (often more in total, spread across windows), latency, and a handoff that has to be briefed well.
• What it loses: whatever the summary leaves out. The parent can't ask a follow-up about a file it never saw, unless it resumes the sub-agent.
• Scope: one session, split across several windows.

Sub-agents are isolate plus compress. They work best for breadth (search ten directories) and worst for tasks where the details matter to the next step.

6. Scratchpads and structured notes

The agent writes its own state to a file outside the window: a todo list, a PROGRESS.md, a running notes file. After compaction, or in a new session, it reads the file back. Anthropic's memory tool formalizes this as a directory the model can create, read and edit files in.

• What it saves: state across compaction and across sessions.
• What it costs: the agent has to decide to write, decide what to write, and remember to read it back.
• What it loses: anything the agent didn't think was worth writing at the time, which is precisely the stuff that turns out to matter.
• Scope: one session to one person. The notes live on one machine, in one person's checkout.

7. Skills and progressive disclosure

Load a short description of each capability up front, and the full instructions only when the capability is used. A skill's body might be 3,000 tokens; its description is 40. Fifty skills cost 2,000 tokens until one is invoked.

• What it saves: instructions that apply to one kind of task, out of every other task's window.
• What it costs: the model has to recognize from a one-line description that the skill applies.
• What it loses: nothing, if the description is good. If it's vague, the skill never fires.
• Scope: person or team, depending on where the skills are stored.

The same idea applies to MCP tools: a client that loads tool definitions on demand instead of all at once is doing progressive disclosure on its tool list.

8. Prompt caching

Reuse the processed prefix of a context across calls so it isn't recomputed. Cached input tokens are typically billed at a fraction of the normal rate and return faster.

• What it saves: money and latency on stable prefixes: the system prompt, tool definitions, instruction files.
• What it costs: discipline. Anything that changes early in the context invalidates the cache for everything after it.
• What it loses: nothing. But it doesn't make the window bigger or the model's attention better, so it isn't really context management, it's context pricing. It's on this list because people often reach for it when the real problem is that the context is too big.
• Scope: one session, or many sessions sharing a prefix.

9. External memory

A store outside the agent that persists across sessions, and from which relevant context is pulled into the window when a task needs it. This is where the products differ most. Some are a local file one agent writes to. Some are a per-user memory API you build into your own app. Glen is the third kind: a memory shared by a whole organization, built from every agent session the team runs plus the tools it already uses.

• What it saves: rediscovery. The minutes at the start of a session where the agent greps around rebuilding what someone already figured out.
• What it costs: a retrieval step, and trust in what comes back. A memory that returns stale or wrong facts is worse than none.
• What it loses: depends entirely on what was recorded. A memory the agent has to remember to write to has the scratchpad's problem. One that records sessions automatically doesn't.
• Scope: person or team, depending on the product.

The comparison

How they fit together

A well-configured coding agent in late 2026 uses most of these at once. Short instruction files for hard rules. Just-in-time search for the code. Tool-result clearing and compaction to survive long sessions. Sub-agents for broad exploration. Skills for task-specific procedures. Caching underneath all of it to keep the bill down.

Notice what that stack is good at: keeping one session alive and efficient. Eight of the nine strategies are about the window you're in. None of them helps with the moment that costs the most, which is the start of a session, when the agent knows nothing about what your team decided last week, and spends ten minutes and fifty thousand tokens finding a fraction of it.

That's the gap we built Glen for. It's external memory at team scope, and it's built to avoid the three ways external memory usually goes wrong:

• Nobody has to write to it. Plugin hooks record every session in Claude Code, Codex, Cursor and the others, and integrations pull in Slack, GitHub, Linear, Notion and call transcripts. The scratchpad problem, the agent not writing down the thing that matters, doesn't apply.
• It doesn't wait to be asked. Glen reads the live session and injects what's relevant before the agent goes looking, as one synthesized answer with a source on every claim, instead of ten raw search results competing for attention.
• It doesn't return both sides of an old argument. When a newer decision contradicts an older one, the older one stops surfacing, and anything wrong can be removed with glen forget.

In Replaying 100 PRs we measured it: 29% fewer tokens and 21% faster on the same model, with quality at parity or better. The savings came from exactly the phase the other eight strategies can't touch: the start of the session.

npx @tryglen/cli@latest install

Start free · Compare agent memory MCP servers