Claude models, prompting and context engineering

The domain opens with the decision every project gets wrong in the same direction: paying for capability the task never uses. At the professional tier, model selection, prompt design and context management are one subject — a prompt that stuffs the window forces a bigger, costlier context strategy; a well-budgeted one makes the cheap model viable. The exam will hand you workloads and ask which model, which technique, which reuse strategy — and the wrong answers will all sound diligent.

01Model selection as a trade-off decision

The Claude model family runs in three tiers, and the trade the exam wants you to articulate is capability against cost and latency. The frontiers — the Opus class — carry the hardest reasoning, agentic long-horizon work and the highest price and latency. The mid-tier — the Sonnet class — is the balanced default: near-frontier quality on most workloads at a fraction of the cost. The small tier — the Haiku class — is fast and cheap, right for classification, extraction, routing, and high-volume tasks where “good enough, immediately” beats “excellent, eventually”. Two selection facts earn marks. Fit beats prestige: the smallest model that clears your evaluation threshold is the correct model, and saying so is a mark-earning answer. And the router pattern is the professional move — Haiku-class on the easy majority, escalation to a larger model on the hard minority (Domain 1’s difficulty cut, implemented at the model layer).

02System prompts, templates and guardrails

A system prompt is a job description, and the exam tests whether you can tell a finished one from a draft. The structure that holds: role (who the model is being, with what expertise and scope), task (what success looks like, in criteria a grader could check), constraints (what it must never do, say, or assume), and the shape of the output (format, schema, tone, language). XML-style tags delimit the parts; the stable material sits at the top where caching can see it (more below); volatile material arrives in user turns.

Templates turn prompts from artisanal objects into a managed asset: a parameterised system prompt with named slots for the task-specific material, version-controlled, tested like code — because it is code. The test the exam keeps returning to: could a competent temp produce the intended output from this brief alone, without asking you anything? If not, the brief is unfinished, and no model quality will finish it. Conflicting instructions inside a template — two formats for the same job, a constraint that fights an example — are a named failure mode: they produce unstable output worse than no instruction.

Guardrails, at this tier, are understood as a stack — and the prompt is the softest layer in it. Prompt-level constraints steer behaviour; they do not enforce it. The guarantees live outside the model: schema validation on output (reject and retry or reject and escalate), tool permissions that make forbidden actions impossible rather than discouraged (Domain 3), output filters for sensitive content, and human review where the stakes demand it (Domain 5). The exam’s trap: a scenario whose only safety layer is a paragraph asking the model to be safe. Defense in depth is the answer, and the prompt is one layer, not the wall.

03Techniques: zero-shot, few-shot, chain-of-thought

The three named techniques are an escalation, and each rung has a price. Zero-shot — instructions only — is the correct starting point: cheapest, easiest to maintain, and modern models are startlingly good at following a clear brief. Few-shot — worked examples in the prompt — pays when the specification is easier to show than to tell: exact output format, edge-case handling, house style. Its costs are real: examples are tokens on every request (a caching decision — below), conflicting examples poison the well, and weak examples teach the wrong lesson harder than no examples. Chain-of-thought — letting the model reason before answering, in its visible thinking or via extended thinking budgets — pays on multi-step reasoning, mathematics, and tasks where the answer should follow from stated steps; it is wasted latency on classification and extraction, where it buys nothing a schema cannot.

04The context window as a budget

Foundations taught what the window is; Professional asks you to allocate it. A well-budgeted window has four accounts: the stable scaffolding (system prompt, tool definitions, standing policy — cache it), the task material (retrieved documents, the user’s input — the reason the call exists), working space (tool results and reasoning that accumulate mid-task), and output room (the answer plus its headroom). The failure the exam tests is window starvation in either direction: material crowded out by scaffolding, or a window filled with everything “just in case” — tokens paid for on every request, slowing every response, for retrieval nobody asked the model to use.

Management levers, in the order a professional applies them. Do not send it: the cheapest token is the one never placed in context — retrieve narrowly (Domain 3), prune boilerplate, summarise stale history. Cache it: stable prefixes behind cache breakpoints (below). Compress it: when conversations or files overflow, context editing and summarisation keep the operative material and retire the rest. Choose the right vessel: small stable corpora can simply live in the window; large or volatile ones belong to retrieval, not to the prompt. And measure it: the usage object on every response — input, output, cache reads and writes — is the ground truth that turns “the context feels bloated” into a number you can defend.

05Reuse: caching, modular prompts, Skills

The economics the exam quotes. Prompt caching reuses a stable prefix across requests: mark the prefix with cache breakpoints, and after the first write, repeated runs read that prefix at about a tenth of the base input cost instead of paying full price every request. The default cache lifetime is five minutes from last use; a one-hour TTL option covers material consulted less often, at a premium on the write. The design rules follow from the mechanism: order stable-before-volatile (a timestamp or per-request variable at the top of the prompt defeats the cache by changing byte one), keep the cacheable prefix byte-identical across requests of the same shape, and remember that caching composes with the Batch API’s half price for asynchronous workloads — a cached batch is the cheapest square inch in the platform.

Modular prompts are the maintainability half of reuse: compose system prompts from named, tested parts — a role module, a policy module, a format module — so a policy change is one edit, not forty pasted copies drifting apart. The failure mode has a name worth remembering: prompt drift, the moment when the copies disagree and behaviour differs by route for no reason anyone can find.

Skills are the newest instrument in this domain and the exam guide names them: packaged capability directories whose metadata (name, description) is always loaded while the body — instructions, scripts, reference files — is read on demand. That is progressive disclosure: a library of procedures costs almost nothing until invoked, then expands the context with exactly the material the task needs. At design level, Skills are the answer to “how do we let the model do fifty specialised procedures without paying for all fifty on every request”. The same principle, applied to everything, is Domain 3’s progressive-discovery-versus-monolithic-context question — the pattern to know cold.

06The traps

• —“Frontier model by default.” Selection without an evaluation is the domain’s most common wrong answer; the correct default is the cheapest tier that clears the bar, with escalation for the hard tail.
• —“More examples, more quality.” Three well-chosen boundary-teaching examples beat twenty variations of the easy case — and cost a fraction of the tokens.
• —“Temperature will fix it.” Sampling knobs are not repair tools: format problems want a schema, accuracy problems want better context or a bigger model, consistency problems want caching and deterministic settings.
• —“Cache-friendly by accident.” A timestamped greeting at the top of the system prompt quietly re-prices the whole application; cache-busting prefixes are a named exam scenario.
• —“The prompt is the guardrail.” Instructions steer; validation, permissions and review enforce. A safe-sounding paragraph is the softest layer of a stack the exam expects you to build.