Context Window Management

Official Exam Guide Objectives

Task 5.1: Manage conversation context to preserve critical information across long interactions.

Knowledge of

• Progressive summarization risks: condensing numerical values, percentages, dates, and customer-stated expectations into vague summaries
• The "lost in the middle" effect: models reliably process information at the beginning and end of long inputs but may omit findings from middle sections
• How tool results accumulate in context and consume tokens disproportionately to their relevance (e.g., 40+ fields per order lookup when only 5 are relevant)
• The importance of passing complete conversation history in subsequent API requests to maintain conversational coherence

Skills in

• Extracting transactional facts (amounts, dates, order numbers, statuses) into a persistent "case facts" block included in each prompt, outside summarized history
• Extracting and persisting structured issue data (order IDs, amounts, statuses) into a separate context layer for multi-issue sessions
• Trimming verbose tool outputs to only relevant fields before they accumulate in context (e.g., keeping only return-relevant fields from order lookups)
• Placing key findings summaries at the beginning of aggregated inputs and organizing detailed results with explicit section headers to mitigate position effects
• Requiring subagents to include metadata (dates, source locations, methodological context) in structured outputs to support accurate downstream synthesis
• Modifying upstream agents to return structured data (key facts, citations, relevance scores) instead of verbose content and reasoning chains when downstream agents have limited context budgets

What You Need to Know

What reaches the context window decides whether a Claude-based system holds together. Multi-turn conversations, multi-agent pipelines, long-document extraction — each one lives or dies on that. The failures are not abstract either: the support agent that has forgotten the refund amount, the research pipeline that drops its citations, the extraction that loses precision on exactly the fields anyone cared about.

The Progressive Summarisation Trap

Long conversations tempt you into compressing earlier turns to recover budget. It is a trap, and a specific one: summarisation destroys precisely the categories of information that transactional systems depend on — figures, dates, percentages, and the expectations a customer has stated aloud.

Here is how it plays out. A customer contacts support about a refund:

Turn 3: "I'd like a refund of $247.83 for order #8891 placed on March 3rd"

After summarisation, this becomes:

Summary: "Customer wants a refund for a recent order"

Everything needed to actually issue the refund — the amount, the order, the date — has gone, and what remains is a description of the conversation rather than its content. This is not an unlucky example. Summarising is lossy in exactly this direction by construction: specifics are what compression removes.

The fix: persistent case facts blocks. Pull the transactional facts — amounts, dates, order numbers, statuses — into a structured block carried in every prompt and held outside the summarised history. Nothing ever compresses it, so it survives whatever happens to the conversation around it.

{
  "caseFactsBlock": {
    "customerId": "C-4421",
    "issues": [
      {
        "orderId": "#8891",
        "orderDate": "2024-03-03",
        "refundAmount": "$247.83",
        "status": "pending_refund",
        "itemDescription": "Wireless headphones — defective"
      }
    ]
  }
}

Where one conversation covers several problems at once, give each its own entry in that layer rather than letting them share a narrative. Kept separate, one issue's order number cannot migrate onto another during compression — which is what cross-contamination looks like in practice.

The "Lost in the Middle" Effect

Position matters. What sits at the start and end of a long input is attended to reliably; what sits in the middle can be weighted lightly or missed altogether. The effect is well documented across large language models, and it governs how aggregated input should be laid out.

The fix is structural, not prompt-based. Lead with a summary of the key findings, then present the detail under explicit headers. Feeding a synthesis agent the output of three research subagents means opening with the conclusions and following with the material they came from, each part clearly bounded.

## Key Findings Summary
- Source A: 12% market growth in renewable sector (2023)
- Source B: Patent filings increased 34% year-on-year
- Source C: Regulatory framework delayed until Q3 2025

## Detailed Findings

### Source A: Market Analysis Report
[Full details here...]

### Source B: Patent Database Analysis
[Full details here...]

### Source C: Regulatory Review
[Full details here...]

Tool Result Trimming

