Claude AI Models Overview: Opus, Sonnet, Haiku

1. Why model selection matters at all with Claude

Anthropic does not offer Claude as a single model, but as a family of tiers with a different balance of capability, speed, and cost. Anyone who always reaches for the most capable model on every request pays for reasoning depth that most tasks simply do not need. Anyone who always reaches for the cheapest model gets noticeably weaker results on complex architectural decisions or security sensitive code reviews, and ends up reworking more often. Model selection is therefore not a minor detail, it is a direct lever on quality, latency, and budget.

For Magento and Hyva developers the difference shows up concretely: a plugin that has to resolve a preference conflict in a core module demands different reasoning than formatting a CSV export file or classifying a hundred support tickets. The following sections place the three current Claude model tiers, show their practical use cases, and give a decision heuristic that maps directly onto everyday work with Claude Code and the Anthropic API.

2. The three model families at a glance: Opus, Sonnet, Haiku

Claude Opus, Claude Sonnet, and Claude Haiku are Anthropic's three current model tiers, currently at versions Opus 4.8, Sonnet 5, and Haiku 4.5. All three share the same API and the same core capabilities, such as tool use, vision, and extended thinking, but differ noticeably in context window, maximum output length, and price per token. Opus and Sonnet offer a 1 million token context window and up to 128,000 output tokens, while Haiku is deliberately smaller at 200,000 tokens of context and 64,000 output tokens, which translates directly into faster response times.

The price structure per one million tokens follows the same hierarchy: Opus costs 5 US dollars for input and 25 US dollars for output, Sonnet sits at 3 dollars input and 15 dollars output, and Haiku at 1 dollar input and 5 dollars output. The gap between Opus and Haiku is therefore a factor of five on both input and output. Important detail: the price difference does not say anything about answer quality for a given task, only about the compute allocated per request. For simple tasks Haiku often delivers quality barely distinguishable from Opus, just faster and cheaper.

3. Opus: deep reasoning for complex architectural decisions

Claude Opus is the tier with the greatest reasoning depth and suits tasks where a wrong answer is expensive: choosing between a Plugin and a Preference for an interceptor conflict, a security critical code review before a major release, a refactor that spans ten or more files, or figuring out why a full page cache combined with ESI blocks invalidates inconsistently. Opus works with an effort parameter that controls thinking depth: high or xhigh suit coding and agentic tasks with many intermediate steps, while lower levels reduce cost when a task turns out to be less complex than initially assumed.

The tradeoff is obvious: Opus is the most expensive and, in practice, also the slowest of the three models, because it spends more time on intermediate steps before answering. For a single architectural review that tradeoff is almost always worth it, because the cost of an overlooked security hole or a broken database schema outweighs the extra cents of the API call by orders of magnitude. For high volume routine work, such as automatically generating a thousand product descriptions, Opus is almost always the wrong choice, because the reasoning depth does not produce a measurable quality gain there, while cost scales linearly with volume.

#!/usr/bin/env bash
# Architecture review with Opus: deep reasoning, high effort
curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-4-8",
    "max_tokens": 8000,
    "thinking": {"type": "adaptive"},
    "output_config": {"effort": "high"},
    "messages": [{
      "role": "user",
      "content": "Review this Magento 2 plugin architecture for the SeoSuite module. Evaluate whether a Preference or a Plugin is the correct interceptor pattern for overriding Magento_Catalog product save, and explain the tradeoffs for maintainability across future core updates."
    }]
  }'

4. Sonnet: the all rounder for daily development work

Claude Sonnet is deliberately positioned as the middle ground, and on coding and agentic tasks it now reaches quality close to Opus for most development work, at a noticeably lower cost. For a typical Magento or Hyva workday, writing new blocks, implementing ViewModels, adjusting layout XML, fixing PHPStan errors, or adding a new configuration page, Sonnet is the obvious default. That is exactly why it is also the default model in Claude Code: it delivers a good balance of answer quality, speed, and token consumption in most situations, without forcing a manual model switch for every request.

