D3 · Product and Model Selection

This domain is roughly 7 of 60 items. It tests whether you can pick the right tool for the job across three dimensions: the product surface (chat, Projects, artifacts, research, connectors, Claude Code, and so on), the plan tier (Free through Enterprise), and the model (Haiku, Sonnet, Opus, Fable). The recurring judgment is matching capability and cost to the stakes of the task – neither over-buying nor under-buying.

Learning objectives

By the end of this page you should be able to:

Identify the right product surface for a given task.
Distinguish the plan tiers conceptually and what each unlocks.
Choose among Haiku 4.5, Sonnet 5, Opus 5 and Fable 5.1 by cost, speed and quality.
Align model choice with the stakes of a task.
Reason about context-window limits and memory: when to start a new chat, summarise, or persist to a Project.
Decide when extended / adaptive thinking helps.

3.1 The product surfaces

Claude is not one thing – it is a family of surfaces. The exam expects you to map a need to the right one.

Surface	What it is	Reach for it when…
claude.ai chat	The core conversational interface	Ad-hoc questions, drafting, analysis in a single thread
Projects	A workspace with custom instructions + knowledge files + memory shared across chats	The same context (docs, tone, rules) recurs across many chats
Artifacts	A side panel for standalone deliverables you iterate on	Documents, tables, charts, mock-ups, scripts you will revise
Research mode / web search	Multi-step web research with citations	You need current, sourced synthesis beyond model knowledge
Memory	Cross-session recall of facts about you/your work	You want Claude to remember preferences and context over time
Skills	Reusable, packaged procedures Claude can invoke	A repeatable multi-step task you or your team run often
Code execution / analysis tool	Runs code to compute, analyse data, make charts	Reliable arithmetic, data crunching, chart generation
Claude Desktop	Desktop app, supports local connectors	Desktop workflows, local file/connector access
Claude for Chrome	Browser extension that acts in the browser	In-context help on web pages (with permission)
Mobile apps	iOS/Android	On-the-go chat, capture, voice
Claude Code	Terminal/IDE agent for developers	Software engineering tasks – escalate to Developers
Connectors	Links Claude to Drive, Gmail, Calendar, Slack, GitHub, etc.	Bringing your own tools’ data into a chat

Exam signal

“The same background applies to every chat” → Project. “Iterate on a deliverable” → Artifact. “Needs current, sourced facts” → Research mode. “Reliable arithmetic on a dataset” → analysis/code tool. “Build an integration / write software” → escalate to Claude Code / Developers.

3.2 Projects vs. a plain chat

A Project bundles reusable context so you do not re-paste it every time:

Custom instructions – a persistent system-level brief (role, tone, format defaults, do/don’t).
Knowledge files – documents every chat in the Project can draw on.
Project memory – accumulated context across the Project’s chats.

Use a plain chat for one-off tasks. Use a Project when the same instructions or documents recur, when a team needs a shared configuration, or when you want consistency across many conversations. (Configuration detail is D5.)

3.3 Plan tiers (conceptual)

You do not need to memorise prices, but you must know what each tier is for.

Tier	Who it is for	Conceptually unlocks
Free	Casual individual use	Basic chat, limited usage, smaller model access
Pro	Individual power users	Higher usage, Projects, more model access, research
Max	Heavy individual users	Much higher usage limits, priority access
Team	Small–mid organisations	Central billing, collaboration, shared workspace, admin controls
Enterprise	Large organisations	SSO, audit logs, data-retention controls, larger context, enterprise governance

Governance follows the tier

Enterprise and Team plans are where organisational controls live – SSO, audit logs, retention settings, and the commercial guarantee that your data is not used to train models. This connects directly to D6.

3.4 The model lineup

Four current models, chosen by the cost / speed / quality trade-off.

Model	Relative cost	Relative speed	Best for
Haiku 4.5	Lowest	Fastest	High-volume, routine, latency-sensitive tasks; simple classification, quick drafts
Sonnet 5	Moderate	Fast	The everyday default – best balance of speed and intelligence for most business work
Opus 5	High	Slower	Complex reasoning, high-stakes analysis, hardest agentic/coding work
Fable 5.1	Highest	Slowest	The most capable tier, for the most demanding tasks (thinking always on)

