Model Selection and Effort Level

Overview

You have Claude Code installed, authenticated, and on the right plan. Now comes the configuration that separates the casual user from the professional: picking the right model and the right depth of reasoning for each task.

Claude Code gives you access to the Claude 5 family — Opus 5, Sonnet 5, and Haiku 4.5 for day-to-day work, plus Fable 5 for frontier tasks — and an effort level setting that controls how much Claude reasons before answering. The model + effort combination is your most powerful lever for balancing quality, speed, and cost. Using Opus + high effort on a trivial task is wasting resources. Using Sonnet + low effort on an architecture decision is compromising quality.

In this capsule you'll learn when to use each model, how each effort level works, and the optimal combinations for the most common development scenarios. By the end, you'll be able to adjust model and effort in real time based on what you need, maximizing both your productivity and your quota.

The available models

Opus 5

┌─────────────────────────────────────────────┐
│  OPUS 5                                     │
│                                             │
│  Type:      Anthropic's flagship model      │
│  Context:   1M tokens                       │
│  Output:    128K tokens max                 │
│  Speed:     Slower than Sonnet              │
│  Cost:      Higher quota consumption        │
│  Strength:  Deep reasoning                  │
│                                             │
│  Ideal for:                                 │
│  → Systems architecture                     │
│  → Multi-file refactoring                   │
│  → Deep code review                         │
│  → Analyzing large codebases                │
│  → Complex decisions                        │
│  → Hard debugging                           │
└─────────────────────────────────────────────┘

1M of context: Opus 5 can process up to a million tokens of context. In practical terms, it can "see" an entire medium-to-large codebase in one go. Sonnet 5 also supports 1M tokens.

128K of output: It can generate extremely long answers — complete multi-file refactorings, extensive documentation, or detailed analyses.

Deep reasoning: Opus thinks more before it answers. It doesn't just generate text — it analyzes, plans, considers edge cases, and produces more robust solutions.

Sonnet 5

┌─────────────────────────────────────────────┐
│  SONNET 5                                   │
│                                             │
│  Type:      Fast and efficient model        │
│  Context:   1M tokens                       │
│  Output:    128K tokens max                 │
│  Speed:     Significantly faster            │
│  Cost:      Lower quota consumption         │
│  Strength:  Speed + efficiency              │
│                                             │
│  Ideal for:                                 │
│  → Quick fixes and small changes            │
│  → Creating simple files                    │
│  → Direct questions                         │
│  → Formatting and renaming                  │
│  → Repetitive tasks                         │
│  → Boilerplate generation                   │
└─────────────────────────────────────────────┘

Speed: Sonnet answers noticeably faster than Opus. For tasks where speed matters more than depth of analysis, Sonnet is the right call.

Efficiency: It consumes less quota. If you're on Pro and rationing your Opus quota, Sonnet lets you keep working without restrictions.

Quality: It isn't "inferior" across the board — for simple and moderate tasks, Sonnet produces results identical to Opus. The difference shows up in tasks that need multi-step reasoning or extensive analysis.

Haiku 4.5

┌─────────────────────────────────────────────┐
│  HAIKU 4.5                                  │
│                                             │
│  Type:      Fastest, cheapest model         │
│  Context:   200K tokens                     │
│  Output:    64K tokens max                  │
│  Speed:     The fastest of the family       │
│  Cost:      Minimum quota consumption       │
│  Strength:  Speed + cost-efficiency         │
│                                             │
│  Ideal for:                                 │
│  → Simple, direct questions                 │
│  → Mechanical tasks (renaming, formatting)  │
│  → Basic boilerplate generation             │
│  → Quick checks                             │
│  → Tasks where cost matters more            │
│    than depth                               │
└─────────────────────────────────────────────┘

Speed: Haiku is the fastest model in the Claude family. It answers almost instantly on simple tasks.

Cost-efficiency: It consumes significantly less quota than Sonnet. If you're rationing your quota and the task is simple, Haiku is the optimal choice.

Limitations: For tasks that need complex reasoning, multi-file analysis, or architecture decisions, Haiku isn't enough. Use Sonnet or Opus for those.

Fable 5: the frontier tier

