Sonnet 5 vs Sonnet 4.6 vs Opus 4.8

Benchmark Comparison

Figures are percentages except GDPval-AA v2, which is an Elo-style rating. Opus 4.8 is shown for reference as the flagship tier. Sonnet 5's column is highlighted as the featured model.

A short read of the numbers

The headline story is generational improvement in the mid tier. Across every benchmark, Sonnet 5 beats Sonnet 4.6 — often by wide margins. On Terminal-Bench 2.1 it jumps from 67.0% to 80.4% (+13.4 points), and on Humanity's Last Exam it gains roughly 9–11 points both with and without tools. The GDPval-AA v2 knowledge-work rating leaps from 1395 to 1618, a 223-point Elo swing that reflects a substantially more capable model on real-world tasks.

More striking is how close Sonnet 5 gets to the flagship. On the "with tools" Humanity's Last Exam (57.4% vs 57.9%) and on GDPval-AA v2 (1618 vs 1615) it is effectively level with Opus 4.8 — and on knowledge work it nudges just ahead. On computer use (81.2% vs 83.4%) and Terminal-Bench (80.4% vs 82.7%) it trails by only about two points.

Where Opus 4.8 still holds a clear edge is the hardest raw-reasoning and agentic-coding tests: SWE-bench Pro (69.2% vs 63.2%, a 6-point gap) and no-tools Humanity's Last Exam (49.8% vs 43.2%). The takeaway: Sonnet 5 offers most of Opus 4.8's capability at the mid tier, making it the sensible default for everyday coding and knowledge work — while Opus 4.8 remains the pick when you need the extra margin on the toughest problems.

Note: What You Should Know About Comparing AI Models

Putting two large language models (LLMs) side by side on a scoreboard is easy — picking the right one for your actual work is the hard part. Benchmark numbers tell a useful story, but only if you know what each test measures, where the numbers lie, and which trade-offs actually matter for your task. Here is the crash course on how to read a model comparison like a pro.

Benchmarks: the scoreboard — and its limits

• Benchmarks are standardized test sets that measure one slice of capability. SWE-bench, for example, feeds models real GitHub issues and checks whether their code edits make the tests pass — a solid proxy for software engineering skill, not a measure of general intelligence.
• Agentic and terminal benchmarks (like Terminal-Bench) test whether a model can drive a command line: write scripts, run commands, read errors, and iterate. A model can ace multiple-choice questions and still flounder here.
• Computer-use benchmarks such as OSWorld put a model in charge of a real desktop environment and ask it to click, type, and navigate apps — closer to a human assistant than a chatbot, and far harder than a text quiz.
• Knowledge-work and Elo-style benchmarks (like GDPval) score models on open-ended professional tasks — research, drafting, analysis — and rank them by pairwise comparison instead of right/wrong answers.
• Hard question sets such as Humanity's Last Exam are designed so that even the best models score surprisingly low. Double-digit scores there are normal and expected; the point is to separate the front-runners, not to hit 90 percent.
• Scores can be gamed or polluted: models occasionally see benchmark questions during training ("contamination"), and a few points of difference on one run can fall within normal randomness. Never marry a single number.

The "with tools vs. no tools" asterisk

• Many models can now use tools: search the web, run code, call APIs. A benchmark taken "with tools" lets the model reach for external help, which is usually much harder than it sounds — the model must decide when to delegate, not just answer.
• When two models look close in the "no tools" column, run the comparison again with tool use enabled — the gap often widens or flips entirely.

Context windows: how much the model can hold in its head

• Context is measured in tokens, not words. As a rough rule of thumb, one token is about three-quarters of an English word, so a large context window can swallow a full book or a hefty codebase in a single prompt.
• Bigger windows are seductive but not free: every extra token costs memory and slows the model down, and processing a 200,000-token prompt is far slower than answering a short chat message.
• Long inputs also invite the "lost in the middle" effect — models often handle the start and end of a long document well while details buried in the middle get ignored. Flag important instructions at the top.
• For genuinely huge documents, don't dump everything in: retrieve the relevant slices first (retrieval-augmented generation, or RAG) or summarize in layers. The best context strategy is sending less, better-chosen text.

Speed vs. reasoning: the classic trade-off

• Reasoning models spend extra compute "thinking" before they answer — they emit hidden chain-of-thought tokens that make them markedly better at math, logic, and multi-step planning, at the cost of slower, pricier replies.
• For simple jobs — summarization, classification, translation, quick Q&A — a fast non-reasoning model will usually beat a slow reasoning model on both latency and cost. Use the big brain only when the task needs it.
• Reasoning shines in agentic loops: coding agents, deep research, and anything with a chain of decisions. If your workload is repetitive and well-specified, the extra thinking is wasted compute.

Price: the number under the numbers

• API pricing is quoted per million tokens, with separate rates for input and output — and output tokens almost always cost two to five times more than input, so chatty models hurt your bill fast.
• Many providers offer context caching: repeated prefixes like system prompts and shared RAG material get served at a deep discount. Long-running agents that resend the same preamble can save a lot this way.
• Keep in mind that every provider tokenizes text slightly differently, so a gem of text counts as a different number of tokens on each service — compare cost on your own documents, not on marketing math.
• The right price-performance strategy is simple: pick the cheapest model that reliably passes your own tests, and save the flagship for the hardest five percent of requests.

Matching the model to the job

• Coding agents want a model with strong tool use, a big context window, and terminal chops — the top of the SWE-bench and Terminal-Bench tables is a fair guide, but the real test is your own repository.
• Computer-use models power UI automation and virtual assistants; verify them against your actual desktop apps, because every interface behaves differently in practice.
• Mid-tier models are quietly the best default for most everyday work: they deliver most of the flagship's capability at a fraction of the cost, which is exactly why "mid-tier" is where most teams land.
• Specialized jobs like structured data extraction, classification, or bulk translation rarely need the strongest model — a small, fast, cheap one handles them at scale.

Three habits of smart model shoppers

• Build a mini-evaluation of your own: twenty real prompts from your workflow, run under identical settings, scored by your own criteria. A 20-question eval on your data beats any headline score.
• Read the model card and release notes before believing the hype — vendors document what changed, what regressed, and which settings they recommend.
• Recheck often: the model landscape moves every few weeks. A model that was mid-pack last quarter may now be the best value, and a "winner" today may be dethroned next release — run your eval again and let the results, not the marketing, decide.