Select Appropriate Claude Models Based on Trade-offs

CCAR-P Exam Guide — Domain 2: Claude Models, Prompting & Context Engineering

Exam: Claude Certified Architect – Professional Exam code: CCAR-P Domain 2 weight: 13% Target objective: Select appropriate Claude models based on trade-offs

---

1 What You Need to Know for the Exam

The central idea is simple:

There is no universally “best” Claude model. There is a best-fit model for a particular workload and its constraints.

CCAR-P is testing whether you can make and defend that architectural decision.

You should be able to look at a scenario and identify:

Business/task complexity → required intelligence → latency requirement → context requirement → volume → acceptable cost → model choice → validation strategy.

The unofficial practitioner workbook summarizes the same principle well: model selection is a multi-factor trade-off, and both “always use the biggest model” and “always use the cheapest model” are bad architectural rules.

Exam mindset

Do not think:

Opus/Fable = good Sonnet = medium Haiku = cheap

Think:

What level of capability does this particular step require, and what is the lowest-cost/latency model that reliably satisfies the required quality bar?

That distinction is likely where CCAR-P distractors will be built.

---

2 The Core Model-Selection Trade-off

For exam purposes, remember these six dimensions:

Dimension	Architect’s question
Reasoning / Intelligence	How difficult is the reasoning required?
Latency	How quickly must the user receive the result?
Cost	What unit economics are acceptable at production volume?
Context capacity	How much information must the model reason over at once?
Output / task complexity	Is this classification, synthesis, coding, planning, or long-horizon agentic work?
Quality / risk	What happens if the model is wrong?

The correct model is the one that satisfies the required quality threshold while respecting the other constraints.

This is fundamentally a constrained optimization problem:

Meet the quality bar first → then optimize cost and latency without dropping below it.

---

3 Current Claude Model Landscape

As of August 17, 2026, Anthropic’s current model comparison lists:

Model	Anthropic positioning	Relative latency	Context	Base API price*
Claude Fable 5	Next-generation intelligence for long-running agents	Slower	1M	$10 input / $50 output per MTok
Claude Opus 5	Complex agentic coding and enterprise work	Moderate	1M	$5 / $25
Claude Sonnet 5	Best combination of speed and intelligence	Fast	1M	$2 / $10
Claude Haiku 4.5	Fastest model with near-frontier intelligence	Fastest	200K	$1 / $5

Anthropic currently positions Sonnet 5 around the speed/intelligence balance, Haiku 4.5 around maximum speed, Opus 5 around complex agentic and enterprise work, and Fable 5 around the most demanding long-running agent workloads.

*Prices are useful for understanding relative economics, but do not make memorizing current dollar values a study priority. Prices and model generations change. Anthropic’s pricing and model documentation should be treated as dynamic.

Important source reconciliation

The supplied practitioner workbook uses the older conceptual mapping:

• Haiku → fastest / cheapest
• Sonnet → balanced production default
• Opus → deepest reasoning

That framework remains useful, but the specific model landscape has moved on. The current official Anthropic documentation now includes Fable 5, Opus 5, Sonnet 5, and Haiku 4.5.

For CCAR-P, memorize the selection logic, not a frozen catalog.

---

4 The Most Important Exam Principle: Match Model Capability to Task Complexity

Model selection should start with the task.

Low-complexity tasks

Examples:

• intent classification
• document routing
• metadata extraction
• basic categorization
• straightforward field extraction
• simple content moderation/triage
• standardized transformations

These tasks generally have:

• constrained inputs;
• easily verified outputs;
• little deep reasoning;
• high transaction volume;
• strong sensitivity to latency/cost.

A faster, lower-cost model such as Haiku-class capability can therefore be the best architectural choice.

Example

An e-commerce company receives 2 million support messages per month.

Claude only needs to classify each into:

• refund
• shipping
• damaged item
• account issue
• other

Using the most capable reasoning model on every request would usually be unnecessary.

Better architectural thinking:

Use the fastest lower-cost model that passes the classification quality threshold.

---

5 Balanced Knowledge Work

Now consider tasks such as:

