Claude · 10 Min.
Claude 4 fuer Agentic Coding: Opus, Sonnet oder Haiku?
Claude ist fuer agentic coding stark, aber nicht jeder Workflow braucht dasselbe Modell. Entscheidend sind Kontext, Tool-Risiko, Laufzeit, Review und Kosten.
SYSTEMS Grafik zu Claude 4 agentic coding: Explore -> Plan -> Verify. Fokus: Wie Entwicklerteams Claude-Modelle fuer agentische Coding-Workflows auswaehlen, ohne nur das groesste Modell einzusetzen.
Kurzfassung
Claude-Modelle sind fuer Coding und Agenten-Workflows stark, aber die Modellwahl sollte nach Aufgabe, Kontext, Risiko und Kosten erfolgen. Opus passt eher zu langen, komplexen, mehrstufigen Aufgaben; Sonnet ist oft der produktive Standard fuer schnelle, hochwertige Umsetzung; Haiku kann fuer leichte Schritte sinnvoll sein. Claude Code, MCP, Tool Use und Long Context sind nur dann wirklich stark, wenn Review-Gates, Tests und Projektregeln mitgebaut werden.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknuepfe es mit den naechsten Architekturentscheidungen.
Stand Mai 2026: Claude 4 ist eine Modellfamilie, kein einzelner Knopf Der Claude-4-Launch vom 22. Mai 2025 war der Startpunkt fuer Opus 4 und Sonnet 4 als starke Coding- und Agentenmodelle. Die aktuelle Modelldokumentation zeigt aber, worauf Teams 2026 achten muessen: Claude 4 ist eine laufende Modellfamilie mit Opus-, Sonnet- und Haiku-Linien, unterschiedlichen Kosten, Kontextfenstern, Denkmodi und Latenzprofilen.
Das ist fuer SEO interessant, aber fuer Architektur noch wichtiger. Wer heute "Claude 4 fuer Coding" sagt, muss klaeren, ob er die Opus-Linie fuer komplexe Agentenarbeit, die Sonnet-Linie fuer taegliche Umsetzung oder die Haiku-Linie fuer schnelle Hilfsschritte meint.
Zweite Regel: In Produktion sollten Teams konkrete Modellversionen oder bewusst verwaltete Aliase nutzen. Anthropic empfiehlt fuer produktive Anwendungen stabile Modellversionen, waehrend Aliase fuer Entwicklung und Tests bequem sind. Modellwahl ist damit auch Release-Management.
Aktuell ist ausserdem wichtig: Claude Code selbst setzt je nach Account- und Deployment-Modell unterschiedliche Defaults. Die Modellstrategie darf deshalb nicht nur in Entwicklerkoepfen leben, sondern gehoert in Team-Settings, Gateway-Regeln und Projektkonventionen.
Warum Modellwahl bei Agentic Coding anders ist Bei normalen Chat-Aufgaben reicht oft die Frage: Welches Modell antwortet gut genug und kostet wenig genug?
Bei agentic coding ist die Frage haerter. Ein Coding-Agent liest Dateien, plant Aenderungen, nutzt Tools, fuehrt Tests aus, interpretiert Fehler, schreibt Code und kann ueber laengere Zeit am selben Problem arbeiten. Das Modell trifft viele kleine Entscheidungen, nicht nur eine Antwort.
Darum ist Modellwahl hier Architekturarbeit.
Ein zu schwaches Modell macht Fehler, verliert Kontext oder fuehrt Tools schlecht. Ein zu starkes Modell fuer jede Kleinigkeit kann Kosten und Laufzeit unnoetig erhoehen. Ein gutes Setup routet Aufgaben nach Risiko.
Opus: fuer komplexe, lange, riskante Coding-Arbeit Anthropic positioniert die Opus-Linie als Modell fuer besonders komplexe Aufgaben und agentic coding. Im Claude-4-Launch wurde Opus 4 stark fuer Coding, komplexes Reasoning und lange Agenten-Workflows hervorgehoben. Die aktuelle Modelldokumentation beschreibt die Opus-Linie weiter als Top-Wahl fuer komplexe Agenten- und Coding-Arbeit.
Opus passt, wenn:
Opus sollte aber nicht fuer jede Kleinigkeit genutzt werden. Es ist ein Schwergewicht fuer Aufgaben, bei denen Qualitaet, Ausdauer und Kontext wichtiger sind als reine Geschwindigkeit.
grosse Codebases verstanden werden muessen viele Dateien betroffen sind Refactors ueber mehrere Schichten laufen Fehlerdiagnose lange Ketten braucht Tool-Nutzung ueber viele Schritte stabil bleiben muss Architekturentscheidungen im Code getroffen werden ein falscher Patch teuer waere Sonnet: der Standard fuer viel taegliche Umsetzung Sonnet ist oft der bessere Default fuer Teams: stark genug fuer anspruchsvolle Coding-Aufgaben, schneller und wirtschaftlicher als Opus, und gut geeignet fuer wiederholte Umsetzungsschritte. Claude Code behandelt die Sonnet-Linie in der Modellkonfiguration als naheliegenden Modus fuer taegliche Coding-Aufgaben.
Sonnet passt, wenn:
In vielen Engineering-Teams waere Sonnet der Arbeitsmodus und Opus der Eskalationsmodus.
ein Ticket klar beschrieben ist Aenderungen lokal begrenzt sind Tests vorhanden sind das Team schnelle Iterationen braucht Review durch Menschen ohnehin vorgesehen ist der Agent vorhandene Patterns befolgen soll Haiku: fuer leichte, schnelle Hilfsaufgaben Haiku ist nicht das Modell fuer tiefe Architekturarbeit. Aber in einem agentischen Setup kann ein schnelleres Modell wertvoll sein. Die aktuelle Claude-Familie positioniert Haiku als schnelle, effiziente Linie fuer leichtere Aufgaben.
Sinnvolle Haiku-Aufgaben:
Der Punkt ist nicht, Haiku fuer Coding-Ownership einzusetzen. Der Punkt ist, leichte Schritte nicht mit dem schwersten Modell zu erledigen.
kurze Klassifikation von Tickets Zusammenfassungen kleiner Diffs einfache Formatpruefungen leichte Dokumentationsentwuerfe Vorfilter fuer Logs oder Fehlermeldungen schnelle Checklisten ohne Codeaenderung Claude Code als Arbeitsumgebung, nicht nur Modellzugriff Claude Code bringt die Modelle in einen agentischen Entwicklerworkflow: Terminal, IDE, GitHub-Kontexte, Hintergrundaufgaben und MCP -Tools.
Das ist ein anderer Modus als "kopiere Fehler in Chat". Claude Code kann die Codebase lesen, Aenderungen vorbereiten, Tests starten und mit Projektkontext arbeiten. Dadurch entstehen neue Produktivitaetshebel, aber auch neue Risiken.
Ein produktiver Claude-Code-Workflow braucht:
Ohne diese Grenzen wird aus agentic coding nur schnelleres Experimentieren.
klare Projektregeln erlaubte und verbotene Tools Test- und Build-Gates Review-Pflicht fuer riskante Aenderungen MCP-Scopes fuer externe Systeme gute Aufgabenzerlegung Memory- und Kontextdisziplin Claude Code Modellkonfiguration gehoert ins Team-Setup Claude Code kennt nicht nur einzelne Modellnamen, sondern Aliase und Betriebsmodi. Besonders wichtig ist `opusplan`: Planung laeuft mit Opus, Ausfuehrung mit Sonnet. Das bildet genau den Workflow ab, den viele Teams brauchen: tiefe Architekturentscheidungen am Anfang, effiziente Umsetzung danach.
Fuer Teams ergeben sich daraus konkrete Regeln:
Wenn Claude Code ueber ein LLM Gateway laeuft, muss das Gateway die Modellwahl, Kosten und Subagenten sauber zuordnen. Claude Code sendet dafuer Session- und Agent-Header, die ein Gateway fuer Attribution nutzen kann. Genau das macht Modellwahl messbar statt nur gefuehlt.
Ein Team sollte festlegen, wer ein Modell wechseln darf. Sonst wird jede schwere Aufgabe reflexartig auf das teuerste Modell geschoben und jede leichte Aufgabe ohne Messung optimiert.
`sonnet` als Arbeitsmodus fuer normale Tickets. `opus` fuer Architektur, unbekannte Fehler und riskante Refactors. `opusplan` fuer Aufgaben, bei denen Planung wichtiger ist als schnelle Ausfuehrung. `haiku` fuer einfache Nebenaufgaben und Hintergrundfunktionen. `[1m]`-Kontext nur, wenn lange Sessions wirklich davon profitieren. MCP und Tool Use: die Macht liegt in den Grenzen Claude kann ueber MCP externe Tools und Daten erreichen. Fuer Coding-Teams heisst das: Issues, Docs, Monitoring, Repositories, Datenbanken oder interne APIs koennen Teil des Workflows werden.
Das ist stark, aber nur wenn Tool-Grenzen stimmen.
Wichtige Fragen:
MCP macht Claude Code nicht automatisch produktionsreif. Es macht den Zugriff auf echte Arbeitsumgebung moeglich. Die Kontrolle muss das Team bauen.
Darf der Agent nur lesen oder auch schreiben? Welche MCP-Server sind pro Projekt erlaubt? Welche Tokens und Scopes werden genutzt? Welche Datenquellen sind untrusted? Welche Aktionen brauchen menschliche Freigabe? Welche Tool Calls werden geloggt? Preislogik: Nicht nur Input und Output Bei agentic coding zaehlen nicht nur Modellpreise. Entscheidend sind Laeufe, Wiederholungen, Tool Calls, Kontextgroesse, Prompt Caching, Batch-Moeglichkeiten und Review-Zeit.
Ein scheinbar teurer Opus-Lauf kann guenstiger sein als drei gescheiterte Sonnet-Laeufe plus menschliche Reparatur. Umgekehrt ist Opus fuer kleine, gut definierte Aenderungen oft Verschwendung.
Darum sollte jedes Team nicht "Kosten pro Token" messen, sondern "Kosten pro akzeptiertem Patch".
Long Context ist kein Ersatz fuer Architektur Aktuelle Claude-Modelle bieten grosse Kontextfenster. Das hilft bei grossen Repositories, langen Dokumenten und komplexen Aufgaben. Aber mehr Kontext loest nicht jedes Problem.
Zu viel Kontext kann:
Gute agentic-coding-Setups laden Kontext gezielt. Nicht alles, was geladen werden kann, gehoert in den Prompt.
Anthropic beschreibt Kontext als Arbeitsgedaechtnis des Modells und warnt, dass mehr Kontext nicht automatisch besser ist. Fuer lange agentische Workflows sind Compaction, Context Editing und bewusste Tool-Result-Bereinigung wichtiger als "alles reinwerfen". Extended Thinking zaehlt ebenfalls ins Budget; auch das gehoert in die Architektur.
relevante Signale verwischen Kosten erhoehen veraltete Informationen mitschleppen falsche Dateien in den Fokus bringen Review schwerer machen Der SYSTEMS-Workflow fuer Claude-Modellwahl Wir wuerden Claude-Modellwahl in vier Stufen schneiden:
1. Leichte Analyse: schnelles Modell fuer Klassifikation, Zusammenfassung, Vorbereitung. 2. Umsetzung: Sonnet fuer klar geschnittene Tickets mit Tests. 3. Eskalation: Opus fuer komplexe Refactors, Architektur und langlaufende Fehlersuche. 4. Review: Modell plus menschliche Pruefung fuer riskante Aenderungen.
Dazu kommen MCP-Grenzen, Projektregeln, Evals und klare Build-Gates.
Eine gute Modellwahl-Matrix sollte pro Workflow festhalten:
Ziel des Agentenlaufs erlaubtes Modell oder Alias maximales Kontextbudget erlaubte Tools und MCP-Server Review-Pflicht Test- und Build-Gate Eskalationsmodell Kostenlimit pro Lauf Der SYSTEMS-Blick auf Claude 4 und Agentic Coding Claude-Modelle sind stark fuer agentic coding, aber das Modell allein baut keinen guten Engineering-Prozess.
Der Unterschied entsteht durch Aufgabenzerlegung, Tool-Governance, Kontextstrategie, Tests, Reviews und Modellrouting . Ein Team, das alles an ein grosses Modell delegiert, bekommt nicht automatisch bessere Software. Ein Team, das die richtige Aufgabe an das richtige Modell mit den richtigen Grenzen gibt, kann wirklich schneller werden.
SYSTEMS baut solche Workflows als Engineering-Infrastruktur: Claude Code, MCP, Modellwahl, Tests, Reviews, Evals und produktionsnahe Regeln gehoeren zusammen. Dann wird agentic coding nicht nur beeindruckend, sondern belastbar.
