Quick Reference: Domain 3 — Product and Model Selection

Read the task's shape before writing any prompt. Four questions settle it: one-off or recurring? Standalone, or needing the same standing context? Consumed once, or revised and reused? Answerable from supplied material, or gathered from outside sources?

On the exam: find the dominant signal first, then match it. Ordinary chat is a legitimate keyed answer, and the heaviest feature is not the safest. Re-pasting the same context chat after chat is a Project doing its job manually; Research adds nothing to a question the attached material already answers. Instructions and knowledge curation belong to Domain 5; format choice for a single output belongs to Domain 2.

The exam guide names three families, and the tested skill is reading which end of the trade-off a task needs:

• Haiku class: the fastest, lowest-cost tier, which Anthropic describes as built for high-volume, latency-sensitive tasks. Home ground: high volume, routine shape, simple transformation, spot-checked outputs.
• Sonnet class: the best combination of speed and intelligence; the balanced everyday default when neither signal set dominates.
• Opus class: the most capable reasoning tier, for ambiguity, contradiction, complex synthesis and judgement with consequences.

Never claim tier equivalence: the documentation nowhere says a lighter tier matches a heavier one on demanding work. The lighter tier's warrant is fitness for the task plus review.

The picker: click the model name in the chat interface; the change applies from the next response, and the picker shows what your account offers. Mid-conversation switching means the decision is never a one-off commitment.

Current line-up (checked 14 October 2026): the models overview lists Claude Fable 5.1 and Claude Opus 5.5 at the capable end, Claude Sonnet 5.5 as the balanced middle and Claude Haiku 5.5 as the fastest, with Fable 5, Opus 5, Sonnet 5 and Haiku 4.5 now legacy models. The guide's objective still names the Haiku-Sonnet-Opus triad, so answer exam items in tiers, not version numbers.

Every model choice spends three currencies; name the one the task needs and pay only that.

• Cost means the plan's usage allowance, not a per-use invoice. Named consumption factors: model choice, effort level, current conversation length, file attachment size.
• Volume multiplies cost and speed. Run once, tier differences are seconds; run hundreds of times, they decide whether the job finishes and the allowance survives. Bulk work goes to the fast tier with a sampled spot-check.
• Stakes multiply quality. One consequential output out-demands hundreds of routine ones; "it is only one letter" is true and irrelevant. High-stakes output gets the capable tier plus qualified human review, whatever model drafted it.
• Split mixed workloads by demands, not habit: bulk fast with sampled review, the hard core capable with proper review.

Three recurring wrong answers: maximum quality everywhere (waste compounds across volume), minimum cost everywhere (shallow output exactly where errors are expensive), and the escalation loop (re-running a vague brief on ever-heavier models; a vague brief fails at every tier, and fixing it is Domain 1's move).

A conversation holds a finite working space, and very long conversations approach the platform's length and usage limits. The official options there are practical: start a new conversation, or use a Project for larger amounts of information. Nothing official claims long chats degrade. The objective tests planning, not damage control.

• Restart when the work is done, when the chat has accumulated dead ends and superseded drafts, or when limits approach.
• Summarise before leaving: decisions, current state, open questions, then verify the summary against source records; it inherits every uncorrected error in the chat. The verified summary opens the fresh conversation.
• Persist what the next conversation needs: paste it in, re-attach the file, or store it in Project knowledge. A standing document that keeps being revised and shared lives as an artifact.

Read the stem's tense: organising work for what comes next is 3.4; diagnosing a chat already producing poor output is Domain 7. "A restart would lose all our context" is the marathon chat's argument, and it is false: the context worth keeping is exactly what the handover carries forward.

• Rollout (dated): cross-chat memory arrived on claude.ai on 11 September 2025 for Team and Enterprise plans, extended to Pro and Max from 23 October 2025; as of 30 September 2026 it is on by default for Free, Pro and Max plans, while on Team and Enterprise plans an owner decides whether memory is available, and it stays off for each member until that member turns it on.
• What memory holds: a set of individual topics covering your role, projects, preferences and ongoing work context. Context about you, not transcripts, drafts or attached documents. Each Project has its own memory, used alongside your memory from chats outside Projects but never another Project's.
• Chat search: on paid plans you can ask Claude to search past chats and reference relevant details. Prompted retrieval, not automatic carry-over.
• The boundary the exam tests: memory saves re-introducing yourself; it does not reliably transport a seating plan, an approved outline or a data file into a new chat. Two stale claims fail in opposite directions: that Claude cannot remember anything across chats, and that memory can be trusted to carry a working document. The dependable pattern for a specific working output is explicit persistence.