Anthropic Context Management: The Context Window Is Big. Your Attention Budget Is Not

The first twenty turns feel clean. By turn sixty, the agent is rereading files, revisiting settled decisions, and answering a simpler question than the one you asked. Nothing has technically broken. That is what makes the failure so expensive.

Anthropic context management is the active curation of what enters Claude's inference window during long agent runs. First-party server-side primitives, conversation compaction, surgical tool-result clearing, and structured memory, replace deprecated client-side SDK summarization. Larger windows do not fix context rot. Developers must match the workload to the right primitive and tune clearing triggers against prompt-cache invalidation and minimum cacheable token boundaries.

Last verified: 22 August 2026 (NotebookLM sources; no live CLI run on this pack).

That is the direct answer. The useful answer takes a little more work, because effective context engineering for AI agents is not one clever prompt or one emergency command. It is a policy for deciding what Claude should keep verbatim, what it can summarize, what it can fetch again, and what must survive beyond the current conversation. For the practitioner layer stack across tools and memory, see context engineering best practices.

A large window still needs valves. Compaction, clearing, and memory control three different kinds of context pressure.

This guide covers runtime context management in LLM applications built with Claude and Claude Code. It does not cover enterprise data catalogs, metadata lineage, or organization-wide governance platforms that happen to use the same phrase.

Inside, we will move through:

• what Anthropic means by context management

• why recall degrades before the window is technically full

• how server-side compaction differs from clearing

• where memory and CLAUDE.md fit

• how context editing interacts with prompt caching

• how to tune clearing without paying for pointless cache rewrites

• which primitive fits dialogue-heavy, tool-heavy, and long-horizon agents

What Anthropic context management means (and what it is not)

Imagine a workshop bench during a complicated repair. The manual stays open at the back. The screws from the current assembly sit in a tray. Three discarded housings, yesterday's measurements, and every tool you touched are piled across the remaining surface. A larger bench delays the mess, but it does not tell you what deserves to stay within reach.

That bench is the context window: the bounded set of tokens Claude can consider while producing its next response. Tokens are the small text units a model reads, roughly pieces of words rather than whole ideas. Anthropic context management is the discipline of keeping the useful pieces accessible without letting bulky, stale, or replaceable material crowd the working surface.

Runtime developer curation vs enterprise metadata catalogs

Search results blur two separate jobs. Runtime context management changes the information supplied to an inference call or an active Claude Code session. Enterprise context management organizes business metadata, catalogs, lineage, permissions, and governance across systems.

Both matter. They do not share an implementation.

If your agent starts contradicting a decision after reading thirty files, you have a runtime attention problem. A catalog will not fix it. If your company cannot establish which customer field is authoritative, a /compact command will not fix that either.

This guide stays on the runtime side: the information Claude can use on the next inference call.

Context engineering vs organization-wide context management

Context engineering means deliberately assembling the instructions, messages, retrieved documents, tool definitions, tool results, and durable state that a model receives. Context management is the operating loop around that assembly: measure it, remove noise, preserve decisions, and refresh it as the task changes.

In practical LLM context management, prompting is only one input. A perfect user instruction can still drown beneath ten raw test logs and several copies of the same file. This is why prompt engineering and context engineering solve different layers of the problem. The prompt tells the model what to do. The context determines what evidence it can notice while doing it.

Three primitives at a glance

Anthropic's first-party approach separates three jobs:

1. Compaction replaces a long dialogue trajectory with a shorter summary that preserves intent and important state.

2. Tool-result clearing removes bulky, re-fetchable outputs while retaining the lighter record that a tool was called.

3. Memory writes durable state outside the immediate conversation so a later turn or session can recover it.

The primitive follows the shape of the waste: dialogue, tool output, or durable state.

Treating all three as "summarization" creates brittle agents. A decision that must survive for a week belongs in memory. A 20,000-token command log may be safe to clear. A nuanced conversation about acceptance criteria may need compaction. Same pressure, different valve.

