Domain 3 · lesson
Product and Model Selection
Learning goal: choose product capabilities and models based on the job, constraints, and evidence rather than habit or prestige. S12 S15 S16 S22 S23
Objective 3.1
Select appropriate product capabilities
Core content
Distinguish between features that provide information, organize work, create reusable deliverables, extend reasoning, or connect to external systems. Projects organize persistent work context and knowledge. Artifacts are reusable/iterable deliverables. Web search and Research retrieve current information; extended thinking allocates more reasoning, not new facts. Connectors provide access according to authentication and permissions. S12 S15 S16 S21
Applied example
A team maintaining policies over weeks benefits from a Project with curated knowledge and stable instructions. A one-off reusable dashboard or document can be an Artifact. A question about today's product release requires current retrieval, not merely longer reasoning over old notes.
Exam decision rule
Identify the missing capability: persistence, current information, structured deliverable, or system access. Do not select a feature simply because it sounds more advanced.
Objective 3.2
Differentiate model families
Core content
Learn model families as capability-speed-cost profiles rather than as a frozen list of exact prices or versions. Current Anthropic documentation should win over memory when versions change. S22 S23
Applied example
A high-volume classification step may favor a faster, less expensive model if it meets the quality threshold. A difficult synthesis with subtle reasoning may justify a more capable model if evaluation shows the difference matters.
Exam decision rule
Explain the trade-off and verify the currently available configuration. Memorizing last quarter's pricing is brittle knowledge.
Objective 3.3
Match model selection to cost, speed, and quality
Core content
Measure the complete workflow: quality threshold, retries, review time, latency, unit price, volume, and failure cost. The cheapest call is not necessarily the cheapest accepted result. S22 S09
Applied example
Model X costs less per call but requires repeated attempts and manual correction on 20% of cases. Model Y costs more per call but usually succeeds once. Compare cost per accepted outcome for the actual case mix.
Exam decision rule
Select the least expensive / fastest configuration that satisfies quality and risk requirements under representative tests. Escalate capability only when evidence indicates it is needed.
Objective 3.4
Manage context, memory, and limits
Core content
Distinguish active context, stored project knowledge, cross-conversation memory, and product usage limits. Context determines what is available in the current interaction. Memory provides continuity under product controls. Usage limits concern consumption. These are not interchangeable. S17 S18 S19 S25
Applied example
If Claude ignores a policy because the wrong file was supplied, increasing usage allowance does nothing. If a long conversation carries irrelevant history, curating context can improve focus. If a new chat lacks a correction made only in the old chat, persist the relevant instruction at the proper scope.
Exam decision rule
Diagnose which layer is missing or overloaded before changing models or prompts.