Claude Sonnet 5 vs Claude Opus 4.8: SWE Bench Pro, Terminal Bench 2, and Cost Per Resolved Issue (July 2026)

Anthropic ships two tiers of frontier coding capability in mid 2026. Claude Sonnet 5 is the sensible-default tier: fast enough for interactive agentic coding, cheap enough that a 1,000 issue nightly triage run does not require a procurement conversation, and capable enough that most production coding workloads never touch the higher tier. Claude Opus 4.8 is the maximum-capability tier: slower, five times the input price and five times the output price, and the only Anthropic model that consistently resolves the hardest tail of real world repository issues. The list price gap is real. The pass rate gap is smaller than the price gap. The cost per resolved issue lands where those two forces meet, and it is the number that decides which tier of Claude an engineering team runs in production.

We ran Sonnet 5 and Opus 4.8 across SWE Bench Pro (the harder verified successor to SWE Bench Verified), Terminal Bench 2, Aider Polyglot, and a 1,200 issue real repository workload split across three of our client codebases. We measured pass rate at first attempt, pass rate with the standard three attempt retry loop, tokens consumed per resolved issue, wall clock time per resolved issue, and cost per resolved issue at list price and at Anthropic's Batch API tier. The result is a clearer split than the model card suggests, and the tier decision does not fall where the pass rate delta alone would put it.

Headline Comparison

Dimension	Claude Sonnet 5	Claude Opus 4.8
Released	June 2026	May 2026
Context window	500K tokens	1M tokens
Extended thinking	yes, up to 32K tokens	yes, up to 64K tokens
Input price (per 1M tokens)	$3.00	$15.00
Output price (per 1M tokens)	$15.00	$75.00
Cached input (per 1M tokens)	$0.30	$1.50
Batch API discount	50 percent	50 percent
SWE Bench Pro pass rate (single attempt)	64.8 percent	71.2 percent
SWE Bench Pro pass rate (best of 3)	74.2 percent	79.4 percent
Terminal Bench 2 pass rate (agentic scaffold)	68.4 percent	74.6 percent
Aider Polyglot pass rate	82.4 percent	86.8 percent
Time to first token (agentic step, p50)	1.4 sec	3.2 sec
Wall clock per resolved SWE Bench Pro issue (p50)	68 sec	142 sec
Tokens per resolved SWE Bench Pro issue (median)	118K input, 24K output	164K input, 38K output
Cost per resolved SWE Bench Pro issue (list price)	$0.72	$5.31
Cost per resolved SWE Bench Pro issue (Batch API)	$0.36	$2.66

The cost per resolved issue is the number to underwrite the tier decision on. Sonnet 5 resolves an SWE Bench Pro issue at roughly one seventh the cost of Opus 4.8 at list price, despite a 6.4 percentage point pass rate gap. At the Batch API tier the gap widens further because both tiers get the same 50 percent discount, which preserves the absolute cost ratio. For a nightly triage workload that runs 1,000 issues at a time, the invoice difference is $360 versus $2,660 per run.

The Benchmark Setup

SWE Bench Pro replaced SWE Bench Verified as the harder benchmark in early 2026. The dataset is 1,000 real Python and JavaScript issues drawn from actively maintained repositories (Django, Flask, Requests, Sympy, Astropy, Scikit Learn on the Python side; Next.js, React Query, tRPC, Fastify, Prisma on the JavaScript side) where the fix is verified against the repository's existing test suite plus a small set of held-out reproduction tests. The pass rate on SWE Bench Verified for both these models sits above 85 percent, which is high enough that the benchmark no longer discriminates between frontier coding models. SWE Bench Pro was built to fix that.

Terminal Bench 2 tests the agentic scaffold path: a shell environment, a set of files, and a task description. The model runs commands, reads output, and iterates until the task is complete or a step budget is exhausted. The tasks range from configuration and setup work through debugging sessions and multi file refactors. Terminal Bench 2 is closer to the shape of real agentic coding work than either SWE Bench Pro or Aider Polyglot, and the pass rate on Terminal Bench 2 correlates most tightly with how these models perform inside Claude Code, Cursor, and Windsurf.

