Claude Models, Prompting & Context Engineering

1. Model Selection Is a Trade-Off Table, Not a Preference

An architect does not have a favorite model. They have a routing policy: a mapping from task shape to the cheapest model that clears the quality bar for that task. The exam tests whether you can read that mapping off a table of real specifications rather than reaching for the biggest name.

Read the table before you read the question. Three facts jump out and each is an exam item:

• Haiku's context is the odd one out. Every other model here carries a 1M window; Haiku 4.5 caps at 200K. If a scenario feeds a stage 400K tokens of retrieved context and offers Haiku as the "cost-optimized" answer, Haiku is disqualified by the context limit, not merely a weaker choice. The request would fail.
• Output is five times the input price on every model. A model that "thinks out loud" or emits a verbose rationale costs far more per token on the way out than in. Output-token discipline is a cost lever, not a style preference.
• Fable 5 is the most expensive tier, above Opus. It is not the default upgrade. Reach for it only when a task genuinely needs the most capable widely released model; otherwise Opus 4.8 is the top of the routing ladder.

The routing discipline

Route on task fit, not on a blanket cost rule. Cheap, high-volume, well-specified work (classification, extraction, routing, short summaries) goes to Haiku. Hard synthesis, long-horizon reasoning, and anything where a wrong answer is expensive goes to Opus. The middle (production workloads that need near-Opus quality at lower cost) is Sonnet's territory.

2. Effort and Adaptive Thinking: The Architectural Dial

Beyond model choice, two request-level controls trade tokens and latency for answer quality. Together they are the finest-grained cost/quality dial you have, and the exam expects you to know they exist and default correctly.

• Adaptive thinking — thinking={"type": "adaptive"} lets Claude decide when and how deeply to reason. On the Opus tier, omitting the thinking parameter means the model runs with no thinking at all. If you want reasoning, you must ask for it explicitly.
• Effort — output_config={"effort": ...} sets how much the model deliberates and spends overall. The default is high. Lower effort means fewer tokens and lower latency at some cost to depth; raise it when correctness matters more than the bill.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=8000,
    # On Opus-tier, omitting this means NO thinking. Ask for it explicitly.
    thinking={"type": "adaptive"},
    # effort is NESTED inside output_config, not a top-level parameter.
    output_config={"effort": "high"},   # low | medium | high | xhigh | max
    messages=[{"role": "user", "content": task}],
)

The nesting is a real exam trap. effort lives inside output_config. A top-level effort= or a top-level output_format= is the wrong shape; structured output is likewise output_config={"format": {...}}. And note what is absent: there is no temperature, no top_p, no top_k. Those sampling parameters have been removed from the current models and now return HTTP 400.

# Every line below is now REJECTED on Opus 4.8 / Sonnet 5 / Fable 5:
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=8000,
    thinking={"type": "enabled", "budget_tokens": 4000},  # removed -> 400
    temperature=0.7,        # removed -> 400
    top_p=0.9,              # removed -> 400
    output_format={...},    # deprecated top-level -> use output_config.format
    messages=[
        {"role": "user", "content": task},
        {"role": "assistant", "content": "{"},  # prefill -> rejected
    ],
)

3. System Prompt Design: Why Guardrails There Are Soft

A well-formed system prompt has five parts, and the exam expects you to name them: a role, the task, the constraints, an output contract, and an escalation rule for what to do when the input falls outside scope. Get those five and most prompt-quality problems disappear.

Now the fact this domain tests harder than any other: guardrails written into the system prompt are advisory, not enforcement. "Never reveal account balances," "always refuse requests for legal advice," "only answer questions about our product": these are soft instructions the model usually follows and can be talked out of. They shape behavior; they do not guarantee it.

Real enforcement lives at egress, in code the model cannot argue with:

• Schema validation — reject any output that does not match the required structure, before it reaches the user.
• Allowlists — if the output must be one of a fixed set of actions or values, verify membership in code.
• Tool removal — if a stage must not send email, do not give it the send_email tool. An unavailable capability cannot be jailbroken into.
• Human-in-the-loop gates — route irreversible or high-blast-radius actions through a person (Lab 1).

4. Zero-Shot vs Few-Shot vs Chain-of-Thought

These three are a decision, not a ladder you always climb. Each wins in a different regime, and each has a cost and a characteristic failure mode the exam probes.