┌─────────────────────────────────────────────┐
│  FABLE 5                                    │
│                                             │
│  Type:      Anthropic's most capable model  │
│  Context:   1M tokens                       │
│  Speed:     The slowest (thinks more)       │
│  Cost:      The highest in the family       │
│  Strength:  Frontier reasoning and          │
│             long-horizon agentic work       │
│                                             │
│  Ideal for:                                 │
│  → The hardest reasoning problems           │
│  → Long, autonomous agentic sessions        │
│  → When correctness matters more than       │
│    cost or speed                            │
└─────────────────────────────────────────────┘

Fable 5 is Anthropic's most capable widely released model. In Claude Code you select it with the fable alias (/model fable). It's not the day-to-day model: it costs considerably more than Opus and thinks for longer. Save it for tasks where the quality of reasoning justifies the cost — a bug nobody else can crack, a critical migration, a long agentic session you can't supervise step by step. For 95% of daily work, Opus 5, Sonnet 5, and Haiku 4.5 are the right call.

Direct comparison

The opusplan alias: Claude Code offers a special alias that uses Opus for planning (plan mode) and automatically switches to Sonnet for execution. It's the most efficient way to combine both models: /model opusplan.

How to switch models

The /model command

Inside a Claude Code session:

> /model

It shows you the available models and lets you pick one. Use the aliases (opus, sonnet, haiku, fable) or the full names (claude-opus-5, claude-sonnet-5, claude-haiku-4-5, claude-fable-5):

> /model sonnet
✓ Switched to sonnet

> /model opus
✓ Switched to opus

> /model haiku
✓ Switched to haiku

Switching mid-session

You can switch models at any point without losing the conversation's context:

> /model opus
✓ Switched to opus

