Models chooser: Haiku, Sonnet, Opus, and Fable (no hype)

Open claude.ai on a busy Tuesday, start a normal chat about a messy status update, and the model picker stares back like a wine list. Haiku. Sonnet. Opus. Something with a storybook name. Maybe a version number. Maybe a “latest” badge. Your coworker already told you Opus is “smarter.” Your group chat already argued about Fable. You still have a paragraph to write before the 11:00 stand-up.

This is Part 5 of the Claude product map series. Parts 1 through 4 covered surfaces: chat versus agentic products, Claude Code, Claude Cowork, then Design and Science. You already know where to work. This part answers a smaller, noisier question: which engine label to pick inside a given product, without treating model names like sports teams. If you are still learning everyday Claude from zero, start with the companion series Learn Claude from scratch, then come back here when the model menu starts to feel like a second job.

What you’ll learn

• How to read the model family as a ladder (fast/light → everyday → hard/agent → top long-horizon), with Jul 2026 names as a snapshot
• Why “start with the default” beats weekly model FOMO for most work
• A switch rule: upgrade only after a clear prompt still fails quality
• How effort / thinking style controls can matter as much as the model label
• Where Mythos-class limited releases sit (interesting, not your daily driver)
• Common mistakes that burn plan limits without improving the deliverable

Names change. The job does not.

Anthropic ships models under marketing names that move. Version numbers move. Which plan can see which model moves. A screenshot from last quarter can already be wrong. Treat every specific name in this post as a July 2026 teaching snapshot, not a permanent product bible. Before a real purchase or a hard deadline, open the live model selector on claude.ai and the current docs on platform.claude.com and claude.com.

What stays stable is the shape of the family:

• A fast, light tier for volume and low-stakes drafts
• An everyday default that handles most writing and coding work
• A heavier tier for complex reasoning, multi-step agent work, and sticky judgment
• A top widely released tier for long-horizon, hardest-available work
• Occasional limited or restricted models that are not the normal menu for most users

If you learn that ladder once, new names map onto it. If you memorize only brand names, every release week restarts the anxiety.

The family snapshot (Jul 2026)

Here is a plain-English map using the names many people see in mid-2026 product talk. Confirm the live selector; hedges apply.

Read the table as intent, not as a guarantee that every account sees every row. Plan tier, region, product surface (chat vs Code vs Cowork vs API), and rollout timing all filter what appears. Fable sitting “above” Opus on capability does not mean you should live there. Mythos being “most interesting in the lab” does not mean you failed as a professional because you never got access.

Haiku: speed and volume

Haiku-class models earn their keep when latency and rate matter more than depth. Translate a bullet list into cleaner bullets. Rename twenty ticket titles into a consistent style. Draft a first pass of a meeting note so you can edit it. Run a pile of low-risk rewrites while you save heavier models for the one analysis that actually needs them.

Haiku is a poor place to argue with a 40-page vendor contract for legal nuance, or to ask for a multi-hour agent plan that spans a repo and three data sources. You can still start there to outline. Move up when the outline is weak after a fair try.

Sonnet: the workday default

On many plans, Sonnet-class is the default for a reason. It is the “open the laptop and do the job” engine: write, rewrite, explain, light code, structure a Project, turn notes into a plan. If you only remember one rule from this post, make it this: do most of your work on the default (often Sonnet) until quality fails after a clear prompt.

People waste hours hopping to Opus because a first draft felt “meh,” when the prompt was “make this better.” “Better” is not a brief. Sonnet with role, goal, constraints, audience, and an example of the tone you want often beats Opus with a shrug prompt. That pattern shows up again and again in real teams.

Opus: when the work gets sticky

Opus-class is for tasks that feel like they need more working memory and judgment: multi-step agent runs, dense tradeoffs, harder debugging, longer chains of “if this then that” reasoning. In Claude Code or Cowork style surfaces, heavier models often show up when the agent has to hold a plan across many tool calls.

