So wählst du die richtige Claude-Modellstufe für jede Coding-Aufgabe

Wenn Menschen anfangen, mit einem KI-Coding-Assistenten zu bauen, wählen sie oft das leistungsstärkste verfügbare Modell und nutzen es für alles. Es fühlt sich sicher an — warum nicht immer das klügste Modell nutzen? Aber das klügste Modell ist auch das langsamste und teuerste, und für viel alltägliche Arbeit ist es überdimensioniert. Zu lernen, die Modellstufe an die Aufgabe anzupassen, ist eine der wirkungsvollsten Gewohnheiten, die du dir aneignen kannst. Sie spart Geld, liefert Antworten schneller und — kontraintuitiv — erzeugt manchmal bessere Ergebnisse, weil ein schnelles Modell, das fertig wird, dich mehr iterieren lässt.

Dieser Leitfaden nutzt Anthropics Claude-Aufstellung als Beispiel, aber das Prinzip gilt für jeden Anbieter, der eine Modellfamilie ausliefert.

Die Stufen, von leicht bis schwer

Mitte 2026 hat Claude vier Stufen, jede in etwa eine Steigerung in Leistungsfähigkeit und Preis (offizielle Preise):

• Haiku 4.5 — 1 $ / 5 $ pro Million Input-/Output-Tokens. Schnell und günstig. Ideal für einfache, klar definierte Arbeit.
• Sonnet 4.6 — 3 $ / 15 $. Das Arbeitspferd. Stark beim Coding und den meisten Produktionsaufgaben.
• Opus 4.8 — 5 $ / 25 $. Schwereres Reasoning für komplexe, mehrstufige Probleme.
• Fable 5 — 10 $ / 50 $. Das neue Mythos-Klasse-Flaggschiff, veröffentlicht am 9. Juni 2026, für die schwersten Probleme.

Beachte, dass Output-Tokens auf jeder Stufe das Fünffache der Input-Tokens kosten und dass der Sprung von Sonnet zu Fable mehr als eine Verdreifachung des Preises ist. Genau diese Lücken sind der Grund, warum die Stufenwahl zählt.

Anthropics eigene Faustregel

Anthropics Preis-Dokumentation gibt eine erfrischend unverblümte Empfehlung: "Wähle Haiku für einfache Aufgaben, Sonnet für die meisten Produktions-Workloads und Opus für das komplexeste Reasoning." Fable 5 verlängert diese Leiter um eine Sprosse für Probleme auf Frontier-Niveau.

In Coding-Arbeit übersetzt:

• Greif zu Haiku, wenn die Aufgabe mechanisch ist: Variablen umbenennen, einen Regex schreiben, JSON formatieren, Boilerplate-Tests generieren, ein Diff zusammenfassen oder schnell "was macht diese Funktion?" beantworten.
• Standardmäßig Sonnet für den Großteil echten Codings: ein Feature implementieren, einen normalen Bug beheben, eine Komponente schreiben, einen Pull Request prüfen. Das sollte deine Heimatbasis sein.
• Eskaliere zu Opus, wenn eine Aufgabe echtes Reasoning über viel Kontext braucht: ein mehrdeutiger Bug ohne offensichtliche Ursache, ein Refactoring über mehrere Dateien, bei dem Änderungen ineinandergreifen, oder architektonische Designentscheidungen.
• Spar dir Fable 5 für das seltene Problem, das Opus bezwingt — eine ausufernde Migration, ein subtiler Nebenläufigkeits-Bug oder Arbeit, die in einer einzigen Sitzung eine sehr große Codebasis umspannt.

Ein durchgespieltes Beispiel

Nimm an, du fügst einer Web-App ein neues "Export nach CSV"-Feature hinzu. Ein stufenbewusster Workflow könnte so aussehen:

1. Planen mit Opus. "Hier ist meine Codebasis-Struktur. Wo sollte die Export-Logik leben, und welche Grenzfälle sollte ich behandeln?" Das ist reasoning-lastig und gibt die Richtung vor — das bessere Modell wert.
2. Implementieren mit Sonnet. "Schreibe die Export-Funktion und verdrahte sie mit einem Button." Standard-Coding, das das Arbeitspferd gut bewältigt.
3. Testen und aufräumen mit Haiku. "Generiere Unit-Tests für diese Funktion" und "formatiere diese Datei neu". Günstig, schnell, mechanisch.

Das teure Modell berührt nur die 10 % der Aufgabe, die es tatsächlich brauchen. In Claude Code wechselst du mitten in der Sitzung mit /model sonnet oder /model haiku; in Cursor wählst du aus dem Modell-Dropdown. Das gesamte Feature kostet einen Bruchteil dessen, was es kosten würde, wenn Opus oder Fable jeden Schritt erledigte — und ist schneller fertig, weil die günstigen Schritte nahezu sofort zurückkommen.

Kosten senken, ohne eine Stufe abzusteigen

Die Stufenwahl ist der größte Hebel, aber zwei eingebaute Features setzen obendrauf an:

• Prompt-Caching. Wenn du denselben großen Kontext wiederholt sendest (einen großen System-Prompt, eine Datei, auf die du immer wieder verweist), kostet das Cachen die folgenden Lesevorgänge nur 10 % des Input-Preises. Für Agent-Schleifen, die jeden Zug den Kontext erneut senden, ist das gewaltig.
• Batch-Verarbeitung. Für nicht dringende, hochvolumige Aufgaben — Tests für 200 Dateien generieren, einen Docs-Ordner übersetzen — läuft die Batch-API asynchron mit 50 % Rabatt auf Input und Output.

Keines davon ändert die Qualität des Modells; sie ändern nur, was du für dieselbe Arbeit zahlst.

Das Fazit

Greif nicht aus Vorsicht standardmäßig zum größten Modell. Greif standardmäßig zu Sonnet, fall zu Haiku ab, wenn die Aufgabe trivial ist, und steig nur zu Opus oder Fable auf, wenn ein Problem wirklich tieferes Reasoning verlangt. Du gibst weniger aus, wartest weniger und — weil du dir mehr Iterationen leisten kannst — lieferst oft besseren Code. Das Ziel ist nicht, das klügste Modell zu nutzen; es ist, das richtige für die Aufgabe vor dir zu nutzen.