Tool output drains the budget quietly. An order lookup may return forty-odd fields — audit timestamps, warehouse codes, carrier identifiers, fulfilment centre references — where five bear on the refund being discussed. The other thirty-five do not merely cost tokens once; they sit in the history and are re-sent on every subsequent turn.

Trim verbose tool outputs to only relevant fields before they accumulate in context. Left undone, a multi-turn system silts up with stale output until nothing else fits. This is structural, not tidying.

const RELEVANT_FIELDS = [
  "order_id", "order_date", "total_amount", "return_eligible", "item_description",
];

function trimOrderResult(rawResult: Record<string, unknown>, relevantFields = RELEVANT_FIELDS) {
  return Object.fromEntries(
    Object.entries(rawResult).filter(([k]) => relevantFields.includes(k))
  );
}

def trim_order_result(raw_result, relevant_fields=None):
    if relevant_fields is None:
        relevant_fields = [
            "order_id", "order_date", "total_amount",
            "return_eligible", "item_description"
        ]
    return {k: v for k, v in raw_result.items() if k in relevant_fields}

Do it in a PostToolUse hook, or inside the tool itself — the requirement is only that it happens before the result joins the conversation. After that point there is no removing it, and it is paid for on every turn that follows.

Full Conversation History

The Claude API holds no state between requests, so each one carries the entire conversation. Drop earlier messages and the model loses the thread, because there is no server-side session quietly remembering them on your behalf.

Which sets up the tension this task statement exists to resolve: coherence wants everything, and the window grows with every turn. The case facts block is what reconciles them — narrative can be summarised freely once the facts that matter are held somewhere summarisation does not reach.

Upstream Agent Optimisation

In a multi-agent pipeline, what an upstream agent finds natural to return is rarely what a downstream agent needs. Reasoning chains and raw content arrive at a synthesis agent whose budget is finite, and the reasoning is unusable to it — it cannot act on how another agent reached a conclusion, only on the conclusion.

Modify upstream agents to return structured data — the claims, their sources, relevance scores — in place of prose and deliberation. Require the metadata that downstream work depends on, including dates, source locations and methodological context, so synthesis has what it needs to be accurate rather than merely fluent.

{
  "findings": [
    {
      "claim": "Renewable energy investment grew 12% in 2023",
      "source": "IEA World Energy Report 2024",
      "sourceUrl": "https://example.com/report",
      "relevanceScore": 0.92,
      "publicationDate": "2024-01-15"
    }
  ]
}

The saving in tokens is the obvious benefit and not the largest one. A downstream agent handed structure reads fields; handed prose, it re-derives them, and every re-derivation is a chance to get one wrong.

Prompt Caching

Caching addresses context economics from the other side: rather than reducing what the model reads, it stops you paying to reprocess the parts that never change. A cache_control breakpoint marks a stable prefix, the API keeps that prefix in processed form, and subsequent requests reuse it at a fraction of the input cost.

Matching runs from the beginning of the prompt forward, prefix by prefix, which makes layout decisive. Anything constant goes first — system instructions, tool definitions, long reference material — with the breakpoint closing that block. Anything that varies per request, the user's message above all, comes after it.

// The cache breakpoint goes on the last stable block. Everything volatile
// (the user's question) sits after it, so the prefix stays byte-identical.
const response = await client.messages.create({
  model: "claude-sonnet-5",
  max_tokens: 4096,
  system: [
    { type: "text", text: LONG_STATIC_INSTRUCTIONS },
    { type: "text", text: REFERENCE_DOC, cache_control: { type: "ephemeral" } },
  ],
  messages: [{ role: "user", content: dynamicUserMessage }],
});

# The cache breakpoint goes on the last stable block. Everything volatile
# (the user's question) sits after it, so the prefix stays byte-identical.
response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    system=[
        {"type": "text", "text": LONG_STATIC_INSTRUCTIONS},
        {
            "type": "text",
            "text": REFERENCE_DOC,
            "cache_control": {"type": "ephemeral"},
        },
    ],
    messages=[{"role": "user", "content": dynamic_user_message}],
)