> "Analyze this project's architecture and suggest improvements"
[Claude answers with Opus's deep analysis]

> /model sonnet
✓ Switched to sonnet

> "Rename 'getData' to 'fetchUserData' in src/api.ts"
[Claude answers quickly with Sonnet]

The conversation's context is preserved when you switch models. All that changes is the "brain" that processes your next message. You can also switch models with Option+P (macOS) or Alt+P (Windows/Linux) without erasing your prompt.

The default model

You can set the default model in several ways:

# When starting the session
claude --model opus

# Via an environment variable
export ANTHROPIC_MODEL=opus

# In settings (permanent) — open /config
# Set "model": "opus"

The default model varies by account type: Pro and Team Standard use Sonnet 5; Max, Team Premium, and pay-as-you-go API usage use Opus 5.

The opusplan alias

opusplan is an automatic hybrid mode that saves you from switching models by hand:

/model opusplan

In Plan mode  → Uses Opus (deep reasoning for planning)
In execution  → Switches automatically to Sonnet (efficiency for implementing)

It's the most efficient way to combine the best of both models.

When to use each model

Opus 5: the deep thinker

Use Opus when the task needs complex reasoning, a broad view, or decisions with consequences:

Architecture and design:

> /model opus
> "Evaluate our microservices architecture. 
   Should we consolidate the auth and users services? 
   Analyze the trade-offs."

Opus can evaluate the impact across multiple services, consider migration edge cases, and give you a well-grounded recommendation.

Multi-file refactoring:

> /model opus
> "Refactor the payments module to use the new 
   Strategy pattern instead of switch cases. 
   It touches 8 files."

Opus keeps files coherent with each other, understands the dependencies, and applies the pattern consistently.

Deep code review:

> /model opus
> "Review the changes in PR #47. Look for potential bugs, 
   performance problems, and violations of our 
   conventions."

Opus analyzes every change in context, spots subtle bugs, and evaluates the impact on the whole system.

Complex debugging:

> /model opus
> "The integration tests fail intermittently in CI 
   but never locally. The error is a timeout on the 
   Redis connection. Help me find the root cause."

Opus can reason about race conditions, environment differences, and concurrency problems.

Analyzing large codebases:

> /model opus
> "I just cloned this 50K-line monorepo. 
   Map the architecture: services, dependencies, 
   and entry points."

With 1M of context, Opus can process entire codebases and generate architectural maps.

Sonnet 5: the fast executor

Use Sonnet when the task is clear, bounded, and doesn't need deep reasoning:

Quick fixes:

> /model sonnet
> "There's a typo on line 42 of src/utils/format.ts: 
   'lenght' should be 'length'"

Creating simple files:

> /model sonnet
> "Create a .gitignore for a Python project with FastAPI"

Formatting and boilerplate:

> /model sonnet
> "Generate the TypeScript types for this JSON response"

Direct questions:

> /model sonnet
> "What's the syntax for a GROUP BY with HAVING in PostgreSQL?"

Repetitive tasks:

> /model sonnet
> "Add JSDoc to every exported function in src/utils/"

Renaming and simple refactoring:

> /model sonnet
> "Rename the file user-service.ts to user.service.ts 
   and update all the imports"

Haiku 4.5: the ultralight

Use Haiku when the task is trivial, mechanical, or when you need to maximize quota efficiency:

Simple questions:

> /model haiku
> "Does the file src/config.ts exist?"

Quick checks:

> /model haiku
> "How many .py files are in the project?"

Basic formatting:

> /model haiku
> "Convert this JSON to YAML"

Mechanical renaming:

> /model haiku
> "Rename the variable 'x' to 'count' in this file"

Haiku is not the right model for tasks that need deep understanding of the codebase, design decisions, or multi-file analysis. For that, use Sonnet or Opus.

The gray zone

Some tasks sit in between. For those, the rule is:

Does the task have multiple steps that depend on each other?
├─ Yes → Opus
└─ No  → Sonnet

Do I need Claude to consider edge cases I might not see?
├─ Yes → Opus
└─ No  → Sonnet

Would a wrong answer have consequences that are hard to undo?
├─ Yes → Opus
└─ No  → Sonnet

Does the task touch more than 3 files?
├─ Yes → Opus (probably)
└─ No  → Sonnet (probably)

Effort Level

What it is

The effort level controls the depth of Claude's adaptive reasoning. At low effort, Claude answers fast and directly. At high effort, it reasons extensively before answering.

Effort is supported on the reasoning models of the Claude 5 family — Opus 5, Sonnet 5, and Fable 5 (and Opus 4.8). All five levels are available on each of them:

Haiku 4.5 doesn't expose a configurable effort: it's tuned to answer fast on simple tasks. If you set an effort level while on Haiku, Claude Code simply ignores it.

The default

The default on the models that support effort is high. It's a good starting point for most work. For coding and agentic tasks, xhigh is usually the better choice: it thinks more before acting, which cuts down the back-and-forth. Adjust it with /effort based on the task.

The 5 levels

Important: low, medium, high, and xhigh persist across sessions. max provides the deepest reasoning with no token restriction and applies to the current session only (except when set via CLAUDE_CODE_EFFORT_LEVEL).

low ─── medium ─── high ─── xhigh ─── max
 │        │          │        │         │
 Fast    Balanced   Default  Recommended  No limit
                             for coding

How to configure it

There are several ways to set the effort level:

1. The /effort command (the most direct):

> /effort low
> /effort medium
> /effort high
> /effort xhigh
> /effort max
> /effort auto    # reset to the model's default

Run /effort with no arguments to open an interactive slider. The current level is displayed next to the logo (for example, "with xhigh effort").

2. Inside /model with the arrow keys:

> /model
[Pick the model]
[Use ← → to adjust effort]

3. A flag at launch:

claude --effort high

4. In settings (permanent):

{
  "effortLevel": "medium"
}

5. Via an environment variable:

export CLAUDE_CODE_EFFORT_LEVEL=low   # or medium, high, xhigh, max, auto

6. Quick tip — "ultrathink": Include "ultrathink" in your prompt to turn on high effort for that turn only, without changing your session configuration.

Fast Mode

Fast mode is a speed optimization for Claude Opus 5. It does not switch you to a different model — it's the same Opus 5 with output optimized to be faster. It's a research preview: its availability and pricing can change, and today it works only on Opus 5 and Opus 4.8.

What it is

Fast mode prioritizes generation speed over maximum reasoning depth. Claude is still Opus — with all its capability and its 1M-token context window — but it generates answers faster.

How to turn it on

> /fast

The /fast command is a toggle: run it once to turn it on, again to turn it off.

When to use it

What Fast Mode is NOT

Fast mode ≠ a different model
Fast mode ≠ Sonnet
Fast mode ≠ less capability

Fast mode = Opus 5 optimized for output speed

Important: If you need a lighter model (and not just faster output), use Sonnet or Haiku instead with /model sonnet or /model haiku. Fast mode is for when you want Opus's capability but with faster answers.

Fast mode vs effort level

Fast mode and effort level are complementary but different controls:

You can combine them: Opus with high effort + fast mode on gives you deep reasoning with fast output.

The combination: model + effort

The decision matrix

The combination of model and effort gives you a spectrum of configurations:

                    Effort (Opus and Sonnet)
              low     medium    high     xhigh    max
           ┌───────┬────────┬────────┬────────┬────────┐
Opus 5     │  ⚡   │   ⚙️    │  🧠    │  🧠➕   │ 🧠🧠   │
           │ fast  │balance │default │coding  │no limit│
           └───────┴────────┴────────┴────────┴────────┘
           ┌───────┬────────┬────────┬────────┬────────┐
Sonnet 5   │  ⚡   │   ⚙️    │  🧠    │  🧠➕   │ 🧠🧠   │
           │ fast  │balance │default │coding  │no limit│
           └───────┴────────┴────────┴────────┴────────┘

Haiku 4.5  → No configurable effort
               (the fastest and cheapest)

⚡ = speed prioritized
⚙️ = balance
🧠 = deep reasoning (default)
🧠➕ = recommended for coding

The 5 most useful combinations

Most of the time you'll live between Haiku/Sonnet (fast tasks) and Opus + xhigh (deep analysis). The opusplan alias automates that switching.

A practical decision matrix

Task → Model + Effort

The pattern of a typical day

9:00  Standup prep      → Sonnet         (summarize changes)
9:30  Checks            → Haiku          (do tests pass? which branch?)
9:35  Implementation    → Sonnet         (endpoints, tests)
11:00 Code review       → Opus + xhigh   (hunt for bugs in a PR)
12:00 Architecture call → Opus + xhigh   (Redis vs Memcached)
2:00  Implementation    → Sonnet         (cache layer)
4:00  Quick fixes       → Haiku/Sonnet   (typos, renaming, versions)

Model and effort change with the task. That's what a professional does — they don't use the same configuration for everything.

Cost implications

Model + effort → quota consumption

Relative quota consumption (approximate):

Haiku            ██░░░░░░░░░░░░░░░░░░  (~0.5x)
Sonnet           ████░░░░░░░░░░░░░░░░  (~1x)

Opus + low       ████████░░░░░░░░░░░░  (~3x)
Opus + high      ████████████░░░░░░░░  (~5x)
Opus + xhigh     ████████████████████  (~8-10x)

What this means: A task on Opus + xhigh effort consumes ~8-10x more quota than the same task on Sonnet. Picking the right combination is the single most effective way to optimize your quota. (Fable 5 sits above all of this: it's the most expensive model in the family — save it for what truly warrants it.)

The practical implication

Pro plan (base):
→ If you use Sonnet all day: ~6-8 hours of use
→ If you use Opus + xhigh all day: ~1-2 hours of use
→ If you mix intelligently: ~4-6 hours of use

Max 5x plan:
→ 5x more quota in every scenario
→ An intelligent mix: ~20-30 hours of use per period

Comparisons and decisions

Is Opus always better than Sonnet?

No. For simple tasks (creating files, renaming, direct questions), Sonnet produces identical results faster and cheaper. Opus earns its cost when the task needs multi-step reasoning, extensive analysis, or handling subtle edge cases.

Can I just use Opus + xhigh all the time?

You can, but you waste 8-10x more quota on tasks that don't need it. Adapting model + effort per task is the smartest way to use your quota: Sonnet where speed matters, Opus + xhigh where quality matters.

When do I switch models vs lower the effort?

Sonnet's result isn't good enough:

The task is clear but needs more analysis
→ Switch to Opus (and raise effort to xhigh if needed)

The result is overkill / too slow with Opus:
→ Lower effort to medium or low

Simple task but you want deep context:
→ Opus + low

Common patterns

Pattern 1: Start low, move up if you need to

# Try Sonnet first (fast and efficient)
> "Implement email validation in the user schema"

# If the result isn't good enough:
> /model opus
> "Improve the validation. Consider edge cases like 
   emails with special characters, invalid domains, 
   and the maximum length per RFC 5321."

That's more efficient than starting on Opus + xhigh for everything.

Pattern 2: A block of tasks with the same config

# Implementation block (multiple similar tasks)
> /model sonnet

> "Create the GET /api/products endpoint"
> "Create the POST /api/products endpoint"
> "Create the PUT /api/products/:id endpoint"
> "Add tests for the 3 endpoints"

# Review block (config change)
> /model opus

> "Review the 4 files we just created"

Group tasks by complexity level to minimize config switching.

Pattern 3: Opus to plan, Sonnet to execute

# Option A: Manual
> /model opus
> "Plan the migration of our authentication from 
   sessions to JWT. Give me a step-by-step plan with the files 
   that need to change."

> /model sonnet
> "Execute step 1 of the plan: create the jwt-utils.ts module"
> "Step 2: modify the auth middleware"
> "Step 3: update the tests"

# Option B: Automatic with opusplan
> /model opusplan
> "Migrate authentication from sessions to JWT"
# Claude uses Opus to plan and Sonnet to execute — automatically

Opus plans, Sonnet executes. With opusplan, you don't even have to switch by hand.

Pattern 4: Sonnet for quick checks

> /model sonnet
> "Does the file src/config.ts exist?"
> "How many tests do we have?"
> "What Python version does pyproject.toml say?"

> /model opus
> "Now design the migration..."

For factual questions and quick checks, Sonnet answers correctly with no need for deep reasoning.

Pattern 5: An escalating debugging session

# First attempt: understand the problem
> /model sonnet
> "The tests in user.service.test.ts are failing. Why?"

# If Sonnet doesn't solve it: escalate to Opus
> /model opus
> "You didn't find the cause. The error is intermittent. 
   Analyze possible race conditions or state dependencies."

# Opus with high effort (the default) already analyzes exhaustively
# If you want more depth for an elusive problem:
# Raise it to xhigh in /effort

Pitfalls and edge cases

Pitfall 1: Using Opus for everything

❌ /model opus
> "Create an empty README.md file"
→ Opus thinks deeply about... an empty file
→ Wasted quota and wasted time

Use Sonnet for simple tasks — it produces the same result faster and cheaper.

Pitfall 2: Using Sonnet for tasks that need deep reasoning

❌ /model sonnet
> "Refactor the entire authentication system"
→ Sonnet does fine but can miss subtle edge cases
→ You can raise effort to xhigh, but for a task this complex Opus is the better call

For complex tasks, the extra cost of Opus + xhigh pays for itself.

Pitfall 3: Never changing your configuration

❌ The whole day on the same model and effort
→ You overspend quota on simple tasks
→ Or you underuse capability on complex ones

Adapting model + effort is like shifting gears while driving. You don't use first gear on the highway or fifth in a parking lot.

Pitfall 4: Assuming effort affects the model's "intelligence"

The effort level doesn't make the model "smarter." It controls how much it reasons before answering. Opus at low effort knows exactly what it knows at xhigh effort — the difference is how much it analyzes before giving you the answer.

Effort low:   Claude knows the answer and gives it fast, without much thought
Effort xhigh: Claude knows the same thing but thinks extensively, 
              weighing alternatives, edge cases, and consequences

Pitfall 5: Forgetting to switch models between tasks

If you use Opus for an architecture task and then ask for something trivial without switching to Sonnet, you waste quota:

> /model opus
> "Design the system architecture" ← Opus, correct
> "Create a .gitignore"            ← Opus, unnecessary

Build the habit of switching models when you switch task type. Or use opusplan so Claude alternates automatically.

Complete worked example

Scenario: a 2-hour session implementing notifications

$ claude

# 1. Orientation (Sonnet) — 2 min
> /model sonnet
> "Summarize what changed since yesterday"

# 2. Planning (Opus) — 10 min
> /model opus
> "Plan the notifications system: files, dependencies, steps"

# 3. Implementation (Sonnet) — 45 min
> /model sonnet
> "Create email.service.ts" → "Create notification.html"
> "Create the POST /notifications/send endpoint" → "Create tests"

# 4. Verification (Sonnet) — 5 min
> "Run the tests and tell me if they pass"

# 5. Review of the work (Opus) — 15 min
> /model opus
> "Review everything. Bugs? Conventions? Error handling?"

# 6. Fixes + cleanup (Sonnet) — 13 min
> /model sonnet
> "Apply fixes 1, 3, 5" → "Lint + format"

# 7. Summary (Sonnet)
> "Summarize in 5 bullets for standup" → /exit

The opusplan alternative: run the whole session with /model opusplan. Claude uses Opus automatically when it plans and Sonnet when it executes. Fewer manual switches, same result.

Result: ~70% Sonnet, ~30% Opus. If all of it had been Opus + xhigh, it would have burned ~4x more quota for similar results.

Practice exercises

Exercise 1: Experiment with the effort levels

Ask the same question at each effort level on Opus and compare:

> /model opus
Question: "Explain how the Node.js event loop works"

# Adjust effort with /effort low
> [observe the answer]

# Set it to medium
> [observe the answer]

# Set it to high (default)
> [observe the answer]

Exercise 2: Compare Opus vs Sonnet on the same task

Ask for the same thing with each model (same effort):

Task: "Suggest 3 performance improvements for this project"

> /model sonnet
> /effort high
> "Suggest 3 performance improvements"

> /model opus
> /effort high
> "Suggest 3 performance improvements"

Exercise 3: Find the minimum effective level

For each of these tasks, find the lowest model + effort combination that produces an acceptable result:

1. Create an .editorconfig file
2. Write a password validation function
3. Explain a bug in your code
4. Plan a 5-file refactoring

Exercise 4: A session with model switches

Run a 15-minute mini-session where you switch models at least 3 times, based on the task:

1. A quick question (Sonnet)
2. A simple implementation (Sonnet)
3. A review of the result (Opus)
4. Fixes and cleanup (Sonnet)

> /model sonnet
> "How many .ts files are in src/?"

> "Create a utility function that formats dates in ISO format"

> /model opus
> "Review the function we just created. 
   Does it handle timezones correctly? Edge cases?"

> /model sonnet
> "Apply the fixes from the review"

Exercise 5: Calculate the savings from an optimized session

Compare (in your head) the quota cost between:

Scenario A: Opus + max for everything, for 2 hours Scenario B: An intelligent mix (like the worked example), for 2 hours

Summary

• The Claude 5 family: Opus 5 (flagship, 1M context, 128K output), Sonnet 5 (fast, balanced, 1M context, 128K output), and Haiku 4.5 (the fastest and cheapest, 200K context, 64K output). Plus Fable 5 (fable), the frontier model for the hardest work — premium in cost.
• Switching models: /model during the session, or Option+P/Alt+P — the context is preserved
• Opus for: Architecture, large refactoring, code review, complex debugging, codebase analysis
• Sonnet for: Quick fixes, boilerplate, standard implementation, questions, repetitive tasks
• Haiku for: Trivial questions, quick checks, basic formatting, tasks where cost matters more
• 5 effort levels (Opus 5, Sonnet 5, Fable 5): low → medium → high (default) → xhigh (recommended for coding) → max
• Effort is set with /effort, inside /model (the ← → arrow keys), the --effort flag, settings (effortLevel), or an env var (CLAUDE_CODE_EFFORT_LEVEL)
• opusplan: An alias that uses Opus to plan and Sonnet to execute, automatically
• Adapt per task: Switching models is like shifting gears — do it to match the terrain
• Start with Haiku/Sonnet, escalate to Opus if you need to: More efficient than always starting on Opus
• Real savings: An intelligent mix consumes ~3-4x less quota than using Opus + xhigh for everything

Next module: Module 03 - CLAUDE.md and the memory system — now that you have Claude Code configured with the right model, the next step is giving it context about your project so its answers get even more precise.

Additional resources

1. Model Configuration — Available models, aliases, effort levels, extended context, and opusplan
2. Fast Mode — How fast mode works and when to use it
3. Claude Code Settings — Setting the default model and effort
4. Claude Code CLI Reference — Complete reference of commands and flags
5. Manage Costs — Cost optimization, model selection, and reducing token usage
6. Claude Models — Specs and per-token pricing for each model