• summarizing business documents;
• drafting reports;
• RAG-based enterprise Q&A;
• standard coding work;
• moderate analysis;
• tool-using assistants;
• customer support with non-trivial reasoning.

Here the system needs substantially more reasoning, but it may still operate at high production volume.

This is the natural territory for a balanced model.

Anthropic currently describes Sonnet 5 as offering the best combination of speed and intelligence.

Example

A B2B SaaS application generates executive reports from:

• usage statistics;
• customer notes;
• product metrics;
• policy documents.

Requirements:

• high quality;
• under ~10 seconds;
• thousands of reports/day;
• reasonable unit cost.

A frontier/highest-cost model may improve a small percentage of difficult cases but significantly worsen economics.

A balanced model is therefore likely the starting candidate.

But notice the wording:

starting candidate, not automatically correct.

The architect must evaluate it against the actual workload.

---

6 Complex Reasoning and Agentic Work

A more capable model becomes justified when task difficulty genuinely requires it.

Signals include:

• complicated planning;
• ambiguous requirements;
• difficult software architecture;
• long-horizon coding;
• complex multi-step reasoning;
• difficult tool orchestration;
• strategic synthesis across many constraints;
• high-value decisions where reasoning quality materially affects the outcome.

Anthropic currently positions Opus 5 for complex agentic coding and enterprise work.

Example

Claude must modernize a large legacy application by:

1. understanding several repositories;
2. discovering dependencies;
3. planning a migration;
4. modifying code;
5. running tests;
6. diagnosing failures;
7. revising the plan;
8. continuing over an extended period.

This is very different from classification.

Paying for additional reasoning capability can be economically rational because the model is replacing or accelerating expensive expert effort.

---

7 Long-Running / Extremely Difficult Agentic Tasks

The current Anthropic model family also includes Claude Fable 5, positioned for long-running agents and as Anthropic’s most capable widely released model.

That does not imply:

Fable 5 is the safest CCAR-P answer.

Quite the opposite.

An exam question may deliberately tempt you with:

“Use the most capable available model to maximize quality.”

That is incomplete architectural reasoning.

Use frontier capability when:

incremental quality/capability has enough business value to justify incremental latency and cost.

---

8 Trade-off #1 — Intelligence vs Cost

This is probably the easiest trade-off to recognize.

Suppose:

• Haiku solves 96% correctly;
• Sonnet solves 98%;
• Opus solves 98.4%.

You cannot decide from those numbers alone.

Ask:

What is the business value of that extra accuracy?

Scenario A — marketing-tag classification

An occasional incorrect category has almost no material consequence.

96% may be perfectly acceptable.

Scenario B — sophisticated software remediation

One bad recommendation can consume several engineering hours.

The additional reasoning capability may easily pay for itself.

CCAR-P lesson

Cost optimization cannot be separated from the cost of errors.

---

9 Trade-off #2 — Intelligence vs Latency

More reasoning capability is useless if the application misses its user-experience SLA.

Consider:

Interactive autocomplete

User expects a response almost instantly.

Binding constraint: latency.

A smaller fast model may be superior even if a bigger model is somewhat more accurate.

Asynchronous architecture review

The answer may take 20–60 seconds without harming the user experience.

Binding constraint: quality.

A more capable model may be justified.

Exam clue words

Watch for:

• “real-time”
• “interactive”
• “checkout flow”
• “sub-second”
• “customer waiting”
• “strict p95 latency”
• “voice assistant”

These are latency signals.

Do not automatically choose maximum capability.

---

10 Trade-off #3 — Intelligence vs Throughput

A model decision made at 100 requests/day may become economically wrong at 10 million requests/day.

Consider:

$0.02 more per task × 10,000,000 requests = $200,000 additional cost.

This is why CCAR-P treats architecture rather than demo quality as the unit of judgment.

Exam rule

When the stem emphasizes:

millions of requests very high volume per-transaction margin tight budget

you should immediately consider:

• smaller model;
• routing;
• batching where appropriate;
• caching;
• per-step model selection.

Not simply “use the cheapest model,” but make cost a binding architectural variable.

---

11 Trade-off #4 — Context Capacity

Context capacity matters when the model genuinely needs to reason over large amounts of information.

