Claude Sonnet vs Opus: Which Model Should You Actually Use?

Sonnet 4.6 scores 79.6% on SWE-bench Verified, just 1.2 percentage points behind Opus 4.6's 80.8%. That gap is the narrowest between any Sonnet and Opus generation. More notably, Sonnet 4.6 became the first Sonnet model to beat the previous-generation Opus on coding evaluations. For developers who assumed Opus was always the better coding model, this changes the calculation.

But coding benchmarks only tell part of the story. On GPQA Diamond, a graduate-level science reasoning benchmark, Opus scores 91.3% compared to Sonnet's 74.1%. That 17.2-point gap reveals where Opus actually earns its premium: tasks that require deep, multi-step analytical reasoning rather than well-scoped code generation.

Here is a quick reference for the current model lineup:

Sonnet 4.6: $3 input / $15 output per million tokens. 1M context window. 79.6% SWE-bench Verified. Best for production workloads, iterative development, and most coding tasks.

Opus 4.6: $5 input / $25 output per million tokens. 1M context window. 80.8% SWE-bench Verified. Best for complex reasoning, multi-file refactoring, and long-running agentic workflows.

Haiku 4.5: $1 input / $5 output per million tokens. 200K context window. Best for classification, extraction, intent routing, and high-volume processing.

The pricing gap is smaller than most developers expect. Opus costs roughly 67% more than Sonnet per token, not the 5x that older comparisons sometimes claim. With prompt caching and batch processing, the effective premium shrinks further. The question worth answering is not "which model is better" but "which 20% of your workload actually benefits from the premium."

Opus does not outperform Sonnet on everything. On simple, well-scoped tasks like writing individual functions, generating test suites, or answering direct questions, production measurements show near-parity. The gap opens under specific, identifiable conditions.

Consider a concrete example: refactoring an authentication module that touches route handlers, middleware, database models, and session management across 15 files. Sonnet can handle each file individually, but it tends to miss cascading type changes or forget that a renamed method in the auth service breaks a call site three files away. Opus, given the same context window, catches those cross-file dependencies on the first pass. The constraint is context utilization: Opus's advantage grows as you load more interdependent files into a single request. Below about 5 files with minimal coupling, both models perform equally well.

For the majority of real development work, Sonnet 4.6 is the right default. It delivers 98% of Opus's coding performance at roughly 60% of the cost, and its faster response times make iterative workflows feel noticeably snappier.

Single-file code generation. Writing new functions, components, or modules from a clear spec is Sonnet's strongest use case. The model generates clean, well-structured code with reliable consistency. Unless the implementation requires reasoning about complex cross-cutting concerns across multiple systems, Sonnet handles it well.

Bug fixes with clear error context. When you have an error message, a stack trace, or a failing test, Sonnet resolves the issue as effectively as Opus. The reasoning demands of "here is what broke, fix it" fall well within Sonnet's capabilities.

Customer-facing applications. Chatbots, support systems, and conversational interfaces benefit from Sonnet's lower latency. For most conversational tasks, users cannot distinguish Sonnet's output quality from Opus's output quality, making the cost savings significant at volume.

Document processing and extraction. Parsing PDFs, extracting structured data, summarizing reports, and classifying content are tasks where Sonnet performs on par with Opus. These workloads also tend to run at high volume, which makes Sonnet's lower per-token cost a meaningful advantage. Tools like Fast.io's Metadata Views can handle the structured extraction layer itself, and either model works equally well for preparing or post-processing those documents.

Iterative development loops. When you work through a problem by making small changes, testing, and iterating, whether in Claude Cowork, Claude Code, or the API, Sonnet's faster response times compound into real productivity gains. A few seconds saved per round-trip adds up across hundreds of interactions in a workday.

The pattern is consistent: if a task has well-defined boundaries and does not require reasoning about multiple interconnected systems simultaneously, Sonnet handles it. Save Opus for work that genuinely needs the extra reasoning depth.

Persist agent outputs across Sonnet and Opus workflows

