Claude Code: Welches Modell wofür – und wie du Tokens sparst
Fable, Opus, Sonnet oder Haiku? Welches Modell sich für welche Aufgabe lohnt, wie du je Modell prompten solltest und mit welchen Handgriffen du Tokens sparst.
Wer mit Claude Code arbeitet, stellt früher oder später zwei Fragen: Welches Modell nehme ich wofür? und Warum ist mein Kontingent schon wieder leer? Beides hängt zusammen. Dieser Artikel fasst zusammen, was in der offiziellen Dokumentation von Anthropic steht, und ergänzt meine Faustregeln aus dem Bau von lx-labs. Was belegt ist, steht mit Quelle am Ende; meine Erfahrung ist als solche gekennzeichnet. Claude Code ändert sich schnell – Stand: Oktober 2026.
Die Modelle im Überblick
In Claude Code wählst du das Modell über einen Alias. Das sind die, die es aktuell gibt:
| Alias | Modell | Anthropic beschreibt es als | Preis je Mio. Token (Eingabe / Ausgabe) | Kontext |
|---|---|---|---|---|
fable | Fable 5.1 | für anspruchsvolles Schlussfolgern und lange, selbstständige Aufgaben; langsamer | 10 $ / 50 $ | 1 Mio. |
opus | Opus 5.5 | für lang laufendes Programmieren und Wissensarbeit; mittlere Geschwindigkeit | 4 $ / 20 $ | 1 Mio. |
sonnet | Sonnet 5.5 | beste Kombination aus Tempo und Intelligenz; schnell | 2 $ / 10 $ | 1 Mio. |
haiku | Haiku 4.5 | das schnellste Modell, mit Intelligenz nahe der Spitze | 1 $ / 5 $ | 200 Tsd. |
opusplan | Opus plant, Sonnet führt aus | — | je nach Phase | — |
Die Preise sind die Listenpreise der API in US-Dollar. Auf einem Abo zahlst du pauschal und verbrauchst stattdessen dein Kontingent — die Verhältnisse bleiben aber ein guter Anhaltspunkt: Ein Fable-Token kostet fünfmal so viel wie ein Sonnet-Token.
Was Anthropic empfiehlt: Die Claude-Code-Dokumentation sagt: Sonnet erledigt die meisten Programmieraufgaben gut und kostet weniger als Opus; Opus ist für komplexe Architekturentscheidungen und mehrstufiges Schlussfolgern. Auf der Modellseite empfiehlt Anthropic dagegen, bei den meisten Aufgaben mit Opus 5.5 zu starten. Fable ist für die Fälle gedacht, in denen Opus selbst mit höherem Effort nicht reicht. Und für die schwierigsten, lang laufenden Aufgaben nennt Anthropic bei Sonnet ausdrücklich ein Opus-Modell als bessere Wahl.
Meine Praxis: Ich starte im Alltag mit Sonnet, weil es schnell ist und das Kontingent schont, und greife für Planung und harte Fehlersuche zu Opus. Fable nehme ich nur, wenn Opus nicht weiterkommt. Haiku nutze ich für Hilfsaufgaben im Hintergrund. Das ist eine Erfahrung und keine Messreihe — wenn du viel Budget hast, ist der Start mit Opus ebenso vernünftig.
Welche Modelle hinter den Aliasen stehen, hängt vom Anbieter ab: Bei Amazon Bedrock oder Google Cloud löst sonnet zum Beispiel auf Sonnet 4.5 auf, bei Microsoft Foundry opus auf Opus 4.6. Mit /status siehst du, welches Modell gerade läuft.
Modell wechseln
/model # Auswahl öffnen
/model sonnet # direkt wechseln
claude --model opus # beim Start festlegen
Im Auswahlfenster speichert Enter das Modell als Standard, s wechselt nur für die aktuelle Sitzung. Auch Hilfs-Agenten (Subagenten) erben das Modell deiner Sitzung — ein Wechsel auf Opus gilt also für sie mit. Für einfache Hilfsaufgaben kannst du in ihrer Konfiguration model: haiku eintragen.
Die Denktiefe (Effort)
Neben dem Modell bestimmt die Denktiefe, wie viel „nachgedacht“ wird. Das Nachdenken zählt als Ausgabe-Tokens und ist der Posten, der am schnellsten wächst.
/effort # Regler öffnen
/effort low # flott und günstig
/effort high # gründlicher
Es gibt low, medium, high, xhigh und max. Bei Opus 5.5 ist medium voreingestellt. Abschalten lässt sich das Denken bei Opus 5.5, Sonnet 5.5 und den Fable-Modellen nicht, nur in der Tiefe regeln. Haiku 4.5 kennt keinen Effort-Regler.
Die Anleitung für Sonnet 5.5 rät: für gut beschriebene Programmieraufgaben mit medium beginnen, für schwerere oder längere mit high. xhigh und max nur dort, wo du einen Qualitätsgewinn gemessen hast — dort wird das Denken und die Antwort deutlich länger, und das Modell startet teils eigene Prüfrunden. Routinearbeit gehört auf high oder darunter.
So prompte ich je Modell
Hier geht es um meine Erfahrung, nicht um offizielle Vorgaben. Der Grundgedanke: Je stärker das Modell, desto mehr kannst du beim Ziel bleiben. Je kleiner das Modell, desto genauer solltest du den Weg beschreiben.
Fable und Opus: Ziel, Grenzen, Prüfkriterium. Beschreibe, was am Ende stimmen muss, nicht jeden Schritt. Ein Beispiel aus lx-labs:
Baue einen Box-Generator für den 3D-Druck: Maße eingeben, STL herunterladen, alles im Browser. Der Deckel muss auch bei Trennwänden passen. Prüfe das mit einem Test, nicht nur mit dem Auge.
Lass dir bei größeren Dingen erst einen Plan zeigen (Plan-Modus mit Shift+Tab) und entscheide dann. Das spart die teure Variante, bei der ein falscher Ansatz komplett neu gebaut wird.
Sonnet: eine konkrete Aufgabe, Datei benannt, Ergebnis prüfbar – und sagen, wann Schluss ist.
Im ESPHome-Baukasten fehlt für den DS3231 die Zeitquelle. Ergänze in
catalog.tsden Block aus der ESPHome-Doku und passe den Test an.
Sonnet bekommt die Aufgabe in einem Satz, die betroffene Datei und einen Weg, die Lösung zu überprüfen. Große Vorhaben zerlegst du in kleine Schritte und testest nach jedem.
Zwei Eigenheiten von Sonnet 5.5, die Anthropic in der Modell-Anleitung beschreibt:
- Es ergänzt gern ungefragt Tests, Dokumentation und kleine Dateien. Wenn du nur das Verlangte willst, sag es: „Wenn die Aufgabe erledigt und geprüft ist, melde das. Füge keine Funktionen, Tests oder Dateien hinzu, die nicht verlangt waren; Vorschläge nennst du am Ende.“
- Bei niedrigem Effort meldet es manchmal „fertig“, ohne die Änderung zu prüfen, und bei langen Aufgaben fragt es öfter zwischendurch nach. Gegenmittel: höheren Effort wählen oder ausdrücklich verlangen, dass vor der Fertigmeldung die Tests oder der Build laufen.
Haiku: schnell und eng geführt. Anthropic nennt es das schnellste Modell mit Intelligenz nahe der Spitze; die Claude-Code-Dokumentation empfiehlt es für das Durchsuchen von Code (der eingebaute Explore-Subagent) und für einfache Aufgaben. Ich gebe ihm Aufgaben mit eindeutiger Eingabe und Ausgabe: Dateien durchsuchen, Texte in ein Format bringen, Logs filtern. Bei Entscheidungen und kniffliger Fehlersuche nehme ich ein größeres Modell — das ist meine Erfahrung, nicht Anthropics Vorgabe. Beachte: Haiku hat nur 200 Tsd. Token Kontext und keinen Effort-Regler.
Bei jedem Modell hilft das:
- Ein Prüfkriterium mitgeben: ein Test, ein erwartetes Ergebnis, ein Screenshot. Wenn Claude sein Ergebnis selbst prüfen kann, fängt es Fehler ab, bevor du nachbessern musst.
- Konkret statt vage. „Verbessere die Seite“ löst breites Durchsuchen aus. „Füge in
auth.tseine Eingabeprüfung für das Login hinzu“ nicht. - Spielregeln einmal festlegen, nicht jedes Mal wiederholen — in der Projektdatei
CLAUDE.md. Bei mir stehen dort zum Beispiel „kurz antworten, keine Einleitung“ und „nur die beste Lösung, dazu kurz die Nachteile“. Das spart Ausgabe bei jeder Antwort.
Tokens sparen: die wichtigsten Handgriffe
Die Kosten wachsen mit der Größe des Kontexts. Claude Code schickt bei jeder Anfrage das gesamte bisherige Gespräch mit. Deshalb sparst du am meisten, wenn der Kontext klein bleibt.
1. Zwischen Aufgaben leeren. /clear startet frisch, wenn du zu etwas Unverwandtem wechselst. Alter Kontext kostet bei jeder weiteren Nachricht. Mit /rename vorher kannst du die Sitzung später mit /resume wiederfinden.
2. Gezielt zusammenfassen. /compact fasst das Gespräch zusammen. Du kannst sagen, was erhalten bleiben soll:
/compact Behalte Code-Änderungen und Testausgaben
Das Zusammenfassen liest den ganzen Verlauf und ist selbst eine große Anfrage. Wenn du ohnehin neu anfangen willst, ist /clear kostenlos.
3. Das passende Modell wählen. Sonnet für den Alltag, Opus oder Fable nur für das, was es braucht. Nach der Planung mit einem großen Modell kann ein kleineres das Umsetzen übernehmen — opusplan macht das automatisch.
4. Denktiefe anpassen. Für einfache Aufgaben /effort low. Das Denken zählt als Ausgabe, und die kostet beim Preis je Token ein Mehrfaches der Eingabe (bei allen vier Modellen das Fünffache). xhigh und max heben dir nur für Fälle auf, in denen du den Gewinn gemessen hast.
5. Verbose Arbeit auslagern. Tests ausführen, Dokumentation lesen oder große Logs durchsuchen lässt du Subagenten erledigen. Deren Ausgabe bleibt in ihrem eigenen Kontext, bei dir kommt nur die Zusammenfassung an. Mit einem kleineren Modell für die Subagenten sparst du zusätzlich.
6. Die Projektdatei schlank halten. CLAUDE.md wird bei jedem Start geladen. Die Dokumentation empfiehlt, sie unter 200 Zeilen zu halten und Anleitungen für einzelne Abläufe in Skills zu verschieben — die laden nur, wenn sie gebraucht werden.
7. Unnötige Anbindungen abschalten. Mit /context siehst du, was Platz belegt. Mit /mcp schaltest du MCP-Server aus, die du gerade nicht nutzt. Wo es ein Kommandozeilenwerkzeug gibt (gh, aws und ähnliche), ist das sparsamer als ein MCP-Server.
8. Früh gegensteuern. Läuft Claude in die falsche Richtung, drückst du Esc. Mit /rewind oder zweimal Esc springst du zu einem früheren Stand zurück. Das ist billiger als eine lange falsche Strecke.
9. Nach Pausen aufpassen. Der Zwischenspeicher für den Kontext (Prompt-Cache) hält auf einem Abo eine Stunde, bei API-Nutzung standardmäßig fünf Minuten. Aus dem Zwischenspeicher gelesene Tokens kosten nur einen Bruchteil des normalen Eingabepreises — nach einer längeren Pause muss aber der ganze Kontext neu verarbeitet werden. Wer nach Stunden eine Sitzung weiterführt, startet besser frisch oder lässt sich zusammenfassen.
10. Den Verbrauch im Blick haben. /usage zeigt den Verbrauch der Sitzung, auf einem Abo die Auslastung deines Kontingents samt Aufschlüsselung. Dort werden Verbräuche markiert, die mehr als 10 Prozent ausmachen, etwa langer Kontext oder verfehlter Zwischenspeicher.
Wenn das Kontingent erreicht ist
Bei einem Abo gilt das Fenster für alle Modelle zusammen. „Session-Limit“ oder „Wochen-Limit“ erreichst du also nicht dadurch, dass du das Modell wechselst. Anders ist es bei einer modellbezogenen Meldung wie „Opus-Limit“: Dann kannst du mit /model auf ein Modell einer anderen Familie ausweichen und weiterarbeiten.
Mein Ablauf in der Praxis
- Neue Aufgabe?
/clear. - Größeres Vorhaben: Plan-Modus, Plan lesen, entscheiden.
- Umsetzen mit Sonnet, in kleinen Schritten, jeweils mit Test.
- Schwierige Fehlersuche oder Architekturfragen kurz an Opus oder Fable geben.
- Lange Ausgaben (Tests, Recherche) an Subagenten.
- Vor dem Feierabend einen Blick auf
/usage.
Mehr dazu, wie lx-labs mit Claude Code gebaut wurde, steht im Artikel So ist lx-labs entstanden.