Current Anthropic documentation lists 1M-token context windows for Fable 5, Opus 5, and Sonnet 5, while Haiku 4.5 has a 200K-token window.

But there is an important exam trap:

A bigger context window does not automatically mean you should fill it.

If you have 500,000 tokens of enterprise documentation but only 5,000 are relevant to a user’s question, good architecture is usually:

retrieve/select relevant information → construct useful context → call the model

rather than:

dump 500,000 tokens into every request.

This connects model selection to context engineering and RAG.

---

12 Context Capacity vs Context Quality

This distinction deserves special attention.

A large context window gives you capacity.

It does not guarantee:

• relevant context;
• current context;
• authorized context;
• well-ordered context;
• noise-free context.

Example

A legal assistant receives 300,000 tokens including:

• 20 relevant contract clauses;
• hundreds of irrelevant emails;
• duplicate drafts;
• obsolete versions.

Moving from a smaller to a larger model does not solve the architectural problem.

The real problem is context assembly.

Exam trap

“The system gives inconsistent answers because its prompt contains excessive irrelevant documents. Upgrade to the model with the largest context window.”

Likely wrong.

Better:

improve retrieval/context management first.

---

13 Model Mismatch vs Prompt Failure vs Context Failure

This is particularly useful for CCAR-P because Domain 4 explicitly expects candidates to diagnose model mismatch.

Learn the symptoms.

Symptom	First suspicion
Poor from the beginning on genuinely difficult reasoning	Model capability mismatch
Understands task but output format is inconsistent	Prompt/schema problem
Strong early, deteriorates during long session	Context management problem
Wrong after document refresh	Retrieval/indexing problem
Accurate but SLA missed	Latency/model architecture issue
Good quality but economically impossible at scale	Cost/model architecture issue

Very important

Do not solve every problem by upgrading the model.

That is one of the easiest distractors to write.

---

14 Model Selection Is Per Step — Not Per Application

This is one of the highest-value concepts from the practitioner workbook.

Consider this pipeline:

Incoming Support Request
        ↓
Intent Classification
        ↓
Retrieve Customer Data
        ↓
Determine Complexity
        ↓
Generate Response
        ↓
Escalate Difficult Cases

There is no reason every step must use the same Claude model.

A better architecture could be:

Simple / high-volume classification
        ↓
Fast lower-cost model

Normal support cases
        ↓
Balanced model

Very difficult / exceptional cases
        ↓
Higher-capability model

This is model routing.

---

15 Tiered Routing — A Very Important CCAR-P Pattern

Suppose 100,000 requests arrive.

Historical evaluation shows:

• 75% simple;
• 20% moderate;
• 5% difficult.

Instead of:

100% → Highest-capability model

use:

Request
   ↓
Classification / complexity estimation
   ↓
┌────────────┬──────────────┬───────────────┐
│ Simple     │ Normal       │ Complex       │
│ 75%        │ 20%          │ 5%            │
↓            ↓              ↓
Fast/cheap   Balanced       High capability
model        model          model

This can give you:

• high aggregate quality;
• lower total cost;
• faster average response;
• targeted use of expensive reasoning.

Exam clue

If a scenario says:

“Most requests are simple, but a small percentage require sophisticated reasoning.”

consider routing, not forcing one model onto everything.

---

16 But Routing Has a Hidden Requirement

A routing architecture only works if the router can reliably identify difficult cases.

Suppose the cheap model incorrectly labels hard requests as simple.

Then your architecture sends the cases that most need capability to the weakest model.

Therefore routing itself needs evaluation.

Measure:

• routing accuracy;
• false-simple rate;
• escalation rate;
• quality per route;
• total cost;
• end-to-end latency.

That is professional architecture thinking.

---

17 Cost Per Call Is Often the Wrong Metric

This is another likely exam area.

Imagine:

Model A

• cost/request = $0.01
• average attempts = 2.5

Model B

• cost/request = $0.02
• average attempts = 1.0

Which is cheaper?

Not enough information until you calculate cost per completed business task.

This matches the broader workbook principle:

measure outcomes at the unit the business cares about, not merely individual model calls.

Consider:

Cost per resolved case =
    model calls
  + retries
  + retrieval/tool costs
  + escalation
  + human review

