Model Tiers: Haiku vs. Sonnet vs. Opus
The trade-off is always the same one: speed and cost on one side, depth of reasoning on the other. Match the tier to the task's volume, complexity, stakes, and autonomy length — don't default to either extreme.
| Tier | Speed / Cost | Best For | Watch Out For |
|---|---|---|---|
| Haiku | Fastest, cheapest | High-volume, simple, well-defined work: ticket tagging, field extraction, quick factual lookups | Reaching for it 'to save cost' on long, high-autonomy, high-complexity work — early mistakes compound |
| Sonnet | Balanced | Default all-rounder: drafting, editing, analysis, everyday coding, summarizing | Treating it as always-correct-by-default even when a scenario clearly points to Haiku or Opus |
| Opus | Slowest, most expensive per request | Long, high-autonomy runs or single highest-stakes decisions where accuracy matters far more than cost/speed | Reaching for it 'to be safe' on high-volume, simple jobs — adds cost/latency the task doesn't need |
Effort Parameter vs. Model Choice — Which Lever?
Two separate, related decisions. Model tier decides which model family does the work at all. Effort decides how thoroughly that already-chosen model works on this particular request. Effort can't grant a tier capabilities it doesn't have; tier choice doesn't remove the value of tuning effort.
| Question | Lever | Example |
|---|---|---|
| Does this task need a different level of reasoning capability? | Model tier (3.1) | 50,000 tickets/day → Haiku; multi-hour codebase refactor → Opus |
| Is the model already right — should it just work more/less carefully on this request? | Effort parameter | Quick syntax sanity check → low effort; careful audit of interdependent formulas → high effort, same model |
- Anthropic recommends xhigh effort for advanced coding and high-autonomy agentic work on Claude Opus 4.8; routine, low-stakes requests need less.
- Distractor: reaching for a bigger model when the real ask is 'make this same model work more carefully.'
- Distractor: maxing out effort by default on a routine request — there's little depth for extra thoroughness to improve.
Which Claude Product Feature?
Work through these questions roughly in order — each solves a different problem.
| Need | Feature | Signal |
|---|---|---|
| Available across many future conversations | Claude Project | You'd otherwise re-paste it into every new chat: style guide, client background, standing facts |
| Current info from multiple external sources, cited | Research mode | Answer requires finding and sourcing information Claude doesn't already know |
| Long-form, self-contained, or iteratively-edited output | Artifact | A report, essay, or prototype the user will keep revising, not just read once |
| Fundamentally comparative or tabular output | Structured output (table) | Rows/columns meant to be scanned side by side rather than read as prose |
| None of the above | Plain chat reply | Self-contained answer read once — the lightweight default |
Features layer together rather than being either/or: a Project conversation might use research mode, then place the synthesized findings into an Artifact for further editing.
Context Limit Signals: Restart, Summarize, or Persist?
Degradation signals: Claude forgets or misapplies an early rule, contradicts an earlier decision, re-asks something already answered, or mishandles a document pasted many messages ago. The fix is structural, not louder wording.
| Signal | Response | Why |
|---|---|---|
| Most of the thread's content is irrelevant to what's next | Restart — brand-new conversation | Clean slate avoids dragging irrelevant baggage forward |
| Real decisions/facts still needed, but the thread has grown unwieldy | Summarize, then continue in a new conversation seeded with that summary | Preserves what matters while shedding the excess length causing degradation |
| Standing reference needed across many future, even unrelated, conversations | Persist to Project knowledge base or custom instructions | Test: would you otherwise re-paste or re-summarize it every time? If yes, persist it. |
- Distractor: repeating the instruction more forcefully in an already-degraded thread — treats a structural problem as a wording problem.
- Distractor: a blind restart when earlier content is still needed — loses useful context instead of preserving it.
- Distractor: re-pasting the same standing reference into every new conversation instead of persisting it once.
Long Documents Hit the Same Limit
Context limits aren't only about conversation length — a single very long document competes for the same limited attention as everything else in the conversation.
- Paste only the relevant section instead of the whole document.
- Ask for a section-by-section summary pass before working with the whole thing.
- Signal: a 300-page report pasted in whole when only two chapters are actually relevant to the task.