Opus is not a truth serum. A polished wrong answer on Opus is still wrong. You still check SQL, numbers, citations, and diffs. Paying for a heavier model buys capacity and (often) better performance on hard tasks. It does not buy a system of record.

Fable: top of the widely released menu

Fable-class, in this snapshot, is the most capable model many people can actually select without special program access: long-horizon work, heavy agents, projects that need coherence across a lot of steps. Use it when the default and the mid-high tier already failed quality after honest prompts, or when you know from prior runs that the job is long and brittle.

Do not treat Fable as a personality upgrade for rewriting LinkedIn posts. That is how weekly limits disappear while the LinkedIn post still needs a human voice pass.

Mythos and limited programs

Mythos 5 (and similar limited releases under programs like Project Glasswing) sits outside the normal “everyone on Pro can pick this after lunch” story. Access can be restricted, invited, regional, or enterprise-gated. Interesting for research chatter. Useless as a baseline for how your team should work next week if nobody on the team can open it.

If you do get limited access, treat it like a lab: log tasks, compare against Sonnet/Opus/Fable on the same brief, and write down whether quality moved enough to justify the operational pain of a rare model. Do not rebuild your whole workflow around a model your new hire cannot open on day one.

The default-first rule

Here is the decision rule AMS recommends for everyday work:

1. Start on the product default (often Sonnet-class on consumer and many team plans).
2. Write a clear prompt: role, goal, constraints, audience, output format, and one short example if tone matters.
3. Iterate once or twice with specific feedback (“cut the adjectives,” “use our metric definition: active = login in 28 days”).
4. Only then upgrade the model if quality still fails for a reason that looks like capability, not ambiguity.
5. If a higher model still fails, fix inputs, tools, or the job definition before climbing again.

That order protects plan limits and your attention. Model hopping is a fun hobby. It is a bad default for a 20-minute writing task.

Rule of thumb: Upgrade the model when a clear prompt fails. Upgrade the prompt when a vague prompt fails. Fix the data when both models invent numbers you never supplied.

When to switch models

Use this flow when you feel the itch to “just try Opus.”

Signals that upgrading might help

• The task needs many steps held at once (agent plans, multi-file refactors, long research synthesis with structure).
• You gave role, constraints, and examples, and the default still misses logical branches or drops requirements.
• The failure mode is “shallow plan” or “loses the thread,” not “I forgot to paste the schema.”
• You are in Code or Cowork and the agent keeps taking shortsighted tool paths on a hard problem.

Signals that upgrading will not help

• Your prompt was one sentence with no goal or constraints.
• You asked for a number that lives in a warehouse you never connected or pasted.
• You want legal, medical, or tax conclusions a licensed human owns.
• You need ground truth from a system of record. Heavier models still cannot be that system.
• You are polishing tone on a paragraph that already works. Haiku or Sonnet is enough.

A worked week (toy, but realistic)

Imagine you are an ops lead with Pro-level access and a normal week.

Notice the last row. Model chooser skill includes knowing when the chooser is irrelevant.

Effort, thinking, and other dials

Beside the model name, some Claude UIs expose effort, thinking, or “how hard to try” style controls. Names and placement change. The idea is stable: you can ask the same model to spend more compute-style effort on a hard problem, or stay light for a quick rewrite.

Practical guidance:

• Light effort + default model for rewrites, formatting, and short Q&A.
• Higher effort on the default before you jump a whole model tier, when the UI offers that lever.
• Higher effort + higher model only for the hard jobs that already failed lighter settings.
• Watch usage. Heavier settings and heavier models often burn shared plan capacity faster. Chat, Code, and Cowork may share one pool depending on plan; treat that as a budget, not a free firehose.

If you cannot find an effort control, you are not broken. Not every surface exposes every dial. Prompt quality still does most of the work.

A practical habit when both dials exist: keep a sticky note of three recent tasks and which setting combination worked. “Status rewrite: Sonnet, light.” “Multi-file bug: Opus, higher effort.” After two weeks you will stop guessing from social media and start guessing from your own log. That log is boring. It also saves money and frustration.

