Claude Code Opus vs Sonnet: When to Use Each (And How to Save on Both)

Opus is 5x the price of Sonnet. Per million tokens, you're paying $15 input / $75 output for Opus versus $3 input / $15 output for Sonnet. On a typical coding task, that's the difference between $2.25 and $0.45. Over a full day of coding, it's the difference between $10-12 and $2-3.

Yet many developers default to Opus for everything because "it's smarter." That instinct is wrong 70-80% of the time — and it's costing them $150+ per month in unnecessary spend.

The Real Price Difference in Dollar Terms

Abstract per-token pricing obscures the actual cost impact. Here's what Opus vs Sonnet looks like in real-world coding scenarios:

Per-task cost (average coding task, ~30K input + ~5K output tokens):

• Sonnet: $0.09 input + $0.075 output = $0.17 per task
• Opus: $0.45 input + $0.375 output = $0.83 per task

Per-session cost (3-hour coding session, ~200K input + ~40K output tokens):

• Sonnet: $0.60 input + $0.60 output = $1.20 per session
• Opus: $3.00 input + $3.00 output = $6.00 per session

Daily cost (2-3 sessions, ~500K input + ~100K output tokens):

• Sonnet: $1.50 input + $1.50 output = $3.00 per day
• Opus: $7.50 input + $7.50 output = $15.00 per day

Monthly cost (20 coding days):

• Sonnet-only: $60/month
• Opus-only: $300/month
• Difference: $240/month, or $2,880/year

That $240/month gap is not a rounding error. It's the cost of a junior developer's tooling budget, a production database tier, or five months of Pro subscription. The question isn't whether the price difference matters — it's whether Opus delivers 5x the value.

Where Opus Actually Outperforms Sonnet

Opus is genuinely superior for a specific class of problems. Understanding that class is the key to spending those 5x premiums wisely.

Complex Multi-File Refactors

When a refactor touches 8-15 files with interdependent changes — renaming a core abstraction, restructuring a module boundary, migrating a data model — Opus maintains coherence across the entire change set better than Sonnet. It holds the full picture in working memory and produces changes that are internally consistent.

Sonnet handles refactors across 3-5 files well. Beyond that, it starts losing track of cascading changes, producing edits that conflict with each other or miss downstream dependencies.

Subtle, Non-Obvious Bugs

Race conditions. Off-by-one errors in state machines. Authentication bypasses hidden in edge cases. Bugs where the code "looks correct" but fails under specific conditions. Opus has a measurably better hit rate on these problems because it explores more hypotheses before settling on a diagnosis.

Sonnet tends to fix the obvious symptom. Opus investigates the underlying cause. On a concurrency bug, the difference might be Sonnet adding a mutex (fixing the symptom) versus Opus restructuring the shared state to eliminate the race condition entirely.

Novel Architectural Patterns

When you're building something that doesn't follow a common pattern — a custom state machine, a novel caching strategy, a domain-specific language — Opus generates more creative and structurally sound solutions. It has a better grasp of design trade-offs and can reason about non-obvious interactions.

Large-Scale Code Generation

Tasks that require generating 200+ lines of cohesive code — a complete module, a comprehensive test suite, an API client — benefit from Opus's ability to maintain structural consistency over long outputs. Sonnet sometimes loses the thread in longer generations, producing code that starts strong but drifts in style or logic.

The Common Thread

Opus excels when the task requires holding a large mental model in working memory and reasoning across multiple dimensions simultaneously. If you can describe the task in a single sentence with a clear scope, Sonnet handles it. If explaining the task requires a paragraph with caveats and edge cases, consider Opus.

Where Sonnet Matches Opus (70-80% of Tasks)

Here's the part that saves you $240/month: for the majority of everyday coding tasks, Sonnet produces output that is functionally identical to Opus.

Feature Implementation

Adding a new API endpoint. Implementing a React component from a design spec. Building a CLI command. Writing a database migration. These are well-defined tasks with clear inputs and outputs. Sonnet handles them efficiently because the patterns are established and the scope is contained.

Sonnet performance vs Opus on feature tasks: virtually identical when the context is clear. The keyword is "when the context is clear" — we'll come back to that.

Bug Fixes (Straightforward)

Null reference errors. Missing error handling. Incorrect API response parsing. Wrong query parameters. Bugs where the fix is locating the problem and applying a known pattern. Sonnet is fast and accurate on these — often faster than Opus because it doesn't over-analyze.

Test Writing

Unit tests, integration tests, and end-to-end test scaffolding. Given a function and its expected behavior, both models produce equivalent test suites. Sonnet sometimes writes slightly less comprehensive edge-case coverage, but the difference is marginal and easily addressed with a follow-up prompt.

Code Cleanup and Formatting

Extracting functions, renaming variables, removing dead code, adding TypeScript types, reorganizing imports. These mechanical tasks don't benefit from Opus's deeper reasoning. Sonnet executes them quickly and correctly.

