Domain 5 at a glance
- Weight
- 15%
- Questions
- ~9 of 60
- Pass line
- 720/1000
- Study time
- ~25 min
Context Management & Reliability is the smallest domain on the exam. Scenarios with a cost spike, a lost thread or an error burst, where you pick the technique that fixes the real cause.
- Context window management and what counts toward it
- Prompt caching: breakpoints, TTLs, and cost multipliers
- Compaction and context editing
- Handling long conversations with summarization and memory
- Escalation patterns and error propagation
- Rate limits, retries with backoff, and overloaded errors
- Observability and graceful degradation
The context window
The context window is everything the model can see in one request: the system prompt, tool definitions, every message, every tool result, and the output it generates. Output counts too, so a request with a nearly full prompt has little room to answer.
Most current models have a 200K-token standard window; a 1M window is available on some models and tiers as an opt-in, priced at a premium above 200K input tokens. Use the token counting endpoint to measure a request before you send it.
Anthropic's context engineering advice is to find the smallest set of high-signal tokens that gets the job done. More context is not better context; irrelevant tokens dilute attention.
On the exam, watch for "cached tokens do not count toward the window". They do; caching changes price, not size.
Prompt caching
Caching reuses a byte-identical prefix across requests. You mark the end of the reusable part with cache_control, and the cache key covers everything before it in this order: tools, then system, then messages. Any change earlier in that order (a new tool, a timestamp in the system prompt, a different model) is a cache miss.
| Rule | Value |
|---|---|
| Breakpoints per request | Up to 4 cache_control markers |
| Prefix order | tools, then system, then messages |
| Lookback | The system checks about 20 blocks back from a breakpoint for a hit |
| Minimum cacheable length | Model-dependent (1,024 to 4,096 tokens on recent models; check the docs) |
| Below the minimum | Not cached, billed as normal input, no error |
| Operation | 5-minute TTL | 1-hour TTL |
|---|---|---|
| Cache write | 1.25x | 2x |
| Cache read (hit) | 0.1x | 0.1x |
| Break-even | 2nd request | 3rd request |
- Put volatile content (timestamps, user IDs, the latest question) after the last breakpoint.
- Reads refresh the TTL, so steady traffic keeps a 5-minute entry warm.
- The
usageblock reportscache_creation_input_tokensandcache_read_input_tokens; watch them to confirm hits.
Cache savings estimator
- Without caching
- $3.87/hr
- With caching
- $0.70/hr
- Saving
- 82%
Break-even: caching pays off from the 2nd call that reuses the prefix within one 5 minutes window (write 1.25x + reads at 0.1x vs paying 1x every time).
Compaction and context editing
| Technique | What it does | Trade-off |
|---|---|---|
/compact [instructions] | Claude Code summarizes the conversation and continues from the summary | Lossy: details not in the summary are gone |
| Auto-compact | Runs when the window nears full | Same loss, at a time you did not pick |
| Server-side compaction | The API summarizes older turns for long-running agents | Lossy; configure what to keep |
| Context editing (clear tool results) | Drops old tool results past a threshold, keeping the call record | Invalidates the cache from the edit point on |
- Tell
/compactwhat matters:/compact keep the failing test names and the migration plan. - Constraints that must survive compaction belong in CLAUDE.md or a memory file, not only in chat.
Long conversations and memory
- Rolling summaries keep a long chat inside the window; refresh them at milestones, not every turn.
- The memory tool lets an agent write and read files that persist across sessions; your app stores them.
- Just-in-time retrieval (keep references, fetch content when needed) beats loading the whole corpus up front.
- Subagents isolate context: each explores in its own window and returns a condensed summary to the coordinator.
- Placement matters: put long documents first and the question last.
Escalation and error propagation
A subagent that fails should say so in a structured way (what failed, why, what it tried, partial results) instead of returning an empty or invented answer. The coordinator then decides whether to retry, route around the failure or escalate to a human. Swallowed errors are the anti-pattern: they turn a visible failure into a silent wrong answer.
Rate limits and retries
| Status | Meaning | Retry? | How |
|---|---|---|---|
| 400 | Invalid request | No | Fix the request |
| 401 / 403 | Auth or permission | No | Fix credentials or access |
| 429 | Your rate limit | Yes | Wait for retry-after, then retry |
| 500 | API error | Yes, briefly | Backoff with jitter |
| 529 | Overloaded (server-side) | Yes | Exponential backoff with jitter; consider a fallback model |
- The official SDKs retry 429 and 5xx with backoff by default; tune
max_retriesrather than wrapping another loop around them. - Retries must be idempotent. A retried tool call that sends an email or charges a card needs an idempotency key.
- A circuit breaker stops hammering a dependency that is clearly down and fails fast until it recovers.
Observability and graceful degradation
- Log
usageon every call (input, output, cache creation, cache read) to catch cost regressions and cache misses. - Fall back to a smaller model on sustained overload, and say so in the response or logs.
- Return partial results with a clear note instead of failing the whole job.
Symptom to technique
| Symptom | Use | Tempting wrong answer |
|---|---|---|
| High cost on a repeated long prefix | Prompt caching | A bigger context window |
| Cache hit rate dropped to zero | Move the timestamp out of the system prompt | Switch to the 1-hour TTL |
| Agent loses the thread in a long session | Compaction with instructions, or durable notes | Raise max_tokens |
| Burst of 529 errors | Backoff with jitter, then a fallback model | Retry immediately in a tight loop |
| Stale fact keeps resurfacing | Context editing or a fresh session with a summary | Repeat the correction louder |
| Tool outputs flood the window | Trim results, clear old tool results, use subagents | Load more context |
Exam traps
Output counts
Wrong: Only input fills the window
Right: Input and output share it
A full prompt leaves no room to answer.
Cached still counts
Wrong: Cached tokens are free space
Right: They are cheaper, not smaller
Caching changes price only.
1M is opt-in
Wrong: Every model has 1M by default
Right: 200K standard; 1M is opt-in on some models
Defaults are tested.
Timestamps break caches
Wrong: Put the current time at the top of the system prompt
Right: Put it after the last breakpoint
Any byte change before a breakpoint is a miss.
/compact is lossy
Wrong: Compaction keeps everything
Right: It summarizes; guide it and store what must survive
Details outside the summary are gone.
Do not retry a 400
Wrong: Retry every error
Right: Retry 429, 500 and 529; fix 4xx requests
A bad request fails the same way every time.
429 vs 529
Wrong: Both mean you are over your limit
Right: 429 is your limit, 529 is server overload
Different causes, different handling.
Below the cache minimum
Wrong: The API errors if a prefix is too short to cache
Right: It silently does not cache
Check cache_creation_input_tokens.
One-page cheat sheet
Save this sheet in Claude Prep for offline review before exam day.
Practice quiz: 10 Context Management & Reliability questions
Original, exam-style questions, one per task statement. Pick an answer to see the explanation. Finish all 10 for your score and your weakest topics. No signup.
- Q1Context window definitionfoundation
Which statement best describes what the context window represents for a Claude model?
Answer: A. The total amount of text the model can reference when generating a response, including the response it generates, functioning as its working memory
The docs define the context window as all the text a model can look back on and reference when generating a response, plus the new text it generates, acting as working memory. It is explicitly distinct from the training corpus. The Messages API is stateless and does not maintain a server-side conversation cache, and max_tokens caps output length rather than defining the window.
- Q2Context window contentsfoundation
When the Claude API processes a Messages request, which of the following counts toward the model's context window?
Answer: A. The system prompt, tool definitions, every message in the conversation (including tool results and documents), and the output Claude generates for the turn, including its extended thinking
Everything in the request counts toward the window: the system prompt, tool definitions, and all messages including tool results and documents, plus the output generated for the turn, including current-turn thinking. Output shares the same window as input, so max_tokens must fit in the remaining space. Cached tokens still occupy the window; prompt caching changes what you pay for those tokens, not whether they count.
- Q3Context window sizesfoundation
What is the context window size for Claude Opus 5.5 on the Claude API?
Answer: A. 1,000,000 tokens, the default with no beta header
Claude Opus 5.5, like Fable 5.1, Sonnet 5.5, and Claude 4.6+ Opus and Sonnet models, has a 1M-token context window, and 1M is the default: no beta header is required and long-context requests bill at standard pricing. 200K applies to other models such as Haiku 4.5, the context-1m beta header belonged to the older Sonnet 4/4.5 beta, and 500K is not an offered size.
- Q4Token counting endpointfoundation
Which API capability lets a developer measure how many tokens a prompt will consume before actually creating a message?
Answer: D. POST /v1/messages/count_tokens, which accepts the same request shape as message creation (model, system, tools, messages) and returns an input_tokens count
The token counting endpoint mirrors the Messages request structure, including system prompts, tools, images, and PDFs, and returns the total input token count. It is free to use, subject to its own requests-per-minute limits separate from the Messages API, and the count is an estimate that may differ slightly from actual usage. The other two endpoints and the dry_run parameter do not exist in the Claude API.
- Q5Diagnosing cache missesintermediate
Repeated requests with an identical-looking system prompt keep returning cache_read_input_tokens of 0. The prompt begins with a header line 'Current date and time: {now}'. What is the cause?
Answer: B. The interpolated timestamp changes the prefix bytes on every request, so nothing is reused
Caching is an exact-prefix match, and a live timestamp at the front of the system prompt makes the prefix differ every request, so each call writes a fresh entry and never reads one. The fix is to move volatile values like timestamps to the end of the messages, after the last breakpoint, or drop them.
- Q6/compact in Claude Codefoundation
During a long Claude Code session refactoring a large module, a developer runs /compact. What does this command do?
Answer: A. It summarizes the conversation history and replaces the older transcript with that summary, freeing context so the session can continue
/compact performs compaction: Claude Code summarizes the conversation and continues from the condensed summary, and you can even steer it with custom instructions such as /compact Focus on code samples and API usage. Wiping the whole history is what /clear does. Summarization is lossy by design, not lossless compression, and the model's context window size is a fixed model property that commands cannot shrink.
- Q7Context engineering principlefoundation
According to Anthropic's guidance on effective context engineering for agents, what is the guiding principle for deciding what belongs in an agent's context window?
Answer: B. Find the smallest possible set of high-signal tokens that maximizes the likelihood of the desired outcome
Anthropic's context engineering guidance states that context must be treated as a finite resource with diminishing marginal returns, and that good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of the desired outcome. Packing the window with everything available degrades recall rather than improving it. There is no documented rule that attention stops at 50 percent of capacity.
- Q8Just-in-time contextintermediate
To keep an agent's context lean, Anthropic's context-engineering guidance recommends what over front-loading all possibly relevant data?
Answer: C. Just-in-time retrieval: hold lightweight identifiers or references and fetch full content only when it is actually needed
Just-in-time loading keeps the working set small by fetching full content only on demand, which counters context rot. Preloading everything, maxing the window, or stuffing the system prompt all inflate the context and degrade recall.
- Q9Subagent summary returnadvanced
In a research system, a subagent reads and processes 50 sources. To protect the orchestrator's context, what should the subagent return?
Answer: D. A condensed summary of its findings, keeping the raw source text in its own isolated context so the orchestrator's window stays lean
Subagents isolate heavy exploration and hand back only condensed findings, so the orchestrator's context stays small. Returning full transcripts or copying context verbatim defeats the isolation, and a bare status code loses the work entirely.
- Q10429 vs 529intermediate
How should a client distinguish HTTP 429 from HTTP 529, and does handling differ?
Answer: D. 429 means your organization exceeded its own rate limit while 529 means the API is broadly overloaded; both are retryable, but 429 should honor retry-after and 529 uses backoff
429 is your own rate limit (honor retry-after); 529 is server-side overload (retry with backoff). Both are transient and retryable, so neither is a permanent client error, and the two codes are not swapped.
Answer all 10 to see your score
You will get a score and your weakest topics. No signup.
Official sources
Every table on this page was checked against these Anthropic pages in October 2026. When a number here and the docs disagree, trust the docs.