Model tier is not plan tier

People mix two ladders:

• Plan ladder: Free / Pro / Max / Team / Enterprise (usage capacity, features, admin).
• Model ladder: Haiku / Sonnet / Opus / Fable / limited Mythos-class.

Paying for a higher plan can unlock more usage and more products (Code, Cowork, higher rate limits). It does not magically make every answer board-safe. Choosing Opus on Free (if available) and choosing Haiku on Max are both possible patterns depending on the week’s product rules. Match capacity plan to how much you use tools. Match model to how hard the task is after a clear prompt.

API pricing on platform.claude.com pricing docs is a third ladder entirely: tokens in, tokens out, billed to a Console account. Part 6 covers that split. For this part, only remember: chat model picker and API model IDs are related cousins, not the same invoice.

Prompt quality still beats model vanity

Here is a before/after you can steal. Same model. Different brief.

Weak:

Make this status update better:
- sales mixed
- eng delayed feature
- hiring 2 roles

Stronger (still on Sonnet):

You are my ops writing partner. Turn these notes into a 120-word Friday status
for a non-technical VP.

Constraints:
- No invented metrics.
- One paragraph + three bullets max.
- Flag unknowns as "TBD: owner will confirm".
- Tone: calm, specific, no hype adjectives.

Notes:
- Pipeline: qualitative "mixed"; do not invent %.
- Eng: Feature X slipped one sprint; new target date next Fri if QA passes.
- Hiring: two IC roles open; both in final panel stage.

Output format:
1) Paragraph
2) Bullets
3) Risks (only if present in notes)

If the stronger prompt still produces fluff or invented numbers on Sonnet, try a higher model. If it invents a “down 12%” you never wrote, the fix is not Fable. The fix is a harder constraint and a human check against the spreadsheet.

Product surface still matters more than the badge

Model choice sits inside a product surface from earlier parts of this series:

• Chat: you ask, Claude answers, you copy or edit. Model choice shapes answer quality.
• Claude Code: software work in repo/terminal/IDE. Model choice shapes agent planning and edit quality. You still review diffs.
• Claude Cowork: office-file and multi-step knowledge work. Model choice shapes plan depth. You still review deliverables.
• Design / Science: specialized workbenches. Pick them for the job class first; then pick a model if the UI offers one.

A common failure mode: staying in chat with Fable when the real need is Claude Code touching the repo, or Cowork sorting a folder. Heavy model, wrong surface. Flip it: right surface, default model, clear goal. Often cheaper and better.

Another failure mode is the opposite: you open Code or Cowork on a heavy model for a job that was really a two-message chat. Example: “Turn these three bullets into a polite Slack update.” That is chat + Sonnet (or Haiku). You do not need a folder grant, a terminal, or Fable. Match surface to the verb of the job (write, edit repo, wrangle files, design, science), then match model to difficulty after a clear prompt.

FAQ: model picker in real life

Should I always pick the newest name?

No. Newest often means “marketed this month,” not “best for your Tuesday.” Prefer the default until quality fails. Then move one step up the ladder you can actually select on your plan.

My teammate swears Opus fixed their writing

Ask what the prompt looked like before and after. Plenty of “Opus magic” is really “they finally wrote a brief.” Reproduce their strong prompt on Sonnet first. If Sonnet matches, keep the brief and save the heavier model for harder work.

What if my plan only shows two models?

Use the same rule on a shorter ladder. Default first. Upgrade once quality fails after a clear prompt. The five-name snapshot is a teaching map, not a requirement that every account displays five rows.

Common mistakes