A nominally expensive model can produce lower total system cost.

---

18 Model Selection and High-Stakes Systems

A common mistake is:

High stakes = always choose the biggest model.

That’s too simplistic.

High stakes usually mean:

1. stronger quality requirements;
2. stronger evaluation;
3. grounding;
4. deterministic controls where appropriate;
5. human oversight;
6. stronger auditability.

A larger model may be part of that architecture, but model capability does not replace governance.

Example: loan underwriting

Do not reason:

“Use Fable/Opus because credit decisions are important.”

Reason:

Use Claude for appropriate language/reasoning tasks, while policy enforcement and final consequential decisions remain controlled according to business/regulatory requirements.

Model selection and decision authority are separate questions.

---

19 Current Model Features Can Affect Architecture

As current context—not something I would prioritize memorizing for the exam—Anthropic’s models also differ in capabilities such as adaptive/extended thinking, context size, and maximum output length. For example, Anthropic currently lists adaptive thinking for Fable 5, Opus 5, and Sonnet 5, while Haiku 4.5 uses extended thinking rather than adaptive thinking.

The architectural lesson is:

Check whether the candidate model supports the feature your design requires.

Do not choose a model merely because its intelligence tier sounds appropriate.

This can apply to:

• context capacity;
• thinking capabilities;
• output limits;
• supported platform;
• tool/API feature compatibility.

Anthropic now exposes model capability and token-limit information programmatically through its Models API as well.

---

20 Model Availability Is an Architectural Constraint

Enterprise architecture may introduce another dimension:

Where must the model run?

Current models can be available across Claude API and cloud-provider platforms, but availability, regional endpoints, and lifecycle can differ. Anthropic’s current documentation describes Claude models across the Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry, and Anthropic’s AWS offering.

This matters when the scenario includes:

• data residency;
• approved cloud provider;
• procurement constraints;
• regional routing;
• enterprise platform standards.

Example

The technically ideal model is irrelevant if corporate policy only permits an approved deployment environment where that version isn’t available.

Architectural fit includes operational fit.

---

21 Do Not Select Models from Benchmark Scores Alone

Benchmarks are useful evidence.

They are not your acceptance test.

Suppose Model X scores higher on a general reasoning benchmark.

Your application is specialized insurance claim extraction.

You still need to evaluate:

Model X + your prompts + your context + your representative data + your tools.

The official preparation guidance explicitly expects candidates to practice model-selection and architectural trade-offs rather than merely memorize platform facts.

Strong CCAR-P answer

Evaluate candidate models against a representative workload and select the least costly/fastest configuration that satisfies the defined quality and risk thresholds.

---

22 A Practical CCAR-P Model Selection Framework

Use this during scenario questions.

Step 1 — Identify the actual task

Is it:

• classification?
• extraction?
• summarization?
• coding?
• reasoning?
• tool orchestration?
• long-running agentic planning?

Step 2 — Identify the binding constraint

Look for:

• accuracy;
• cost;
• latency;
• context;
• volume;
• risk;
• availability.

Usually one or two dominate.

Step 3 — Establish the quality floor

Ask:

What accuracy or task-success level must the solution meet?

Not:

Which model is smartest?

Step 4 — Choose candidate models

Start with the lowest-complexity model reasonably capable of meeting the requirement.

Then evaluate upward where necessary.

Step 5 — Test using representative workload

Include:

• normal cases;
• edge cases;
• ambiguous cases;
• difficult cases;
• production-like context.

Step 6 — Measure system-level metrics

Evaluate:

Quality + latency + cost + safety + reliability

—not model accuracy alone.

Step 7 — Consider routing

If workload difficulty varies substantially:

route rather than overprovision.

Step 8 — Define escalation

Example:

Haiku-class
   ↓
confidence / complexity threshold
   ↓
Sonnet-class
   ↓
exception / very hard case
   ↓
Opus/Fable-class or Human

Step 9 — Revalidate on model change

A model upgrade is a behavioral change, not merely infrastructure maintenance.

Re-run evaluation before rollout.

---

23 Quick Decision Matrix