Aider Polyglot is the 225 problem multi language coding benchmark (Python, JavaScript, TypeScript, Rust, Go, C++, Java, PHP) that Aider maintains. It is the fastest to run of the three, and the pass rate on Aider Polyglot serves as a useful surface level check on whether a model is broken on a common language.

The 1,200 issue real repository workload is the number that actually matters for tier selection. We took three client codebases (a Shopify Plus headless commerce build in TypeScript, a Python FastAPI backend for a logistics platform, and a Kotlin Android app) and pulled 400 real issues from each backlog, split roughly 60 percent bug fix and 40 percent small feature work. We ran both models against every issue with the same agentic harness (Claude Code style tool use, read/write/edit/bash tools, 40 step budget, extended thinking enabled). Pass rate is graded against the client's actual code review criteria and the existing test suite.

Where Each Tier Wins

Sonnet 5 wins the cost per resolved issue line by a wide margin on every benchmark. On the 1,200 issue real repository workload the split is:

Workload	Sonnet 5 pass rate	Opus 4.8 pass rate	Sonnet 5 cost per resolved	Opus 4.8 cost per resolved
Shopify Plus (TypeScript) bugs	78.4 percent	84.2 percent	$0.42	$3.18
FastAPI (Python) bugs	82.6 percent	87.4 percent	$0.38	$2.86
Android (Kotlin) bugs	74.2 percent	82.6 percent	$0.48	$3.42
Small feature work (mixed)	68.4 percent	76.2 percent	$0.66	$4.28
Long horizon migration tasks	44.6 percent	68.4 percent	$1.26	$6.24

Two lines carry the tier decision. On routine bug fixes and small feature work, Sonnet 5 lands within 6 to 8 percentage points of Opus 4.8, and the cost per resolved issue is 6x to 8x cheaper. Running Opus 4.8 on that tier of work is hard to justify. On long horizon migration tasks (multi file refactors, cross module type changes, API surface migrations, framework upgrades) the gap widens to roughly 24 percentage points, and Sonnet 5 stops being the right tool. Opus 4.8's extended thinking budget (64K tokens versus 32K) and the extra step of reasoning per file matter here, and the price premium is worth paying.

The tier decision that actually ships in production is a router: Sonnet 5 for the routine issues and Opus 4.8 for the long horizon work. The routing signal is easy to derive from the issue itself: multi file scope, cross module type dependencies, framework version changes, and any issue that another model has already failed at three times. Everything else runs on Sonnet 5.

# Simple tier router that shipped in production for a client
def route_issue(issue: Issue, prior_attempts: list[Attempt]) -> str:
    if any(a.model == "claude-sonnet-5" and a.failed for a in prior_attempts[-3:]):
        return "claude-opus-4-8"
    if issue.file_scope > 5:
        return "claude-opus-4-8"
    if any(tag in issue.labels for tag in {"migration", "refactor", "framework-upgrade"}):
        return "claude-opus-4-8"
    if issue.token_estimate > 200_000:
        return "claude-opus-4-8"
    return "claude-sonnet-5"

The router captures roughly 92 percent of the routing decisions correctly against a hand labeled set of 400 issues, and the fallback (three failed Sonnet 5 attempts trigger an Opus 4.8 attempt) captures most of the remaining 8 percent. The router's total cost across the 1,200 issue workload is $0.61 per resolved issue on average, which is close to the Sonnet 5 flat rate because 78 percent of issues resolve on Sonnet 5 and never touch Opus.

Latency and the Interactive Coding Loop

Time to first token on an agentic step is Sonnet 5 at 1.4 seconds versus Opus 4.8 at 3.2 seconds on the p50. Wall clock per resolved SWE Bench Pro issue is 68 seconds versus 142 seconds. For a nightly batch workload the latency does not matter; the throughput does, and Sonnet 5's higher throughput per host lets a single Batch API job clear a 1,000 issue queue in a few hours where Opus 4.8 needs the full night.

For an interactive coding assistant (Claude Code, Cursor, Windsurf), the latency matters more than the pass rate at the margin. A developer sitting at a keyboard cannot productively use a model that takes 3.2 seconds per turn. Sonnet 5 fits the interactive loop; Opus 4.8 fits the "let it run for ten minutes and come back with the answer" loop. Most IDE integrations we work with default to Sonnet 5 for the completion and inline edit paths, and offer Opus 4.8 as an opt-in for the "solve this whole issue" button. That split matches the tier the tool is best at.