Context rot, recall decay, and the Anthropic context window

A context window has a hard capacity, but quality can soften before the cap. Context rot is the practical decay in recall and instruction-following as relevant facts compete with a growing amount of old, duplicated, or low-value material. The model still has the text. It does not necessarily give every part of that text equal practical attention.

Attention dilution before hard limits

Long agent loops accumulate more than chat messages. They also collect assistant output, extended thinking blocks, tool definitions, file reads, command results, API responses, images, and system instructions. The next request carries that history forward unless your application edits it.

Every turn inherits prior messages and tool material, so token pressure compounds unless something leaves.

Sources in the research pack describe recall decay appearing around the 30,000 to 50,000 token region in some long-running workflows. That is an operational warning zone, not a universal model limit. Workload shape matters. Fifty thousand tokens of tightly relevant source text are different from fifty thousand tokens containing duplicate file reads, verbose logs, abandoned plans, and conflicting instructions.

The symptoms are familiar: Claude asks for a path it already read, reopens a resolved design choice, slows down, hedges more than usual, or produces an answer that is locally sensible but globally wrong. Those are signals to inspect context composition, not proof that the model needs a larger maximum.

Large windows vs recall accuracy

Anthropic documents context capacities as high as 1 million tokens for supported models. Capacity answers, "Will this request fit?" It does not answer, "Will the model recover the right sentence from a noisy history at the right moment?"

The larger-window trap is subtle. Teams use the extra space to postpone curation. Then they discover that the expensive part was never storing the evidence. It was maintaining a clean path back to the evidence.

That is my builder's rule for long agent runs: the most dangerous token is not the old one. It is the old one that still looks relevant.

Check your own session

Claude Code exposes /context, an interactive command that shows what is consuming the active window. Use it before a session feels broken. The breakdown can reveal system instructions, tools, Model Context Protocol tool specifications, memory, messages, and free space. Model Context Protocol, or MCP, is a standard for connecting an AI application to external tools and data sources.

Run /context to inspect headroom and identify the category creating pressure.

Claude Code's application-level auto-compaction triggers at 95 percent of its context capacity. Do not confuse that convenience with raw Platform API behavior. If you build your own loop, you own the trigger policy.

For a conceptual walkthrough of why long-horizon agents need active curation, this context engineering video is useful reinforcement. It is not a substitute for the current Claude API schemas below.

Server-side dialogue compaction

Compaction keeps a task alive by converting a bulky conversation trajectory into a smaller representation. It is appropriate when the dialogue itself contains the state you need: goals, decisions, constraints, partial conclusions, and the next intended action.

Migrating off deprecated client-side compaction

Older implementations used client-side SDK controls such as compaction_control or built a separate summarization call, then manually replaced conversation history. Anthropic now marks that client-side direction as deprecated in favor of first-party server-side compaction. The modern beta identifier is compact-2026-01-12.

The following payload shows the shape, not a drop-in wrapper for every SDK version. Check the official context editing documentation before production because the feature is beta.

{
  "model": "YOUR_SUPPORTED_CLAUDE_MODEL",
  "max_tokens": 2048,
  "messages": [
    {"role": "user", "content": "Continue the investigation."}
  ],
  "context_management": {
    "edits": [
      {
        "type": "compact_20260112",
        "trigger": {"type": "input_tokens", "value": 120000}
      }
    ]
  }
}

Send the current beta header named by the docs for this feature. The research ledger records compact-2026-01-12 for server-side compaction and context-management-2025-06-27 for context editing capabilities. Beta headers and payload identifiers are not interchangeable strings, so copy them from the current first-party example rather than guessing.

Auto-compact thresholds in Claude Code vs API triggers

In Claude Code, /compact asks the application to summarize the active conversation, and auto-compact provides a 95 percent safety net. In a Platform API agent, you define when compaction should happen. Your threshold should leave enough headroom for the next tool result and model response, not merely squeeze under the current maximum.

