Product and Model Selection

Knowledge of

• Plain chat as the surface for quick, one-off questions and short tasks with no persistent knowledge beyond the conversation
• Projects as a persistent workspace that holds instructions and uploaded knowledge reused across many chats
• Research mode as the surface for deeper, multi-source investigation that gathers and synthesizes across sources
• Artifacts as a separate, editable window for substantial, self-contained deliverables meant to be refined or shared
• The signals that point to Projects (re-pasting the same background) versus Artifacts (the output is a reusable document, not a chat reply)

Skills in

• Recognizing when recurring work around a shared body of knowledge calls for a Project instead of plain chat
• Recognizing when a deliverable calls for an Artifact instead of a chat reply
• Choosing research mode when a question needs synthesis across multiple sources rather than a single quick answer
• Avoiding the default of plain chat for workflows that repeat the same knowledge or produce reusable documents

Knowledge of

• Haiku as the fastest, lowest-cost model, fit for high-volume, simple, latency-sensitive work
• Sonnet as the balanced, everyday workhorse for most business tasks
• Opus as the most capable, highest-cost model, fit for hard analysis and nuanced or multi-step reasoning
• The fundamental tradeoff that more capability generally costs more and runs slower
• That there is no single 'best' model -- only the best fit for a given task

Skills in

• Recalling the consistent ordering of Haiku, Sonnet, and Opus across speed, cost, and capability
• Avoiding the assumption that a bigger model fixes a badly written prompt
• Resisting the instinct to pick the most capable model 'to be safe' regardless of task

Knowledge of

• That simple, high-volume, latency-sensitive tasks call for a faster, lower-cost model
• That balanced everyday work -- drafting, summarizing, analysis -- is handled well by Sonnet
• That hard, high-value reasoning tasks justify Opus's added cost and time
• The idea of an implicit budget: every task has a target for cost, latency, and quality that selection should match, not maximize one dimension of
• That plan/pricing tier determines which models and features are reachable at all

Skills in

• Matching a task's reasoning demands and volume to the appropriately sized model
• Recognizing that a slow top-tier model can bottleneck a high-volume batch workflow
• Choosing to right-size the model rather than switching platforms or disabling features to cut cost

Knowledge of

• The context window as the finite total amount of text -- instructions, uploaded material, conversation history, and the answer -- a model can consider at once
• That in a very long conversation, early details can get crowded out and quality can drift
• Summarize, restart, and persist as the three practical moves for managing long conversations
• That degraded output late in a long session is often a context problem, not a model problem
• That a bigger context window is not free -- it can raise cost and latency, and curating what's relevant beats stuffing everything in

Skills in

• Condensing a long thread into a short recap and continuing from that summary
• Starting a fresh chat when the current one is cluttered or off-track, carrying over only what matters
• Moving durable, reusable context into a Project instead of leaving it in a fragile chat history
• Diagnosing late-conversation quality drops as a context problem rather than assuming the model is broken