Rules of thumb:

Default to Sonnet for general knowledge work.
Drop to Haiku for routine, repetitive, high-volume, or speed-critical tasks to save cost and time.
Step up to Opus/Fable only when the task is genuinely hard or high-stakes and the extra quality is worth the cost and latency.

Two symmetrical mistakes

Using the most expensive model for everything wastes money and time; using the cheapest model for high-stakes work risks quality where it matters most. Both are wrong exam answers. Match the model to the stakes.

3.5 Aligning model choice with stakes

Ask two questions: How hard is the reasoning? and How costly is a mistake? If both are low, go cheap and fast. If either is high, step up.

3.6 Context windows and memory

A context window is how much text (conversation + documents) the model can consider at once. Current models have very large windows, but they are not infinite, and very long chats can still drift or lose earlier detail.

Three tools for managing long-running context:

Situation	Best move
A chat has grown long and Claude is losing earlier detail or drifting	Start a new chat with a clean, consolidated brief
You want to carry forward only the conclusions	Ask Claude to summarise the thread, then paste the summary into a new chat
The same context must apply to many future chats	Persist it to a Project (custom instructions + knowledge)
You want Claude to remember preferences over time	Use Memory

Exam signal

“The conversation is very long and answers are drifting / forgetting” → start a new chat (optionally after summarising). “This context recurs across many chats” → Project. Distinguish a one-time carry-forward (summarise → new chat) from a permanent need (Project / Memory).

3.7 Extended / adaptive thinking

Current models can think before answering – working through a problem internally before producing the final response. On today’s models this is adaptive: the model decides how much thinking a task needs, and you can turn extended thinking on for harder problems.

For multi-step reasoning, complex analysis, hard planning, tricky trade-offs – tasks where a careful chain of reasoning improves the answer. It costs more time (and tokens) but improves quality on genuinely hard problems.

As a business user you experience thinking as a toggle/option in the interface, not as an API parameter. Match it to task difficulty the same way you match the model.

3.8 A selection workflow

What kind of output? Deliverable to iterate → artifact. Machine data → structured output. Current facts → research mode.
Does context recur? Yes → Project. No → plain chat.
How hard / high-stakes? Route model: Haiku → Sonnet → Opus/Fable.
Multi-step reasoning? Turn on extended thinking.
Is it software / an integration / an autonomous agent? → escalate to Developers/Architects; not a business-user chat task.

3.9 Feature-to-need decision table

The exam loves stems that describe a need in plain business language and ask which feature fits. Memorise the mapping and its one-line trigger.

The need in the stem…	Correct feature	Why (and the tempting wrong pick)
“The same background/tone/docs apply to many chats”	Project	Shared context. Wrong: pasting each time; Memory (personal, not curated).
“Run this standard multi-step procedure repeatedly”	Skill	Reusable procedure. Wrong: a Project (holds context, not steps).
“Iterate on a document/deliverable and keep versions”	Artifact	Persistent, versioned deliverable. Wrong: inline chat.
“Need current, sourced facts beyond the model’s knowledge”	Research mode / web search	Sourced synthesis. Wrong: plain chat on built-in knowledge.
“Reliable arithmetic / charts over a dataset”	Code / analysis tool	Executes, not estimates. Wrong: research mode; plain chat.
“Remember my preferences across sessions”	Memory	Personal cross-session recall. Wrong: a knowledge file.
“Bring my Drive/Gmail/Slack data into the chat”	Connector	Reaches your tools’ data. Wrong: pasting exports manually.
“Work with local files / desktop apps”	Claude Desktop	Local connector access. Wrong: mobile app.
“Help me on the web page I’m viewing”	Claude for Chrome	In-page browser assistant. Wrong: Desktop.
“Capture an idea / quick chat on the go”	Mobile app	On-the-go surface. Wrong: Desktop.
“Build software / an unattended integration”	Escalate to Claude Code / Developers	Beyond the business-user ceiling.

Exam signal