Workload	Likely architectural starting point	Why
High-volume intent classification	Fast/low-cost model	Simple + latency/cost sensitive
Metadata extraction	Fast/low-cost model	Structured and verifiable
Customer-support RAG	Balanced model	Reasoning + speed + volume
Enterprise report generation	Balanced model	Strong synthesis without frontier cost
Standard coding assistant	Balanced-capability model	Quality/latency compromise
Difficult architecture analysis	Higher-capability model	Reasoning quality dominates
Long-horizon autonomous coding	High/frontier capability	Planning and sustained reasoning
Mixed easy + hard requests	Tiered routing	Avoid overpaying for easy cases
Huge changing knowledge corpus	Appropriate model + RAG	Model size alone doesn’t solve knowledge freshness
High-stakes decision	Strong model if justified + governance	Capability doesn’t replace controls

The word starting is deliberate. Evaluation determines the final decision.

---

24 Five Common CCAR-P Exam Traps

Trap 1 — “Use the most capable model for maximum accuracy”

Why it sounds good

More capable models often perform better on hard reasoning.

Why it can be wrong

The workload may be:

• simple;
• high-volume;
• latency-critical;
• already above its quality threshold with a smaller model.

Better reasoning

Use capability proportional to task complexity.

Trap 2 — “Always select the cheapest model first”

Also wrong.

Saving model cost while causing:

• retries;
• human escalation;
• failed tasks;
• user abandonment

can increase total business cost.

Better metric

Cost per successfully resolved task.

Trap 3 — “Large context window means use all available context”

Wrong.

Context capacity ≠ useful context.

Prefer:

relevant + authoritative + current + well-structured context.

Trap 4 — “Upgrade the model whenever quality degrades”

Wrong diagnosis when quality:

• deteriorates only later in long sessions → context problem;
• deteriorates after corpus refresh → retrieval problem;
• produces malformed structure → prompt/schema problem.

Upgrade only when evidence points to a capability mismatch.

Trap 5 — “One application should standardize on one model”

Operational simplicity is useful, but not when task requirements differ dramatically.

A production architecture can deliberately use:

different models for different steps.

The workbook specifically emphasizes that model selection can be made per step rather than per system.

---

25 High-Yield Exam Signals

Memorize this mapping.

Scenario phrase	Think
“millions of requests”	Cost / throughput
“real-time”	Latency
“straightforward classification”	Smaller/faster model
“deep multi-step reasoning”	Higher capability
“most cases simple, few difficult”	Routing
“large corpus changes weekly”	Retrieval/RAG before model upgrade
“approaching context limits”	Context engineering
“good initially, worse after many turns”	Context issue
“wrong immediately on hard cases”	Possible model mismatch
“strict quality threshold”	Evaluate candidate models
“high stakes”	Capability + controls + human oversight
“budget per transaction”	Unit economics
“same model everywhere”	Consider per-step selection

---

26 A Helpful Mental Model: Quality Floor, Not Capability Ceiling

This is worth memorizing.

Imagine model capability as a staircase.

Highest capability
      ↑
      │       Frontier
      │       ─────────
      │
      │       Advanced
      │       ─────────
      │   ← Required quality threshold
      │
      │       Balanced
      │       ─────────
      │
      │       Fast
      │       ─────────
      ↓
Lowest capability

Your goal is generally:

Choose the most economical configuration that sits safely above the required quality threshold.

Not:

Climb to the top because the top exists.

This is the essence of architectural model selection.

---

27 Worked Example 1 — Customer Support

Requirement

An online retailer handles 500,000 requests/day.

• 70% simple FAQs
• 20% order-specific questions
• 10% complex complaints
• user expects quick response
• expensive human escalation

Weak architecture

Every request → Most capable Claude model

High quality, unnecessary cost.

Better architecture

Request
   ↓
Fast classification
   ↓
┌───────────┬──────────────┬───────────────┐
Simple      Normal         Complex
↓           ↓              ↓
Fast model  Balanced       Higher-capability
            model          model / human

Why this is better

It aligns model capability to request complexity.

What must be tested?

Not merely model accuracy.

Measure:

• classification/routing accuracy;
• resolution rate;
• escalation rate;
• latency;
• total cost per resolved ticket.

---

28 Worked Example 2 — Enterprise Research Assistant

