CCAR-P · module 2 of 7 · 13% of the exam

Claude models, prompting, and context engineering

Covers the 5 official objectives: select models based on trade-offs; design system prompts/templates/guardrails; apply prompting techniques (zero-shot/few-shot/CoT); optimize context windows and token usage; implement prompt reuse (caching, modular prompts, Skills).

Official sample theme lives here: prompt-caching + static-prefix ordering — expect at least one question built around this.

Objective: Select appropriate Claude models based on trade-offs

• Core concept: Model choice trades off intelligence/reasoning depth against latency and cost. Right-sizing to the task is the architect skill being tested, not "always pick the best model."
• Anthropic-platform specifics:
  • Current tiers (highest to lowest capability/cost): Claude Fable 5 (most capable, always-on thinking, premium pricing — used only when explicitly justified), Opus (complex reasoning, long-horizon agentic work, highest of the "normal" tiers), Sonnet (best speed/intelligence balance, near-Opus quality on coding/agentic at lower cost — the default production workhorse), Haiku (fastest/cheapest, for simple/high-volume/latency-sensitive tasks like classification).
  • effort (low/medium/high/xhigh/max inside output_config) is a second, finer-grained lever independent of model choice — controls thinking depth/token spend within a model. Lower effort = fewer, more consolidated tool calls, less preamble.
  • Adaptive thinking (thinking: {type:"adaptive"}) lets the model decide when/how much to think, rather than a fixed token budget — the modern replacement for manually tuning budget_tokens.
• Decision heuristic: High-volume, simple, latency-sensitive (classification, short extraction) → Haiku. Balanced production workloads, most coding/agentic tasks → Sonnet. Complex, high-stakes reasoning, long-horizon autonomous work → Opus (or Fable-tier only when justified by task difficulty, not by default).

Objective: Design system prompts, templates, and guardrails

• Core concept: The system prompt is the architectural surface for persona, constraints, and safety — not just "instructions." Templates externalize repeated structure; guardrails are explicit boundaries on what the model will/won't do.
• Anthropic-platform specifics:
  • System prompt goes in the system parameter (string or array of content blocks) and renders before messages in the cache-relevant order (tools → system → messages) — see caching below.
  • Guardrails are layered, not a single prompt line: system-prompt-level behavioral constraints, tool-level permission_policy (always_allow vs always_ask — human-in-the-loop gate before execution), and structured outputs (output_config.format / strict: true tool schemas) to constrain the shape of output, not just its content.
  • Aggressive imperative language ("CRITICAL: you MUST...") tends to overtrigger on current models — the recommended style is direct, calibrated instructions ("use this tool when...") rather than all-caps urgency; over-aggressive guardrail language is itself an exam-style anti-pattern.
• Decision heuristic: A guardrail that lives only in prose in the system prompt is weaker than one enforced structurally (tool permission policy, schema validation, human approval gate) — prefer structural enforcement for anything security- or compliance-critical.

Objective: Apply prompt engineering techniques (zero-shot, few-shot, chain-of-thought)

• Core concept: Three escalating techniques for eliciting better output, each with a cost:
  • Zero-shot — instruction only, no examples. Cheapest, works when the task is well-specified and common.
  • Few-shot — 2-5 worked examples embedded in the prompt (often as prior user/assistant turns). Improves format adherence and edge-case handling; costs tokens on every request unless cached.
  • Chain-of-thought (CoT) — explicit "think step by step" or structured reasoning before the final answer. On current models this is largely superseded by adaptive/extended thinking, which reasons internally without polluting the visible response — but manual CoT prompting is still relevant for models/paths without thinking enabled, or when you want the reasoning steps to be part of the visible output for auditability.