Two feature pairs are the most-tested confusions: Project vs. Skill (context vs. procedure) and research mode vs. code/analysis tool (sourced web facts vs. executed data work). Read the stem for “recurring context” vs. “repeatable steps”, and “current sourced facts” vs. “reliable numbers on a dataset”.

3.10 Surface selection across devices and clients

Business users reach Claude through several clients; the right one depends on where the work and the data live.

Client	Best for	Data / access note
claude.ai (web)	General chat, Projects, artifacts, research	Data governed by your plan tier
Claude Desktop	Local files, local connectors, desktop workflows	Can reach local resources you grant
Claude for Chrome	Acting on the current web page, in-context help	Acts in the browser with per-site permission
Mobile (iOS/Android)	Capture, quick questions, voice, on the go	Same account/plan governance
Claude Code (terminal/IDE)	Software engineering	Developer territory – escalate

Same governance, different surface

Switching client does not change your plan’s governance. Confidential-data rules (D6) and the no-training guarantee follow the account/plan, not the app you happen to open.

3.11 Common misconceptions

Misconception	Reality	Why it matters on the exam
“Use the most capable model for everything to be safe.”	Over-buys cost and latency on routine work.	Over-engineered distractor; match model to stakes.
“Use the cheapest model to save money everywhere.”	Under-buys quality on hard/high-stakes work.	Constraint-blind distractor.
“A Project and a Skill are interchangeable.”	Project = shared context; Skill = reusable procedure.	The most-tested feature confusion.
“Research mode is for any factual question.”	It is for current, sourced facts; use the analysis tool for data/maths.	Research-vs-analysis distractor.
“A bigger model remembers longer conversations.”	Long chats drift regardless of tier; reset/summarise.	Model-as-context-fix distractor.
“Memory and a Project’s knowledge are the same.”	Memory = personal recall; knowledge = curated shared docs.	Personal-vs-shared scope item.
“Extended thinking always improves the answer.”	It adds latency/cost with little gain on trivial tasks.	Setting-as-fix distractor.
“A business user can build the unattended integration in chat.”	Automation without a human per run escalates to Developers.	Escalation-boundary item.

3.12 Scenario walkthrough – choosing tools for a market-entry study

Scenario. A strategy associate must produce a market-entry recommendation. The work has three parts: (1) a current, sourced view of a regulatory change this quarter; (2) a reliable financial model summing and comparing five scenarios from a spreadsheet; (3) a polished 2-page brief the team will revise several times. The associate also runs this study for a new market every month. A colleague suggests “just use Opus for all of it in one long chat”.

Expert reasoning trace.

Split by need, not by model. Three different needs map to three different surfaces; a single long chat on one model conflates them and invites drift. Reject “Opus for everything in one chat”.
Part 1 – current sourced facts → research mode with citation verification (D2). Built-in knowledge may be stale, so plain chat is rejected here.
Part 2 – reliable arithmetic over a spreadsheet → the code/analysis tool, which executes rather than estimates. Research mode (wrong: it is for web facts) and plain chat (wrong: LLM arithmetic is unreliable) are rejected.
Part 3 – iterated 2-page brief → an artifact, which persists and versions the deliverable. Inline chat is rejected for a repeatedly-revised document.
Model choice by stakes. The synthesis/recommendation is high-stakes and reasoning-heavy → step up to Opus (or Fable) with extended thinking for that step, then verify figures. The routine parts do not need the top tier.
Recurring monthly → persist the instructions, the criteria and the document locations in a Project so each month starts configured; if the report follows a fixed procedure, capture it as a Skill.
Context hygiene. Keep the parts in focused chats; if a synthesis chat grows long and drifts, summarise and reset rather than upgrading the model.

Exam-correct decision: research mode for the sourced regulatory view, the analysis tool for the financial model, an artifact for the iterated brief, top-tier model + extended thinking only for the hard synthesis, and a Project (plus a Skill) for the recurring monthly setup. Not one long Opus chat for everything.

Exam traps in this domain