This is where teams get surprised. A research agent may receive a large webpage or database result on its next tool call. Triggering compaction only a few tokens below the window cap leaves no room for that result to arrive.

A useful trigger creates working headroom before the next large tool response, not after an overflow.

What survives a compaction event

Compaction does not mean flattening the entire request into one vague paragraph. Anthropic's design preserves the stable prefix layers such as system prompts and tool definitions while compressing the middle dialogue trajectory. Claude Code rules and memory remain available according to the application's normal loading behavior.

Stable instructions and durable state survive. Bulky dialogue history becomes a smaller continuation record.

If you provide custom instructions for compaction, those instructions replace the default summarizer rather than adding a small preference to it. That makes you responsible for asking the summarizer to retain commitments, unresolved questions, identifiers, and the current plan. Test that output like any other lossy transformation.

This short Claude Code compact and clear demonstration shows the behavioral distinction in the terminal. The underlying Platform configuration still belongs in the API docs.

Tool-result clearing and when to reset context

Tool-heavy agents often have a different problem. Their conversation is fine. Their evidence trail is enormous.

A file-reading agent might store the full contents of ten files even after it has extracted the two functions that matter. A deployment agent might preserve pages of successful logs. A research loop may carry complete HTML documents long after recording the relevant claims. Compaction can summarize all of that, but surgical clearing gives you tighter control.

Tool-result and thinking-block clearing schemas

Anthropic's server-side tool-result edit uses the clear_tool_uses_20250919 type. It removes eligible tool-result content while keeping a lightweight execution record, which lets the model retain the fact that an action occurred. The extended-thinking edit uses clear_thinking_20251015. If you combine both in one edits array, thinking edits must come first.

{
  "context_management": {
    "edits": [
      {
        "type": "clear_thinking_20251015"
      },
      {
        "type": "clear_tool_uses_20250919",
        "trigger": {"type": "input_tokens", "value": 80000},
        "keep": {"type": "tool_uses", "value": 3}
      }
    ]
  }
}

Treat the numeric values as policy examples, not universal recommendations. Tool-result size, retrieval cost, model capacity, and cache behavior should determine your actual trigger. The Claude context editing reference defines the currently accepted fields and defaults.

/compact versus /clear versus Platform clears

These operations sound similar because each creates space. Their continuity cost differs:

• /compact summarizes the conversation so you can continue the same task.

• /clear resets Claude Code's conversational history for a genuinely new task. It does not delete files, code edits, or Git state.

• Platform tool clearing removes selected tool-result payloads while preserving the surrounding conversational path.

• Platform thinking clearing removes eligible thinking blocks according to the configured edit.

So when should you clear context? Use /clear when the previous task has become noise. Use /compact when the task remains the same but the trajectory is too large. Use surgical Platform edits when your custom agent knows exactly which class of material is replaceable.

Combining clearing strategies in one request

Anthropic allows context edits to work together. Ordering matters, and so does observability. Record which edit ran, how many tokens it removed, whether the next request hit the prompt cache, and whether the agent later had to fetch the same evidence again.

Startup instructions occupy context before the first prompt. File reads and tool results add weight as the session proceeds.

This will not work if you clear evidence that is expensive, unavailable, or impossible to reproduce. A live API response, a transient error, or a one-time user clarification may need a durable note before its raw result leaves the window.

Cross-session memory, CLAUDE.md, and the memory tool

Clearing solves clutter. Memory solves continuity.

The memory tool stores structured state outside the immediate message history so an agent can write and later recover durable facts. That makes it suitable for decisions, preferences, progress markers, and lessons that must survive compaction or a new session. It is not a license to save every conversation verbatim. When corrupted facts persist in durable stores, the failure mode is context poisoning, not a bigger window.

Memory tool with server-side context editing