Sonnet supports adaptive thinking by default and the full range of effort levels from low to max, which lets you fine tune thinking depth within a single model instead of jumping straight to Opus. In practice this means: if you notice Sonnet reasoning too shallowly on a particular task, raise effort to high or xhigh first, before switching to Opus. Only once that still is not enough, for example on a multi step migration with many implicit dependencies, is the switch to Opus justified.

5. Haiku: fast and cheap routine tasks

Claude Haiku is built for tasks where speed and cost matter more than maximum reasoning depth: autocomplete style suggestions in an editor, classifying support tickets, simple formatting work, extracting structured data from short texts, or bulk processing large volumes of data where each individual request is simple. With a context window of 200,000 tokens instead of 1 million and a maximum output of 64,000 instead of 128,000 tokens, Haiku is deliberately sized smaller, which translates directly into lower latency. For interactive applications where users are waiting for a response, that speed advantage often matters more than any additional reasoning depth.

Haiku's limit shows up on tasks with many implicit dependencies or multi step planning: a complex refactor spanning several modules, or a security analysis with many edge cases, tends to overwhelm Haiku, because it spends less compute time on intermediate steps. The effort parameter and its max level are not available on Haiku, a signal that the model is designed for compact, clearly scoped tasks rather than open ended, exploratory reasoning chains. In practice Haiku works particularly well as the model for subagents that own a narrowly defined subtask inside a larger Claude Code workflow.

{
  "model": "claude-haiku-4-5",
  "max_tokens": 50,
  "messages": [
    {
      "role": "user",
      "content": "Classify this Magento support ticket as one of: bug, feature-request, how-to, urgent-outage. Reply with only the label.\n\nTicket: Checkout throws a 500 error for guest customers after the last deployment."
    }
  ]
}

6. Model selection in Claude Code: /model, subagents, and effort

In Claude Code, the active model can be switched at any time with the /model command, without restarting the running session. That is useful when a session starts on Sonnet but midway through the work it becomes clear the current task demands deeper reasoning, for instance because a bug turns out to sit in an unexpected part of the cache layer. Alternatively, the default model can be set for an entire terminal via the ANTHROPIC_MODEL environment variable, or specified explicitly per invocation with the --model flag. For one off, clearly scoped tasks like formatting an export file, an explicit Haiku call is often the cheapest option without changing the session's default configuration.

Another important lever is model selection for subagents: Claude Code can delegate subtasks to separate subagents, and each subagent can use its own model. An orchestrator agent that breaks a complex task into several subtasks can itself run on Opus, while the individual subagents fall back to Sonnet or Haiku for simple, clearly scoped subtasks. That significantly lowers the total cost of a workflow without hurting the quality of the critical decisions, because the most demanding reasoning work still stays with the most capable model.

# Switch the active model inside a running Claude Code session
/model opus

# Or set the default model for a whole terminal session
export ANTHROPIC_MODEL="claude-sonnet-5"

# Run a one-off task on Haiku for a cheap, fast subagent task
claude --model claude-haiku-4-5 -p "Format this CSV export as a Markdown table"

7. API cost in detail: pricing, prompt caching, and the Batch API

The raw token price list is only half the picture, because two additional mechanisms can dramatically change actual production cost. Prompt caching stores recurring prompt portions, such as a long system prompt or a product database reference, and on a cache hit serves the corresponding input tokens at roughly a tenth of the regular price. For workflows that repeatedly combine the same large context with varying small requests, such as a product catalog analysis with a hundred individual queries, prompt caching can cut total cost by 70 to 90 percent, regardless of which model is used.

The Batch API is the second lever: requests that do not need a real time answer, such as generating product descriptions for the entire catalog overnight, can be processed at 50 percent of the standard price, usually completing in under an hour and never more than 24 hours. Combining the Batch API and prompt caching with the right model choice can produce a cost difference that easily reaches a factor of twenty on volume workloads, compared to a naive implementation that synchronously calls the most expensive model for every single request.

