Claude-KI-Modelle im Überblick: Opus, Sonnet, Haiku

1. Warum die Modellwahl bei Claude überhaupt zählt

Anthropic bietet Claude nicht als ein einzelnes Modell an, sondern als Familie von Modellstufen mit unterschiedlichem Verhältnis aus Fähigkeit, Geschwindigkeit und Kosten. Wer immer das leistungsfähigste Modell für jede Anfrage nutzt, zahlt für Reasoning-Tiefe, die viele Aufgaben gar nicht brauchen. Wer umgekehrt immer das günstigste Modell nutzt, bekommt bei komplexen Architekturentscheidungen oder sicherheitsrelevanten Code-Reviews spürbar schwächere Ergebnisse und muss häufiger nacharbeiten. Die Modellwahl ist damit keine Nebensächlichkeit, sondern ein direkter Hebel auf Qualität, Latenz und Budget.

Für Magento- und Hyvä-Entwickler zeigt sich der Unterschied konkret: Ein Plugin, das einen Preference-Konflikt in einem Kernmodul auflösen soll, verlangt anderes Reasoning als das Formatieren einer CSV-Exportdatei oder das Klassifizieren von hundert Support-Tickets. Die folgenden Abschnitte ordnen die drei aktuellen Claude-Modellstufen ein, zeigen ihre praktischen Einsatzgebiete und liefern eine Entscheidungsheuristik, die sich direkt auf den Entwickleralltag mit Claude Code und der Anthropic API übertragen lässt.

2. Die drei Modellfamilien im Überblick: Opus, Sonnet, Haiku

Claude Opus, Claude Sonnet und Claude Haiku sind die drei aktuellen Modellstufen von Anthropic, aktuell in den Versionen Opus 4.8, Sonnet 5 und Haiku 4.5. Alle drei teilen sich dieselbe API und dieselben Grundfunktionen wie Tool-Nutzung, Vision und Extended Thinking, unterscheiden sich aber deutlich in Kontextfenster, maximaler Ausgabelänge und Preis pro Token. Opus und Sonnet bieten ein Kontextfenster von 1 Million Token und bis zu 128.000 Ausgabe-Token, Haiku ist mit 200.000 Token Kontext und 64.000 Ausgabe-Token kleiner dimensioniert, dafür spürbar schneller in der Antwortzeit.

Die Preisstruktur pro einer Million Token folgt derselben Hierarchie: Opus kostet 5 US-Dollar für Eingabe und 25 US-Dollar für Ausgabe, Sonnet liegt bei 3 US-Dollar Eingabe und 15 US-Dollar Ausgabe, Haiku bei 1 US-Dollar Eingabe und 5 US-Dollar Ausgabe. Der Faktor zwischen Opus und Haiku beträgt damit das Fünffache bei der Eingabe und ebenfalls das Fünffache bei der Ausgabe. Wichtig ist: Der Preisunterschied sagt nichts über die Antwortqualität für eine konkrete Aufgabe aus, sondern über die Rechenkapazität, die pro Anfrage bereitgestellt wird. Für einfache Aufgaben liefert Haiku oft eine Qualität, die von Opus kaum zu unterscheiden ist, nur eben schneller und günstiger.

3. Opus: tiefes Reasoning für komplexe Architekturentscheidungen

Claude Opus ist die Modellstufe mit der größten Reasoning-Tiefe und eignet sich für Aufgaben, bei denen ein falsches Ergebnis teuer wird: die Wahl zwischen Plugin und Preference bei einem Interceptor-Konflikt, ein sicherheitskritisches Code-Review vor einem Major-Release, ein Refactoring über zehn oder mehr Dateien hinweg, oder die Analyse, warum ein Full-Page-Cache in Kombination mit ESI-Blöcken inkonsistent invalidiert. Opus arbeitet mit einem effort-Parameter, der die Denktiefe steuert: high oder xhigh eignen sich für Coding- und Agenten-Aufgaben mit vielen Zwischenschritten, während niedrigere Stufen die Kosten senken, wenn die Aufgabe weniger komplex ist als ursprünglich angenommen.