In a long-running research agent, the useful pattern is progressive disclosure. Keep a short index or summary in active context. Store detailed notes externally. Retrieve the detailed note only when the current step needs it. The memory tool and context editing can operate together: editing controls the active window, while memory preserves selected state beyond it.

The question to ask is simple: would losing this fact force the agent to repeat work or violate a decision? If yes, write it to durable state. If no, leave it transient.

Keeping CLAUDE.md lean

Claude Code loads CLAUDE.md as project guidance. That makes it a strong home for stable coding conventions, build commands, architectural boundaries, and instructions that apply across sessions. It also means every unnecessary paragraph taxes the window repeatedly.

Keep it bulleted. Remove history. Link to detailed documentation instead of pasting it. Review it when a rule changes. A CLAUDE.md that contains last month's debugging diary is memory pretending to be policy.

Community memory and MCP extensions

Community tools extend these ideas. memsearch and the claude-mem plugin focus on cross-session recall. MCP connections can expose external stores and specialized retrieval. RTK compresses terminal-oriented material, while Token Savior uses progressive reads and summaries to reduce file pressure. These are experimental layers, not native guarantees, and their install commands can change.

Memory preserves decisions across sessions. Code retrieval locates current project evidence on demand.

Memory and code retrieval are not twins. Retrieval answers, "Where is the implementation of this behavior?" Memory answers, "What did we decide about this behavior last Tuesday?" Strong agents need both, and they should not fill either store with the other's material.

Prompt caching dynamics with context editing

Prompt caching lets repeated prompt prefixes reuse prior computation. A prefix is the unchanged sequence at the beginning of a request, such as stable system instructions, tool definitions, and earlier messages. When that prefix remains identical and meets the model's cache rules, later calls can read it at a lower input-token multiplier.

This is where context caching in Anthropic systems collides with context editing. Clearing and compaction save working memory, but they can change the prefix and force a fresh cache write.

Minimum cacheable token boundaries

The research ledger records minimum cacheable boundaries of 512 tokens for Claude 5 models and 4,096 tokens for Haiku 4.5. These limits are model-specific, so check the official prompt caching documentation when selecting a model.

The pricing relationship matters more than a made-up dollar example. A 5-minute cache write bills at 1.25 times the base input-token rate, a 1-hour write at 2 times, and a cache read at 0.1 times. Reusing a stable prefix can be efficient. Rewriting it after every tiny cleanup can erase that advantage.

Cache economics depend on model boundaries, write duration, and whether later turns reuse the prefix.

When edits invalidate the cached prefix

Compaction changes prior message content. Tool clearing changes prior tool-result content. A model swap changes the cache domain. Each can invalidate some or all of the reusable prefix. The exact break point depends on where the edit occurs.

Edits near the front of a request discard more reusable prefix than changes near the end.

In Claude Code, /rewind and /recap are documented as cache-safe actions, while /compact and model changes invalidate the cache. That does not make compaction bad. It means compaction has a compute cost that belongs in the decision.

Cache-safe vs cache-breaking CLI actions

Claude Code also exposes environment overrides for its application-level caching behavior:

ENABLE_PROMPT_CACHING_1H=1
FORCE_PROMPT_CACHING_5M=1
DISABLE_PROMPT_CACHING=1

These variables apply to Claude Code behavior described in its prompt caching documentation. They are not substitutes for cache controls in a custom Platform API integration.

A stable prefix becomes cheaper across turns. An edit starts a new write from the changed boundary.

Cache-trigger tuning: memory savings vs cache invalidation

The naive policy says, "Clear whenever there is anything removable." The cache-aware policy asks whether the reclaimed context is worth breaking a prefix that several near-term turns could reuse.

Neither policy wins universally. A tool result consuming 30 percent of the window can justify an immediate clear. A tiny result near the end of a healthy request usually cannot.

The compaction-or-clear versus cache-write trade-off