Order it the other way and the benefit vanishes completely rather than partially: a single varying token ahead of the static block changes the prefix, so nothing matches and every request pays in full. The window is short as well — an ephemeral breakpoint survives roughly five minutes from last use, which makes caching a tool for bursts of related requests rather than for material reused across a working day.

Deep Dive

Context window sizes per model, and the 1M-token default

The captured lesson content never states an actual number — this is the gap. As of the current model line-up, Claude Fable 5, Opus 5, and Sonnet 5 ship a 1,000,000-token context window; Claude Haiku 4.5 ships 200k. For every model with a 1M window, 1M is the default — there is no beta header to opt in, and long-context requests bill at standard pricing. Max output is 128k tokens for Fable 5, Opus 5, and Sonnet 5 (64k for Haiku 4.5) on the synchronous Messages API; the Message Batches API raises this to 300k output tokens on Opus/Sonnet with the output-300k-2026-03-24 beta header.

Sources: https://platform.claude.com/docs/en/about-claude/models/overview · https://platform.claude.com/docs/en/build-with-claude/context-windows (fetched 2026-07-30)

What counts toward the context window

The context window is "all the text a language model can reference when generating a response, including the response itself" — a working memory distinct from training data. Concretely, everything in the request counts: the system prompt, every message in messages (including tool results, images, and documents), and the tool definitions. The model's output for the turn — including its extended thinking — counts too. Cached prompt prefixes still occupy the window; prompt caching changes what you pay for those tokens, not whether they count. This is why untrimmed tool results (Task 5.1's central example) are a budget problem even when they're cheap to reprocess.

Sourceplatform.claude.com › context-windowsfetched 2026-07-30

Overflow behaviour: 400 error vs model_context_window_exceeded

If the input alone already exceeds the model's context window, the API returns a 400 invalid_request_error ("prompt is too long") on every model — there is no silent truncation. On Claude 4.5 models and newer, if input tokens plus max_tokens together exceed the window, the request is instead accepted, and if generation reaches the limit it stops with stop_reason: "model_context_window_exceeded" (earlier models return a validation error instead). To avoid both failure modes, the docs recommend the token counting API (POST /v1/messages/count_tokens) to estimate usage before sending a request; that endpoint is "free to use but subject to requests per minute rate limits", and token counting and message creation have "separate and independent rate limits".

Sources: https://platform.claude.com/docs/en/build-with-claude/context-windows · https://platform.claude.com/docs/en/build-with-claude/token-counting (fetched 2026-07-30)

Context rot: why more context is not automatically better

"As token count grows, accuracy and recall degrade, a phenomenon known as context rot. This makes curating what's in context just as important as how much space is available" — straight from the docs, and echoed by Anthropic's engineering team: context must be "treated as a finite resource with diminishing marginal returns" because LLMs draw on a limited "attention budget" that every added token depletes. Two causes are named: the n² pairwise attention relationships between tokens get stretched thin as sequences lengthen, and models simply see fewer long sequences than short ones in training. This is the mechanism behind the lost-in-the-middle effect and the reason a bigger context window is not a substitute for trimming and structuring what goes into it.

Sources: https://platform.claude.com/docs/en/build-with-claude/context-windows (the "context rot" definition) · https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents (attention budget and causes) (fetched 2026-07-30)

Context awareness: automatic token-budget tracking

Claude Sonnet 5, Sonnet 4.6, Sonnet 4.5, and Haiku 4.5 have built-in "context awareness": these models track their own remaining context window (their "token budget") throughout a conversation via budget tags the API injects automatically — there is nothing to enable. This lets the model itself factor "how much room is left" into decisions such as when to compress its own output or wrap up a turn, independent of any case-facts or trimming pattern the developer builds on top.

Sourceplatform.claude.com › context-windowsfetched 2026-07-30

Compaction: the official long-horizon technique, and its risk