Der Kompromiss ist offensichtlich: Opus ist das teuerste und in der Praxis auch das langsamste der drei Modelle, weil es mehr Zeit in Zwischenschritte investiert, bevor es antwortet. Für einen einzelnen Architektur-Review lohnt sich das fast immer, weil die Kosten einer übersehenen Sicherheitslücke oder eines fehlerhaften Datenbankschemas die zusätzlichen Cent für die API-Anfrage um Größenordnungen übersteigen. Für Routineaufgaben in großer Zahl, etwa das automatische Generieren von tausend Produktbeschreibungen, ist Opus dagegen fast immer die falsche Wahl, weil die Reasoning-Tiefe dort keinen messbaren Qualitätsgewinn bringt, aber die Kosten linear mit der Menge steigen.

#!/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: der Allrounder für die tägliche Entwicklungsarbeit

Claude Sonnet ist bewusst als Mittelweg positioniert und erreicht bei Coding- und Agenten-Aufgaben inzwischen eine Qualität, die für die meisten Entwicklungsaufgaben nahe an Opus liegt, bei spürbar niedrigeren Kosten. Für den typischen Magento- oder Hyvä-Arbeitstag, also neue Blöcke schreiben, ViewModels implementieren, Layout-XML anpassen, PHPStan-Fehler beheben oder eine neue Konfigurationsseite anlegen, ist Sonnet die naheliegende Standardwahl. Genau deshalb ist es auch das Standardmodell in Claude Code: Es liefert in den meisten Situationen ein gutes Verhältnis aus Antwortqualität, Geschwindigkeit und Token-Verbrauch, ohne dass man für jede Anfrage manuell zwischen Modellen wechseln muss.

Sonnet unterstützt adaptives Thinking standardmäßig und den vollen Bereich der effort-Stufen von low bis max, was es erlaubt, die Denktiefe innerhalb eines Modells fein zu justieren, statt gleich auf Opus zu wechseln. In der Praxis bedeutet das: Wer merkt, dass Sonnet bei einer bestimmten Aufgabe zu oberflächlich reasoniert, sollte zuerst effort auf high oder xhigh stellen, bevor er zu Opus wechselt. Erst wenn auch das nicht ausreicht, etwa bei einer mehrstufigen Migration mit vielen impliziten Abhängigkeiten, ist der Wechsel auf Opus gerechtfertigt.

5. Haiku: schnelle und günstige Routineaufgaben

Claude Haiku ist für Aufgaben gedacht, bei denen Geschwindigkeit und Kosten wichtiger sind als maximale Reasoning-Tiefe: Autocomplete-ähnliche Vorschläge im Editor, das Klassifizieren von Support-Tickets, einfache Formatierungsaufgaben, das Extrahieren strukturierter Daten aus kurzen Texten oder das Massenverarbeiten großer Datenmengen, bei denen jede einzelne Anfrage simpel ist. Mit einem Kontextfenster von 200.000 Token statt 1 Million und einer maximalen Ausgabe von 64.000 statt 128.000 Token ist Haiku bewusst kleiner dimensioniert, was sich direkt in niedrigerer Latenz niederschlägt. Für interaktive Anwendungen, bei denen Nutzer auf eine Antwort warten, ist dieser Geschwindigkeitsvorteil oft wichtiger als jede zusätzliche Reasoning-Tiefe.

Die Grenze von Haiku liegt bei Aufgaben mit vielen impliziten Abhängigkeiten oder mehrstufiger Planung: Ein komplexes Refactoring über mehrere Module hinweg oder eine Sicherheitsanalyse mit vielen Randfällen überfordert Haiku eher, weil es weniger Rechenzeit in Zwischenschritte investiert. Der effort-Parameter und max-Stufe sind auf Haiku nicht verfügbar, ein Hinweis darauf, dass das Modell für kompakte, klar umrissene Aufgaben konzipiert ist, nicht für offene, explorative Reasoning-Ketten. In der Praxis bewährt sich Haiku besonders gut als Modell für Subagents, die eine eng definierte Teilaufgabe innerhalb eines größeren Claude-Code-Workflows übernehmen.

