Opus vs Sonnet in Claude Code: Which Model to Use (and How to Switch)

You're deep in a Claude Code session, you hit a gnarly bug or a refactor that touches a dozen files, and the question surfaces: am I on the right model for this? Or the opposite — you've been letting Claude Code chew through routine edits on the most expensive model and your weekly limit is suddenly gone. Model choice in Claude Code is one of those settings most people leave on default and never revisit, and it quietly determines both how good your results are and how fast you burn through your quota.

This is a decision guide. We'll cover when Opus earns its cost over Sonnet, how to switch between them, and how that choice interacts with rate limits and pricing — using the current model lineup.

The current lineup

As of this writing, Claude Code's two workhorse models are Sonnet 4.6 and Opus 4.8, with Haiku 4.5 as the fast, cheap option for trivial work. Here's how they compare on the API price sheet, which is the clearest objective signal of the cost gap:

The /model aliases resolve to those versions on the Anthropic API (opus → Opus 4.8, sonnet → Sonnet 4.6). On other providers the aliases can point to different versions — on Claude Platform on AWS, opus resolves to Opus 4.7, and on Bedrock/Vertex/Foundry, opus → Opus 4.6 and sonnet → Sonnet 4.5. The aliases track the recommended version for your provider and shift over time, so don't hardcode a version assumption.

Anthropic's official guidance is blunt and worth internalizing: Sonnet "is the default and is the right choice for the large majority of coding work." Opus "offers deeper reasoning for harder problems such as large cross-cutting refactors, difficult debugging, or architectural decisions." Start from Sonnet; reach for Opus deliberately.

When Opus is worth it

The honest answer is: less often than you'd think. Sonnet 4.6 is fast, capable, and cost-efficient, and it handles the overwhelming bulk of coding — writing functions, fixing bugs with a clear repro, adding tests, wiring up an endpoint, explaining code. If the task is well-scoped and you can describe it clearly, Sonnet is almost always the right call.

Opus pulls ahead on a specific class of problems:

• Large cross-cutting refactors — changes that ripple through many files and require holding the whole system in mind at once.
• Difficult debugging — the kind of bug where the symptom and the cause are far apart, and you need the model to reason through multiple hypotheses.
• Architectural decisions — designing a module, choosing between approaches, planning a migration.

The common thread is reasoning depth under ambiguity. When the path forward isn't obvious and a wrong turn is expensive to unwind, Opus's deeper reasoning earns its higher cost. When the path is clear and you're mostly translating intent into code, you're paying a premium for capability you don't need.

A useful rule of thumb: plan on Opus, execute on Sonnet. Use Opus to think through the hard problem, then drop back to Sonnet to grind out the implementation. Anthropic built a mode that does exactly this automatically — more on that below.

How to switch models

Switching is immediate and non-destructive. Your conversation history and context carry over; only the model handling your next message changes.

Mid-session:

/model              # opens the interactive picker
/model opus         # switch directly to Opus
/model sonnet       # switch directly to Sonnet
/model haiku        # switch directly to Haiku

To check what you're currently on:

/status

