Optimize Context Windows and Manage Token Usage
Claude Certified Architect – Professional (CCAR-P) Exam Guide
Domain 2: Claude Models, Prompting & Context Engineering — 13% Target objective: Optimize context windows and manage token usage
1 What You Need to Know for the CCAR-P Exam
For this objective, expect architecture and scenario questions around the following concepts:
| Exam Area | What You Must Understand |
|---|---|
| Context window | Claude’s available working context for an inference |
| Token budget | How input, output, tools, history and thinking consume context |
| Context rot | Why adding more information can reduce model effectiveness |
| Token counting | Estimating input size before making a request |
| Context selection | Supplying only information relevant to the current task |
| Long-context prompting | Structuring very large document inputs effectively |
| RAG / retrieval | Loading relevant information instead of the entire knowledge base |
| Just-in-time retrieval | Allowing agents to fetch information only when required |
| Progressive disclosure | Giving an agent increasingly detailed information as needed |
| Prompt caching | Reducing repeated processing cost/latency for reusable prefixes |
| Context editing | Removing obsolete tool results or thinking blocks |
| Compaction | Summarizing older conversation state to continue long-running tasks |
| External memory | Persisting important state outside the model context |
| Multi-agent isolation | Giving individual agents only the context necessary for their tasks |
Anthropic summarizes the central principle of context engineering as finding the smallest set of high-signal tokens that maximizes the likelihood of the desired outcome.
That sentence captures much of what the exam is testing.
2 Context Window: Understand the Architecture
A context window is the information Claude can reference while producing the current response.
Conceptually:
┌───────────────────────────────────────────────────────────────┐
│ CLAUDE CONTEXT WINDOW │
│ │
│ System Prompt │
│ + │
│ Tool Definitions │
│ + │
│ Conversation History │
│ + │
│ Documents / Images │
│ + │
│ Retrieved Knowledge │
│ + │
│ Tool Results │
│ + │
│ Current User Request │
│ + │
│ Generated Output / Thinking │
│ │
└───────────────────────────────────────────────────────────────┘All of these consume the available context budget. Anthropic’s current documentation states that its newest models can support context windows of up to 1 million tokens depending on the model, while other supported models may use smaller windows such as 200K. The exact number is model-specific and should therefore be treated as a model-selection consideration rather than a universal Claude property.
Exam mindset
Do not memorize only:
“Claude supports a very large context window.”
Understand instead:
“The architect should select and structure context so the model receives enough relevant information to perform the task accurately without unnecessarily increasing cost, latency or context pollution.”
3 Context Window Is Not the Same as Model Knowledge
This distinction is easy to test.
| Concept | Meaning |
|---|---|
| Training knowledge | Information learned during model training |
| Context window | Information available during the current inference |
| External memory | Information stored outside the model and retrieved when required |
| RAG | Mechanism for retrieving external information into context |
| Prompt cache | Reuse of previously processed prompt prefixes |
| Conversation history | Earlier messages carried forward into subsequent requests |
If a model has a 1M-token context window, that does not mean it permanently remembers 1M tokens across all sessions.
The context window is working memory, not permanent memory. Anthropic explicitly distinguishes context from the data used to train the model.
4 The Most Important Exam Concept: More Context ≠ Better Context
Suppose an enterprise has:
HR policies 80,000 tokens
Finance procedures 120,000 tokens
Security standards 70,000 tokens
Product manuals 250,000 tokens
Support tickets 300,000 tokens
Legal documents 100,000 tokens
──────────────
Total 920,000 tokensThe user’s question is:
“What is our reimbursement limit for domestic hotel stays?”
A poor architecture sends all 920K tokens to Claude simply because the selected model can accommodate them.
A better architecture retrieves:
Employee Expense Policy
↓
Travel Policy
↓
Domestic Hotel Section
↓
Relevant 2–5K token context
↓
ClaudeWhy?
The smaller context has:
higher relevance → lower noise → lower token usage → lower cost → often lower latency → better attention to the important evidence
Anthropic calls degradation from increasingly large, noisy context context rot and recommends deliberate curation of what goes into the context window.
CCAR-P exam rule
When choosing between:
A. Maximum possible context
and
B. Minimum sufficient high-quality context
Prefer B, assuming the necessary information can reliably be retrieved.
5 Think in Terms of a Token Budget
For an architecture question, think of the context window as a finite budget.
Total Context Budget
│
├── System instructions
├── Tool definitions
├── User request
├── Conversation history
├── Retrieved documents
├── Tool outputs
├── Thinking
└── ResponseA simplified planning equation is:
Available Context
≈
Model Context Window
-
Current Input
-
Space Needed for OutputThis is conceptual rather than a substitute for Anthropic’s actual token counting.
Example
Assume a hypothetical architecture gives a request a 200K-token window.
System + tools 10K
Conversation history 35K
Retrieved documents 115K
Current request 5K
Expected output 20K
────
Total 185KThere is relatively little headroom remaining.
Instead of continuing to add documents, the architect might:
Remove stale history
+
Clear old tool output
+
Retrieve fewer documents
+
Summarize older stateThis is context engineering.
6 Token Counting Should Be Proactive
Anthropic provides a token counting API that estimates how many input tokens a request will consume before it is submitted.
The endpoint supports structured request content including system prompts, messages, tools, images and PDFs. Anthropic specifically recommends it for managing costs and rate limits, making routing decisions and fitting prompts to target lengths.
Architecturally:
Incoming Request
│
▼
Assemble Candidate Context
│
▼
Token Count
│
├──── Within Threshold ───→ Claude
│
└──── Too Large
│
▼
Context Optimizer
/ | \
Retrieve Summarize Remove
│
▼
Re-countExam trap
Question: What is the best way to know whether a constructed API request fits a desired token budget?
Wrong:
Estimate characters manually.
Better:
Use Claude’s token counting capability against the model/request structure.
Anthropic also warns that tokenization can change between model generations, so counts measured for one model should not automatically be assumed to apply to another.
7 Context Engineering vs Prompt Engineering
This distinction is particularly important for Domain 2.
Prompt engineering
Focuses mainly on:
HOW should I ask Claude?Examples include role instructions, few-shot examples, XML structure, task instructions and output formatting.
Context engineering
Focuses on:
WHAT information should Claude see
at this particular inference step?Anthropic describes context engineering as curating and maintaining the optimal set of tokens available to the model—including instructions, tools, external information and message history.
Consider an insurance claims agent.
Poor design:
System Prompt
+
500-page Claims Manual
+
Entire Customer History
+
Entire Product Catalog
+
All Previous Agent Outputs
+
User ClaimOptimized design:
System Prompt
+
Current Claim
+
Customer's Relevant Policy
+
Relevant Claims Rules
+
Relevant Prior Claim Summary
+
Required ToolsThe second architecture is usually what the exam wants you to recognize.
8 Use Retrieval Instead of Loading Everything
One of the strongest ways to manage context is to keep large information sets outside Claude and retrieve the relevant portions.
┌──────────────────┐
│ Enterprise Data │
│ │
│ Policies │
│ Manuals │
│ Tickets │
│ Contracts │
│ Knowledge Base │
└────────┬─────────┘
│
Search / RAG
│
▼
Relevant Content
│
▼
User Question ───────────→ Claude
│
▼
AnswerThis architecture provides focused context, rather than blindly maximizing context.
Example
Question:
“Can customer ABC terminate its agreement early?”
Do not necessarily send:
10,000 company contractsRetrieve:
Customer ABC contract
+
Termination clause
+
Relevant amendments
+
Approved legal policyThen send those to Claude.
9 Just-in-Time Context for Agents
Traditional RAG often retrieves documents before model inference.
Agentic systems can go further.
Instead of inserting everything upfront, give Claude references and tools allowing it to retrieve additional information when it determines that information is needed.
Anthropic calls this a just-in-time context strategy. Agents may retain lightweight identifiers such as filenames, queries or links, then dynamically load data through tools during execution.
Example:
Task:
Analyze payment processing defect
Initial Context:
- architecture overview
- repository index
- incident description
│
▼
Claude identifies payment-service
│
▼
Read payment-service files
│
▼
Claude identifies DB dependency
│
▼
Retrieve schema
│
▼
Claude identifies suspicious log
│
▼
Query relevant log windowCompare this with:
Load entire repository
+
entire database schema
+
30 days of logs
+
every design document
BEFORE startingThe first is usually much more context-efficient.
10 Progressive Disclosure
Closely related to just-in-time retrieval is progressive disclosure.
Claude starts with enough information to navigate the environment and discovers deeper information only when required.
Level 1
Repository structure
↓
Level 2
Relevant module list
↓
Level 3
Relevant files
↓
Level 4
Relevant methods
↓
Level 5
Specific implementation detailsInstead of:
EVERYTHING
↓
ClaudeAnthropic describes this approach as allowing agents to incrementally discover information while maintaining only what is necessary in working memory.
Exam keyword
If you see:
“Huge information environment and the agent does not know in advance which pieces will be required.”
Think:
tool-based retrieval + progressive disclosure + just-in-time context
11 Long-Context Prompt Structure Matters
Sometimes you genuinely need to send a large document or multiple large documents.
For inputs above roughly 20K tokens, Anthropic recommends deliberately structuring long-context prompts. Its current guidance says to put the long documents near the top of the prompt and place the query/instructions afterward. Anthropic reports that putting queries at the end can improve response quality in complex multi-document tasks.
Recommended pattern:
<documents>
<document>
<source>Contract A</source>
<document_content>
...
</document_content>
</document>
<document>
<source>Policy Manual</source>
<document_content>
...
</document_content>
</document>
</documents>
<instructions>
Compare the termination obligations.
Identify conflicts between the agreement
and corporate policy.
</instructions>Anthropic specifically recommends XML structure for separating documents, metadata, instructions, examples and other prompt components.
12 Ground Long-Document Analysis Before Reasoning
With very large documents, an effective technique is:
Large Documents
↓
Identify / extract relevant evidence
↓
Reason over evidence
↓
Produce final responserather than:
Large Documents
↓
Immediately produce answerAnthropic recommends asking Claude to identify relevant parts of long documents before performing the final task because doing so helps focus the model on useful evidence.
Example
Instead of:
Analyze these eight contracts and tell me whether the acquisition triggers termination rights.
Use a workflow conceptually like:
Step 1: Find acquisition/change-of-control provisions.
Step 2: Identify relevant language and source.
Step 3: Compare the provisions.
Step 4: Determine which agreements may create risk.This reduces distraction from irrelevant portions of the documents.
13 Prompt Caching: Understand What It Does—and Does NOT Do
Prompt caching is a likely exam topic because it is often confused with context optimization.
Suppose every customer-support request contains:
System Instructions 4K
Product Documentation 50K
Few-shot Examples 10K
User Question 1KThe first 64K tokens are largely repeated.
Prompt caching allows reusable prompt prefixes to be processed efficiently rather than repeatedly paying the same processing cost.
STATIC / REUSABLE
──────────────────────────
System Prompt
Product Documentation
Examples
↓
CACHE
──────────────────────────
DYNAMIC
──────────────────────────
User Question
Current Customer DataAnthropic says prompt caching is especially useful with large context, many examples, repeated instructions and long multi-turn conversations.
Critical exam trap
Prompt caching reduces repeated processing cost and latency.
It does NOT magically free up context-window capacity.
Anthropic explicitly states that cached prompt prefixes still occupy the context window.
Remember:
Prompt Caching
↓
Cost optimization ✓
Latency optimization ✓
Context capacity gain ✗14 Arrange Static Content Before Dynamic Content for Caching
Prompt caching works on reusable prefixes.
Therefore structure requests conceptually as:
STATIC
────────────────────────
Tool definitions
System instructions
Reference documentation
Few-shot examples
────────────────────────
CACHE POINT
────────────────────────
DYNAMIC
Current conversation
Current user input
Retrieved current data
────────────────────────Anthropic’s caching documentation recommends placing reusable static content toward the beginning of the prompt, with changing information later.
Poor cache architecture
User-specific timestamp
System prompt
Different user identifier
Product manual
Dynamic metadata
ExamplesFrequent changes early in the prefix can undermine reuse.
Better
System prompt
Product manual
Examples
------------------
Reusable prefix
------------------
User-specific state
Current question15 Conversation History Becomes a Context Problem
Suppose a customer-support agent handles a 70-turn conversation.
Naive architecture:
Turn 1
Turn 2
Turn 3
...
Turn 69
Turn 70
+
Everything generated by every toolEach new request carries a progressively larger history.
Eventually you face:
Increasing token usage
+
Increasing latency/cost
+
Irrelevant history
+
Potential context pollution
↓
Lower-quality agent behaviorKeeping the entire history forever is rarely the best architecture.
16 Compaction for Long-Running Conversations
Anthropic now recommends server-side compaction as the primary strategy when long-running conversations or agentic workflows regularly approach context limits. Compaction summarizes older information while preserving what is needed to continue the task.
Conceptually:
Before
Turn 1
Turn 2
Turn 3
...
Turn 67
Turn 68
Turn 69
Turn 70
↓ COMPACT
After
┌─────────────────────────────┐
│ Summary of Turns 1–60 │
│ │
│ • Goals │
│ • Decisions │
│ • Constraints │
│ • Important discoveries │
│ • Outstanding work │
└─────────────────────────────┘
+
Recent Turns 61–70Anthropic describes compaction as a particularly useful first lever for maintaining long-term coherence in long-horizon tasks.
17 What Should Compaction Preserve?
Imagine an AI software architect has been working for several hours.
Poor summary:
“The agent has been developing the payment application and encountered several issues.”
This saves tokens but destroys useful state.
Better compacted state:
OBJECTIVE
Migrate payment module from API v1 to v2.
COMPLETED
✓ Authentication migration
✓ Payment-create endpoint
✓ Retry handler
KEY DECISIONS
• Preserve legacy transaction IDs
• Maximum retry count = 3
• Idempotency key required
OPEN ISSUE
Refund endpoint fails integration test INT-27.
FILES CHANGED
payment_client.py
retry_handler.py
payment_service.py
NEXT STEP
Investigate response mapping in refund_adapter.py.This preserves high-signal information while discarding verbose execution history.
Anthropic warns that overly aggressive compaction can lose subtle information that later becomes important, so compaction should initially optimize for recall of important state, then be tuned to remove unnecessary detail.
18 Context Editing
Compaction is not the only technique.
Anthropic also provides context editing, including strategies for removing old tool results and managing thinking blocks.
Example agent history:
User asks for analysis
Agent searches database
↓
20,000-token DB result
Agent analyzes result
↓
Extracts five important facts
Agent calls another tool
↓
15,000-token outputLater, Claude may need:
The five conclusionsbut not necessarily:
the original 35,000 tokens
of raw tool output.A context-editing strategy can remove obsolete tool results while retaining information needed for subsequent reasoning.
19 Tool Results Are Frequent Token Hogs
This is particularly important for agent architectures.
Consider:
Agent
│
├── Search → 8K tokens
├── Database → 15K tokens
├── Logs → 25K tokens
├── Repository search → 20K tokens
└── API response → 12K tokens
Total = 80K tokensIf every raw result stays in context, the agent’s available context can disappear rapidly.
Better architecture:
Tool Call
↓
Result
↓
Extract Useful Information
↓
Persist Important State
↓
Clear Obsolete Raw ResultAnthropic specifically identifies clearing older tool calls/results as one of the safer lightweight forms of context management.
20 External Memory for Long-Horizon Agents
Not every useful fact needs to remain inside Claude’s context window.
For long-running tasks:
Claude Context
│
┌────────┴────────┐
│ │
Active Context External Memory
│
┌──────────┼──────────┐
│ │ │
Decisions Progress FindingsAnthropic discusses structured note-taking or agentic memory as a way for an agent to persist state outside the active context window and retrieve it later.
For example:
PROJECT_STATE.md
Objective:
Modernize authentication module
Completed:
- OAuth integration
- token validation
Decisions:
- JWT expiry = 30 minutes
- refresh token stored securely
Outstanding:
- session revocation
- logout integration
Known Issues:
- test #AUTH-27 failingClaude can reload this compact state after a context reset.
21 Long-Horizon Context Strategy
For an agent expected to work for hours, the architecture might therefore become:
┌───────────────┐
│ Current Goal │
└───────┬───────┘
│
▼
┌─────────────────┐
│ Active Context │
│ │
│ Instructions │
│ Current State │
│ Recent Results │
└────────┬────────┘
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Retrieve Tool Calls External
Context Memory
│ │ │
└──────────────┼──────────────┘
│
▼
Continue
│
Context grows
│
▼
Compact
│
▼
ContinueThat is far more robust than assuming a sufficiently large context window eliminates context engineering.
22 Multi-Agent Architectures Can Also Reduce Context Pressure
Consider a research task involving:
Financial analysis
Security analysis
Legal analysis
Technical analysisA single agent could consume all supporting material.
Alternatively:
ORCHESTRATOR
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Financial Security Legal
Agent Agent Agent
│ │ │
Finance Context Security Context Legal Context
│ │ │
└─────────────────┼─────────────────┘
▼
Compact Results
│
▼
ORCHESTRATOREach specialist receives only the context relevant to its task.
Anthropic identifies sub-agent architectures as another strategy for handling complex work where separate exploration paths can operate with isolated context windows.
Exam caution
Do not select multi-agent architecture just to save tokens.
Use it when task decomposition and parallel/specialized reasoning justify the additional orchestration complexity.
23 Output Tokens Matter Too
Candidates frequently think only about input tokens.
But output also matters.
A prompt asking:
“Provide a comprehensive 30-page analysis with reasoning, alternative interpretations and detailed recommendations.”
may consume substantial output capacity and increase latency/cost.
Your architecture should control outputs appropriately:
Poor
Explain everything you know about the issue.
Better
Return:
1. Decision
2. Top 3 supporting reasons
3. Risks
4. Recommended action
Maximum 600 words.This is not simply “make responses short.”
It means aligning generated content with actual business requirements.
24 Extended Thinking Also Has a Token Cost
When thinking capabilities are used, reasoning tokens form part of the resource equation. Anthropic states that thinking tokens are billed as output tokens and count toward relevant limits/context behavior.
Therefore:
Simple classification
↓
Heavy reasoning budget?
↓
Probably unnecessarywhile:
Complex architectural trade-off
↓
Deeper reasoning
↓
Potentially worthwhileCCAR-P principle
Do not maximize reasoning tokens for every request.
Allocate reasoning effort according to task complexity, quality requirements, latency objectives and cost constraints.
25 Context Optimization Is a Quality–Cost–Latency Trade-off
This is the broader architecture decision the CCAR-P exam is likely to assess.
QUALITY
▲
/ \
/ \
/ \
/ \
/ \
/___________\
COST LATENCYLarge context can improve completeness when necessary, but may increase:
cost + processing time + irrelevant information + context rot risk
Aggressive compression can reduce cost but may lose important detail.
Excessively narrow retrieval can miss necessary evidence.
Therefore, the correct architecture seeks:
Enough context
+
High relevance
+
Required fidelity
+
Acceptable latency
+
Acceptable costrather than simply:
Minimum tokensor:
Maximum tokens26 Choosing the Right Context Strategy
Use this decision matrix for the exam:
| Situation | Best-Fit Technique |
|---|---|
| Same large instructions repeated | Prompt caching |
| Huge knowledge base, small relevant subset | RAG / retrieval |
| Agent does not know what information it will need | Just-in-time retrieval |
| Complex information environment | Progressive disclosure |
| Long conversation approaching context limit | Compaction |
| Old raw tool results no longer useful | Context editing / tool-result clearing |
| State must survive long-running tasks | External memory / structured notes |
| Multiple independent specialist domains | Sub-agents |
| Large documents genuinely required | Long-context prompting |
| Unsure whether request fits | Token counting |
| Model output unnecessarily large | Output constraints |
| Long prompt contains many unrelated items | Context pruning |
| Same static prefix used repeatedly | Prompt caching |
| Need current information rather than historical conversation | Retrieve fresh information on demand |
27 A Strong Production Architecture
A well-designed context pipeline may look like this:
USER REQUEST
│
▼
┌──────────────────┐
│ Intent / Task │
│ Classification │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Context Planner │
└────────┬─────────┘
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Conversation RAG / External
State Search Memory
│ │ │
└─────────────┼─────────────┘
▼
┌──────────────────┐
│ Context Filter │
│ + Rank │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Token Counter │
└────────┬─────────┘
│
Too large?
/ \
Yes No
│ │
▼ │
Prune / Compact │
/ Retrieve Less │
│ │
└────────┬────────┘
▼
┌────────────────────┐
│ Cached Static │
│ Prompt Prefix │
└─────────┬──────────┘
│
▼
CLAUDE
│
▼
Tool Calls
│
▼
Context Update
│
┌─────────┴────────┐
│ │
Keep Relevant Clear Obsolete
State Tool ResultsThis illustrates why context management is an architectural concern, rather than merely a prompt-writing technique.
28 Practical Example: Enterprise Customer-Support Agent
Assume an enterprise has:
5,000 product documents
10 years of tickets
Customer CRM records
Policies
Knowledge articles
Conversation historyPoor architecture
Load every potentially related document
+
Entire customer history
+
Full conversation
+
Large system prompt
↓
ClaudeProblems:
| Problem | Result |
|---|---|
| Excessive tokens | Higher cost |
| Huge prompt | More processing |
| Irrelevant documents | Noise |
| Old tickets | Context pollution |
| Long raw tool results | Wasted context |
| Growing conversation | Eventually requires management |
Better architecture
Customer Question
↓
Determine intent
↓
Retrieve customer/account state
↓
Retrieve top relevant product docs
↓
Retrieve only relevant recent ticket history
↓
Token check
↓
Claude
↓
Additional retrieval only if needed
↓
AnswerStatic system instructions and commonly reused material can be cached, while old tool results and stale conversation state can be cleared or compacted.
That is the kind of architecture judgment expected of a Professional-level architect.
29 Common CCAR-P Exam Traps
| Trap | Why It Is Wrong | Better Thinking |
|---|---|---|
| “The model has a huge context window, so load everything.” | Capacity does not guarantee relevance or accuracy. | Retrieve/select high-signal context. |
| “Prompt caching increases context-window size.” | Caching changes processing economics, not context capacity. | Cached tokens still occupy context. |
| “RAG and prompt caching solve the same problem.” | RAG selects information; caching reuses repeated prefixes. | Know their distinct purposes. |
| “Always preserve complete conversation history.” | History grows indefinitely and may contain stale information. | Compact/prune while preserving state. |
| “Summarize everything aggressively.” | Critical details can be lost. | Preserve decisions, constraints and unresolved state. |
| “Only user messages consume tokens.” | System prompts, messages, tools, documents and output also matter. | Budget the complete request. |
| “Large context eliminates the need for retrieval.” | Large contexts can still suffer pollution and relevance problems. | Retrieve high-signal information. |
| “Use deep thinking for every request.” | Adds unnecessary output/token cost and latency. | Match reasoning effort to complexity. |
| “Token optimization means shortest possible prompt.” | Removing critical context damages accuracy. | Optimize information value per token. |
| “Just use a larger model when context grows.” | Does not solve irrelevant or stale context. | Fix context architecture first. |
30 Exam Decision Framework
When you get a CCAR-P scenario involving context, mentally run this sequence:
1. What does Claude actually need to know?
↓
2. Is all proposed context relevant?
↓
3. Can some information stay external?
↓
4. Can relevant information be retrieved?
↓
5. Is static material repeated?
↓
6. Would caching help?
↓
7. Is conversation/tool history growing?
↓
8. Can obsolete information be removed?
↓
9. Does important state need compaction/memory?
↓
10. Does the request fit the token budget?
↓
11. Is sufficient capacity reserved for output?
↓
12. Does the design satisfy quality,
latency and cost requirements?For exam purposes, the best answer is usually the one that preserves required information while minimizing irrelevant context.
31 Key Distinctions to Memorize
| Technique | Primary Purpose | Does It Reduce Active Context? | Primary Benefit |
|---|---|---|---|
| Token counting | Measure request size | No | Planning |
| Prompt caching | Reuse prompt prefix | No | Cost + latency |
| RAG | Retrieve relevant information | Usually | Relevance + scale |
| Context pruning | Remove irrelevant information | Yes | Efficiency |
| Context editing | Remove selected historical content | Yes | Long-running agents |
| Compaction | Summarize older state | Yes | Continuity |
| External memory | Persist state outside context | Yes | Long-term state |
| Just-in-time retrieval | Load information when needed | Yes | Efficient agents |
| Progressive disclosure | Gradually expose information | Yes | Focus |
| Multi-agent decomposition | Isolate task context | Indirectly | Scale + specialization |
Exam favorite: Prompt caching and compaction are not interchangeable.
Caching:
"Don't repeatedly process the same static tokens."
Compaction:
"Don't keep carrying all old conversational tokens."32 Exam-Focused Rules to Remember
If you memorize only one set of rules from this topic, memorize these:
- Context window = working memory, not permanent memory.
- More context is not necessarily better.
- Optimize for high-signal, relevant tokens.
- Use retrieval when only part of a large corpus is needed.
- Use just-in-time retrieval when an agent discovers information needs dynamically.
- Use token counting proactively.
- Use prompt caching for repeated static prefixes—not to increase context capacity.
- Use compaction for long-running conversations.
- Remove obsolete tool outputs/context when they no longer provide value.
- Persist critical long-term state externally when appropriate.
- Structure genuinely large prompts carefully: documents first, query later.
- Treat context, output and reasoning tokens as architectural resources.
- Optimize simultaneously for quality, latency and cost—not token count alone.
Anthropic’s current documentation supports this overall approach: context should be deliberately curated, server-side compaction is recommended for long-running conversations, and token counting should be used to stay within planned limits.
33 Five CCAR-P Style Practice Questions
Question 1 — Large Knowledge Base
A financial-services company is building a Claude-powered assistant over 600,000 tokens of internal policies. Most employee questions require information from only one or two policies. The selected Claude model can technically accommodate the complete corpus within its context window.
Which architecture is BEST?
A. Include the complete policy corpus in every request because it fits within the model’s context window.
B. Summarize the entire corpus into a single document and use the summary for every question.
C. Retrieve the most relevant policy sections for each request and provide those sections to Claude.
D. Increase max_tokens so Claude can examine more policies.
Correct Answer: C
Why?
The fact that the corpus fits does not mean it should all be provided.
Retrieving the most relevant sections minimizes context pollution and unnecessary token usage while preserving the source information needed for the task. Anthropic explicitly notes that larger context is not automatically better and that context quality deteriorates when irrelevant information accumulates.
Why the others are wrong
A: Confuses context capacity with optimal context usage.
B: May lose important policy details through excessive summarization.
D: max_tokens controls generated-output considerations; it does not solve irrelevant input context.
Exam clue
“Huge corpus + only a small subset is relevant”
Think:
RAG / selective retrieval.
Question 2 — Prompt Caching
A customer-support application includes a 40,000-token product guide and an 8,000-token set of instructions in every Claude API request. These sections rarely change, while the customer question changes on every call.
The team wants to reduce repeated processing cost and latency without removing the product guide from Claude’s context.
What should the architect recommend?
A. Compaction B. Prompt caching C. RAG only D. Reduce Claude’s context-window size
Correct Answer: B
Why?
The large prefix is repeated and static, which is the ideal use case for prompt caching. Anthropic recommends caching for large repeated context, examples, instructions and multi-turn histories.
A good request layout is:
System Instructions
Product Guide
Examples
────────────────────
Cached Prefix
────────────────────
Customer Question
Current Customer StateImportant trap
Caching does not make those 48K tokens disappear from the context window. They still occupy context; they are simply processed more efficiently for repeated requests.
Exam clue
“Repeated large static prefix + cost/latency problem”
Think:
Prompt caching.
Question 3 — Long-Running Agent
A Claude-based engineering agent has been working for several hours. Its history contains many shell outputs, repository searches and debugging logs. The agent must continue working while retaining architectural decisions, completed tasks and unresolved issues.
Which approach is BEST?
A. Send the complete interaction history indefinitely. B. Delete the entire history whenever the context becomes large. C. Compact earlier history while preserving important state and remove obsolete raw tool results. D. Increase the response length so Claude can reconstruct previous information.
Correct Answer: C
Why?
Long-running agents need continuity without indefinitely accumulating context.
Compaction preserves important state:
Goals
Decisions
Constraints
Completed work
Open issues
Next actionswhile raw historical information that no longer contributes can be removed.
Anthropic recommends server-side compaction as the primary context-management strategy for long-running conversations and identifies tool-result clearing as another context-management mechanism.
Exam clue
“Agent running for hours + context/history approaching limit”
Think:
Compaction + context editing/external state.
Question 4 — Agentic Retrieval
A software-development agent operates over a repository containing several million lines of code. It does not know in advance which files will be necessary for each task.
Which design provides the most context-efficient architecture?
A. Insert the complete repository into Claude’s context before each task. B. Give Claude repository navigation/search tools and allow it to retrieve relevant files as its investigation progresses. C. Convert the repository into one very large system prompt. D. Select files randomly until Claude has enough information.
Correct Answer: B
Why?
This is a classic just-in-time context and progressive disclosure scenario.
The agent starts with enough information to navigate the repository and retrieves:
Repository structure
↓
Relevant package
↓
Relevant files
↓
Relevant functionsrather than loading everything upfront.
Anthropic describes this strategy explicitly for agentic systems, including Claude Code-like workflows where tools are used to navigate large information environments.
Exam clue
“Agent doesn’t know beforehand what information it needs.”
Think:
Just-in-time retrieval.
Question 5 — Multiple Correct Answers
An enterprise document-analysis application processes very large groups of contracts. Testing shows that Claude occasionally overlooks important clauses when given extremely large multi-document prompts.
Which TWO changes are most appropriate?
A. Place the long documents before the question/instructions in the prompt. B. Add unrelated examples until the context window is almost full. C. Structure documents and metadata clearly, such as with XML tags. D. Automatically increase output tokens to the maximum supported value. E. Duplicate the most important documents several times.
Correct Answers: A and C
Anthropic’s current long-context guidance recommends putting long-form documents near the top of a prompt and the query afterward. It also recommends structured document boundaries and metadata using XML tags.
A strong structure would resemble:
<documents>
<document>
<source>Contract-A.pdf</source>
<document_content>
...
</document_content>
</document>
<document>
<source>Contract-B.pdf</source>
<document_content>
...
</document_content>
</document>
</documents>
<instructions>
Identify change-of-control provisions.
Compare obligations and highlight conflicts.
</instructions>Why B, D and E are wrong
They add tokens without increasing useful information density.
Exam clue
“Claude misses information in genuinely necessary long documents.”
Think:
long-context structure + clear document boundaries + evidence grounding, not simply adding more tokens.
34 Exercise 1 — Design a Context Strategy for an Enterprise HR Assistant
Instead of a generic “Build Exercise,” use this architecture exercise.
Scenario
Your organization has:
Employee Handbook 50K tokens
Benefits Documents 120K
HR Policies 180K
Country-Specific Policies 200K
Historical HR Tickets 500K
Employee Profile 5KAn employee asks:
“I work in New York and have been employed for 18 months. How many weeks of parental leave am I eligible for?”
Your task
Design the context flow before looking at the suggested answer.
Consider:
What information is required?
What should NOT enter the context?
What should be retrieved?
What can be cached?
What is dynamic?
How will token usage be controlled?Recommended Architecture
Employee Question
↓
Intent = Parental Leave
↓
Retrieve Employee Attributes
Location = NY
Tenure = 18 months
↓
Retrieve
Corporate Parental Leave Policy
+
New York-specific Policy
+
Relevant Benefits Rules
↓
Exclude
Unrelated HR policies
Historical HR tickets
Other countries' policies
↓
Token Count
↓
Claude
↓
Grounded AnswerStatic system instructions can be cached.
The exercise reinforces the key CCAR-P principle:
Do not ask how much context Claude can accept. Ask how much high-quality context Claude actually needs.
35 Exercise 2 — Repair a Context-Heavy Agent
Scenario
You inherit this architecture:
SYSTEM PROMPT 12K
FULL DOCUMENTATION 100K
CONVERSATION HISTORY 80K
RAW DATABASE RESULTS 50K
SEARCH RESULTS 40K
LOG OUTPUT 70K
CURRENT TASK 2K
────────────────────────────
Very Large Active ContextThe system is expensive, slow and becoming less reliable during long sessions.
Your challenge
Redesign it using the appropriate context techniques.
Recommended Solution
CURRENT TASK
│
▼
CONTEXT PLANNER
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Relevant docs Current state Required tools
via retrieval from memory
│ │ │
└─────────────────┼─────────────────┘
▼
Token Count
│
▼
CLAUDE
│
▼
Tool Use
│
▼
Extract useful results
│
┌────────┴────────┐
▼ ▼
Persist decisions Clear obsolete
/ critical state raw tool results
│
▼
Context grows
│
▼
CompactUse:
| Original Problem | Improvement |
|---|---|
| Full docs always included | RAG |
| Repeated instructions | Prompt caching |
| Entire conversation | Compaction |
| Huge raw DB results | Tool-result clearing |
| Massive logs | Targeted retrieval |
| Important long-term decisions | External memory/state |
| Unknown future information | Just-in-time retrieval |
| Token uncertainty | Token counting |
This exercise closely resembles the architectural reasoning expected at the Professional level.
36 Final CCAR-P Cheat Sheet
┌─────────────────────────────────────────────────────────┐
│ CONTEXT & TOKEN EXAM CHEAT SHEET │
├─────────────────────────────────────────────────────────┤
│ │
│ Huge corpus │
│ → RAG / selective retrieval │
│ │
│ Unknown future information needs │
│ → Just-in-time retrieval │
│ │
│ Complex information hierarchy │
│ → Progressive disclosure │
│ │
│ Repeated static prefix │
│ → Prompt caching │
│ │
│ Long-running conversation │
│ → Compaction │
│ │
│ Old large tool outputs │
│ → Context editing / clearing │
│ │
│ Long-term state │
│ → External memory / structured notes │
│ │
│ Request may exceed budget │
│ → Token counting │
│ │
│ Large documents genuinely required │
│ → Documents first, query later │
│ → XML structure │
│ → Ground reasoning in relevant evidence │
│ │
│ Independent specialist tasks │
│ → Consider sub-agents │
│ │
│ Excessive generated content │
│ → Constrain output │
│ │
│ MOST IMPORTANT PRINCIPLE │
│ → Maximize useful information per token │
│ │
└─────────────────────────────────────────────────────────┘The one sentence to remember for the exam
Context optimization is not about fitting as much information as possible into Claude’s context window; it is about providing the smallest, highest-signal set of information needed to achieve the required outcome while balancing accuracy, cost, latency and long-running system reliability.
That interpretation aligns closely with Anthropic’s current context-engineering guidance.
