The problem
What the customer needs
- Pick a product fast enough that it doesn't become its own project, most decisions take under two minutes.
- Avoid overpaying for capability the task doesn't need, and avoid under-provisioning a task that genuinely needs more.
- Have a repeatable rule of thumb, not a fresh debate every time a new task shows up.
Why naive approaches fail
- Defaulting to whichever Claude product is already open in a browser tab, regardless of what the task actually requires.
- Assuming "the newest, most capable model" is always the right choice, the highest-capability tier is not free, and most tasks don't need it.
- Setting up a recurring, team-shared workflow inside a single throwaway chat, losing the work and the knowledge the moment the chat is closed.
- The chosen product matches the task's recurrence (one-off chat vs. persistent Project vs. embedded tool)
- The chosen model tier matches the task's complexity and stakes, not habit or hearsay
- The decision is made in under two minutes using a consistent rule of thumb
- The choice is revisited when the task's nature changes, not locked in forever
The system
What each part does
4 components, each owns a concept. Click any card to drill into the underlying primitive.
Task Profile
the three questions that actually matter
Before touching any product, answer three things about the task: is it one-off or recurring, does it need persistent shared knowledge, and what's the cost of a wrong or slow answer. These three answers, not preference, drive the rest of the decision.
Configuration
One-off + low stakes + no shared knowledge needed = a plain chat. Recurring + shared team knowledge = a Project. Embedded in a client-facing product or high-volume automated flow = an API-backed tool your organization built.
Product Tier Match
chat vs. Project vs. built tool
claude.ai chat is for one-off, exploratory, or personal-scope work. A Project is for recurring work that needs the same source documents and instructions available every time, shared across a team. An API-backed internal tool is for high-volume or embedded use cases someone on the engineering side has already built for you, you're a user of it, not a builder.
Configuration
Ask: will three colleagues need this same context next month? If yes, a Project. Will this run the same way a hundred times a day inside another product? If yes, it's already (or should be) an API-backed tool, not a manual chat habit.
Model Tier Match
not "the best one" by default
Faster, lighter model tiers handle routine drafting, summarizing, and formatting well and cheaply. Higher-capability tiers earn their cost on genuinely hard reasoning, nuanced judgment calls, or high-stakes deliverables where an error is expensive. Most day-to-day delivery work does not need the top tier.
Configuration
Rule of thumb: routine and low-stakes defaults to the fast/cheap tier. Ambiguous, high-stakes, or reasoning-heavy work justifies the top tier. When unsure, start at the lighter tier and escalate only if the output falls short, not the other way around.
Cost-Stakes Tradeoff Check
the two-minute gut check
A short, explicit pause before committing: does the value of getting this right justify the extra cost and time of the higher tier or richer product? For most routine tasks the answer is no. For a handful of genuinely high-stakes deliverables, the answer is clearly yes, and paying for it is the correct call, not a waste.
Configuration
Two-minute rule: if you can't articulate why the task needs the higher tier or richer product in one sentence, default to the lighter, cheaper option.
Data flow
5 steps to production
Ask the three task-profile questions before opening any tool
Is this one-off or recurring? Does it need shared, persistent knowledge across a team? What's the real cost if the output is wrong or slow? Answering these first prevents the default habit of "whatever's already open."
↪ Concept: claude-product-feature-selectionMatch the answer to a product tier
One-off and low-stakes goes to a plain chat. Recurring with shared team context goes to a Project. High-volume or embedded-in-another-product work should already be running through an API-backed tool your organization set up, not a manual chat routine.
Match the task's complexity and stakes to a model tier
Default to the lighter, faster tier for routine drafting, summarizing, and formatting. Reserve the top tier for genuinely hard reasoning or high-stakes deliverables. Starting light and escalating only if needed costs less than defaulting to the top tier out of habit.
↪ Concept: model-selection-tradeoffsRun the two-minute cost-stakes check
State, in one sentence, why this task justifies the product or model tier you picked. If you can't, you've probably over-provisioned. If you can, you've made a defensible, explainable choice, which matters when someone later asks why the workflow costs what it costs.
↪ Concept: accuracy-latency-cost-tradeoffsRevisit the choice when the task's nature changes
A one-off chat that becomes a weekly habit should graduate to a Project. A Project whose stakes just went up (it now feeds a client-facing deliverable) may justify a higher model tier. The decision isn't permanent, it should track the task.
The four decisions
| Decision | Right answer | Wrong answer | Why |
|---|---|---|---|
| One-off question vs. recurring team workflow | One-off → plain chat. Recurring, shared → a Project | Everything stays in whatever chat window is already open | A Project persists source documents and instructions for the whole team; a throwaway chat loses that context the moment it's closed. |
| Model tier for routine drafting | The faster, lighter tier by default | The top-capability tier, out of habit or assumption | Routine drafting and summarizing rarely need the top tier's reasoning depth. Defaulting to it wastes cost and time without improving the output. |
| Model tier for a high-stakes client deliverable | The higher-capability tier, deliberately chosen | Whatever tier was used for the last unrelated task | Stakes, not habit, should drive the tier choice. A high-stakes deliverable justifies paying for stronger reasoning; the previous task's tier is irrelevant. |
| A workflow that will run a hundred times a day | Belongs in an API-backed tool, not manual chat use | Keep doing it by hand in claude.ai because it already works | High-volume, repetitive work is exactly what an embedded, automated tool is for. Manual chat use doesn't scale and isn't the efficient choice at that volume. |
Where it breaks
4 failure pairs. Each maps to an exam-style question - the naive move on the left, the disciplined fix on the right.
A recurring, team-shared research task gets redone from scratch in a fresh chat every week.
AP-CCAOF-D3-01Recognize the recurrence and move the task into a Project with persistent source documents and instructions.
Routine internal summaries run on the highest-capability tier out of assumption that "best" is always right.
AP-CCAOF-D3-02Default routine, low-stakes work to the faster, cheaper tier. Reserve the top tier for tasks that actually need its reasoning depth.
A client-facing deliverable with real financial stakes gets drafted on the lightest, fastest tier to save time.
AP-CCAOF-D3-03Match the tier to the stakes. A genuinely high-stakes deliverable justifies the higher tier's cost and time.
A task that runs dozens of times a day continues to be done by hand in a chat window because "it already works."
AP-CCAOF-D3-04Recognize the volume signal and route the task to an API-backed tool built for that scale.
Cost & latency
The three-question task profile plus the cost-stakes check is designed to be fast enough that it doesn't become its own overhead.
Defaulting routine work to the lighter tier, instead of the top tier by habit, adds up materially across a team's day-to-day volume.
Correctly matching a high-stakes task to the stronger tier upfront avoids the cost of catching a shallow answer late and redoing it.
Moving a weekly recurring task from a fresh one-off chat into a Project eliminates the re-explaining and re-uploading tax paid every time.
Ship checklist
Two passes. Build-time gates verify the code; run-time gates verify the system in production.
Build-time
- Task-profile questions (recurrence, shared knowledge, stakes) answered before tool selection↗ claude-product-feature-selection
- Recurring, team-shared tasks live in a Project, not a rotating set of one-off chats
- Model tier chosen based on task complexity and stakes, not habit↗ model-selection-tradeoffs
- Two-minute cost-stakes justification articulated for any non-default choice↗ accuracy-latency-cost-tradeoffs
- High-volume or embedded workflows routed to a built tool, not manual chat use
- Product and model choice revisited when the task's recurrence or stakes change
Run-time
- Team has a shared, simple rule of thumb for chat vs. Project vs. built tool
- Recurring tasks have been migrated out of one-off chats into Projects
- Model-tier defaults are understood (light for routine, top tier deliberately chosen for stakes)
- High-volume workflows have been flagged to the team that owns built tools
- Product/model choices get revisited periodically as tasks evolve