In recent Claude Code versions (v2.1.153+), the /model picker saves your choice as the default for new sessions — pressing Enter switches and saves, while s switches for the current session only. Typing /model <name> behaves like Enter. (In the v2.1.144–v2.1.152 range the behavior was inverted: /model applied to the current session and d saved the default. If your version is in that window, check the picker's on-screen hints.)

Beyond the session, you have several ways to set the model, in priority order:

# Per-session, at startup:
claude --model opus

# Per-session, via environment variable:
ANTHROPIC_MODEL=opus claude

// Permanent default, in settings.json:
{ "model": "opus" }

The --model flag and ANTHROPIC_MODEL apply only to the session launched with them; settings.json makes it stick. For teams, enterprise admins can restrict which models are selectable via availableModels in managed/policy settings (e.g. ["sonnet","haiku"]), and a fallbackModel / --fallback-model chain handles cases where the primary model is overloaded.

opusplan: the best-of-both option

If "plan on Opus, execute on Sonnet" sounds appealing, you don't have to do it by hand. The opusplan alias is a hybrid mode that uses Opus during plan mode (complex reasoning and architecture) and automatically switches to Sonnet for execution (code generation and implementation). It only consumes Opus while you're actively in plan mode — everything else runs on Sonnet.

/model opusplan

For most developers on a budget-conscious plan, this is the sweet spot. You get Opus-grade planning on the parts that benefit from it without burning your Opus quota on routine implementation work. It's also the cheapest way to keep Opus-level planning quality without managing the switch manually.

How model choice interacts with limits and pricing

This is where model choice stops being abstract. On subscription plans, the model you pick directly determines how fast you hit a wall.

The cost gap is per-turn, not a fixed ratio. Anthropic's current framing is that "Opus costs several times more per turn than Sonnet, and Sonnet more than Haiku." Don't anchor on an exact multiplier — older figures floating around (Sonnet being "5x cheaper," fixed "hours per week" tables) refer to the previous Claude 4 generation and are stale. Treat any precise hours-per-week number you see online with suspicion.

Weekly limits on Max use two independent buckets:

• An overall all-models weekly limit.
• A separate Sonnet-only limit.

Opus usage counts only against the all-models limit. Sonnet usage counts against both. The practical consequence catches people off guard: heavy Sonnet use can exhaust the Sonnet-only bucket first, even when you still have all-models capacity left. If you find Sonnet locked out but Opus still works, that's why. On top of the weekly limits there's also a rolling session limit (roughly 5 hours).

Plan tiers (2026):

• Pro (~$20/month) — access to both Sonnet and Opus, but small weekly capacity. Heavy Opus use exhausts it fast; opusplan or selective manual switching is the realistic way to touch Opus here.
• Max 5x ($100/month) and Max 20x ($200/month) — both models, substantially more weekly capacity. This is what makes meaningful Opus use practical.

Effort levels compound the cost. Effort (adaptive reasoning depth) is a separate dial that interacts with model choice — higher effort means more tokens and faster quota drawdown. Opus 4.8 supports low/medium/high/xhigh/max; Sonnet 4.6 supports low/medium/high/max. Both default to high. For most work, Sonnet at default effort is plenty. Reserve high or xhigh effort on Opus for the problems where correctness genuinely outweighs cost. Set it with /effort, --effort, the CLAUDE_CODE_EFFORT_LEVEL env var, or effortLevel in settings.

One more wrinkle — the 1M context window. Both Opus and Sonnet have a 1M-token context, but accessing it differs by plan. On Max/Team/Enterprise, Opus is automatically upgraded to 1M context (including the plan-mode Opus phase of opusplan). Sonnet's 1M requires usage credits on every plan, including Max. On Pro, both Opus and Sonnet at 1M require usage credits. Request it explicitly with /model opus[1m] or /model sonnet[1m].

A simple decision flow

Putting it together:

1. Default to Sonnet. It's the right call for most coding, and on Pro/Team Standard/Enterprise seats it's already your default.
2. Hit a hard problem — a sprawling refactor, a subtle bug, an architecture call? Switch to Opus (/model opus) for that stretch, then switch back.
3. Want it automatic? Use opusplan so Opus handles planning and Sonnet handles execution.
4. Watching your quota? Check /status, lean on Sonnet and opusplan, and keep effort at default unless a task demands more.

Bottom line

Sonnet 4.6 is the workhorse and the default for good reason — it's fast, cheap, and handles the large majority of coding work. Opus 4.8 is the specialist you call in for deep reasoning: big refactors, hard debugging, architecture. The cost difference is real and per-turn, and on subscription plans it translates directly into how fast you hit your weekly limits — with the added quirk that Sonnet draws down two buckets while Opus draws down one. Switching is a single /model command away, your context carries over, and opusplan gives you Opus-quality planning without the Opus-sized bill. Set your default deliberately, switch when the problem warrants it, and you'll get better results without torching your quota.