Documentation

JSDoc comments, README updates, API documentation, inline comments. Both models write equally good documentation when given the relevant code context.

Configuration and Boilerplate

Dockerfile creation, CI pipeline configuration, linter setup, package.json updates, environment variable management. Template-driven tasks where the challenge is knowing the right syntax and structure, not reasoning about complex logic.

How Context Quality Changes the Equation

This is the insight that transforms the Opus-vs-Sonnet decision from "pick the smarter model" to "optimize the context first."

Sonnet with excellent context performs at the level of Opus with mediocre context.

Here's why. Most of Opus's advantage comes from its ability to reason about code it hasn't seen — to infer relationships, guess at types, and navigate ambiguity. When you give Sonnet the same information upfront — the exact function signatures, the dependency graph, the relevant type definitions — it doesn't need to infer. It has the answers.

A context engine like vexp eliminates the information gap between models by serving pre-computed, dependency-ranked context for every task. The agent doesn't need to explore or infer — it receives exactly the code symbols, types, and relationships relevant to the current task.

The practical result:

• Opus + no context engine: Reads 20 files, infers dependencies, produces correct output after exploring. Cost: $2.25/task.
• Sonnet + vexp context: Receives pre-computed context, produces correct output immediately. Cost: $0.17/task.
• Quality difference: Negligible for 70-80% of tasks.

This is a 13x cost reduction for equivalent output quality. The context engine doesn't make Sonnet smarter — it makes Sonnet's context as good as what Opus figures out through expensive exploration.

The Optimal Model Switching Strategy

Based on task type and context quality, here's the model allocation that minimizes cost without sacrificing output quality:

Default: Sonnet (70-80% of tasks)

Start every session with Sonnet. Use it for feature implementation, bug fixes, test writing, code cleanup, documentation, and configuration. With a context engine providing relevant code, Sonnet handles these tasks as well as Opus.

Upgrade to Opus: When You Hit a Wall (15-25% of tasks)

Switch to Opus when:

• Sonnet's output is wrong or incomplete after one retry
• The task involves 5+ files with complex interdependencies
• You're debugging a subtle behavior that Sonnet can't diagnose
• You need to generate a large, cohesive code module from scratch
• The problem requires novel architectural reasoning

Use the `/model` command in Claude Code to switch: `/model opus`. Switch back to Sonnet after completing the complex task.

Never Opus: Mechanical Tasks (5-10% of tasks)

Some tasks should never use Opus regardless of difficulty:

• Formatting and style changes
• Import reorganization
• Adding log statements
• Simple rename refactors
• Copy-paste-modify boilerplate

These are token-in, code-out tasks with zero reasoning requirement.

Combined Savings Calculation

Let's calculate the full savings from model switching combined with context optimization.

Baseline: Opus-only developer, no context engine

• 10 tasks/day x $2.25/task = $22.50/day
• 20 coding days/month = $450/month

Step 1: Model switching (Sonnet 75%, Opus 25%)

• 7.5 tasks x $0.45 + 2.5 tasks x $2.25 = $3.38 + $5.63 = $9.00/day
• Monthly: $180/month
• Savings: $270/month (60% reduction)

Step 2: Add context engine (58% token reduction)

• Sonnet tasks: 7.5 x $0.17 = $1.28
• Opus tasks: 2.5 x $0.83 = $2.08
• Daily: $3.36/day
• Monthly: $67/month
• Total savings: $383/month (85% reduction from baseline)

From $450/month to $67/month. That's the combined effect of two decisions: using the right model for each task, and giving every model better context.

Making the Switch: Practical Implementation

Week 1: Baseline

Track your current Opus usage with ccusage or the Anthropic console. Note which tasks you use Opus for and whether Sonnet could have handled them.

Week 2: Model Switching

Default to Sonnet for all tasks. Only switch to Opus when Sonnet fails or when you identify a task from the "Opus-excels" category above. Track the switch rate.

Week 3: Add Context Optimization

Install vexp or another context engine. Continue the Sonnet-default strategy with context-enriched sessions. Track token usage and compare against Weeks 1 and 2.

Expected Results

Most developers find that their Opus usage drops to 15-25% of tasks once they start paying attention to which tasks actually need it. Adding context optimization further reduces the need for Opus by giving Sonnet the information it needs to match Opus's output quality.

The Bottom Line

Opus is a better model. It's not 5x better. For the majority of coding tasks, Sonnet with good context matches Opus with no context — at one-fifth the price.

The optimal strategy isn't "always Opus" or "always Sonnet." It's Sonnet by default, Opus by exception, combined with a context engine that elevates Sonnet's effective capability. This approach delivers the same output quality at $67/month instead of $450/month.

That $383/month in savings isn't a sacrifice — it's the result of matching your tools to your tasks instead of paying a premium for capability you don't need 75% of the time.