• Model FOMO as a morning ritual. Opening the picker before writing the brief is backwards.
• Using Opus for every email. You will hit limits mid-week when you need the heavy model for a real fire.
• Assuming higher model = allowed data. Policy and product settings govern data, not the marketing name on the badge.
• Trusting fluent wrong answers more on expensive models. Fluency rises with skill. So can confident mistakes. Verify what ships.
• Ignoring plan shared pools. Chat + Code + Cowork can share capacity. A Fable agent marathon can starve your afternoon writing.
• Chasing Mythos gossip while skipping Projects and good files. Context design beats rare models for most knowledge work.
• Copying API model IDs into chat advice for non-builders. Builders need Console docs. Most readers need the on-screen selector.
• Never re-checking the live list. Names in this post will age. The default-first rule ages slower.

Practice: 25 minutes

1. Open your live model selector. Write down the names you actually see today (screenshot optional).
2. Map each name onto the ladder: light / default / hard / top / limited. If a name is new, put it where the UI description points and note uncertainty.
3. Pick one real task from this week. Run it on the default with a strong prompt (role, goal, constraints, format).
4. Score the output from 1 to 5 for usefulness. Only if 3 or below, rerun on one higher tier with the same prompt.
5. Write one sentence in your notes: “Upgrade helped / did not help because ___.” Keep that log for a month. Patterns beat Twitter takes.

How this fits the series

The product map so far:

• Part 1: chat versus agentic surfaces
• Part 2: Claude Code job fit
• Part 3: Claude Cowork job fit
• Part 4: Design and Science niches
• Part 5 (this post): model chooser without hype
• Part 6: API and Console, only if you build apps

Everyday skills (first half hour, Projects, privacy, judgment) live in Learn Claude from scratch. After the product map closes, deep how-to continues in the Claude Code tutorial and Claude Cowork tutorial series. You do not need the API to finish those paths.

Quick recap

• Treat model names as a snapshot: Haiku light, Sonnet default, Opus hard/agents, Fable top widely released, Mythos limited.
• Start on the default. Upgrade only when a clear prompt still fails for capability reasons.
• Try effort/thinking dials on the default before you burn the top tier on a soft brief.
• Pick the right product surface first; then pick a model inside it.
• Heavier models are not systems of record. Verify numbers, SQL, and anything that ships.
• Re-check claude.ai and platform docs the week you care. The ladder shape lasts longer than the labels.

Next: Part 6 explains the API and Console for builders, why Pro chat is not free unlimited API, and when most AMS readers should ignore the whole topic until they ship software.

Sources

Product names and plan access change. Prefer live pages over any snapshot in this article.

• Claude product overview: https://claude.com/product/overview
• Claude plans and pricing (verify before you buy): https://claude.com/pricing
• Claude Platform (Console / API home): https://platform.claude.com/
• Claude Platform model and API pricing docs: https://platform.claude.com/docs/en/about-claude/pricing
• Claude Platform docs index (models, API, builders): https://platform.claude.com/docs
• Anthropic company site: https://www.anthropic.com/
• Anthropic news and announcements (release notes age; check dates): https://www.anthropic.com/news
• Anthropic engineering notes on products and agents (context for chat vs agent surfaces): https://www.anthropic.com/engineering
• Usage limit best practices (session and weekly style limits): https://support.claude.com/en/articles/9797557-usage-limit-best-practices
• AMS Learn Claude series: https://analyticsmadesimple.com/series/learn-claude/
• AMS Learn hub: https://analyticsmadesimple.com/learn/
• AMS: How to check AI-written SQL before you ship it: https://analyticsmadesimple.com/tutorials/how-to-check-ai-written-sql/

Merch on Etsy

Open store →

Naive Bayes Mouse Pad, Data Science Mouse Pad, Analytics Mouse Pad, Bayesian Mouse Pad View on Etsy → You're On Mute White Ceramic Coffee Mug, Data Science Mug, Data Mug, Analytics Mug, Statistics Mug, Programming Mug, Gift Mug, Coffee Mug View on Etsy → Good Cheap Fast White Ceramic Coffee Mug, Data Science Mug, Data Mug, Analytics Mug, Statistics Mug, Programming Mug, Gift Mug, Coffee Mug View on Etsy → Mute Mouse Pad, Data Science Mouse Pad, Analytics Mouse Pad, You're On Mute View on Etsy →