Prompt and context engineering
Three subdomains, 11% of the marks, split cleanly in half: managing what fills the context window, and getting reliable shapes out of the model. Context engineering on one side — prompt engineering on the other.
Anthropic’s framing, which the exam has absorbed whole: prompt engineering grew up into context engineering. The unit of design is no longer the instruction — it is everything the model sees in a request: system prompt, tool definitions, retrieved documents, images, the whole conversation history, and the response itself, which becomes input for the next turn.
How to read this page, because it tells you what to memorise: the domain number and the 11% weight come straight from the official exam guide, and the examinable ideas are collected in the box at the end of each section. The model-specific facts were checked against the official documentation in September 2026 — the ones likely to change between exam editions are stamped "current as of September 2026", and those are the only ones worth re-verifying the week you sit it.
The budget for one request: system prompt, every message including tool results, tool definitions, images and documents, and the output including thinking tokens. A budget to spend, not a bucket to fill.
Quality degradation as the window fills. Attention spreads across more tokens — the number of pairwise relationships grows with the square of the length — and accuracy and recall slip long before any limit is hit.
A discount on an unchanged request prefix. Cache-read tokens cost less to pay for, but they still count against the window.
Clearing stale content after it has arrived in the window. Compaction and context editing.
Designing so stale content never arrives. Subagents, tool search, programmatic tool calling.
Restricting the model’s sampling so every possible output matches a schema you supplied. The mechanism that makes JSON outputs and strict tool use guarantees rather than requests.
01The window is a budget, not a bucket
Everything in the request counts toward the window: the system prompt, every message including tool results, tool definitions, images and documents (up to 600 image or PDF pages per request on the 1M-token models, 100 on the 200K ones — request size limits can bite before token limits do), the output including any thinking tokens — and, the fact people refuse to believe, cached prefixes.
Caching changes what you pay, not what counts: 2,000 fresh tokens plus 180,000 cache-read tokens on a 200K model leaves you nearly full.
Why not fill it? Context rot: as token count grows, attention spreads thinner (the number of pairwise relationships grows with the square of the length), and accuracy and recall gradually degrade.
The failure mode in the wild is quieter than a limit error: an agent that has read forty files and started answering vaguely with the window half-empty — stale tool results and finished reasoning competing for attention long before any limit is hit. Treat context as a budget to spend deliberately on what the next turn actually needs.
02Managing a long context
The toolkit has a named split the exam leans on: pruning clears stale content after it has arrived; isolation stops it arriving at all. Every tool in one comparison — with the detail the exam checks on each:
| Strategy | Pruning or isolation | What it does | The detail the exam checks |
|---|---|---|---|
| Server-side compaction | Pruning | The server replaces older turns with a summary; the conversation continues past what would have been the limit | The primary strategy for long agent sessions. A compact_boundary system message marks where it happened. Beta, and only on Claude 4.6-and-later models, Mythos Preview included — current as of September 2026 |
| Context editing | Pruning | The server clears old tool results and old thinking blocks before the prompt reaches the model | Configurable triggers, keep-recent windows, per-tool exclusions, and a clear_at_least floor — each clearing invalidates the prompt cache, so every clearing should be worth that cost. Your client keeps the full unedited history; there is nothing to sync |
| Context awareness | Neither — it is pacing | The model is told how much space it has left | Sonnet 5, Sonnet 4.6, Sonnet 4.5 and Haiku 4.5 automatically receive injected token-budget tags and per-tool-call usage updates; Opus 4.7-and-later, Fable and the Mythos 5-series do not — set explicit task budgets (beta) there instead. You never write the tags, and knowing the remaining budget creates no extra space — current as of September 2026 |
| Delegation — subagents | Isolation | A subagent runs in its own window and returns only its final message | The parent’s window never sees the subagent’s tool results or reasoning |
| Tool search | Isolation | Tool definitions stay out of the window until requested | The pattern for twenty-plus-tool sets |
| Programmatic tool calling | Isolation | Claude chains many small tools inside one script in the code-execution sandbox | Intermediate results never enter the conversation at all |
| The memory tool | Neither — it is durability | Durable notes stored as files under /memories, written and read on demand across sessions | Client-side: Claude requests the file operations, your application executes them |
When a scenario hands you a symptom and asks for the strategy, run the simplest decision framework: the session is long and must continue as one conversation — compaction. Old tool results and thinking are the bloat — context editing. The work generates noise the parent conversation never needs — delegation or programmatic tool calling. The knowledge must outlive the session — the memory tool.
03Thinking blocks: what stays, what goes back
Whether old thinking blocks stay in the window is model-dependent — current as of September 2026. Opus 4.5-and-later and Sonnet 4.6-and-later keep them by default, where they count as ordinary input on every later request. Earlier Opus and Sonnet models, and every Haiku, strip them automatically when they come back.
One mechanical rule from the tool-use cycle applies either way, on every model: when you return a tool result, you must pass the model’s thinking block back unmodified, signature included — altering it is an API error.
And in Claude Code, the PreCompact hook is the right place to archive a full, unsummarised transcript before compaction throws detail away — a practical detail for real deployments rather than an examinable API rule.
04Prompts that hold
The mental model that organises every technique here: you are briefing a capable new colleague. Claude is strong and knows nothing about your norms, your audience, or your definition of done. The test — could a competent human with minimal context execute this brief? If not, the prompt is the problem.
From that flow the practices the exam tests. Be explicit about scope when you want ambition: "build a dashboard" gets a dashboard; asking for every relevant feature and interaction gets that instead. And explain the reasons behind rules rather than shouting them in capitals — "this text is read aloud by a TTS engine, so no ellipses" generalises; "NEVER use ellipses" does not.
Give examples — three to five of them, chosen the way you would choose a test suite: relevant to the real use case, diverse enough to cover edge cases (a set of near-identical examples teaches an unintended pattern, like every answer being short and polite), and structurally separated from the instructions with example tags.
The exam counts examples in shots — zero-shot is instructions only, single-shot adds one worked example, and few-shot (also called multishot) supplies several. Worked examples remain among the most dependable levers over output format, tone and structure.
Structure long prompts with XML tags — instructions, context, documents, inputs in separate labelled sections, and when several documents ride along, nest them with index attributes so the model can keep sources straight. Put the stable role in the system parameter (even one sentence of role focusses tone) and the volatile ask in the user turn. And define the output contract explicitly: JSON with named keys and enumerated values, or a template that fixes each field’s shape and length.
One model-specific rule that appears as a fact question — current as of September 2026: on Claude Sonnet 5, setting temperature, top_p or top_k to non-default values is rejected with a 400 error. Control tone and variety through the system prompt instead.
05Structured outputs and strict tool use
The old way to get JSON was to ask nicely and write a defensive parser. The current way is constrained decoding: supply a JSON Schema and the model’s sampling is limited to outputs that match it — structurally valid every time, no retries for malformed syntax. Two independent features deliver this, and you can use either or both:
- —JSON outputs — set output_config.format to your schema and the JSON arrives in the response’s text content block. The SDKs make this pleasant: pass a Pydantic model or Zod schema to the parse helpers and receive a typed, validated object back.
- —Strict tool use — set strict: true on a tool definition and the model’s tool calls are guaranteed to carry a valid tool name and arguments matching your input_schema.
Two fine prints worth real study time. First: the API supports only a subset of JSON Schema. The SDK helpers handle the gap by removing constraints like minimum, maximum and length bounds, restating them in field descriptions, and adding additionalProperties: false — then validating the response against your original schema in your code. The constraint is enforced, just not by the decoding.
Second: strict mode has edges. The computer-use and browser-use toolsets reject it outright, and its schemas compile into cached grammars — so PHI stays out of schema identifiers, enum values and patterns, in messages only.
The rule of thumb for scenario questions: machine-readable final answer, use JSON outputs; correctly typed function arguments, use strict tool use; both at once is legal.
06One page to revise from
Five sections of prose sit above this line. Here is the same domain compressed: the two structured-output features side by side, and the five lines to walk in with below. The long-context toolkit table in section 02 is the other half of your night-before reread — if you reread two things, reread that table and this one.
| Question | JSON outputs | Strict tool use |
|---|---|---|
| What you set | output_config.format = your schema | strict: true on the tool definition |
| What is guaranteed | Schema-valid JSON in the response’s text content block | Every tool call carries a valid tool name and arguments matching input_schema |
| Reach for it when | The final answer must be machine-readable | Function arguments must be correctly typed |
| SDK support | Pydantic or Zod schema through the parse helpers; a typed, validated object back | Schemas compile into cached grammars — PHI stays out of identifiers, enum values and patterns |
| The edge to know | Only a subset of JSON Schema is enforced by decoding; bounds come back as field descriptions and your code validates | The computer-use and browser-use toolsets reject it outright |
One line to draw through the domain, the same line as every page in this series: the ideas are stable, the product details are not. The budget-not-bucket framing, pruning versus isolation, reasons over capitals, the shots vocabulary, constrained decoding — those will outlive any product change. The model rosters here — which models keep thinking blocks, which receive context-awareness tags, the Sonnet 5 sampler restriction, compaction’s model floor — were checked against the official documentation in September 2026 and can change between exam editions. Anything stamped "current as of" falls in that second group; re-check it against the live docs the week you sit the exam.
07The traps in this domain
- —"Caching frees window space" — cached tokens still count; caching changes cost, not capacity.
- —"A million-token window means fill it" — context rot degrades accuracy as content grows.
- —"The model knows its remaining budget, so it will free up space" — context awareness lets the model pace against the space left; it creates no extra space.
- —"Context editing will desynchronise my client history" — the client keeps the full unedited history; there is nothing to sync.
- —"A subagent shares the parent’s window" — isolation is the point: it runs in its own window and returns only its final message.
- —"Strip the thinking block before returning the tool result" — pass it back unmodified, signature included; altering it is an API error.
- —"Restate the rule louder" — explain the reason instead; the model generalises from reasons.
- —"Near-identical examples are best practice" — diversity and edge cases are what teach.
- —"Constrained decoding enforces my Pydantic bounds" — the SDK strips them, documents them, and your code validates.
- —"strict: true works on any tool" — the computer and browser toolsets refuse it.
08Check yourself
Four scenario questions, in roughly the exam’s register. Each one expands to show the answer and — more usefully — why the wrong options are wrong.
A request to a 200K-window model carries 2,000 fresh tokens and 180,000 cache-read tokens, plus tool definitions and a PDF. A teammate says: "Relax — most of those tokens are cache reads, so the window is nearly empty." What is the correct position?
- ACache-read tokens still count against the window; caching changes cost, not capacity
- BThe teammate is right — cache-read tokens do not count against the context window
- CCache-read tokens count at half weight, so only about 90,000 are used
- DThe context window only limits output tokens, so input size is irrelevant
→Check your answer
The fact people refuse to believe: cached prefixes count toward the window exactly like fresh tokens. Caching changes what you pay, not what counts — 2,000 fresh plus 180,000 cached on a 200K model leaves you nearly full. That makes every "free the window with caching" answer wrong.
An agent session has run for hours and the conversation is about to outgrow the window; the session itself must continue as one conversation. Which strategy does the documentation name as the primary one here?
- AContext editing — clear the old tool results and the session shrinks
- BThe memory tool — persist the history to /memories and reload what is needed
- CServer-side compaction — the server replaces older turns with a summary and the conversation continues
- DDelegation — hand the rest of the work to a subagent with a fresh window
→Check your answer
Compaction is the primary strategy for long agent sessions: older turns become a summary, a compact_boundary system message marks where it happened, and the same conversation continues past what would have been the limit. Context editing clears old tool results and thinking, not the whole conversation. The memory tool is for knowledge that must outlive sessions, not for rescuing one. Delegation is isolation — right when a fresh window suits the work, wrong when the session itself must continue.
Your TTS pipeline keeps finding ellipses in copy Claude prepares, despite a system prompt reading "NEVER use ellipses." What is the documented fix?
- AMove the rule into the user turn and repeat it before every generation
- BWrite the rule in capital letters at the very start of the system prompt
- CExplain the reason: this text is read aloud by a TTS engine, so ellipses break the output
- DAdd ten near-identical examples of text containing ellipses, each labelled "wrong"
→Check your answer
Reasons generalise; capitals do not. A model told why — the text is read aloud by a TTS engine — can apply the rule to cases you never listed. Relocating or re-capitalising the rule just re-shouts it, and a set of near-identical negative examples teaches an unintended pattern rather than the boundary you want.
You need the final answer of a tool-free request as machine-readable JSON with named keys — validated in your code against the original Pydantic schema, including its minimum and maximum bounds. What is the correct build?
- AAsk for JSON in the prompt and parse the response defensively
- BJSON outputs via output_config.format; the SDK restates the bounds as field descriptions and your code validates against the original schema
- Cstrict: true on a tool definition whose input_schema carries the bounds
- DJSON outputs alone — constrained decoding enforces every Pydantic bound at sampling time
→Check your answer
A machine-readable final answer with no tools involved points to JSON outputs. But the API supports only a subset of JSON Schema: the SDK helpers remove bounds like minimum and maximum, restate them in field descriptions, add additionalProperties: false — and your code validates against the original schema. Option D is the planted trap: the constraint ends up enforced, just not by the decoding. And strict tool use answers a different question — typed function arguments, not final answers.