Claude Sonnet 3.5 / 4 – the middle tier analyzed
Technical scope Major labs & flagship models, anthropic, vendor-analysis
Claude Sonnet is the variant most teams actually ship. It sits in the middle of Anthropic's three-tier structure, priced above the small Haiku model and well below the flagship Opus, and for most production workloads it is the version that gets picked once the novelty of running the biggest model wears off and someone has to pay the bill. If you are evaluating a default workhorse for document analysis, code generation, retrieval pipelines or an agentic loop that runs thousands of times a day, Sonnet is usually the model you are comparing everything else against.
As of this writing, the current production Sonnet is Claude Sonnet 4.5, with Claude Sonnet 4 and the earlier Claude 3.5 Sonnet still widely referenced in deployed systems and documentation. Prices, version availability and benchmark positions move quickly in this field, so treat every specific figure below as time-sensitive and verify against the Anthropic pricing page and the official model card before you commit a budget.
Claude Sonnet in one paragraph
Claude Sonnet is Anthropic's balanced tier: a model tuned so that capability, latency and cost land in a zone broad enough to cover the majority of real applications. Haiku is built for speed and volume at the lowest price; Opus is built for the hardest reasoning and the longest, most tangled tasks, at the highest price. Sonnet is the one in between, and that middle position is not a compromise so much as a deliberate product decision – Anthropic has repeatedly shipped Sonnet updates that close much of the gap to the previous Opus generation while keeping the per-token cost far lower. The practical consequence is that Sonnet has become the default choice for builders: strong enough for coding and multi-step agent work, cheap enough to run at scale, fast enough for interactive products. For a fuller picture of how the three tiers relate, see our guide to the Claude model family.
Versions timeline
Understanding Sonnet means tracking a short but consequential sequence of releases.
Claude 3.5 Sonnet (June 2024). Anthropic introduced Claude 3.5 Sonnet as the first model in the 3.5 generation, and it arrived with an unusual claim for a mid-tier model: it outperformed the previous flagship, Claude 3 Opus, on many of Anthropic's internal and public evaluations while costing a fraction as much. This was the release that reset expectations for what "middle tier" could mean. It also shipped with Artifacts, a workspace feature in the Claude interface for generating and iterating on code, documents and small applications. Later in 2024 Anthropic issued an upgraded Claude 3.5 Sonnet – frequently distinguished informally as the October 2024 version – which improved coding performance and introduced an experimental "computer use" capability, letting the model operate a desktop by reading the screen and issuing mouse and keyboard actions.
Claude Sonnet 4 (2025). With the Claude 4 generation, Anthropic dropped the decimal-heavy naming in favour of a cleaner scheme. Claude Sonnet 4 pushed coding and agentic reliability further, with stronger performance on long-horizon tasks – the kind where a model must stay coherent across many tool calls without drifting off course or hallucinating state.
Claude Sonnet 4.5. The most recent Sonnet at the time of writing, positioned by Anthropic as its strongest model for coding and agent-building, with improvements in sustained multi-step work and instruction adherence. Because release notes and capability claims for this tier change on a scale of months, confirm the current status, context window and feature set on the Anthropic Claude Sonnet model card rather than relying on any single snapshot.
The through-line across these versions is consistent: each Sonnet release absorbs capability that previously required the Opus tier, and each pushes harder on coding and agent workflows specifically, because that is where the commercial demand has concentrated.
Capability picture
Where Sonnet competes with Opus, and where it does not, is the question that actually decides architecture.
Sonnet is strongly competitive with the flagship on tasks with a bounded reasoning depth: summarising and extracting from documents, generating and refactoring code against a clear spec, answering domain questions, classifying and routing, drafting structured output, and running agent loops where each individual step is tractable. On many public coding benchmarks, recent Sonnet releases sit near the top of the field, and independent trackers such as Vellum's model comparison have repeatedly shown Sonnet versions matching or exceeding larger and more expensive models on software-engineering evaluations. Benchmark leaderboards shift constantly and each uses its own methodology, so read them for direction rather than as a settled ranking – our explainer on MMLU, GPQA and the LMSYS Arena covers how to read these numbers without being misled by them.
Where Sonnet falls behind Opus is at the frontier of difficulty and depth. The hardest multi-step reasoning, research-grade problems, the longest and most ambiguous tasks where a small error early compounds into failure later – these are where paying for the larger model still earns its keep. The gap is narrower than the price difference implies, which is exactly why Sonnet is the default: for the median task, the marginal quality Opus adds does not justify the marginal cost. You reach for Opus when a task genuinely sits at the edge of what is solvable, not as a reflex.
All current Sonnet models are multimodal on input, handling images alongside text, which matters for document pipelines that include scanned pages, charts, screenshots or diagrams.
Pricing (date-stamped)
Pricing is where Sonnet's middle position becomes concrete, and it is also the detail most likely to be out of date by the time you read this. As of this writing, Anthropic prices Sonnet per million tokens, with separate input and output rates, and output priced several times higher than input – a structure common across the major API vendors. Sonnet sits well below Opus on both dimensions and above Haiku, placing it in a cost band where high-volume production use is viable without the eye-watering bills that frontier models can generate.
Rather than quote figures that will drift, verify the exact per-million-token input and output prices on the Anthropic pricing page, and pay particular attention to two cost levers that change the economics substantially: prompt caching and the Message Batches API, both discussed below. The headline rate is only the starting point.
Use cases that fit
Document analysis. Sonnet's combination of a large context window and solid extraction accuracy makes it a natural fit for ingesting contracts, reports, filings and support tickets and returning structured output. The multimodal input handles mixed documents – a PDF with embedded tables and charts – without a separate OCR stage for most cases.
Code generation. This is where recent Sonnet releases are strongest. Sonnet underpins a large share of AI coding assistants and agentic developer tools precisely because it generates, edits and reasons about code at close to frontier quality while remaining cheap enough to call repeatedly inside an IDE loop. If you are building in this space, our overview of AI chatbot development frameworks and the running coverage in AI agents news and developments give context on the tooling around it.
Agentic workflows. Sonnet's reliability across chained tool calls – staying coherent over many steps, respecting the task definition, calling functions correctly – is the capability Anthropic has pushed hardest in the 4 and 4.5 releases. For workflows that plan, call tools, read results and continue, Sonnet is frequently the best cost-adjusted choice.
Customer service. For routing, drafting responses, summarising conversation history and answering from a knowledge base, Sonnet offers more headroom than Haiku on the genuinely hard queries while staying affordable at support-centre volumes. Many teams run a tiered setup: Haiku for the easy majority, Sonnet for anything that needs more judgement.
When to use Sonnet vs Opus or Haiku
A workable decision framework starts from the task, not the model.
Reach for Haiku when latency and cost dominate and the task is well bounded – classification, extraction against a clear schema, high-volume routing, simple drafting. If the task reliably succeeds on the small model, paying for anything larger is waste. Our analysis of Claude Haiku covers where that line sits.
Reach for Sonnet as the default for anything requiring real reasoning, code of non-trivial complexity, multi-step agent work, or document understanding where accuracy matters. This is the broad middle, and it covers most production applications.
Reach for Opus only when the task genuinely sits at the frontier – the hardest reasoning, research-grade analysis, long tasks where early errors compound, or cases where a measured quality gap over Sonnet justifies the price. The honest test is empirical: run the task on Sonnet first, measure where it fails, and escalate to Opus only for the failing slice. Our Opus version comparison details that tier.
The most cost-effective systems rarely use one model. They route by difficulty, reserving the expensive tier for the queries that need it.
Production deployment notes
Two features move Sonnet's real cost far from the list price.
Prompt caching lets you cache a large, stable prefix – a system prompt, a tool schema, a long reference document – so that repeated calls reusing that prefix are billed at a sharply reduced rate for the cached portion. For agent loops and retrieval-augmented systems where the same context is sent on every turn, the saving is substantial and the latency improves too. Check the current cache write and read rates and time-to-live on Anthropic's documentation, since these govern whether caching pays off for your access pattern.
The Message Batches API processes large volumes of asynchronous requests at a discount relative to the standard synchronous rate, with results returned within a longer window. For offline work – bulk document processing, dataset labelling, evaluation runs – batching is the obvious lever. It does not suit interactive traffic, where you need a response in real time, but for anything that can tolerate delay it meaningfully lowers the bill.
Beyond cost, plan for rate limits. High-throughput deployments hit per-minute token and request ceilings, and handling backoff gracefully matters; the general patterns we describe for rate-limit errors apply across vendors, Anthropic included.
The summary for a builder is straightforward. Claude 3.5 Sonnet redefined what a mid-tier model could do, and the Sonnet 4 and 4.5 releases have kept that tier at or near the frontier for coding and agentic work while holding a price that makes scale affordable. Start there, measure where it breaks, and escalate only the parts that need it. For most production systems, Sonnet is not the safe compromise – it is the right answer.