Think in batches. Let R be the removable tokens in eligible results. Let F be the model's minimum cacheable floor. Let H be the headroom required for the next expected tool response and model output. A useful clearing event should normally satisfy two conditions: it restores enough headroom to keep the loop safe, and it removes a meaningful batch rather than repeatedly rewriting the prefix for crumbs.

This is a tuning heuristic, not a promise from Anthropic:

clear when:
  available_headroom < expected_next_turn_size
  AND removable_tokens >= chosen_clear_at_least

choose clear_at_least so that:
  it is not below the model's cacheable floor
  AND it reflects the smallest cleanup worth a cache rewrite

Why use the cacheable floor as a lower bound? Because a cleanup smaller than 512 tokens on a Claude 5 model, or 4,096 tokens on Haiku 4.5, is unlikely to justify a prefix rewrite on cache economics alone. Emergency headroom can override that rule.

Aligning clear_at_least with cache thresholds

The clear_at_least parameter prevents a tool-clear operation from firing unless enough eligible tokens can be removed. It turns a noisy sequence of tiny edits into a batched policy.

Start at the model floor, then raise the batch size when tool results are cheap to retain and likely to be reused.

The floor is only a starting point. Raise clear_at_least when results are small, later turns are likely to reuse the cached prefix, and headroom remains comfortable. Lower the operational threshold when results arrive in large bursts or the next turn could overflow. Never lower it below the documented minimum without a concrete headroom reason.

Worked cache-aware clearing policy

Here is a practical HowTo for a tool-heavy agent:

1. Measure the workload. Log input tokens, output tokens, cache-read tokens, cache-write tokens, and the size of tool results. Context-editing responses expose token accounting you can use for this loop.

2. Estimate the next-turn reserve. Use the largest normal tool result plus the response budget, not the average turn. This creates H, your required headroom.

3. Select the model floor. Start with 512 tokens for Claude 5 or 4,096 for Haiku 4.5, subject to the current docs.

4. Choose a batch threshold. Set clear_at_least at or above that floor. Increase it if repeated cache writes outnumber useful clears.

5. Protect recent evidence. Keep the last few tool uses or any result the immediate plan still references.

6. Test two trajectories. Compare a representative run with editing enabled and disabled. Watch task quality, re-fetches, headroom, cache reads, and cache writes.

7. Move one threshold at a time. If the loop compacts too late, adjust the headroom trigger. If it clears too often, raise the batch threshold. Do not change both and pretend you learned which one mattered.

That last step is boring. It is also where most of the savings live.

Pick the right primitive for your agent workload

Context policies should follow token shape, not developer preference. Start by identifying what grows fastest.

Dialogue loops compact, file-heavy agents clear re-fetchable results, and long projects externalize durable state.

Dialogue-heavy workloads

Support agents, planning assistants, and iterative design conversations accumulate intent in the conversation itself. Prefer server-side compaction. Your custom summarization instructions should preserve commitments, unresolved questions, user preferences, and the immediate next step.

Do not aggressively clear the very messages that explain why a decision exists. That is how an agent preserves the answer while losing the problem.

Tool- and file-read-heavy workloads

Coding, browsing, and data agents often accumulate large tool outputs that can be fetched again. Prefer surgical tool-result clearing, keep a small number of recent uses, and write irreversible discoveries to memory before clearing the raw source.

If a tool is slow, metered, unstable, or returns time-sensitive information, "re-fetchable" may be technically true and operationally foolish. Price the retrieval cost alongside tokens.

Long-horizon state workloads

Multi-day projects need structured memory. Keep stable project rules in a lean CLAUDE.md, progress and decisions in durable notes or the memory tool, and only the immediate work packet in active context. This creates continuity without dragging every prior conversation through every request.

CLI, API, and community tool Rosetta

The environments expose related ideas through different controls. /compact is a Claude Code action; compact_20260112 is the server-side API edit type recorded in the cookbook. /context shows local headroom; API responses provide token accounting. RTK and Token Savior reduce noisy inputs before or while they enter the window.

