Quick Reference: Domain 2 — Claude Models, Prompting & Context Engineering

Selection is choosing the model that meets the constraints, not the most prestigious one. Five axes: capability (a measured quality target), latency (adds up across chains and loops), cost (price × tokens × volume), context/output limits, lifecycle and platform availability. Constraints remove candidates before preference is considered.

• Two documented starting points: efficiency-first (start Haiku-class, upgrade on a measured gap) or capability-first (start Opus-class, then lower effort or try smaller models). Either way, benchmark evals on representative data decide each move.
• Right-size per pipeline stage, not per application. The smallest model that meets each stage's measured quality target.
• Effort parameter (current models) lets you choose between more intelligence and lower latency and cost within one model, often a better choice than switching tiers.
• Escalation cascade (our shorthand; Anthropic documents the pattern as routing): default to the small model, escalate on low confidence or failed validation. Near-big-model quality at near-small-model average cost. It is the right answer in cost-vs-quality questions. Anthropic's cost guidance: tune the single model across effort levels first, and add a second model only if the pair scores better relative to its cost than the single model.
• Lifecycle: every model ID is a pinned snapshot; models move active → legacy → deprecated → retired, with at least 60 days' notice. Pin versions, monitor notices, re-run evals before migrating. A model change is an architecture change.
• Snapshot checked 13 November 2026 (re-verify before relying on it): Fable 5.2 $8/$40, Opus 5.5 $4/$20, Sonnet 5.5 $2/$10, Haiku 5.5 $0.10/$0.50 per MTok (million tokens) in/out (Haiku 5.5 rises to $0.50/$2.50 for prompts over 100,000 tokens); 1M-token windows and 128k max output on all four. Older models, including Fable 5.1, Opus 5, Sonnet 5 and Haiku 4.5, are still listed, and the docs advise defaulting to the latest models where possible.

The system prompt is a contract: role, audience, standing policy, output contract (the format the output must follow). Per-request data belongs in user turns. The split matters for two reasons: stable behavioural authority and a prefix that caching can reuse.

• Altitude rule: the level of detail in a system prompt, between hardcoded brittle logic and vague guidance — specific enough to steer behaviour, flexible enough to give the model strong heuristics.
• Golden rule: if a colleague with minimal context would be confused, so will Claude. Give the motivation behind unusual rules.
• Escape hatch: an explicit option to return null plus permission to admit uncertainty. An output contract without one forces the model to invent. The escape hatch is the first control against hallucination.
• Templates: XML-tagged sections (instructions, context, examples, per-request input) with named variable slots — diffable, reviewable, evaluated before deploy, rolled back on regression. One reviewed template is better than ten copies made by hand that slowly become different.
• Guardrails in three layers: instruction-level (scope, refusal rules, a way to say that information is missing) → input-side (validate, sanitise, delimit untrusted content as data) → output-side (schema plus business-rule checks before any later step uses the answer). Instructions shape behaviour probabilistically; only code guarantees it.
• Every refusal needs a route. A block with no fallback turns a safety control into an outage.

The techniques are ordered by cost: clear zero-shot instructions → few-shot examples (3–5) → chain-of-thought. The exam rewards the cheapest technique that fixes the observed failure, so diagnose first.

• Few-shot sets must be relevant, diverse, structured (wrapped in example tags). Sets that only show the happy path (the normal case with no problems) teach the wrong pattern.
• CoT: separate reasoning from the answer with tags, or downstream parsing breaks. Wrong for latency-critical trivial tasks.
• Built-in thinking (mid-2026): adaptive on 4.6-generation and later models; thinking tokens bill as output and count toward max_tokens. Prompted CoT stays right where reasoning must be auditable in the response body.
• 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.
• Reasoning inside one call is 2.3. Decomposing into chained calls is Domain 1 architecture.

Everything occupies the window: system prompt, history, tool definitions, tool results, images, and the output being generated — thinking tokens included. Every token is billed on every request it appears in: the replay bill, the cost of resending context.

• Instruments: the usage field on every response (input_tokens, cache_read_input_tokens, and cache_creation_input_tokens all count toward the window); the free token counting API for estimates before you send a request.
• Overflow: input too large → 400 "prompt is too long"; generation hitting the limit → stop_reason model_context_window_exceeded.
• Context rot: accuracy and recall degrade as token count grows. Target the smallest set of high-signal tokens. A bigger window is not a strategy for managing context.
• Toolkit, in order: curate (send the fields, not the file; longform documents above the query) → retrieve instead of putting everything into the prompt → server-side compaction (the recommended primary strategy for long sessions) → context editing (clears stale tool results) → tight output contracts and short tool definitions.
• Two kinds of compaction (checked 29 October 2026): on-demand compaction runs when your application asks for the summary. Threshold compaction runs when input tokens reach a threshold that you set. Anthropic says to use on-demand compaction wherever it is available.
• Truncation ≠ curation. Cutting to a fixed count discards by position; curation selects by how useful the content is.
• Caching never frees window space — cached prefixes still occupy the window. "Enable caching" as the fix for overflow or rot is a wrong answer that questions include.

Three mechanisms, three problems: caching (the same prefix resent at full price), modular prompts (drifting hand-copies of shared text), Skills (occasional deep expertise without a cost on every request).

• Cache prefix order: tools → system → messages. A change at any level invalidates that level and everything after it — put stable content first. A timestamp early in the prompt stops the whole cache from working.
• Mechanics (checked 14 November 2026): up to 4 explicit breakpoints (or automatic caching via a top-level cache_control field); 5-minute TTL default, 1-hour option, refreshed free on use; minimum cacheable length 512 tokens (Fable 5.2, Mythos 5.2, Fable 5.1, Mythos 5.1, Opus 5.5, Sonnet 5.5, Haiku 5.5, Opus 5, Fable 5, Mythos 5), 1,024 (Sonnet 5), 4,096 (Haiku 4.5). Prompts below the minimum run uncached without an error.
• Economics (checked 13 November 2026): writes cost 1.25× (5-min) or 2× (1-hour). Reads cost 0.1× on most models. Opus 5.5 and Sonnet 5.5 read at 0.05×, and Fable 5.2, Mythos 5.2, Fable 5.1 and Mythos 5.1 read at 0.025×. So reads are at least 90% off. Break-even after one read (5-min) or two (1-hour). At high request volume, caching cuts both cost and time-to-first-token; on sporadic traffic outside the TTL, the write premium can exceed the savings.
• Caching is not persistence, a way to free window space, or a way to improve quality.
• Skills: a folder with SKILL.md — name (max 64 chars) plus a description that also acts as the trigger (max 1,024). Progressive disclosure: ~100-token metadata always loaded; the body (under 5k tokens) loads on trigger; bundled resources cost nothing until read. Custom Skills do not sync across surfaces (API, claude.ai, Claude Code).
• Placement rule: standing policy → cached system prompt; on-demand expertise → Skills; per-request data → messages.