Requirement

Users ask complex questions over:

• internal policies;
• contracts;
• technical documents;
• changing regulatory material.

Incorrect conclusion

“Use the largest model because there is lots of information.”

Better decomposition

There are actually two questions:

1. Which information should Claude receive?

→ retrieval/context engineering.

2. How difficult is reasoning over that information?

→ model selection.

A high-capability model does not compensate for bad retrieval.

---

29 Worked Example 3 — Loan Document Extraction

Task:

• extract name;
• income;
• term;
• interest rate;
• collateral;
• applicant ID.

Output is structured and independently verifiable.

A frontier model may be unjustified.

But suppose the requirement changes:

Analyze inconsistent evidence across 20 supporting documents and identify material contradictions requiring underwriting review.

Now the reasoning complexity changes.

Same business domain. Different model requirement.

This is exactly how CCAR-P scenarios can hide the real decision inside business terminology.

---

30 Worked Example 4 — Coding

Consider two tasks.

Task A

Add unit tests to a simple utility function.

Lower reasoning requirement.

Task B

Analyze a multi-repository microservice architecture, identify a race condition causing intermittent production failures, develop a safe remediation plan, implement changes, and verify regressions.

Higher reasoning requirement.

“Coding” alone does not determine the model.

Task complexity does.

---

31 Worked Example 5 — High-Stakes Medical Application

A clinical assistant summarizes patient history for physician review.

Requirements:

• quality is important;
• physician remains responsible;
• response is interactive;
• many requests/day.

Don’t automatically conclude:

highest model because healthcare.

Instead evaluate:

• quality threshold;
• latency;
• cost;
• context;
• error types;
• human review process.

A balanced model might pass all requirements.

If difficult cases need deeper reasoning, add escalation.

Key distinction

Business risk influences the required quality/control threshold. It doesn’t mechanically dictate the model name.

---

32 Model Changes Must Trigger Re-Evaluation

This connects Domain 2 directly with Domain 4.

Suppose you migrate:

Model A → Model B

because B is:

• cheaper;
• faster;
• newer.

Do not assume behavioral equivalence.

Run:

Existing evaluation dataset
        ↓
Old Model      New Model
   ↓               ↓
Quality          Quality
Latency          Latency
Cost             Cost
Safety           Safety
        ↓
Compare
        ↓
Staged rollout

Anthropic’s platform evolves rapidly—2026 alone has included multiple model launches, retirements, context changes, and feature updates.

For the exam:

Model change = system behavior change = re-evaluation event.

---

33 How the Practice Exams Frame This Topic

Both supplied 63-question practice exams contain essentially the same Domain 2 model-selection pattern:

A team must choose a Claude model while considering reasoning ability, response speed, context capacity, and cost together.

The intended answer is that model choice is a multi-factor architectural trade-off matched to workload complexity, quality requirements, latency, and budget.

That tells us something important about probable CCAR-P item design:

Don’t expect

“What model has feature X?”

as the primary cognitive challenge.

Expect something closer to

“Given these business constraints, which model-selection strategy is architecturally justified?”

That is consistent with the official certification positioning: candidates are architects expected to select appropriate models and make production trade-offs.

---

34 Five CCAR-P-Style Practice Questions

Question 1 — Straightforward high-volume workload

A retailer processes 3 million incoming product reviews per month. Claude only needs to classify each review into six predefined categories. Tests show a fast lower-cost Claude model meets the required accuracy threshold. The architecture team proposes using the most capable model anyway to maximize quality.

What is the best architectural decision?

A. Use the most capable model because production applications should maximize model intelligence. B. Use the fast lower-cost model because it already meets the quality requirement and better satisfies the workload’s scale, latency, and cost constraints. C. Use both models for every request and compare the results. D. Allow users to select which model processes each review.

Correct answer: B

Why?

The requirement is already satisfied by the smaller model. Additional capability has no demonstrated business value but adds cost and potentially latency.

Why the others are wrong

A — optimizes capability rather than the system requirement.

C — doubles processing without a justified reliability requirement.

D — exposes an architectural concern to users who should not have to make it.

Exam concept

Choose the least expensive/fastest model that reliably clears the required quality bar.