• Anthropic-platform specifics: extended/adaptive thinking (thinking: {type:"adaptive"}) is the API-native mechanism for reasoning depth; it's distinct from prompted CoT because thinking tokens are billed and controllable via effort, and are hidden or summarized (display: "summarized") rather than always shown.
• Decision heuristic: Use few-shot when the failure mode is format/structure (model doesn't know the exact output shape you want). Use CoT/thinking when the failure mode is reasoning (model jumps to a wrong answer on multi-step logic). Adding more examples doesn't fix a reasoning failure, and enabling thinking doesn't fix a format-adherence failure — matching technique to failure mode is a common exam judgment call.

Objective: Optimize context windows and manage token usage

• Core concept: Context is a finite, costed resource. Optimization means keeping only what's relevant to the current step, not maximizing what's stuffed in.
• Anthropic-platform specifics:
  • Context window is up to 1M tokens on current models (200K on Haiku 4.5); max output up to 128K (with streaming required above ~16K to avoid HTTP timeouts).
  • Token counting (messages.count_tokens) — always use the API's counter, never a third-party tokenizer approximation (different models tokenize differently; using the wrong tokenizer under/over-estimates cost and risks silent truncation).
  • Long-running-agent context management tools: context editing (clears stale tool results/thinking blocks, pruning without summarizing), compaction (server-side summarization of earlier turns when nearing the context limit — must echo back response.content, not just text, or compaction state is lost), memory (persists facts across sessions via file-based memory tools/memory stores, distinct from within-session context management).
  • Tool search / progressive disclosure keeps large tool catalogs and Skills out of the base context until relevant, rather than loading everything up front.
• Decision heuristic: "Context is running out mid-session" → compaction (summarize) or context editing (prune stale tool results), not simply raising max_tokens (that's an output cap, unrelated to input context pressure). "Context is large because of an oversized tool/skill catalog" → tool search / progressive disclosure, not manual trimming.

Objective: Implement prompt reuse strategies (caching, modular prompts, Skills)

• Core concept: Reuse strategies exist so repeated structure (system prompts, tool definitions, large shared context) isn't reprocessed at full cost/latency on every call.
• Anthropic-platform specifics — prompt caching (the official sample theme for this domain):
  • Caching is a strict prefix match — any byte change anywhere in the prefix invalidates everything after it, not just the changed block.
  • Render order is fixed: tools → system → messages. A cache_control breakpoint on the last system block caches tools + system together. This is why stable content must be ordered first and volatile content (timestamps, session IDs, the user's specific question) must come after the last breakpoint — putting a timestamp in the system prompt invalidates the entire downstream cache on every request.
  • cache_control: {type: "ephemeral"} on a content block, or top-level auto-caching for the simplest case; max 4 breakpoints per request; minimum cacheable prefix is model-dependent (~1024–4096 tokens) — a prompt below that silently doesn't cache (no error).
  • Cache economics: reads ~0.1× base input price, writes ~1.25× (5-min TTL) or 2× (1-hr TTL) — break-even needs 2+ (5-min) or 3+ (1-hr) requests reusing the same prefix.
  • Verify with usage.cache_read_input_tokens — if it's zero across repeated identical-prefix requests, something is silently invalidating the cache (non-deterministic JSON serialization, a datetime.now() in the system prompt, a varying tool list, a model switch).
  • Changing the tool list or the model invalidates the cache entirely (both render at/near position 0); changing tool_choice or toggling thinking only invalidates system+messages, not tools; changing message content only invalidates messages. Not all changes cost the same — know the invalidation hierarchy.
  • Modular prompts / Skills: package reusable instructions as a Skill (SKILL.md + supporting files) that loads on demand via progressive disclosure, instead of concatenating every possible instruction into one giant static system prompt. This keeps the cached prefix lean and lets you compose capabilities.
• Decision heuristic: If a scenario describes a large shared system prompt/context reused across many requests with low measured cache_read_input_tokens, the fix is almost always reordering (move volatile content after the breakpoint) or fixing a silent invalidator — not disabling caching or switching models.

How to think through the question

Domain 2 questions usually describe a symptom and offer four levers. Almost all of them are decided by matching the lever to the symptom rather than by knowing an extra API detail.

Signal words to look for

Reasoning procedure

1. Classify the symptom as a format problem, a reasoning problem, or a capability problem. Three quarters of this domain's questions are decided at this step.
2. If cost or repeated context is mentioned, work the caching chain in order: is there a genuinely stable prefix, is it ordered first, is anything volatile sitting ahead of the last breakpoint, and is the prefix long enough to cache on that model at all.
3. If the scenario says the session is running out of room, separate input context pressure from the output cap, then choose between pruning and summarizing based on whether the content being removed is still needed.
4. If the scenario describes a large tool or instruction surface, ask whether the scale actually justifies a discovery mechanism, since applying progressive disclosure to five stable tools is over-engineering in the other direction.
5. Discard options that reach for a bigger model, a higher effort level, or more examples when the named symptom points somewhere else.

Worked example

An extraction pipeline pulls the correct values out of supplier invoices, but the shape of the output varies from run to run and the downstream system intermittently fails to parse it. A colleague proposes moving to the top model tier at maximum effort.

Work the signals first. The scenario explicitly says the values are correct, so this is not a reasoning failure and not a capability ceiling. What varies is the shape, which names a format problem.

Now match the lever. Format problems are addressed by showing the model the exact shape you want, and more strongly by constraining the shape at the API level so the response is guaranteed to validate against a schema rather than merely encouraged to. The proposed tier upgrade spends materially more on every request to fix a problem it does not address, and it would leave the downstream parser exposed to the same intermittent failure. The answer is a structured output with a schema, with few shot examples as the weaker fallback if a schema is not available for that path.

Exam traps (Domain 2)

• Putting a timestamp, session ID, or per-request UUID early in the system prompt "for logging" — this is the textbook silent cache-invalidator distractor; the fix is moving it after the last breakpoint or into a later message, not abandoning caching.
• "Just add more few-shot examples" as the fix for a reasoning failure (should be CoT/thinking) — plausible-but-inferior because it treats a logic problem as a format problem.
• "Always use the most capable model to be safe" — ignores cost/latency trade-offs the exam expects you to weigh explicitly.
• Reordering caching guidance backwards (volatile-first, stable-last) — sounds intuitive ("put the specific question first so the model sees it immediately") but is exactly wrong for cache hit rate.
• Raising max_tokens to fix a context-window/input-side problem — max_tokens only bounds output, it does nothing for input context pressure or compaction needs.
• Manually managing a fixed budget_tokens thinking allocation as the "modern" answer — adaptive thinking is the current best practice; fixed budgets are a legacy/transitional pattern.