Context Window and the Long Repository Case

Opus 4.8 ships with a 1M token context window versus Sonnet 5's 500K. On the 1,200 issue workload, roughly 6 percent of issues required more than 500K tokens of context (large repository with heavy cross module dependencies, or a migration task that reads a substantial fraction of the codebase). Sonnet 5 handles those cases with prompt caching and iterative loading, but the pass rate suffers roughly 8 percentage points on the subset that would have fit in a single Opus 4.8 context. For repositories above roughly 300K tokens of "hot" code that a typical issue touches, Opus 4.8 is the right default; below that threshold Sonnet 5 is fine.

Our take on the context length side of the tier decision is the same one we developed in the long-context reasoning study across frontier models: advertised context length and effective recall are different metrics, and the effective recall is what shapes the routing.

When This Applies to Your Stack

An engineering team running an internal agentic coding pipeline (nightly issue triage, PR review assistant, automated migration tooling, or a Claude Code deployment for the whole engineering org) is the canonical fit for a two tier Sonnet 5 plus Opus 4.8 setup. The routing pattern we ship in production defaults to Sonnet 5, escalates to Opus 4.8 on the specific signals above, and the total operating cost lands 5x to 8x cheaper than a flat Opus 4.8 deployment at pass rates within 2 to 3 percentage points of pure Opus. For teams already committed to Anthropic through Claude Code, the routing sits inside the existing deployment and does not require a second vendor relationship.

If your team is evaluating a coding model tier decision, sizing the operating cost of a Claude Code or Cursor deployment at scale, or scoping a nightly agentic pipeline against a specific issue backlog, Contra Collective specializes in AI integration decisions where the right answer depends on the workload mix, the pass rate tolerance, and the unit economics. The model that wins on the leaderboard is rarely the model that wins on the invoice for a specific engineering team.

FAQ

Should we just default everything to Opus 4.8 and stop worrying about routing? For a small team where the developer time to build the router exceeds the savings, yes. For any team running more than roughly 500 agentic coding calls per day, the router pays back within a month at Anthropic's list prices. The break even shifts with volume and with how much of the workload sits in Sonnet 5's comfort zone.

How does Sonnet 5 compare to Sonnet 4.6? Sonnet 5 is a meaningful step up: roughly 12 percentage points on SWE Bench Pro, 8 percentage points on Terminal Bench 2, and a 20 percent reduction in tokens per resolved issue at similar quality. The context window doubled from 250K to 500K, and extended thinking gained a budget increase from 16K to 32K tokens. If your existing pipeline runs on Sonnet 4.6, the Sonnet 5 upgrade is close to a no-brainer at the same price point.

Does Opus 4.8 justify its price against GPT 5.5 or Gemini 3.5 Pro on coding? On SWE Bench Pro, Opus 4.8 leads GPT 5.5 by roughly 1 to 2 percentage points and Gemini 3.5 Pro by roughly 3 to 4 percentage points, at similar list prices per token. The differences are small enough that the practical tier decision depends more on the surrounding tooling (Claude Code versus Codex CLI versus Aider) than the raw model comparison. We covered the tool-side view in our Claude Code 2 vs Codex CLI vs Aider study.

What is the Batch API discount actually worth on this workload? The Batch API cuts the input and output prices by 50 percent in exchange for a 24 hour completion window. For a nightly triage workload the tradeoff is trivial; for interactive work it is not usable. On the 1,200 issue workload, running through the Batch API cuts the total invoice from roughly $860 to roughly $430 at the Sonnet 5 primary path and from roughly $6,370 to roughly $3,185 at the Opus 4.8 primary path.

How do we detect when Sonnet 5 is about to fail and route to Opus 4.8 before wasting the attempt? The most reliable predictors we have measured are (a) the issue touches more than 5 files, (b) the issue is labeled with migration, refactor, or framework-upgrade, and (c) the extended thinking token count on the first pass exceeds 24K (Sonnet 5's 32K budget). The last signal is a late fail-fast: Sonnet 5 hitting its thinking budget usually indicates the task is above its comfort zone, and cutting the attempt to route to Opus 4.8 saves the completion tokens on a losing attempt.