Trap	Why it is wrong
“Use Opus for everything to be safe”	Over-buys cost and latency on routine work; match model to stakes
“Use Haiku for the board-level financial analysis to save money”	Under-buys quality where mistakes are costly
“Re-paste the same context into every chat”	Recurring context belongs in a Project
“Keep one giant chat forever”	Long chats drift and lose detail; start a fresh chat, summarising if needed
“Use research mode for arithmetic on a dataset”	Data crunching → analysis/code tool; research mode is for sourced web synthesis
“Build the API integration yourself as a business user”	Integrations/agents escalate to Developers/Architects
“Turn on extended thinking for a one-line rewrite”	Adds latency/cost with no benefit on trivial tasks
“Free plan is fine for enterprise governance needs”	SSO, audit logs and no-training guarantees live in Team/Enterprise
“A Project works when you need a repeatable procedure”	Repeatable procedures are Skills; Projects hold shared context
“Research mode for reliable arithmetic on a dataset”	Data/maths → analysis/code tool; research mode is for sourced web facts
“Switching to Claude Desktop changes the data governance”	Governance follows the account/plan, not the client app
“Memory replaces a Project’s curated knowledge files”	Memory is personal recall; shared curated docs belong in a Project

Practice questions

Each item states how many responses to select. Attempt before revealing.

Q1 · A marketing team runs the same brand-voice and product context through dozens of chats each week. What is the BEST way to manage this? (Select one)

A. Paste the context at the top of every new chat. B. Create a Project with custom instructions and knowledge files so every chat in it uses the context automatically. C. Use Memory to store it and hope it is recalled. D. Use the most expensive model so it ‘remembers’ better.

Answer: B. Recurring, shared context is exactly what Projects are for. Pasting each time (A) is error-prone and inconsistent. Memory (C) is for personal preferences, not a shared, curated knowledge base. Model tier (D) has nothing to do with persistence.

Q2 · A user must classify 5,000 short support messages into three buckets as fast and cheaply as possible. Which model is MOST appropriate? (Select one)

A. Fable 5.1 B. Opus 5 C. Sonnet 5 D. Haiku 4.5

Answer: D. High-volume, low-complexity, latency-sensitive classification is the archetypal Haiku task – fastest and cheapest. The higher tiers over-buy cost and speed for a simple, repetitive job.

Q3 · A CFO needs a complex, multi-step financial scenario analysis that will inform a board decision. Which choice BEST fits? (Select one)

A. Haiku 4.5 to save money, since it is just numbers. B. Opus 5 (or Fable 5.1) with extended thinking, then human verification of the figures. C. Sonnet 5 with extended thinking off. D. Research mode alone.

Answer: B. Hard reasoning + high stakes justifies the top model tier and extended thinking, followed by human verification (D2). Haiku (A) under-buys quality on high-stakes work. Research mode alone (D) does not do the reasoning/analysis.

Q4 · A conversation has run for two hours; Claude is now forgetting earlier decisions and contradicting itself. What is the BEST action? (Select one)

A. Keep going; the context window is large. B. Ask Claude to summarise the key decisions, then start a fresh chat with that summary as the brief. C. Switch to a cheaper model. D. Turn on extended thinking.

Answer: B. Long, drifting chats are best reset: capture the conclusions in a summary and continue in a clean context. Continuing (A) compounds drift. Model tier (C) and thinking (D) do not fix a bloated context.

Q5 · A team needs SSO, audit logs, and a guarantee that their data is not used for model training. Which tier is required? (Select one)

A. Free B. Pro C. Max D. Team or Enterprise

Answer: D. Organisational governance controls – SSO, audit logs, retention settings and the commercial no-training guarantee – live in Team/Enterprise plans. Individual tiers (A–C) do not provide org-level administration.

Q6 · A user needs a current, sourced summary of this quarter's regulatory changes in their industry. Which surface is MOST appropriate? (Select one)

A. A plain chat relying on the model’s built-in knowledge. B. Research mode / web search, then verify each citation. C. The code execution tool. D. An artifact.

Answer: B. Current, sourced facts beyond the model’s knowledge call for research mode with citations, which you then verify (D2). Built-in knowledge (A) may be stale or ungrounded. The code tool (C) computes, and artifacts (D) are a container, not a research capability.

Q7 · Which TWO tasks are best served by the code execution / analysis tool rather than plain chat? (Select two)

