Right-Sizing
Assigning each pipeline stage the smallest model that meets its measured quality target, rather than one model for the whole application. Benchmark evidence on representative data decides each move, to a larger model or to a smaller one.
Exam context: Choosing the biggest model "to be safe" and moving to a smaller model to cut cost without re-running evals are the two opposite wrong answers that questions include. A move to a larger or a smaller model needs eval evidence.
See also: 2.1 Selecting Claude Models
Escalation Cascade
A routing design that sends each request to a small model first and escalates to a larger tier on low confidence, failed validation, or explicit triggers. Because most requests never escalate, it gives near-big-model quality at near-small-model average cost. The name is this guide's shorthand; Anthropic's agent guidance documents the underlying pattern as routing (smaller models for easy requests, larger models for hard ones). Anthropic's cost guidance says to tune the single model across effort levels first and add the second model only if the pair gets a better score relative to its cost than the single model.
Exam context: A right answer that recurs in questions about cost versus quality, because it handles both cost and quality instead of losing one of them. An expected escalation rate above roughly a third signals the small model does not meet the quality target at all.
See also: 2.1 Selecting Claude Models
Effort Parameter
A control on current models, including Haiku 5.5, that lets you choose between more intelligence and lower latency and cost within a single model. Anthropic's model-choice guidance notes that tuning effort is often a better lever than switching models.
Exam context: The setting to check before choosing a different tier. The wrong options go directly to a model swap when an in-model adjustment would meet the constraint.
See also: 2.1 Selecting Claude Models
Model Lifecycle
The published progression of Claude models through active, legacy, deprecated, and retired states, with at least 60 days' notice before retirement of publicly released models. Every model ID is a pinned snapshot; requests to retired models fail.
Exam context: The right process is to pin the snapshot, monitor deprecation notices, and run a migration that proceeds only after the evals pass. Letting an alias or provider default silently move the production model is the failure that questions include as a wrong answer.
See also: 2.1 Selecting Claude Models
System Prompt Contract
The design stance that a system prompt carries everything true for every request — role, audience, standing policy, output contract (the format the output must follow) — while per-request data is placed in user turns. The split matters for two reasons: standing policy keeps the same authority on every request, and a stable prefix is what caching can reuse.
Exam context: Policy restated differently in each user turn varies from developer to developer, behaves less consistently, and is billed at the full input price on every request. Moving it into the system prompt fixes both at once.
See also: 2.2 System Prompts and Guardrails
Escape Hatch
An explicit, honest answer for missing information in the output contract: return null when the source lacks the field, or say the information is missing when the sources do not cover the question. Anthropic's guidance is that permission to admit uncertainty can drastically reduce false information.
Exam context: The first control to use against hallucination. A schema that demands a value for every field forces the model to break the schema or invent — the fix is the option to return null, not a larger model or lower temperature.
See also: 2.2 System Prompts and Guardrails
Prompt Template
A prompt with named variable slots and XML-tagged sections separating instructions, context, examples, and per-request input. Turning a prompt into a template makes it a testable, versionable engineering artefact: diffable, code-reviewed, evaluated before deploy, rolled back on regression.
Exam context: One reviewed template that serves a workflow is better than ten copies made by hand that slowly become different. Tags also mark untrusted content as data rather than instructions. Current state (checked 6 October 2026): for third-party content the prompt-injection docs now say to deliver it in tool_result blocks, never the system prompt or plain user text.
See also: 2.2 System Prompts and Guardrails
Layered Guardrails
Defence built in three layers around the model: instruction-level (scope, refusal rules, a way to say that information is missing), input-side (validation, sanitisation, delimiting untrusted content), and output-side (schema and business-rule checks before later steps use the output). The prompt is one layer, never the whole defence.
Exam context: Instructions shape behaviour probabilistically; only programmatic validation guarantees it. When a question shows a system-prompt-only defence, the missing piece is code-level validation — and every refusal needs a fallback route.
See also: 2.2 System Prompts and Guardrails
Technique Ladder
The cost-ordered escalation of single-call techniques: clear zero-shot instructions first, few-shot examples second, chain-of-thought last. Each step adds recurring tokens, so the cheapest technique that fixes the observed failure is the right choice.
Exam context: Questions pair a failure symptom with four plausible fixes; the tested skill is diagnosis. Examples for a reasoning failure, or reasoning for a format failure, spend tokens on the wrong problem.
See also: 2.3 Prompt Engineering Techniques
Few-Shot Prompting
Steering output with 3–5 worked examples wrapped in example tags. An effective set is relevant (matches the real use case), diverse (covers edge cases and near-misses), and structured (distinguishable from instructions).
Exam context: The canonical fix for format-compliance failures and classification boundaries. Five restatements of the happy path (the normal case with no problems) teach an unintended pattern; the quality of the set depends on its hardest example.
See also: 2.3 Prompt Engineering Techniques
Chain-of-Thought (CoT)
Instructing the model to reason step by step before answering, with tags separating the reasoning from the final answer so downstream parsing still works. Improves accuracy on multi-step reasoning, but costs latency and output tokens.
Exam context: Reserved for failures that are genuinely about reasoning; on a high-volume trivial endpoint it is over-engineering. Visible reasoning is also an audit tool — it exposes faulty logic for review.
Current state (checked 14 November 2026): the prompting docs now say to rely on thinking on Claude Fable 5.2, Fable 5.1, Fable 5, Opus 5.5, Opus 5 and Sonnet 5.5, where a prompt asking for written-out reasoning (for example in <thinking> tags) may be declined. On the exam, prompted CoT is still the answer.
See also: 2.3 Prompt Engineering Techniques
Built-In Thinking
The reasoning capability inside current Claude models. On 4.6-generation and later models, adaptive thinking decides when and how much to think. The older Haiku 4.5 uses configured extended thinking. Thinking tokens bill as output and count towards max_tokens and the context window.
Exam context: Not a rival to prompted CoT. The architect's question is where reasoning happens and whether it must be auditable in the response body. Prompted CoT keeps it there. But as of 14 November 2026, the docs say to rely on thinking instead on Claude Fable 5.2, Fable 5.1, Fable 5, Opus 5.5, Opus 5 and Sonnet 5.5.
See also: 2.3 Prompt Engineering Techniques
Context Rot
The documented degradation of accuracy and recall as token count grows, which makes curating what is in context as important as how much space is available. The goal is the smallest set of high-signal tokens (tokens that carry information the task needs) that maximises the likelihood of the desired outcome.
Exam context: The reason "move to the bigger window and load more" is a wrong answer that questions include. A bigger window lets the content fit, but it increases context rot, cost, and latency.
See also: 2.4 Context Window Optimisation
Replay Bill
The cost consequence of context accumulation: every token is billed on every request it appears in, so a 50k-token history sent again on each of twenty turns is a million billed input tokens. At high request volume, context that is not managed with care becomes the largest cost, ahead of model choice.
Exam context: What makes context strategy an economics decision rather than a minor maintenance task. Curation, caching, and compaction each reduce a different part of the cost.
See also: 2.4 Context Window Optimisation
Compaction
Server-side summarisation of earlier conversation turns into a compaction block. It lets the conversation continue past the window limit. It is in beta, for 4.6-generation and later models. Anthropic's recommended primary strategy for long-running conversations and agentic sessions. There are two kinds (checked 29 October 2026). On-demand compaction runs when your application asks for the summary. Threshold compaction starts once input tokens reach a trigger threshold. Anthropic says to use on-demand compaction wherever it is available.
Exam context: The right answer for questions about long sessions where cost and late-conversation quality degrade together. It reduces context and keeps the working state. A fresh conversation destroys the working state.
See also: 2.4 Context Window Optimisation
Context Editing
A server-side mechanism (beta) that clears the oldest tool results once a threshold is reached. Optionally, it also clears thinking blocks. It replaces what it clears with placeholders. Reclaims window space occupied by stale content that adds cost and rot without adding information.
Exam context: The setting to use when tool results are the largest part of the cost of resending the history on every request. Used with compaction in questions about agentic sessions.
See also: 2.4 Context Window Optimisation
Prefix Invalidation
The cache mechanic that prefixes build in the order tools → system → messages, and a change at any level invalidates that level and everything after it. The design rule that follows is to put stable content at the start: static content first, dynamic content last.
Exam context: A timestamp or request ID early in the prompt silently stops the entire cache from working. In questions about a near-zero hit rate, the right answer is reordering content, not reconfiguring the cache.
See also: 2.5 Prompt Reuse Strategies
Cache Break-Even
The arithmetic that decides whether caching saves money. Writes cost 1.25× base input with a 5-minute TTL, or 2× with a 1-hour TTL. Reads cost 0.1× on most models, 0.05× on Opus 5.5 and Sonnet 5.5, and 0.025× on Fable 5.2, Mythos 5.2, Fable 5.1 and Mythos 5.1 (checked 13 November 2026). So caching costs less than no caching after one read on the 5-minute duration, and after two reads on the 1-hour duration. TTLs refresh free on use.
Exam context: At high request volume, the read discount is the largest effect, and caching cuts both cost and time-to-first-token. On sporadic traffic outside the TTL, the write premium can exceed the savings. "Cache everything" is not universally correct.
See also: 2.5 Prompt Reuse Strategies
Modular Prompts
Composing prompts from sections that are versioned and have an owner (role, policy, task instructions, format contract, examples). Each feature assembles its prompt from a shared library of these sections. One reviewed change to a shared section reaches every prompt that uses it. Ten copies made by hand slowly become different, and the same fix is made nine times.
Exam context: Also cache design: shared stable sections form common prefixes across features, and section ordering decides how much of the prefix caches. A module nobody owns slowly becomes different, like a copy made by hand.
See also: 2.5 Prompt Reuse Strategies
Agent Skill
A folder with a SKILL.md file. The file has YAML frontmatter with a name (max 64 characters) and a description (max 1,024 characters). The description also acts as the trigger. The file also has an instruction body. Optionally, the folder also holds bundled files and scripts. Loads deep expertise on demand instead of paying for it on every request.
Exam context: The placement rule that questions test: standing policy belongs in the cached system prompt, on-demand expertise in Skills, per-request data in messages. Custom Skills do not sync across surfaces (the API, claude.ai and Claude Code).
See also: 2.5 Prompt Reuse Strategies
Progressive Disclosure
How Skills use tokens, in three levels: metadata only (~100 tokens per Skill) loads at startup, the SKILL.md body (under 5k tokens) loads only when triggered, and bundled resources cost nothing until read. Scripts execute with only their output entering context.
Exam context: The contrast is the monolithic system prompt that pays for every capability's instructions on every request whether used or not — the common wrong option that puts too much into the prompt.
See also: 2.5 Prompt Reuse Strategies