{
  "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. Modellwahl in Claude Code: /model, Subagents und Effort

In Claude Code lässt sich das aktive Modell jederzeit über den Befehl /model wechseln, ohne die laufende Session neu zu starten. Das ist nützlich, wenn eine Session mit Sonnet beginnt, aber mitten in der Arbeit klar wird, dass die aktuelle Aufgabe tieferes Reasoning verlangt, etwa weil ein Bug an einer unerwarteten Stelle im Cache-Layer liegt. Alternativ lässt sich das Standardmodell über die Umgebungsvariable ANTHROPIC_MODEL für ein ganzes Terminal setzen, oder pro Aufruf über das Flag --model explizit angeben. Für einmalige, klar abgegrenzte Aufgaben wie das Formatieren einer Export-Datei ist ein expliziter Haiku-Aufruf oft die günstigste Option, ohne die Standardkonfiguration der Session zu verändern.

Ein weiterer wichtiger Hebel ist die Modellwahl für Subagents: Claude Code kann Teilaufgaben an separate Subagents delegieren, und jeder Subagent kann sein eigenes Modell nutzen. Ein Orchestrator-Agent, der eine komplexe Aufgabe in mehrere Teilschritte zerlegt, kann selbst auf Opus laufen, während die einzelnen Subagents für einfache, klar umrissene Teilaufgaben auf Sonnet oder Haiku zurückgreifen. Das senkt die Gesamtkosten eines Workflows erheblich, ohne die Qualität der kritischen Entscheidungen zu beeinträchtigen, weil die anspruchsvollste Reasoning-Arbeit weiterhin beim leistungsfähigsten Modell bleibt.

# 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-Kosten im Detail: Pricing, Prompt Caching und Batch API

Die reine Token-Preisliste ist nur die halbe Wahrheit, weil zwei zusätzliche Mechanismen die tatsächlichen Kosten in Produktion drastisch verändern können. Prompt Caching speichert wiederkehrende Prompt-Anteile, etwa ein langes System-Prompt oder eine Produktdatenbank-Referenz, und liefert bei einem Cache-Treffer die entsprechenden Eingabe-Token zu rund einem Zehntel des regulären Preises. Für Workflows, die wiederholt denselben großen Kontext mit wechselnden kleinen Anfragen kombinieren, etwa eine Produktkatalog-Analyse mit hundert Einzelanfragen, kann Prompt Caching die Gesamtkosten um 70 bis 90 Prozent senken, unabhängig davon, welches Modell verwendet wird.

Die Batch API ist der zweite Hebel: Anfragen, die nicht in Echtzeit beantwortet werden müssen, etwa das nächtliche Generieren von Produktbeschreibungen für den gesamten Katalog, lassen sich zu 50 Prozent des Standardpreises verarbeiten, mit einer Bearbeitungszeit von meist unter einer Stunde und maximal 24 Stunden. Kombiniert man Batch API und Prompt Caching mit der richtigen Modellwahl, ergibt sich ein Kostenunterschied, der bei Volumen-Workloads leicht das Zwanzigfache betragen kann, verglichen mit einer naiven Implementierung, die für jede Einzelanfrage synchron das teuerste Modell aufruft.

#!/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. Entscheidungsheuristik: welches Modell für welche Aufgabe

Eine einfache Faustregel hilft in den meisten Situationen weiter: Wenn die Aufgabe eine kurze, klar definierte Antwort ohne viele implizite Abhängigkeiten verlangt, zum Beispiel eine Formatierung, eine Klassifikation oder eine autocomplete-ähnliche Vervollständigung, ist Haiku die richtige Wahl. Wenn die Aufgabe zum normalen Entwicklungsalltag gehört, etwa das Implementieren eines neuen ViewModels, das Schreiben von PHPDoc-Blöcken oder das Debuggen eines konkreten, gut eingegrenzten Fehlers, ist Sonnet der naheliegende Standard. Wenn die Aufgabe hingegen tiefes, mehrstufiges Reasoning über viele Dateien oder Systemgrenzen hinweg verlangt, etwa eine Architekturentscheidung mit langfristigen Konsequenzen oder ein Sicherheitsaudit vor einem Release, rechtfertigt das den Wechsel zu Opus.

Diese Heuristik lässt sich um eine zweite Dimension ergänzen: die Kosten eines falschen Ergebnisses. Eine falsch klassifizierte Support-Anfrage kostet wenig, weil sie sich leicht korrigieren lässt. Eine übersehene SQL-Injection-Schwachstelle in einem Custom-Modul, das direkt mit der Datenbank interagiert, kostet potenziell sehr viel. Je höher der Schaden eines Fehlers, desto eher lohnt sich die zusätzliche Investition in Opus, selbst wenn die Aufgabe auf den ersten Blick nicht besonders komplex wirkt. Umgekehrt gilt: Bei hohem Volumen und geringem Einzelrisiko, etwa bei automatisierten Produktbeschreibungen, überwiegt fast immer der Kostenvorteil von Sonnet oder Haiku im Batch-Modus.

9. Modellwahl im Team- und Produktionsmaßstab

Sobald mehrere Entwickler und automatisierte Pipelines gleichzeitig auf die Anthropic API zugreifen, wird die Modellwahl zu einer Frage der Kostengovernance, nicht mehr nur der Einzelaufgabe. Ein sinnvoller Ansatz ist, Modellwahl-Regeln in CI-Pipelines und internen Tools zu kodifizieren, statt sie jedem Entwickler einzeln zu überlassen: Ein automatisierter Code-Review-Bot vor jedem Merge in den Hauptbranch kann auf Opus mit hohem Effort-Level laufen, während ein Linter-Bot, der nur Formatierungsfehler meldet, mit Haiku auskommt. Diese Aufteilung reduziert nicht nur Kosten, sondern beschleunigt auch die schnellen, häufigen Prüfungen, während die seltenen, kritischen Prüfungen die nötige Tiefe behalten.

Für die Skalierung über ein ganzes Team hinweg lohnt sich außerdem ein einfacher Routing-Mechanismus, der die Modellwahl anhand messbarer Kriterien trifft, statt sie jeder Person individuell zu überlassen. Anzahl der betroffenen Dateien, ob Kernlogik oder nur Formatierung betroffen ist, und ob ein Merge-Request sicherheitsrelevante Bereiche berührt, sind brauchbare Signale für eine automatische Vorauswahl. Das folgende Beispiel zeigt eine minimale Routing-Funktion, wie sie sich in eine CI-Pipeline oder ein internes Tool einbetten lässt.

// 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. Zusammenfassung

Die Claude-KI-Modelle Opus, Sonnet und Haiku lösen dasselbe Grundproblem auf unterschiedliche Weise: die richtige Balance zwischen Reasoning-Tiefe, Geschwindigkeit und Kosten für eine gegebene Aufgabe zu finden. Opus liefert die größte Denktiefe für Architekturentscheidungen und sicherheitskritische Reviews, kostet dafür das Fünffache von Haiku bei Eingabe und Ausgabe. Sonnet ist der praxistaugliche Standard für den täglichen Entwicklungsalltag und deshalb auch das Standardmodell in Claude Code. Haiku liefert bei einfachen, klar umrissenen Aufgaben eine kaum unterscheidbare Qualität bei deutlich geringerer Latenz und deutlich niedrigeren Kosten, besonders im Zusammenspiel mit Subagents und Batch-Verarbeitung.

Der größte Hebel liegt selten in der Wahl eines einzelnen Modells, sondern in der konsequenten Kombination aus richtiger Modellwahl pro Aufgabentyp, Prompt Caching für wiederkehrende Kontexte und Batch API für nicht zeitkritische Volumen-Workloads. Wer diese drei Mechanismen kombiniert, kann die Gesamtkosten eines produktiven Claude-Einsatzes um eine Größenordnung senken, ohne bei den Aufgaben, die tatsächlich tiefes Reasoning verlangen, an Qualität einzubüßen.

11. FAQ: Claude-KI-Modelle im Überblick