80% History, 20% Task: Budgeting the Context Window

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 53)

▶ Watch on YouTube & subscribe to The Stack Underflow

An agent has been running for a while — forty, sixty, a hundred turns. You check the request payload and the math is ugly: 80% of the tokens going out the door are conversation history, and only a sliver is left for the actual task, the tool schemas, and anything retrieved to answer the current question. Output quality has been sliding for a dozen turns and nobody can point to a single broken step. Nothing crashed. The context window isn’t even full. It’s just spending itself on the wrong thing — and that’s the exact scenario Domain 5 of the Claude Certified Architect exam is built to test.

The one-sentence version: A context window is a fixed budget shared across history, task, tools, and retrieval — when one category (usually history) balloons unchecked, it doesn’t just cost more tokens, it starves the categories that actually produce the answer, so the fix is to rebalance the budget, not add to the model or the history.

The question

Your context is 80% conversation history and 20% task, and quality is dropping. Fix?

• A) Add more history
• B) Rebalance the token budget — trim/summarize history so task, tools, and retrieval get room
• C) A bigger model
• D) Lower max_tokens

Pause here and pick an answer before you scroll — the point of these practice questions is reasoning through the mechanism, not pattern-matching the letter.

The answer

The correct answer is B. A context window isn’t a single resource, it’s several resources sharing one budget: the system prompt, tool definitions, retrieved documents, conversation history, and the room reserved for the model’s own output. When history is left to grow unbounded — every user turn, every assistant reply, every intermediate tool call appended forever — it doesn’t stay in its own lane. It crowds out everything else competing for the same token ceiling. At 80% history and 20% task, the model is spending most of its attention re-reading a transcript instead of reasoning about the thing you actually asked it to do right now.

The fix follows directly from the diagnosis: rebalance the proportions. Trim or summarize the history so it takes a smaller, denser slice of the budget, and let the task, the tool schemas, and any retrieved context expand back into the room that frees up.

CONTEXT WINDOW AS A BUDGET, NOT A LOG

BEFORE — history is unbounded, quality drops
┌──────────────────────────────────────────────────────────────────┐
│ HISTORY ████████████████████████████████████████ 80%             │
│ TASK    ██████ 12%                                                │
│ TOOLS   ███ 5%                                                    │
│ RETRIEVAL ██ 3%                                                   │
└──────────────────────────────────────────────────────────────────┘
   the transcript keeps growing → task/tools/retrieval get squeezed
   → the model reasons on scraps of the thing it's actually doing

           │  rebalance: trim / summarize / compact the history
           ▼

AFTER — history compacted, room given back to what earns the answer
┌──────────────────────────────────────────────────────────────────┐
│ HISTORY   ████████████████ 40%  (summarized, key facts kept)      │
│ TASK      ██████████ 25%                                          │
│ TOOLS     ████████ 20%                                            │
│ RETRIEVAL ██████ 15%                                              │
└──────────────────────────────────────────────────────────────────┘
   same window, same model — quality recovers because the tokens
   that reach the model are the tokens that answer the question

The window is a budget. Spend it on what earns the answer — not on preserving every byte of how you got here. In practice this is the same lever used across long-running agents: summarize the parts of history that are no longer load-bearing (the earlier turns’ content, not necessarily their conclusions), keep any decisions or facts that still matter, and let the freed-up space go to the current task, the tool definitions the model needs to act, and any retrieved documents relevant to this step.

Why the other options fail

• A) “Add more history.” This is the mechanism running in reverse. If an 80/20 split is already starving the task, adding more history pushes the ratio further in the wrong direction. It treats “more context” as inherently good, when the actual problem is that the proportions are wrong — the model has plenty of context, just not enough of the right kind.
• C) “A bigger model.” A larger model may support a longer window or handle degraded signal slightly more gracefully, but it doesn’t change what fraction of the budget history is eating. Swap in a bigger model with the same unbounded history-append pattern, and the ratio problem reproduces — it just takes a few more turns to get there. It’s also the expensive way to paper over something a compaction step fixes directly at a fraction of the cost.
• D) “Lower max_tokens.” max_tokens caps the model’s output length — it reserves less room for the response, or truncates it. It does nothing to the input side of the budget, where the actual imbalance lives. Lowering it doesn’t give the task, tools, or retrieval any more room; if anything, it risks cutting off the answer before it’s fully expressed, compounding the quality problem instead of solving it.