Use the matrix as a conceptual translation layer, then verify exact commands and payloads in the owning tool's documentation.

What about repository tools such as claude-context and code-review-graph? Use semantic retrieval when you need related code but do not know its exact name. Use a structural graph when you need deterministic relationships such as callers, imports, dependencies, and change blast radius. Neither replaces memory, compaction, or cache policy.

Contextual retrieval and multi-agent isolation

Contextual retrieval improves the evidence before it enters the window. Anthropic's approach prepends chunk-specific context to source chunks before embedding them, which helps retrieval retain the meaning that ordinary chunking can strip away. An embedding is a numeric representation used to find semantically similar text. For the full preprocessing and hybrid search workflow, use the forthcoming Anthropic contextual retrieval guide.

That is different from clearing. Retrieval selects evidence for entry. Clearing decides when old evidence should leave.

Sub-agent isolation for heavy read pipelines

Multi-agent isolation gives a read-heavy task its own temporary context. A sub-agent can inspect a large collection of files or documents, return a compact finding, and keep its raw working set out of the coordinator's window. This is especially useful when the parent agent needs the conclusion and citations, not every intermediate read.

Isolation has an honest constraint: the handoff can lose nuance. Define the output contract before delegating. Ask for file paths, decisive excerpts, unresolved conflicts, and confidence, not a cheerful paragraph saying the investigation went well.

Framework-specific middleware and retriever APIs deserve their own implementation guide. Our LangChain context engineering guide owns that layer. Here, the important principle is narrower: give each model call the smallest complete evidence set for its current job.

Frequently asked questions

How do I reduce Claude Code token usage without losing useful context?

Compress the noisiest inputs first: repeated file reads, raw terminal logs, and bulky tool outputs. Use /context to find the pressure, /compact to preserve continuity in the same task, and targeted retrieval tools to fetch only the code you need.

Should I use claude-context or code-review-graph for a large repo?

Use claude-context for semantic search when you know the idea but not the symbol or filename. Use code-review-graph for structural questions about calls, imports, test dependencies, or change blast radius. Treat both as community tools and verify their current setup instructions.

Is memory different from code retrieval in Claude Code?

Yes. Code retrieval finds active project files and symbols. Memory retrieves durable decisions, progress, preferences, and debugging lessons across sessions.

Do these tools replace prompt caching or a larger context window?

No. A larger window provides capacity, and prompt caching reduces repeated computation for stable prefixes. Context-management tools improve the relevance and density of what occupies that capacity.

What happens when Claude Code runs out of context window?

Claude Code automatically compacts at 95 percent capacity. If the session still cannot create enough room, it eventually reaches the hard limit and cannot continue processing normally until you compact, clear, or start a clean session.

Does /clear delete my code or files?

No. /clear resets conversational history. It does not delete local files, code edits, or Git state.

How do I know when my context window is getting full?

Run /context for a live category breakdown. Also watch for repeated file questions, contradictions, slower answers, and verbose hedging, which can indicate context bloat before the hard cap.

When should I use /compact versus /clear?

Use /compact to continue the same task with a compressed history. Use /clear when switching to a new problem where old conversational state would create more noise than value.

Does CLAUDE.md help or hurt context window management?

Both. It gives Claude persistent project instructions without re-explaining them, but it loads into sessions and consumes context. Keep it lean, stable, bulleted, and free of temporary debugging history.

Pick one agent loop this week. Run /context, name its dominant token source, and choose exactly one intervention. Compact dialogue, clear re-fetchable tool results, or externalize durable state. Then record cache reads and writes across a representative run before changing another setting.

You are not trying to make the context window empty. You are trying to make the next decision obvious. As agents run longer and touch more systems, that curation layer will become part of application architecture, not a cleanup trick developers remember at 95 percent.

Until then...

• Sage

PS. Try leaving one deliberately useless tool result in a test session. If you cannot identify it from your telemetry five turns later, your first problem is observability, not compaction.