Anthropic names the pattern this lesson's case-facts block is a variant of: compaction is "the practice of taking a conversation nearing the context window limit, summarizing its contents, and reinitiating a new context window with the summary." It is one of three long-horizon techniques (alongside structured note-taking and sub-agent architectures) for work that outlasts a single context window. The risk is explicit: "overly aggressive compaction can result in the loss of subtle but critical context whose importance only becomes apparent later" — exactly the failure mode this lesson calls the progressive summarisation trap. The lightest-touch form is "tool result clearing", which the post calls "one of the safest lightest touch forms of compaction" and notes was "most recently launched as a feature on the Claude Developer Platform". Separately, the API docs describe a beta server-side compaction feature, available for Claude 4.6 and later models, that "automatically summarizes earlier parts of the conversation on the server, so the conversation can continue past the context window limit".

Sources: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents (compaction, note-taking, sub-agents, tool result clearing) · https://platform.claude.com/docs/en/build-with-claude/context-windows (beta server-side compaction) (fetched 2026-07-30)

Quick Reference

Exam Traps

Practice Scenario

Build Exercise

Build a Persistent Case Facts Context Manager

Difficulty: Intermediate (2/4)

45 minutes

1. Create a case facts extractor that identifies transactional data (amounts, dates, order numbers, statuses) from tool results

Why: The persistent case facts block is the single most important pattern in context window management. Extracting transactional facts into a structured block that is never summarised prevents the progressive summarisation trap from destroying critical numerical values and identifiers.

You should see: A function that takes raw tool output and returns a structured object containing only the transactional facts: customer ID, order numbers, amounts, dates, and statuses. Non-transactional narrative content should be excluded.

2. Implement a persistent case facts block that is prepended to every prompt, outside summarised history

Why: The case facts block must persist across every turn regardless of what happens to the conversation history. It sits outside the summarised portion of the context, ensuring amounts, dates, and order numbers survive even when earlier conversation turns are compressed.

You should see: A prompt construction function that always includes the case facts block at the top of every message, followed by any summarised history, followed by the current turn. The case facts block should be clearly delimited with a section header.

3. Build a tool result trimmer that filters order lookup responses from 40+ fields to only the 5 relevant return-related fields

Why: Untrimmed tool results are a silent context budget killer. An order lookup returning 40+ fields consumes tokens in every subsequent turn as conversation history grows. Trimming to relevant fields before results enter context is essential, not optional.

You should see: A trimming function that takes a raw tool result object and returns only the fields needed for the current task. The trimmed result should be 80-90% smaller than the original.

4. Test with a multi-turn conversation where summarisation occurs and verify that transactional facts survive intact across all turns

Why: This validates that the persistent case facts pattern actually works. The exam tests whether you understand that progressive summarisation destroys specific amounts and dates, and the case facts block is the fix. You need to verify this empirically.