Fast.io gives agents 50GB of free storage, a Streamable HTTP MCP server, and workspace intelligence for semantic search. No credit card, no trial, no expiration.

Sign Up Free

The raw per-token pricing tells a clean story: Opus charges $5 input and $25 output per million tokens, Sonnet charges $3 and $15. That is a 67% premium. But raw pricing rarely reflects what teams actually pay in production.

Prompt caching changes the math. Both models support prompt caching, which reduces the cost of repeated input tokens by 90%. If you send the same system prompt, few-shot examples, or large context documents across multiple requests, caching cuts your input costs regardless of model tier. A 5-minute cache write costs 1.25x the base input price. A 1-hour cache write costs 2x. Cache reads cost 0.1x, which is where the savings show up on repeated calls.

Batch processing for async work. The Batch API offers a flat 50% discount on both input and output tokens. Sonnet via batch drops to $1.50 input and $7.50 output per million tokens. Opus drops to $2.50 and $12.50. For workloads that tolerate higher latency, like report generation, bulk analysis, or nightly processing runs, batch mode dramatically reduces costs for both tiers.

Per-request math. A typical coding request with 2,000 input tokens and 8,000 output tokens costs about $0.13 with Sonnet and about $0.21 with Opus. The difference is roughly 8 cents per request. At 100 requests per day, that gap is $8. At 1,000 requests per day on an API-driven product, it is $80. Whether that matters depends entirely on whether Opus reduces your retry rate enough to offset the premium.

The retry cost of choosing wrong. Cheaper per-token pricing does not always mean cheaper total cost. If Sonnet fails on a complex reasoning task and requires two or three follow-up turns to reach the right answer, those extra turns can exceed the cost of a single Opus request that gets it right the first time. The most effective optimization is tracking your actual retry rates by task type and routing accordingly.

Haiku for background work. Haiku 4.5 at $1 input and $5 output per million tokens handles classification, intent routing, content filtering, and simple extraction well. Offloading these tasks to Haiku frees your Sonnet and Opus budgets for work that needs the capability. A three-tier routing strategy (Haiku for simple tasks, Sonnet for standard work, Opus for complex reasoning) can cut API costs by 40-60% compared to running everything on a single tier.

The 80/20 rule maps directly to model selection: route roughly 80% of tasks to Sonnet and escalate the remaining 20% to Opus. The practical challenge is making that routing automatic instead of manual.

Start every task on Sonnet. Set Sonnet 4.6 as your default model for all new sessions, whether you work in Claude Cowork, Claude Code, or the API. Most tasks complete successfully on the first attempt without escalation.

Define your escalation triggers. Move to Opus when you see these patterns: the task involves more than 10 files with shared dependencies, the response contains logical contradictions or missed edge cases you can identify, the work requires reasoning about system architecture across multiple services, or the agent session will run autonomously for more than 30 minutes without human checkpoints.

Persistent state across model tiers. When agents switch between Sonnet and Opus mid-workflow, their outputs need to persist across the transition. You could use a local directory structure, S3 with a naming convention, or a managed workspace that handles indexing and access control. Fast.io works well for this because agents on either model can read and write to the same workspace via MCP at /mcp or the REST API. Files are auto-indexed for semantic search and RAG chat once Intelligence is enabled, so downstream agents or humans can query what was produced without manually tracking outputs. The free tier (50GB, 5,000 credits/month) covers most development workflows without a credit card.

Automated routing with Haiku. For API-driven pipelines, use Haiku 4.5 as a lightweight classifier at the front of the queue. It reads the task description, estimates complexity based on file count and dependency depth, and returns a model recommendation. The actual work then goes to Sonnet or Opus based on that classification. The classification call itself costs a fraction of a cent.

Human-agent handoff. In collaborative workflows, an agent can draft work on Sonnet, a human reviews and flags the sections that need deeper reasoning, and those specific sections get re-processed on Opus. The final output goes back to a shared workspace where both agents and humans can access it. Ownership transfer lets agents build workspaces and hand them to humans while retaining admin access for future iterations.