The concept behind it

Treat the context window as a budget with named line items, not a single undifferentiated pool. A rough mental model for what’s competing for space in most agent calls:

History is the dangerous line item precisely because nothing forces it to stay small. Every other category has a natural ceiling — a system prompt doesn’t grow mid-session, a tool schema doesn’t balloon on its own — but a transcript accumulates by default, one turn at a time, unless something actively prunes it. Left alone, it eventually dominates the budget the way it does in this question: 80% and climbing.

Three practical levers follow from that:

1. Compact instead of letting history grow unbounded. Summarizing older turns into a scratchpad — keeping decisions and facts, dropping the verbatim back-and-forth — is the direct lever for reclaiming budget. See The Task Overflowed the Window: Chunking and Decomposition for when and how to trigger that compaction before you hit a hard overflow.
2. Cache the parts of the budget that don’t change. A large stable system prompt or policy block doesn’t need to be re-sent raw on every turn at full price — it can be cached once and read cheaply. That’s a cost fix more than a quality fix, but it changes the economics of keeping tool definitions and retrieval generous instead of trimming them to compensate for a bloated history. See Stop Re-Sending the Same Big Block: Prompt Caching for Context.
3. Watch where the surviving tokens land, not just how many there are. Rebalancing the ratio only helps if the history you keep is still positioned where the model attends to it well. A trimmed-but-still-present rule buried in the middle of a long transcript has the same fate as an un-trimmed one. See It Forgot Your First Instruction: Lost-in-the-Middle and Context Rot for the attention mechanics behind that.

The broader exam-relevant idea: fits in the window and is being used well are different claims. A context that’s 100% full but well-proportioned across system, task, tools, retrieval, and a lean history summary will out-perform one that’s the same size but 80% stale transcript. Domain 5 keeps testing that gap in different scenario dressing — lost-in-the-middle, overflow, caching, and this budgeting question are all the same underlying discipline of context engineering viewed from a different angle.

FAQ

Isn’t more history always better, since the model has more information to work with? Not once history starts crowding out the categories that produce the current answer. More history is useful right up until it starts displacing tool schemas, retrieved facts, or reasoning room for the task at hand. Past that point it’s not adding signal, it’s diluting the ratio of useful-to-stale tokens the model has to sort through. Volume of context and usefulness of context are different variables.

How do I know if my ratio is actually the problem versus something else, like a bad prompt? Instrument it. Log the token count per category — system, tools, retrieval, history, output reserve — on a representative sample of calls. If history is consistently the dominant line item and quality correlates with conversation length, that’s the signature of a budgeting problem, not a prompt-wording problem. It’s a diagnosis you can measure, not just guess at.

Does summarizing history lose information I might need later? It can, if done carelessly — which is exactly why summarization is a design decision, not a blunt truncation. Keep decisions, facts, and anything a downstream step depends on; drop the verbatim back-and-forth that got you there. If some working state genuinely needs to survive across a compaction boundary untouched, that’s a signal it belongs in persisted memory rather than being reconstructed from a shrinking transcript — see Your Scratchpad Vanished on Compaction: Persisting Agent State.

Is this the same fix as when the context window overflows outright? Related but not identical. Overflow is a hard limit — content literally doesn’t fit and something gets truncated or rejected. This question is a quality problem well before that hard limit: everything technically fits, but the proportions are wrong, so the model’s effective performance degrades even though nothing errors out. The compaction lever helps with both, but budgeting is the discipline of catching the imbalance before you’re forced into an emergency truncation.

Where this fits in the CCA series

This is Q10 of the Domain 5 (Context Management & Reliability, 15% of the exam) practice set — the last of ten scenario questions on context and reliability. Start with the Claude Certified Architect (CCA) Exam Guide for how all five domains fit together, and RAG vs Context Engineering for why managing the window became its own discipline in the first place. The rest of the D5 set builds the same muscle from different angles: It Forgot Your First Instruction: Lost-in-the-Middle and Context Rot, The Task Overflowed the Window: Chunking and Decomposition, and Stop Re-Sending the Same Big Block: Prompt Caching for Context.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

As of mid-2026, the CCA-F exam runs on Pearson VUE, costs $125, and allows retakes — the format is 60 questions in 120 minutes with a passing scaled score of 720/1000 across five domains. Confirm these logistics on Anthropic’s official certification pages before you register, since exam details change.

Browse all tutorials for the rest of the series.