Domain 3: Product and Model Selection
12% of examChoose the right Claude product surface
Key Points
- Four surfaces: plain chat (quick one-offs, no persistent knowledge), Projects (persistent instructions + knowledge reused across chats), research mode (multi-source synthesis), Artifacts (separate editable window for substantial deliverables).
- Re-pasting the same background into every new chat signals you need a Project instead.
- An output that's a polished, reusable document rather than a chat reply signals an Artifact.
- Plain chat is fine for genuinely one-off, non-recurring work.
Decision Rules
When: A team keeps re-pasting the same brand guide/FAQ/policy into new chats
→Move that content into a Project's instructions/knowledge instead.
When: A question needs synthesis across multiple sources
→Use research mode rather than a single quick chat answer.
When: The output is a document meant to be refined and shared, not a chat reply
→Use an Artifact.
✗ Anti-Patterns to Reject
- Defaulting to plain chat for a workflow that reuses the same knowledge every time.
- Treating Artifacts as just longer chat messages instead of a distinct editable, shareable surface.
Differentiate the Haiku, Sonnet, and Opus models
Key Points
- Consistent ordering: Haiku (fastest, lowest cost) -> Sonnet (balanced, everyday workhorse) -> Opus (most capable, highest cost).
- Haiku fits high-volume, simple, latency-sensitive work; Sonnet fits most drafting/summarizing/analysis; Opus fits hard, high-value, multi-step reasoning.
- The fundamental tradeoff: more capability generally costs more and runs slower.
- There is no single 'best' model -- only the best fit for a specific task.
- A bigger model does not fix a badly written prompt.
Decision Rules
When: Asked to rank the models by cost/speed/capability
→Order them Haiku -> Sonnet -> Opus, from cheapest/fastest to costliest/most capable.
When: Tempted to pick the most capable model 'to be safe'
→Reject that instinct -- it wastes cost and latency budget on simple work.
When: Output quality is poor and the prompt is vague
→Fix the prompt first; don't assume a bigger model will compensate.
✗ Anti-Patterns to Reject
- "Always use the most capable model to be safe."
- Assuming a bigger model fixes a bad prompt.
Align model selection with the task's needs
Key Points
- Speed/cost-sensitive, simple reasoning -> a faster, lower-cost model (Haiku). Canonical exam example: high-volume short customer-reply drafts.
- Balanced everyday work (drafting, summarizing, analysis) -> Sonnet.
- Hard, high-value reasoning -> Opus, where the quality gain justifies the added cost/time.
- Every task carries an implicit cost/latency/quality budget; selection matches the model to that target rather than maximizing one dimension.
- Per-request latency compounds across a high-volume batch -- a slow top-tier model can bottleneck an entire workflow.
- Plan/pricing tier bounds which models and features are reachable at all.
Decision Rules
When: Generating a high volume of short, simple replies where speed/cost matter more than deep reasoning
→Pick the faster, lower-cost model (Haiku-class), not the top-tier one.
When: Considering a cost-cutting move
→Right-size the model rather than switching AI platforms or disabling product features.
When: A workflow processes many requests through a slow, top-tier model
→Recognize the latency compounds across the batch and can bottleneck the whole workflow.
✗ Anti-Patterns to Reject
- Switching AI platforms or disabling features to cut cost instead of right-sizing the model.
- Ignoring latency for high-volume tasks because each individual answer is higher quality.
Manage context limits and memory across a conversation
Key Points
- The context window is the finite total of instructions, uploaded material, conversation history, and the answer that a model can consider at once.
- In a very long conversation, early details get crowded out and quality can drift -- nothing 'broke.'
- Degraded output late in a long session is usually a context problem, not a model problem.
- Three moves: summarize (condense and continue), restart (fresh chat, carry over only what matters), persist (move durable context into a Project).
- A bigger context window is not free -- it can raise cost/latency, and curating what's relevant beats stuffing everything in.
Decision Rules
When: Output quality drops only near the end of a very long chat
→Diagnose a crowded context window, not a broken model -- summarize or restart.
When: The same durable instructions/reference material will be needed across many future chats
→Persist them in a Project rather than re-summarizing or re-pasting each time.
When: A conversation has drifted off-track and is cluttered
→Restart with a fresh chat, carrying over only what matters, rather than trying to salvage it with a summary.
✗ Anti-Patterns to Reject
- Blaming the model for worse answers deep in a long chat instead of managing context.
- Assuming a bigger context window is free and stuffing everything into it.