A. Summing and cross-tabulating a 2,000-row spreadsheet accurately. B. Generating a chart from a dataset. C. Writing a warm apology email. D. Brainstorming campaign names. E. Translating a paragraph.

Answer: A and B. Reliable arithmetic over many rows and chart generation are exactly what the analysis/code tool does well – it executes rather than estimates. Emails, brainstorming and translation are ordinary language tasks that do not need code execution.

Q8 · A business user wants to build an automated pipeline that reads incoming emails, extracts fields, and updates a database without a human in the loop. What is the CORRECT response? (Select one)

A. Do it themselves in claude.ai chat. B. Recognise this as an API/agent integration and escalate to Developers/Architects. C. Use a Project. D. Use research mode.

Answer: B. An autonomous, system-to-system integration is a developer/architect solution, not a business-user chat task – recognising this and escalating is the Associate’s job. A Project (C) or research mode (D) does not build automation, and doing it in chat (A) is not a real integration.

Q9 · For a quick one-line rewrite of a sentence, which setting is MOST appropriate? (Select one)

A. Opus 5 with extended thinking on. B. Sonnet 5 (or Haiku) with extended thinking off. C. Fable 5.1. D. Research mode.

Answer: B. A trivial rewrite needs neither a top-tier model nor extended thinking; a fast, moderate model with thinking off is appropriate. The heavier options add cost and latency for no gain.

Q10 · A user wants Claude to remember their preferred writing style and ongoing project context across future sessions. Which feature is designed for this? (Select one)

A. Artifacts B. Research mode C. Memory (and/or a Project for shared context) D. The code tool

Answer: C. Memory is built for cross-session recall of preferences and context; for shared, curated team context a Project is the counterpart. Artifacts (A), research (B) and the code tool (D) do not persist personal context.

Q11 · A user is iterating on a five-page proposal, revising it repeatedly. Which output surface is MOST appropriate? (Select one)

A. Inline chat messages. B. An artifact, which persists and versions the deliverable alongside the chat. C. A JSON blob. D. Research mode.

Answer: B. A deliverable revised repeatedly belongs in an artifact, which persists and is easy to iterate, copy and download. Inline text (A) is hard to manage across revisions; JSON (C) and research (D) do not fit a prose proposal.

Q12 · When is stepping up from Sonnet 5 to Opus 5 MOST justified? (Select one)

A. Whenever the user can afford it. B. When the task involves genuinely complex reasoning or the cost of a mistake is high. C. For all customer emails. D. Only for translation.

Answer: B. Step up when reasoning difficulty or the cost of error is high – that is when the extra quality earns its cost and latency. Affordability alone (A), routine emails (C) and translation (D) do not by themselves justify the top tier.

Q13 · A user needs to carry only the final conclusions of a long chat into a new, focused conversation. What is the BEST approach? (Select one)

A. Copy the entire two-hour transcript into the new chat. B. Ask Claude to produce a concise summary of the conclusions, then start the new chat with that summary. C. Create a Project just for this one-off. D. Keep using the old chat forever.

Answer: B. A one-time carry-forward is best handled by summarising the conclusions and starting fresh, keeping the new context lean. Pasting the whole transcript (A) reintroduces the bloat. A Project (C) is for recurring, not one-off, context; keeping the old chat (D) continues the drift.

Q14 · A team needs BOTH the same brand tone and reference docs across many chats AND a fixed weekly-report procedure run the same way each time. What combination is BEST? (Select one)

A. A single very long prompt reused each week. B. A Project for the shared tone/docs and a Skill for the repeatable report procedure. C. Memory only. D. A separate account per task.

Answer: B. Shared context is a Project’s job; a repeatable multi-step procedure is a Skill’s job – the two are complementary. A long prompt (A) and Memory (C) cover neither well; separate accounts (D) fragment the setup and governance.

Q15 · An associate needs to accurately sum and cross-tabulate a 4,000-row sales spreadsheet AND get a current, sourced view of a new regulation. Which TWO surfaces are correct, respectively? (Select two)

A. The code / analysis tool for the spreadsheet maths. B. Research mode / web search for the current sourced regulation. C. Plain chat on built-in knowledge for the regulation. D. Research mode for the spreadsheet totals. E. An artifact for the spreadsheet maths.

