3 Claude Models, Prompting & Context Engineering (13%) · CCAR-P

What the exam tests: choosing the right model tier for each step, writing prompts that hold up in production, and spending context and tokens deliberately.

Official task statements: select Claude models based on trade-offs; design system prompts, templates, and guardrails; apply zero-shot, few-shot, and chain-of-thought prompting; optimize context windows and token usage; reuse prompts through caching, modular prompts, and Skills.

Model selection

Claude ships in tiers: a most-capable tier (Opus), a balanced tier (Sonnet), and a fast, low-cost tier (Haiku). Exact model versions change; confirm current names and prices in Anthropic's models overview before you quote them.

Need Lean toward Why
Hard reasoning, long agentic tasks, complex code Most-capable
tier
Fewer failed attempts can cost less over‐
all

Most production workloads Balanced tier Best quality per dollar for general use High-volume classification, routing, extraction, sub‐

agents

Fast tier Latency and unit cost dominate

The professional answer is usually mixed: route easy requests to a small model and escalate hard ones, or let a capable orchestrator delegate to fast subagents. Decide with your evaluation set, not intuition: run the candidate models on the same cases and compare quality, p95 latency, and cost per successful task.

Plan for model migration. Pin model versions in production, track deprecation dates, and rerun the full evaluation suite before switching. Prompts tuned for one model may need adjustment for the next.

System prompts and templates

A production system prompt has a stable structure:

Role and goal, including who the user is.

Context the model needs (policies, product facts), clearly delimited, for example with XML tags.

Rules and guardrails: what to refuse, when to escalate, what never to reveal. Output contract: a schema, or a precise format with an example.

Behavior when unsure: abstain, ask, or flag low confidence.

Keep instructions positive and specific ("answer in under 120 words") rather than vague ("be concise"). Explain the reason behind a rule; Claude generalizes better from the why. Version prompts like code, review changes, and gate them on evaluations.

Prompting techniques

Zero-shot: clear instructions alone. Start here.

Few-shot: 3 to 5 diverse, representative examples, including an edge case. Use when format or judgment is hard to describe. Watch for the model copying surface features of the examples. Chain of thought: ask for reasoning before the answer, or enable extended thinking for hard multi-step problems. It improves accuracy on complex tasks and costs tokens and latency, so do not switch it on for simple classification.

Structured output: use JSON schemas or tool definitions so downstream code can validate output.

Prompt chaining: split a complex prompt into steps when one prompt keeps failing on part of the task.

Context engineering

Context is a budget. More tokens cost more, add latency, and can dilute attention, so put the right information in, not all of it.

Prioritize: instructions and the most relevant retrieved passages first; drop stale conversation turns. Compact: summarize long histories and tool results; keep raw data out of the window when a summary will do.

Isolate: give subagents their own windows and have them return summaries.

Load on demand: let the model fetch details through tools instead of preloading everything.

Reuse: caching, modular prompts, and Skills