Two subtleties the exam rewards. Few-shot examples are not free context you set once; they ride along on every request as input tokens, which is precisely why you want them in a cacheable prefix (next section). And chain-of-thought inflates output tokens, the expensive direction; on the current models, prefer adaptive thinking (Section 2) over hand-rolled "think step by step" prose, because thinking tokens are managed and the visible answer stays clean.

5. Prompt Caching: the Exam's Favorite Lever

No mechanism in this domain is tested more than prompt caching, because it is the rare lever that improves cost and latency at once. The guide's own Sample 2 is built on it:

An application sends the same 8,000-token system prompt plus a policy document on every request, followed by a short varying user message. Both latency and cost are concerns. The correct answer is to place the static content before the dynamic content and enable prompt caching.

That is the guide's Sample 2 verbatim, and it encodes the one invariant everything else follows from: caching is a prefix match. The cache key is the exact bytes from the start of the prompt up to each breakpoint. Any change anywhere in the prefix invalidates everything after it. So stable content goes first, the varying user message goes last, and you put the cache breakpoint at the boundary.

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": POLICY_DOCUMENT,          # ~8,000 stable tokens
            "cache_control": {"type": "ephemeral"},  # breakpoint HERE
        },
    ],
    messages=[
        # The varying part comes AFTER the cached prefix.
        {"role": "user", "content": customer_question},
    ],
)

# Verify the cache actually hit:
print(response.usage.cache_read_input_tokens)   # ~8000 on a hit
print(response.usage.input_tokens)              # only the uncached remainder

Now the mistake the exam builds a distractor from, putting the varying content first, so the prefix changes every request and the cache never hits:

# WRONG: the question changes every request, so it invalidates the
# entire prefix that follows it. cache_read_input_tokens stays 0 forever.
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system=[
        {"type": "text", "text": customer_question},      # varies -> poisons prefix
        {"type": "text", "text": POLICY_DOCUMENT,
         "cache_control": {"type": "ephemeral"}},          # never reused
    ],
    messages=[{"role": "user", "content": "Answer using the policy above."}],
)

The rules the exam quizzes on caching

The economics follow from the multipliers. A 5-minute write costs 1.25×; a read costs 0.1×. So two requests that share a prefix already win: 1.25 + 0.1 = 1.35× versus 2× uncached. The 1-hour TTL doubles the write to 2× but keeps the entry alive across gaps, worth it only when traffic is bursty enough that a 5-minute entry would expire between requests.

6. Context Window Optimization

The 1M-token window is a budget, not a target. Cost is linear in tokens, so filling the window because it is available is the same mistake as buying the biggest model because it exists. The architect's job is to put the fewest tokens in front of the model that let it succeed.

One token-counting rule the exam states plainly: count with the API, never with a foreign tokenizer.

# Token counts are model-specific. Pass the model you will actually call.
count = client.messages.count_tokens(
    model="claude-opus-4-8",
    system=[{"type": "text", "text": POLICY_DOCUMENT}],
    messages=[{"role": "user", "content": customer_question}],
)
print(count.input_tokens)

# NEVER use tiktoken here: it is OpenAI's tokenizer and UNDERCOUNTS for
# Claude (worse on code and non-English), so any budget built on it is wrong.

7. Prompt Reuse: Caching, Modular Prompts, and Skills

Reuse is one objective with three mechanisms, and they compose. Caching (Section 5) reuses rendered bytes. Modular prompts and Skills reuse authored content in a way that keeps those bytes cacheable.

• Modular prompts — compose the prompt from stable blocks (role, policy, format contract) plus a small volatile tail. Because the stable blocks render identically every time, they form a cacheable prefix. Modularity is what makes caching survive as the prompt evolves.
• Skills — versioned, reusable capability folders (instructions plus resources) that Claude progressively discloses: the short description sits in context by default, and the full instructions load only when the task calls for them. That is context-window optimization and reuse in one primitive.

There is a single architecture rule that ties reuse to caching, and it is worth memorizing as one sentence: anything that varies goes last.