#!/usr/bin/env python3
# Cost comparison for generating 5,000 Magento product descriptions
# Prices in USD per 1M tokens (input / output)
MODELS = {
    "claude-opus-4-8": {"input": 5.00, "output": 25.00},
    "claude-sonnet-5": {"input": 3.00, "output": 15.00},
    "claude-haiku-4-5": {"input": 1.00, "output": 5.00},
}

products = 5000
avg_input_tokens = 400   # product data, attributes, category context
avg_output_tokens = 250  # generated description

for model, price in MODELS.items():
    input_cost = (products * avg_input_tokens / 1_000_000) * price["input"]
    output_cost = (products * avg_output_tokens / 1_000_000) * price["output"]
    total = input_cost + output_cost
    print(f"{model}: ${total:.2f} for {products} descriptions")

# With prompt caching on the shared system prompt (roughly 90% cheaper
# for the cached portion), the input cost drops further on repeated runs.

8. Decision heuristic: which model for which task

A simple rule of thumb helps in most situations: if a task needs a short, clearly defined answer without many implicit dependencies, for example a formatting job, a classification, or an autocomplete style completion, Haiku is the right choice. If the task belongs to normal day to day development, such as implementing a new ViewModel, writing PHPDoc blocks, or debugging a specific, well scoped bug, Sonnet is the obvious default. If the task, on the other hand, demands deep, multi step reasoning across many files or system boundaries, such as an architectural decision with long term consequences or a security audit before a release, that justifies switching to Opus.

This heuristic can be extended with a second dimension: the cost of a wrong answer. A misclassified support request costs little, because it is easy to correct. An overlooked SQL injection vulnerability in a custom module that talks directly to the database can potentially cost a great deal. The higher the damage a mistake can cause, the more the extra investment in Opus pays off, even when the task does not look particularly complex at first glance. Conversely, at high volume with low individual risk, such as automated product descriptions, the cost advantage of Sonnet or Haiku in batch mode almost always wins out.

9. Model selection at team and production scale

Once several developers and automated pipelines are hitting the Anthropic API at the same time, model selection turns into a question of cost governance, not just a per task decision. A sensible approach is to codify model selection rules in CI pipelines and internal tools instead of leaving them to each developer individually: an automated code review bot that runs before every merge into the main branch can run on Opus with a high effort level, while a linter bot that only reports formatting issues can get by on Haiku. This split not only reduces cost, it also speeds up the fast, frequent checks while the rare, critical checks keep the depth they need.

Scaling across an entire team also benefits from a simple routing mechanism that picks the model based on measurable criteria, rather than leaving the decision to each individual. Number of affected files, whether core logic or only formatting is touched, and whether a merge request touches security relevant areas are useful signals for automatic pre selection. The example below shows a minimal routing function that fits into a CI pipeline or an internal tool.

// scripts/pick-model.js
// Route a CI task to the right Claude model based on estimated complexity
function pickModel(task) {
  const { fileCount, touchesCoreLogic, isFormatting } = task;

  if (isFormatting || (fileCount === 1 && !touchesCoreLogic)) {
    return "claude-haiku-4-5"; // lint fixes, phpdoc blocks, simple renames
  }

  if (touchesCoreLogic || fileCount > 10) {
    return "claude-opus-4-8"; // cross-module refactors, security-relevant changes
  }

  return "claude-sonnet-5"; // default: everyday feature work
}

module.exports = { pickModel };

10. Summary

The Claude AI models Opus, Sonnet, and Haiku solve the same underlying problem in different ways: finding the right balance between reasoning depth, speed, and cost for a given task. Opus delivers the deepest thinking for architectural decisions and security critical reviews, at five times the input and output cost of Haiku. Sonnet is the practical default for everyday development work, which is also why it is the default model in Claude Code. Haiku delivers barely distinguishable quality on simple, clearly scoped tasks at much lower latency and much lower cost, especially when paired with subagents and batch processing.

The biggest lever is rarely the choice of a single model, but the consistent combination of the right model per task type, prompt caching for recurring context, and the Batch API for non time critical volume workloads. Combining these three mechanisms can cut the total cost of a production Claude deployment by an order of magnitude, without losing quality on the tasks that genuinely need deep reasoning.

11. FAQ: Claude AI Models Overview