Question 2 — Mixed workload complexity

A customer-support platform handles 100,000 requests daily. Approximately 85% are straightforward, while 15% require substantial reasoning over several policies. Using the highest-capability model for every request meets quality requirements but exceeds the operating budget.

Which design is BEST?

A. Switch every request to the cheapest model. B. Keep the highest-capability model for all requests and accept the cost. C. Route straightforward requests to a faster lower-cost model and escalate difficult requests to a higher-capability model, validating the routing strategy with an evaluation set. D. Reduce the system prompt until the current model fits the budget.

Correct answer: C

Why?

The workload has heterogeneous difficulty. Tiered routing lets the architecture allocate expensive reasoning only where it creates value.

The important second half is validate the router.

Why not A?

Some difficult requests genuinely require additional reasoning.

Why not B?

It unnecessarily overprovisions 85% of requests.

Why not D?

Prompt reduction may optimize tokens but doesn’t address the fundamental mismatch between request complexity and model capability.

Exam concept

Different task complexity → different model tiers → routing can optimize total economics.

Question 3 — Diagnose before upgrading

A long-running enterprise assistant gives accurate answers during the first several turns. Later in the session it starts repeating information and contradicting earlier decisions. The team proposes moving every request to the highest-capability Claude model.

What should the architect do FIRST?

A. Upgrade the model because contradiction proves inadequate intelligence. B. Investigate context growth and context-management strategy before changing models. C. Increase temperature. D. Add another model to independently validate every answer.

Correct answer: B

Why?

The time-dependent degradation is a strong context-management signal.

If capability were fundamentally insufficient, poor results would typically appear on the difficult task from the start.

The practitioner workbook explicitly highlights this diagnostic distinction: systems that begin well and degrade throughout a run often have a context problem rather than a model problem.

Exam concept

Diagnose model mismatch separately from prompt, retrieval, and context failures.

Question 4 — Cost per resolved task

A cheaper Claude model costs 40% less per API call, but evaluation shows that customer-support requests require substantially more retries and human escalations with that model.

Which metric should primarily guide the final model decision?

A. API cost per individual call B. Number of input tokens C. Cost per successfully resolved customer-support task, including retries and escalation D. Benchmark score of the model

Correct answer: C

Why?

Architecture should optimize the business unit of work.

A cheaper call does not imply a cheaper solution.

Total cost includes:

• model calls;
• retries;
• extra tool calls;
• human escalations;
• failure handling.

Exam concept

Measure system economics, not model pricing in isolation.

Question 5 — High-stakes workload

A financial-services company is building an assistant that analyzes complex loan documentation. The architecture team argues that selecting the most capable Claude model is sufficient to make automated final lending decisions safe.

What is the BEST response?

A. Agree because higher model intelligence eliminates model risk. B. Agree if temperature is set to zero. C. Use model capability appropriate to the analysis task, but treat governance, deterministic policy enforcement, evaluation, and accountable human decision-making as separate architectural controls. D. Use the cheapest model because human review eliminates the need for model quality.

Correct answer: C

Why?

Model capability and system governance are separate architectural dimensions.

A stronger model does not eliminate:

• hallucination;
• nondeterminism;
• policy requirements;
• audit obligations;
• accountability.

Exam concept

Do not use model capability as a substitute for system controls.

---

35 Two Better Exercises for This Topic

You asked to ignore the site’s “Build Exercise.” The referenced CCAR-F lesson follows a good pattern—concept → traps → scenario → exercise—but for CCAR-P model selection, architecture exercises are more useful than coding exercises.

Exercise 1 — The Model Selection Board

Scenario

You are architecting four Claude workloads:

Workload	Volume	Quality requirement	Latency	Complexity
Email classification	2M/month	Medium-high	<2 sec	Low
Executive report generation	20K/month	High	<20 sec	Medium-high
Architecture review	500/month	Very high	<2 min	Very high
Support assistant	1M/month	High	<5 sec	Mixed

Your task

For each workload write:

1. Binding constraint
2. Initial model class
3. Why a larger model is unnecessary—or necessary
4. Why a smaller model may fail
5. Evaluation metric
6. Escalation/routing rule
7. Condition that would cause you to change the decision