Prompt caching reuses an unchanged prompt prefix across requests. Put static content (tools, system prompt, policy documents, examples) first and dynamic content (the user's message) last, and mark the cache breakpoint after the static part. Cache reads are billed at a small fraction of normal input price and cut time to first token; cache writes cost slightly more than normal input. Caches expire after a short time-to-live (5 minutes by default, with a longer option), so caching pays off on steady, repeated traffic. Any change to the prefix, even one character, misses the cache.

Modular prompts assemble a prompt from versioned parts (shared policy block, task block, persona block) so a policy change updates every product at once.

Skills package instructions, scripts, and resources in a folder. Only a short name and description sit in context until the task needs the skill, then the full content loads. That is progressive disclosure, and it keeps the base context small while giving many specialized capabilities.

Deep dive: prompt craft for production

Principles that hold across models

Be explicit about the goal and the audience. "Write a summary for a claims adjuster deciding whether to approve within 24 hours" beats "summarize this." Give the reason behind each rule. Claude applies the spirit of a rule to new cases when it knows why the rule exists.

Say what to do, not only what to avoid. "Use plain sentences without bullet points" works better than "don't use markdown."

Separate instructions from data with clear delimiters such as XML tags (<instructions>,

<document>, <customer_message>). This also helps defend against injection, because the

model can tell content apart from commands, though it is not a complete defense. Specify the output precisely: format, length, fields, and what to do when information is missing.

Let the model say "I don't know." Explicit permission to abstain reduces fabrication. Match the prompt's style to the desired output style. A prompt written in heavy markdown tends to produce markdown.

Working with long context

Put long documents near the top of the prompt and the question or task at the end; this ordering tends to improve answer quality on long inputs. Wrap each document in tags with metadata (source, date, title) so the model can cite and distinguish them.

CLAUDE MODELS, PROMPTING & CONTEXT ENGINEERING (13%)

Ask for relevant quotes first, then the answer based on those quotes. It focuses attention and makes the answer checkable.

Do not assume more context is better. Irrelevant material costs money and can lower quality. Retrieve or select what the task needs.

Prompting for tool use

Tool definitions are part of the prompt, and their quality decides how well the model uses them.

Element Good practice

Tool name Clear and specific: search_orders_by_customer, not query Description What it does, when to use it, when not to, and what it returns, in a few sentences Parameters Typed, with descriptions, allowed values, and formats (for example ISO dates) Errors Return helpful error messages the model can act on ("customer_id not found; search by email instead") Output size Return only what the model needs; paginate or summarize large results Overlap Avoid several tools that do nearly the same thing; the model will pick inconsistently You can also require the model to call a specific tool, or any tool, when the application needs structured output every time.

Reasoning and thinking

For hard, multi-step problems, extended thinking gives the model room to reason before answering. You can set a budget for it, and usage is billed as output tokens. In agentic use, thinking between tool calls helps the model decide what to do with each result. For simple tasks, thinking adds latency and cost without benefit; test it on your evaluation set rather than enabling it everywhere.

Without extended thinking, asking the model to reason step by step inside tags before giving its final answer still helps on complex tasks, and lets your code strip the reasoning from the user-facing output.

Sampling settings

Lower temperature gives more consistent output for extraction and classification; higher temperature gives more variety for creative drafts. Temperature does not fix factual errors, and some model features constrain which settings you can use, so check current documentation.

A prompt review checklist
Goal, audience, and success criteria stated
Instructions and data clearly separated
No contradictory rules

Output format specified, with behavior for missing information
Examples are diverse and include an edge case
Static content first, dynamic content last (cache-friendly)
Versioned, with an evaluation result attached to the change

Worked example 3.1: a model-selection bake-off

Brief. An insurer's claims-notes summarizer runs 300,000 times a month on the balanced tier. Finance asks whether the fast tier would do.

Method. Do not argue from intuition. Run both tiers on the same 300-case evaluation set and compare on the metrics that matter for this use case.

Metric Balanced tier Fast tier Target

Rubric score (1 to 5, LLM judge calibrated to adjusters) 4.4 4.1 4.0 or more Critical omissions (injury, liability, fraud flags) 0.7% 2.3% under 1% p95 latency 3.8 s 1.6 s under 5 s

Relative cost per summary 1.0 about 0.3 n/a

Figures are an illustrative example of what such a comparison looks like, not measured results. Reading it. The fast tier passes the average-quality bar but fails the critical-omission bar, which is the metric that matters most. A single blended score would have hidden this. Options to present.

Stay on the balanced tier (safe, no savings).

Route: fast tier for short, routine notes; balanced tier when notes mention injury, litigation, or fraud indicators (a keyword or classifier gate). Re-run the eval per segment to confirm critical omissions stay under 1%.

Fast tier plus a targeted prompt section and a code check that the summary mentions each flagged entity found in the source. Re-evaluate.

Option 2 is the typical professional answer: it captures most of the savings where risk is low and keeps quality where it matters. The general lesson: evaluate per segment and per critical metric, not only on average.

Worked example 3.2: rebuilding a failing system prompt

Before. A customer-support prompt has grown to 6,000 tokens over a year. It starts with today's date and the customer's name, mixes product facts with rules, contains three contradictory instructions about refunds, and ends with "BE CONCISE!!!". Cache hit rate is 2%, and evaluations show the model violates the refund policy in 9% of relevant cases.

CLAUDE MODELS, PROMPTING & CONTEXT ENGINEERING (13%)

Diagnosis.

Dynamic content at the top breaks prefix caching.

Contradictory rules cause inconsistent behavior; the model cannot follow both. Rules without reasons generalize poorly to new situations.

Shouting does not replace a precise output contract.

After (structure).

<role>: who the assistant is, who the customers are, the goal.
<policies>: one refund policy, stated once, with the reason (for example "refunds over $200

need a supervisor because of fraud losses last year").

<product_facts>: delimited reference material.
<escalation>: when to hand off and how.
<output_format>: "Reply in 2 to 4 sentences. If a refund is requested, state the eligible
amount and the next step."

Three short examples, including one refusal and one escalation.

Cache breakpoint here. Then the dynamic block: customer name, account tier, today's date, conversation.

Result to verify. Re-run the evaluation set. Expect higher cache hits (static prefix now shared), lower latency, and fewer policy violations. Ship the new prompt behind a flag, A/B it, and record the change as a versioned prompt with an ADR.

Worked example 3.3: context budget for a long-running agent

Brief. A coding agent works on tasks that run for 2 to 3 hours and hundreds of tool calls. Late in a run it forgets earlier decisions and repeats work.

Diagnosis. The context fills with raw tool outputs (full file reads, long test logs). Older but important decisions are pushed out or diluted. Remedies, in order of effort.

Trim tool outputs at the source: return the failing test names and the first error lines, not 4,000 lines of log.

Compaction: periodically summarize the conversation into decisions made, current plan, and open issues; continue from the summary.

External memory: have the agent write a progress file (plan, decisions, done, next) that it re-reads when needed.

Subagents for wide searches, returning summaries.

Progressive loading of tools and skills so their definitions are not all in context.

Exam wording to recognize: "context rot," "the agent loses track of earlier instructions," "token usage grows with every turn." The answer is context engineering, rarely a bigger window by itself.

Worked example 3.4: placing the cache breakpoint

A request has five parts. Which order maximizes cache reuse?

Part Changes how often
Tool definitions Monthly
System prompt and policy Weekly
Retrieved documents for this question Every request
Conversation history Every turn
Current user message Every request

Answer: tools, then system prompt and policy (breakpoint), then conversation history (a second breakpoint can cover the stable earlier turns in a multi-turn chat), then retrieved documents and the new message. The rule: order from least to most frequently changing.

Scenario drills

A classifier needs to output one of 14 labels. Engineers enabled extended thinking "for accuracy." Latency tripled with no accuracy gain. What do you recommend? A team writes "never mention competitors" and the model still compares products when users ask directly. What is a better approach?

A few-shot prompt with three examples, all about laptops, now gives laptop-shaped answers to questions about printers. What happened?

An app sends a 50-page product manual with every question; questions are bursty, with long quiet periods. Is caching enough?

Twelve product teams each maintain their own copy of the company's safety and privacy instructions. What should the architect introduce? A provider retires the model version you pinned. What must already exist for this to be routine?

Answers.

Turn extended thinking off for this task; it adds tokens and latency without benefit on simple classification. Consider the fast tier and structured output.

Explain the policy and give the desired behavior ("if asked to compare, describe our product's features and suggest the user consult independent reviews"), add an example, and add an output check if the rule is critical.

CLAUDE MODELS, PROMPTING & CONTEXT ENGINEERING (13%)

The examples lacked diversity, so the model copied their surface features. Use varied examples across product types. Possibly not: caches expire after their time-to-live, so bursty traffic gets frequent misses. Consider the longer cache duration option, or retrieval of only the relevant manual sections. A shared, versioned prompt module (or Skill) included in every product's prompt, owned by one team.

A regression evaluation suite, version pinning, a migration runbook, and canary release capability.

Common traps

Truncating required policy text to save tokens, instead of caching it.

Putting a timestamp or user ID at the top of the prompt, which breaks every cache hit. Upgrading to the biggest model when the evaluation shows a prompt problem.

Turning on extended thinking for every call by default.

Check yourself

A 9,000-token policy precedes every short user query. Two changes to cut cost and latency?

When is few-shot better than more instructions?

How do Skills keep context small?

Your provider announces deprecation of the model you use. List your migration steps. Answers: (1) Order static content before dynamic content and enable prompt caching; also route simple queries to a smaller model if evaluations allow. (2) When the desired format or judgment is easier to show than describe. (3) Only metadata is loaded until the skill is needed (progressive disclosure). (4) Inventory usage, run the eval suite on the replacement, adjust prompts, canary release, monitor, then cut over before the retirement date.