Answer: A and B. Reliable arithmetic over many rows is executed by the analysis tool; current sourced facts come from research mode with citation checks. Built-in knowledge (C) may be stale; research mode does not do arithmetic (D); an artifact (E) is a container, not a compute engine.

Q16 · A user wants Claude to act on the web page they are currently viewing to help fill a long form. Which client is MOST appropriate? (Select one)

A. The mobile app. B. Claude for Chrome, which can act on the current page with per-site permission. C. Claude Code. D. Research mode in the web app.

Answer: B. In-page assistance on the current site is exactly what the Chrome extension provides, with permission. The mobile app (A) is for on-the-go capture; Claude Code (C) is developer tooling; research mode (D) does web synthesis, not acting on the open page.

Q17 · A manager argues that switching from the web app to Claude Desktop will let them safely use confidential data that policy currently disallows. What is CORRECT? (Select one)

A. Correct; Desktop is inherently more secure. B. Incorrect; data governance follows the account/plan, not the client app, so the policy still applies. C. Correct; local apps bypass policy. D. Correct if they delete files afterward.

Answer: B. The plan/account determines governance and the no-training guarantee; changing client does not change what data is allowed. Desktop is not inherently more compliant (A, C), and deletion (D) does not change policy permissions.

Q18 · A one-line rewrite of a subject line is needed thousands of times per day at the lowest cost and latency. Which model AND thinking setting is MOST cost-effective? (Select one)

A. Opus 5 with extended thinking on. B. Haiku 4.5 with extended thinking off. C. Fable 5.1 with thinking on. D. Sonnet 5 with extended thinking on.

Answer: B. A trivial, high-volume, latency-sensitive task wants the cheapest fast model with no extra thinking. Opus/Fable (A, C) over-buy; extended thinking on Sonnet (D) adds cost and latency for no quality gain here.

Q19 · A user wants Claude to remember their personal tone preferences across future sessions, while their team wants a shared, curated set of policy docs available to everyone. Which pairing is CORRECT? (Select one)

A. Memory for the personal preferences; a Project’s knowledge files for the shared curated docs. B. A Project for the personal preferences; Memory for the shared docs. C. Both in Memory. D. Both in one personal Project.

Answer: A. Memory handles personal cross-session recall; curated shared documents belong in a Project’s knowledge. Swapping them (B), putting shared docs in personal Memory (C), or hiding shared docs in a personal Project (D) mis-scopes the need.

Q20 · A board-level scenario analysis is complex and high-stakes, but a routine batch of 5,000 ticket tags must also be produced cheaply. What is the BEST model strategy? (Select one)

A. Use one model for both to keep it simple. B. Use Opus/Fable with extended thinking for the board analysis, and Haiku for the ticket tagging. C. Use Haiku for both to save the most money. D. Use Opus for both to be safe.

Answer: B. Match each task to its stakes: top tier plus thinking for hard high-stakes reasoning, cheapest fast model for routine high-volume tagging. One model for both (A) mismatches at least one task; Haiku for the board analysis (C) under-buys; Opus for tagging (D) over-buys.

Key takeaways

Map the need to the surface: Project (recurring context), artifact (iterable deliverable), research mode (sourced facts), analysis/code tool (data & arithmetic), connectors (your tools’ data).
Escalate software, integrations and autonomous agents to Developers/Architects.
Default to Sonnet; drop to Haiku for routine/high-volume/fast work; step up to Opus/Fable for hard or high-stakes work.
Match both the model and extended thinking to task difficulty and stakes – avoid over-buying and under-buying.
Manage long context: start a fresh chat (summarising first) when a thread drifts; persist recurring context to a Project; use Memory for personal preferences.
Enterprise/Team tiers are where SSO, audit logs, retention controls and the no-training guarantee live.
Project vs. Skill = shared context vs. repeatable procedure; research mode vs. analysis tool = sourced web facts vs. executed data work.
Pick the client by where the work/data live (web, Desktop, Chrome, mobile); governance follows the account/plan, not the app.
Memory is personal recall; a Project’s knowledge files are curated shared documents – do not confuse the two.