Expected reasoning

Email classification

→ fast/low-cost candidate.

Executive reports

→ balanced candidate.

Architecture review

→ higher-capability candidate.

Support

→ likely routing rather than one-model-for-all.

Why this exercise is valuable

It trains the exact skill:

justify a choice from constraints instead of associating model names with industries.

Exercise 2 — Optimize a Production Architecture

Initial system

1,000,000 requests/month
          ↓
Highest-capability model
          ↓
$X monthly cost
          ↓
98.5% task success

Analysis shows:

• 65% requests are simple;
• 25% moderate;
• 10% difficult.

You have three model candidates:

Candidate	Simple	Moderate	Difficult	Relative cost
Fast	98%	86%	61%	1×
Balanced	99%	96%	84%	2×
Advanced	99%	98%	96%	5×

Design a new architecture

A good solution might resemble:

Incoming request
       ↓
Complexity Router
       ↓
┌─────────────┬──────────────┬───────────────┐
│ Simple      │ Moderate     │ Difficult     │
│             │              │               │
│ Fast model  │ Balanced     │ Advanced      │
└─────────────┴──────────────┴───────────────┘
       ↓
Validation / confidence check
       ↓
Escalate when necessary

Then calculate:

• expected quality;
• model cost;
• escalation rate;
• latency;
• false-routing risk.

Final question

Under what measurable condition would you abandon routing and return to one model?

That final question makes the exercise architect-level rather than merely cost optimization.

---

36 What You Should Memorize

For maximum exam value, memorize these principles rather than model specifications:

Rule 1

Model selection is multi-factor.

Reasoning + latency + cost + context + volume + quality.

Rule 2

There is no universally best model.

There is a best fit for the workload.

Rule 3

Don’t always choose the largest.

Unused capability is unnecessary cost/latency.

Rule 4

Don’t always choose the cheapest.

Retries and failures can make it more expensive.

Rule 5

Model selection can be per step.

One application can deliberately use several models.

Rule 6

Mixed difficulty is a routing signal.

Cheap/fast for simple work; escalate genuinely hard work.

Rule 7

Large context does not fix poor context engineering.

Capacity ≠ relevance.

Rule 8

Diagnose before upgrading.

Prompt, retrieval and context problems are not automatically model problems.

Rule 9

Evaluate on your workload.

Generic benchmark superiority is insufficient.

Rule 10

Optimize cost per business outcome.

Not merely cost per API call.

Rule 11

High capability does not replace governance.

Model choice, authorization, validation and human oversight are separate decisions.

Rule 12

Model change means re-evaluation.

Never assume a replacement model is behaviorally identical.

---

37 One-Minute Exam Cheat Sheet

If you see…

Simple + high-volume + latency sensitive → fast/lower-cost model.

Typical enterprise knowledge work → balanced model.

Very difficult reasoning / complex agents → higher-capability model.

Extreme long-horizon work where incremental intelligence is valuable → consider frontier capability.

Mostly simple + some very difficult → tiered routing.

Huge knowledge corpus → think RAG/context engineering, not automatically bigger model.

Quality deteriorates during long sessions → context management.

Model is too weak from the beginning on difficult reasoning → possible model mismatch.

Cheaper model needs retries → calculate cost per resolved task.

High-stakes scenario → capability plus evaluation/governance/human oversight, not capability alone.

---

38 Final Exam Takeaway

The professional-level question is rarely:

“Which Claude model is best?”

It is:

“Given this workload’s quality requirement, complexity, latency SLA, context needs, scale, risk, and budget, which model—or routing strategy—provides sufficient capability at the best system-level trade-off, and how will you prove that choice with evaluation?”

If you approach every CCAR-P model-selection question that way, most distractors become easy to eliminate.

The official exam guide supports exactly this architecture-oriented interpretation: candidates must select appropriate Claude models based on trade-offs, while the overall role requires balancing cost, latency, performance, safety, and maintainability across production AI solutions.

The supplied practitioner workbook and both practice exams reinforce the same exam pattern, while current Anthropic documentation confirms why specific model names/prices should remain secondary to the trade-off framework: the model lineup continues to evolve rapidly.