# Stable, reusable blocks render byte-identical every request -> cacheable.
system_blocks = [
    {"type": "text", "text": ROLE_AND_TASK},        # module 1 (stable)
    {"type": "text", "text": OUTPUT_CONTRACT},      # module 2 (stable)
    {
        "type": "text",
        "text": POLICY_DOCUMENT,                    # module 3 (stable, large)
        "cache_control": {"type": "ephemeral"},     # breakpoint after the last stable block
    },
]

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system=system_blocks,
    # Everything that varies is here, AFTER the cached prefix.
    messages=[{"role": "user", "content": customer_question}],
)

8. Design Exercise: A Support System at 40k/Day

Scenario. A support platform sends the same 8,000-token policy prefix on every request, followed by a short varying customer question. Volume is 40,000 requests per day. Leadership wants both lower cost per ticket and faster first response. Work the numbers and the routing.

1. Confirm the shape matches Sample 2. Large stable prefix, short varying suffix, both cost and latency in play. This is the caching case. Place the 8k policy in the system array before the question, with a cache_control breakpoint on the policy block.
2. Check the minimum. 8,000 tokens clears Opus 4.8's 4096-token minimum cacheable prefix comfortably, so the breakpoint will actually take.
3. Compute the cache economics. Without caching, each request pays for 8,000 prefix tokens at input price. With caching, the first request of each 5-minute window writes at 1.25× and every subsequent request reads at 0.1×. At 40k/day the prefix is re-read constantly, so almost every request pays 0.1× instead of 1× on the prefix, roughly a 90% reduction on the 8k prefix cost, plus lower time-to-first-token because the prefix is not reprocessed.
4. Choose models per stage. Route a cheap first stage (classify the ticket's intent and detect whether it is even in scope) to Haiku 4.5 ($1/$5). Send only the tickets that need genuine policy synthesis to Opus 4.8. Do not route the whole volume to Opus, and do not route the hard synthesis to Haiku to "save money"; that is the always-wrong smallest-model answer.
5. Watch the context ceiling. If any stage must load a much larger policy corpus (say 300K tokens of retrieved regulation), Haiku's 200K window disqualifies it for that stage regardless of price. Sonnet or Opus, both 1M, carry it.
6. Write the escalation rule into the system prompt. The five-part prompt needs its escalation clause: e.g. "If the question is not answerable from the policy above, or asks for a refund over $500, do not answer; return {"escalate": true, "reason": ...} so a human agent takes it." Then enforce that at egress with schema validation (Section 3): the prompt asks, the validator guarantees.

Step 3 is the number you put in front of a CFO. Step 4 is the routing that keeps the bill honest. Step 6 is the one the exam tests hardest, because the escalation clause lives in a soft prompt, and the guarantee lives in the hard validator.

Key Takeaways

• usage.input_tokens is the uncached remainder only. Total prompt size is the sum of input_tokens + cache_creation_input_tokens + cache_read_input_tokens. Cost math on the single field undercounts every cache hit.
• Route by task fit: Haiku 4.5 for cheap well-specified work, Opus 4.8 for hard synthesis, Sonnet 5 for the volume middle, Fable 5 only when Opus is demonstrably insufficient. "Smallest model regardless of fit" is always wrong.
• Haiku's 200K context is the odd one out; a stage that needs more than 200K tokens disqualifies Haiku on capacity, not price.
• On Opus-tier, omitting thinking means no thinking. Use thinking={"type":"adaptive"} and the nested output_config={"effort":...} dial. budget_tokens, temperature, top-level output_format, and assistant prefill all return 400.
• System-prompt guardrails are soft. Real enforcement is at egress: schema validation, allowlists, tool removal, human gates. When an item asks how to guarantee behavior, the answer is a code-level control, not a stronger instruction.
• Caching is a prefix match: stable content first, breakpoint on the last stable block, varying content last. Order is tools → system → messages; max 4 breakpoints; reads ≈ 0.1×, writes 1.25× (5m) or 2× (1h). The guide's Sample 2 is exactly this.
• On Opus 4.8 the minimum cacheable prefix is 4096 tokens; below it, the breakpoint silently does nothing. Verify hits with cache_read_input_tokens.
• The 1M window is a budget, not a target. Retrieve instead of stuffing; prune tool output; compact; isolate corpora in subagents. Count tokens with client.messages.count_tokens(), never tiktoken.
• Reuse composes: modular prompts keep a cacheable prefix, Skills progressively disclose. The one rule that ties it together: anything that varies goes last.