You should see: A 6-8 turn conversation where summarisation occurs after turn 4. After summarisation, the agent should still reference the exact refund amount ($247.83), order number (#8891), and date (March 3rd) from the case facts block. Without the block, these values would be lost to summarisation.

5. Add key findings placement logic that positions summaries at the beginning of aggregated inputs to mitigate the lost-in-the-middle effect

Why: Models process information at the beginning and end of long inputs reliably, but findings buried in the middle may be missed. Placing key findings summaries at the start of aggregated inputs is a structural fix for this well-documented phenomenon.

You should see: An aggregation function that places a Key Findings Summary section at the top of combined inputs, followed by detailed results with explicit section headers. The key findings should be concise bullet points drawn from the detailed content.

Sources

• Claude Certified Architect Foundations Exam Guide — Domain 5, Task Statement 5.1 — Anthropic
• Anthropic API Documentation — Messages — Anthropic
• Anthropic Prompt Engineering — Long Context Tips — Anthropic
• Claude Models Overview — Anthropic
• Context Windows — Anthropic
• Effective Context Engineering for AI Agents — Anthropic

Appendix A — Build Exercise Step Hints

Progressive hints revealed by the "Stuck? Get a nudge" control on each step.

Step 1. Create a case facts extractor that identifies transactional data (amounts, dates, order numbers, statuses) from tool results

Why: The persistent case facts block is the single most important pattern in context window management. Extracting transactional facts into a structured block that is never summarised prevents the progressive summarisation trap from destroying critical numerical values and identifiers.

You should see: A function that takes raw tool output and returns a structured object containing only the transactional facts: customer ID, order numbers, amounts, dates, and statuses. Non-transactional narrative content should be excluded.

function extractCaseFacts(toolResult) {
  return {
    customerId: toolResult.customer_id,
    issues: [{
      orderId: toolResult.order_id,
      orderDate: toolResult.order_date,
      refundAmount: toolResult.total_amount,
      status: toolResult.status,
      itemDescription: toolResult.item_description
    }]
  };
}

// Usage: extract facts from every tool result
const caseFacts = extractCaseFacts(orderLookupResult);

def extract_case_facts(tool_result: dict) -> dict:
    return {
        "customer_id": tool_result["customer_id"],
        "issues": [
            {
                "order_id": tool_result["order_id"],
                "order_date": tool_result["order_date"],
                "refund_amount": tool_result["total_amount"],
                "status": tool_result["status"],
                "item_description": tool_result["item_description"],
            }
        ],
    }


# Usage: extract facts from every tool result
case_facts = extract_case_facts(order_lookup_result)

Step 2. Implement a persistent case facts block that is prepended to every prompt, outside summarised history

Why: The case facts block must persist across every turn regardless of what happens to the conversation history. It sits outside the summarised portion of the context, ensuring amounts, dates, and order numbers survive even when earlier conversation turns are compressed.

You should see: A prompt construction function that always includes the case facts block at the top of every message, followed by any summarised history, followed by the current turn. The case facts block should be clearly delimited with a section header.

function buildPrompt(caseFacts, summarisedHistory, currentMessage) {
  const caseFactsBlock = `## Active Case Facts (DO NOT SUMMARISE)\n` +
    `${JSON.stringify(caseFacts, null, 2)}\n\n`;
  
  return [
    { role: "user", content: caseFactsBlock + summarisedHistory },
    { role: "assistant", content: "I have the case facts and history." },
    { role: "user", content: currentMessage }
  ];
}

import json


def build_prompt(case_facts, summarised_history, current_message) -> list[dict]:
    # The facts block sits outside the summarised history precisely so
    # progressive summarisation cannot round off the numbers in it.
    case_facts_block = (
        "## Active Case Facts (DO NOT SUMMARISE)\n"
        f"{json.dumps(case_facts, indent=2)}\n\n"
    )
    return [
        {"role": "user", "content": case_facts_block + summarised_history},
        {"role": "assistant", "content": "I have the case facts and history."},
        {"role": "user", "content": current_message},
    ]

Step 3. Build a tool result trimmer that filters order lookup responses from 40+ fields to only the 5 relevant return-related fields

Why: Untrimmed tool results are a silent context budget killer. An order lookup returning 40+ fields consumes tokens in every subsequent turn as conversation history grows. Trimming to relevant fields before results enter context is essential, not optional.

You should see: A trimming function that takes a raw tool result object and returns only the fields needed for the current task. The trimmed result should be 80-90% smaller than the original.

function trimToolResult(rawResult, relevantFields = null) {
  if (!relevantFields) {
    relevantFields = [
      "order_id", "order_date", "total_amount",
      "return_eligible", "item_description"
    ];
  }
  return Object.fromEntries(
    Object.entries(rawResult).filter(([k]) => relevantFields.includes(k))
  );
}

// Before: 40+ fields, ~2000 tokens
// After: 5 fields, ~200 tokens
const trimmed = trimToolResult(orderLookupResult);

DEFAULT_FIELDS = [
    "order_id", "order_date", "total_amount", "return_eligible", "item_description",
]


def trim_tool_result(raw_result: dict, relevant_fields=None) -> dict:
    fields = relevant_fields or DEFAULT_FIELDS
    return {k: v for k, v in raw_result.items() if k in fields}


# Before: 40+ fields, ~2000 tokens
# After: 5 fields, ~200 tokens
trimmed = trim_tool_result(order_lookup_result)

Step 4. Test with a multi-turn conversation where summarisation occurs and verify that transactional facts survive intact across all turns

Why: This validates that the persistent case facts pattern actually works. The exam tests whether you understand that progressive summarisation destroys specific amounts and dates, and the case facts block is the fix. You need to verify this empirically.

You should see: A 6-8 turn conversation where summarisation occurs after turn 4. After summarisation, the agent should still reference the exact refund amount ($247.83), order number (#8891), and date (March 3rd) from the case facts block. Without the block, these values would be lost to summarisation.

// Simulate multi-turn conversation with summarisation
const caseFacts = { orderId: "#8891", refundAmount: "$247.83", orderDate: "2024-03-03" };

// Turn 5: after summarisation
const withCaseFacts = buildPrompt(caseFacts, "Customer wants a refund for a recent order", "Please confirm the refund details.");
// Agent should reference: $247.83, #8891, March 3rd

const withoutCaseFacts = buildPrompt(null, "Customer wants a refund for a recent order", "Please confirm the refund details.");
// Agent will say: your recent refund request (no specifics)

# Simulate multi-turn conversation with summarisation
case_facts = {"order_id": "#8891", "refund_amount": "$247.83", "order_date": "2024-03-03"}

# Turn 5: after summarisation
with_case_facts = build_prompt(
    case_facts,
    "Customer wants a refund for a recent order",
    "Please confirm the refund details.",
)
# Agent should reference: $247.83, #8891, March 3rd

without_case_facts = build_prompt(
    None,
    "Customer wants a refund for a recent order",
    "Please confirm the refund details.",
)
# Agent will say: your recent refund request (no specifics)

Step 5. Add key findings placement logic that positions summaries at the beginning of aggregated inputs to mitigate the lost-in-the-middle effect

Why: Models process information at the beginning and end of long inputs reliably, but findings buried in the middle may be missed. Placing key findings summaries at the start of aggregated inputs is a structural fix for this well-documented phenomenon.

You should see: An aggregation function that places a Key Findings Summary section at the top of combined inputs, followed by detailed results with explicit section headers. The key findings should be concise bullet points drawn from the detailed content.

function aggregateWithKeyFindings(sources) {
  const keyFindings = sources.map(s => `- ${s.name}: ${s.keyClaim}`);
  
  return `## Key Findings Summary\n${keyFindings.join("\n")}\n\n` +
    `## Detailed Findings\n\n` +
    sources.map(s => `### ${s.name}\n${s.fullContent}`).join("\n\n");
}

// Key findings at top, detailed content with headers below
// Mitigates lost-in-the-middle effect structurally

def aggregate_with_key_findings(sources: list[dict]) -> str:
    key_findings = "\n".join(f"- {s['name']}: {s['key_claim']}" for s in sources)
    detailed = "\n\n".join(f"### {s['name']}\n{s['full_content']}" for s in sources)
    return f"## Key Findings Summary\n{key_findings}\n\n## Detailed Findings\n\n{detailed}"


# Key findings at top, detailed content with headers below.
# Mitigates the lost-in-the-middle effect structurally, not by prompting.

Appendix B — Interactive Study Prompts

Two prompts to paste into Claude. B1 drills the judgement the exam actually measures; B3 reviews the code you wrote for the Build Exercise above. The exam simulator between them is the interactive quiz on this page.

B1. Concept Check — Discrimination Drill

B2. Exam Simulator

B3. Build Coach — Code Review

The Build Exercise and its hint ladder are already on this page. This prompt is for the one thing the page cannot do: review the code you actually wrote.