Claude Code Effort Levels: Fable 5, Opus 4.8 und Sonnet 4.6

Jeder, der ernsthaft mit der Claude API baut, kennt die Frage aus dem Alltag. Welcher Effort-Level für welchen Task, ohne dass die Token-Rechnung am Monatsende aussieht wie eine Cloud-Migration ohne Budgetplan. Genau hier setzen die Claude Code Effort Levels an. Sie bestimmen, wie großzügig Claude Tokens für eine Aufgabe einsetzt, und damit lassen sich Qualität, Geschwindigkeit, Latenz und Kosten gezielt beeinflussen. Bei Techiota bauen wir KI-Integrationen, Agenten und API-gestützte Workflows, und der Effort-Parameter ist einer der wenigen Hebel, der gleichzeitig Qualität und Kosten anfasst. Dieser Artikel ist die Entwicklersicht darauf, mit konkreten API-Details, Code und Empfehlungen aus der Praxis. Die offizielle Referenz steht in der Anthropic-Dokumentation zum Effort-Parameter.

Die Claude API unterscheidet fünf Stufen: low, medium, high, xhigh und max. Nicht jedes Modell kennt alle fünf. Claude Fable 5 und Claude Opus 4.8 lassen sich auch mit xhigh betreiben, bei Claude Sonnet 4.6 stehen low, medium, high und max zur Verfügung. Der Effort-Level ist kein festes Thinking-Token-Budget, sondern ein Verhaltenssignal an das Modell. Claude entscheidet innerhalb dieses Rahmens, wie ausführlich es antwortet, wie tief es analysiert und wie viele Tools oder Funktionen es aufruft.

Effort Levels im schnellen Überblick

Hier die kompakte Matrix. Sie beantwortet die zwei häufigsten Fragen aus dem Code-Review auf einen Blick. Was tut die Stufe, und welches Modell kann sie.

high ist der allgemeine Standardwert. Wird kein Effort-Level angegeben, verhält sich Claude so, als wäre high gesetzt. Das heißt aber nicht, dass high für jedes Modell und jede Aufgabe die wirtschaftlich beste Einstellung ist. Anthropic empfiehlt abhängig vom Modell unterschiedliche Ausgangspunkte, und genau diese Empfehlungen schauen wir uns gleich modellweise an.

Was Effort bei Claude wirklich bedeutet

Effort steuert, wie bereitwillig Claude Tokens für eine Antwort ausgibt. Das betrifft nicht nur das interne Denken des Modells. Der Parameter beeinflusst den gesamten erzeugten Output: normale Textantworten, Erklärungen, Tool-Aufrufe, Funktionsargumente, Extended Thinking, Planungsschritte, Code-Kommentare und Zusammenfassungen nach einer Aufgabe.

Ein niedriger Effort-Level führt typischerweise zu kürzeren Antworten und weniger Tool-Aufrufen. Claude versucht, schneller und direkter zum Ergebnis zu kommen. Ein höherer Effort-Level kann dazu führen, dass Claude mehr Dateien untersucht, zusätzliche Tools verwendet, einen Plan vor der Ausführung erstellt, mehr Randfälle berücksichtigt, Änderungen ausführlicher dokumentiert, Ergebnisse gründlicher kontrolliert und umfangreichere Code-Kommentare erzeugt. Effort steuert damit nicht nur, wie lange Claude nachdenkt. Es beeinflusst den gesamten Arbeitsstil des Modells, und das merkt man im Agenten-Loop deutlich.

Effort ist kein festes Token-Budget

Eine häufige Fehlannahme lautet, dass jeder Effort-Level einer bestimmten Anzahl von Thinking-Tokens entspricht. Das ist nicht der Fall. Der Effort-Level ist ein weiches Steuerungssignal. Claude darf auch bei low nachdenken, wenn eine Aufgabe schwierig genug ist. Für dieselbe Aufgabe wird das Modell bei low jedoch normalerweise weniger Tokens einsetzen als bei high, xhigh oder max.

Die tatsächliche Nutzung hängt unter anderem ab von der Schwierigkeit der Aufgabe, der Länge des Kontexts, der Anzahl erforderlicher Tool-Aufrufe, dem gewählten Claude-Modell, der gesetzten max_tokens-Grenze und der Aktivierung von Adaptive Thinking. Das macht Effort flexibler als ein starres Token-Budget. Gleichzeitig solltest du die Einstellung mit realen Aufgaben testen, weil sich ihre Wirkung je nach Workflow unterscheiden kann. Bei Techiota heißt das konkret, wir messen pro Workflow, statt einmalig eine Stufe zu raten und sie dann für jeden Task festzunageln.

Low Effort

low ist die effizienteste Einstellung. Claude verwendet weniger Tokens, antwortet knapper und versucht, Aufgaben mit möglichst wenig zusätzlicher Analyse zu erledigen.

Gute Einsatzbereiche sind einfache Klassifizierungen, schnelle Nachschlagefragen, kurze Chat-Antworten, Formatierungsänderungen, Tippfehler- und Syntaxkorrekturen, kleine Umbenennungen, einfache Code-Erklärungen, klar definierte Subagent-Aufgaben, große Mengen gleichartiger Anfragen und latenzkritische Anwendungen.

Beispiel: „Ändere den Variablennamen customerName in diesem Code in clientName.” Für eine solche Aufgabe ist keine ausführliche Architekturprüfung nötig. Ein höherer Effort-Level würde wahrscheinlich mehr Tokens verbrauchen, ohne das Ergebnis entscheidend zu verbessern.

low reicht dagegen nicht, wenn eine Aufgabe mehrere Dateien betrifft, versteckte Abhängigkeiten enthält, eine Root-Cause-Analyse benötigt, sicherheitsrelevant ist, mehrere Lösungswege gegeneinander abwägen muss oder eine lange Kette von Tool-Aufrufen erfordert. Bei komplexen Aufgaben kann eine Antwort mit Low Effort plausibel aussehen und trotzdem wichtige Zusammenhänge übersehen. Eine zu niedrige Stufe spart hier an der falschen Stelle, weil die Korrekturrunden teurer werden als die eingesparten Tokens.

Medium Effort

medium bietet ein ausgewogenes Verhältnis aus Leistung, Geschwindigkeit und Tokenverbrauch. Diese Stufe eignet sich für viele typische Entwicklungsaufgaben und ist insbesondere bei Claude Sonnet 4.6 ein sinnvoller Ausgangspunkt.

Gute Einsatzbereiche sind normale Codegenerierung, klar beschriebene Features, Unit-Tests, kleinere Refactorings, Standard-Bugfixes, API-Anbindungen, Formularvalidierung, Tool-gestützte Arbeitsabläufe, Agentenaufgaben mit überschaubarem Umfang, technische Dokumentation und Code-Reviews mit klarer Prüfliste.

Beispiel: „Erstelle Unit-Tests für diese Funktion. Berücksichtige gültige Werte, leere Eingaben und ungültige Datentypen.” Claude braucht hier mehr Kontextverständnis als bei einer einfachen Umbenennung. Die Aufgabe ist aber klar genug, um normalerweise ohne maximale Denktiefe gelöst zu werden.

Eine Besonderheit gibt es bei Sonnet 4.6. Obwohl Sonnet 4.6 technisch mit high startet, empfiehlt Anthropic ausdrücklich, medium für die meisten Anwendungen zu setzen. Medium passt bei Sonnet 4.6 besonders für agentisches Coding, Tool-heavy Workflows, Codegenerierung und normale produktive Anwendungen. Die explizite Einstellung verhindert außerdem, dass Anwendungen unerwartet mehr Latenz und Tokens verursachen als erforderlich. In unseren Pipelines bei Techiota setzen wir Sonnet 4.6 deshalb explizit auf medium, statt uns auf den Default zu verlassen.

High Effort

high ist der Standardwert der Claude API. Diese Stufe ist für komplexe Denkaufgaben, schwieriges Coding und anspruchsvolle Agentenprozesse vorgesehen.

Gute Einsatzbereiche sind schwierige Fehleranalysen, Architekturentscheidungen, anspruchsvolle Code-Reviews, Performance-Optimierung, Sicherheitsanalysen, komplexere Refactorings, mehrstufige technische Planungen, agentische Aufgaben mit mehreren Tools, Analyse größerer Codebereiche und Aufgaben mit wichtigen Randbedingungen.

Beispiel: „Analysiere, warum dieser asynchrone Prozess sporadisch doppelte Datenbankeinträge erzeugt. Berücksichtige Parallelität, Retries und fehlende Idempotenz.” Hier reicht oberflächliche Mustererkennung nicht aus. Claude muss mehrere mögliche Fehlerursachen prüfen und ihre Wechselwirkungen verstehen.

Für Claude Fable 5 empfiehlt Anthropic, bei den meisten Aufgaben mit high zu beginnen. Routineaufgaben lassen sich anschließend auf medium oder low reduzieren, besonders anspruchsvolle Workloads auf xhigh erhöhen. high ist damit der natürliche Startpunkt für Fable 5, von dem aus du nach unten oder oben kalibrierst.

XHigh Effort

xhigh steht zwischen high und max. Diese Einstellung ist für besonders anspruchsvolle Aufgaben gedacht, bei denen Claude über einen längeren Zeitraum planen, suchen, programmieren, prüfen und korrigieren muss. Unter den hier betrachteten Modellen unterstützen Claude Fable 5 und Claude Opus 4.8 xhigh, Claude Sonnet 4.6 unterstützt kein xhigh.

Gute Einsatzbereiche sind langlaufende Coding-Aufgaben, komplexe agentische Workflows, wiederholte Tool-Aufrufe, ausführliche Recherchen, umfangreiche Codebase-Analysen, große Multi-File-Refactorings, Migrationen über mehrere Komponenten, autonome Implementierungsaufgaben, Aufgaben mit Subagents und tiefgehende Fehlersuche.

Beispiel: „Analysiere die bestehende Authentifizierungsarchitektur. Plane die Migration auf ein rollenbasiertes Berechtigungsmodell, implementiere die notwendigen Änderungen und prüfe Tests, Datenmigration und Rückwärtskompatibilität.” Diese Aufgabe besteht nicht aus einem einzigen Denkschritt. Claude muss den Ist-Zustand verstehen, einen Plan entwickeln, Änderungen durchführen und das Ergebnis kontrollieren.

Bei Claude Opus 4.8 empfiehlt Anthropic für Coding und agentische Anwendungen, mit xhigh zu beginnen. Für andere Aufgaben, bei denen Intelligenz und Analysequalität wichtig sind, ist high meist der richtige Ausgangspunkt. Eine Reduzierung auf medium oder low sollte erst erfolgen, wenn eigene Tests zeigen, dass die Qualität stabil bleibt. Bei Techiota fahren wir agentisches Coding mit Opus 4.8 standardmäßig mit xhigh und drehen erst herunter, wenn die Evaluation grünes Licht gibt.

Bei Claude Fable 5 ist high der empfohlene Standard. xhigh solltest du für besonders leistungssensitive Aufgaben einsetzen. Das betrifft Workloads, bei denen zusätzliche Analysefähigkeit einen messbaren Vorteil bringt, etwa besonders schwierige Architekturentscheidungen, langfristige Agentenprozesse, komplexe technische Forschung, kritische Code-Migrationen und umfassende Systemanalysen.

Max Effort

max weist Claude an, die höchstmögliche Leistungsfähigkeit einzusetzen, ohne den Tokenverbrauch zugunsten von Effizienz einzuschränken. Max ist bei Claude Fable 5, Claude Opus 4.8 und Claude Sonnet 4.6 verfügbar.

Gute Einsatzbereiche sind außergewöhnlich schwere Probleme, sicherheitskritische Analysen, komplexe Algorithmen, schwer reproduzierbare Fehler, Race Conditions, kritisches Systemdesign, finale Prüfung risikoreicher Änderungen, anspruchsvolle Architektur-Reviews und wichtige Entscheidungen mit hohen Fehlerkosten.

Beispiel: „Prüfe dieses Mandanten- und Berechtigungsmodell auf mögliche Privilege-Escalation-Pfade, Datenlecks und fehlerhafte Vertrauensgrenzen.” Bei solchen Aufgaben können übersehene Fehler erhebliche Folgen haben. Der zusätzliche Tokenverbrauch ist dann häufig besser vertretbar als eine zu oberflächliche Analyse.

max ist trotzdem nicht für jede Aufgabe die richtige Wahl. Bei einfachen oder stark strukturierten Aufgaben kann Max unnötig viele Tokens verbrauchen, die Antwortzeit erhöhen, zu übermäßiger Analyse führen, mehr Text erzeugen als erforderlich und kaum messbare Qualitätsgewinne bringen. Die stärkste Einstellung bringt also nicht in jedem Fall den besten Kosten-Nutzen-Schnitt.

Welcher Effort-Level zu welchem Modell passt

Die Modelle haben unterschiedliche Ausgangspunkte, und genau das macht den Unterschied zwischen einer durchdachten und einer teuren Konfiguration aus. Hier die drei Empfehlungstabellen, wie wir sie auch intern als Default-Karte nutzen.

Claude Sonnet 4.6 (1M Kontext): Medium für die meisten Anwendungen

Für die meisten Anwendungen ist medium der sinnvollste Ausgangspunkt. low empfiehlt sich für hohe Anfragevolumen und latenzkritische Workloads. high solltest du nutzen, wenn Qualität wichtiger ist als Geschwindigkeit. max bleibt außergewöhnlich schwierigen Aufgaben vorbehalten. Sonnet 4.6 unterstützt kein xhigh.

Claude Opus 4.8 (1M Kontext): XHigh für Coding und Agenten

Für Coding und agentische Anwendungsfälle empfiehlt Anthropic xhigh als Ausgangspunkt. high eignet sich für die meisten anderen Aufgaben, bei denen Analysequalität entscheidend ist. medium und low solltest du erst einsetzen, nachdem eigene Evaluationen bestätigt haben, dass die geringere Einstellung für den jeweiligen Workflow ausreicht. max ist nur sinnvoll, wenn Tests einen messbaren Qualitätsvorteil gegenüber xhigh zeigen.

Claude Fable 5 (1M Kontext): High als Standard

Anthropic empfiehlt, bei Fable 5 grundsätzlich mit high zu starten. Wenn eine Aufgabe zwar erfolgreich abgeschlossen wird, aber unnötig lange dauert, kannst du den Effort-Level reduzieren. Für besonders anspruchsvolle Workloads steht xhigh zur Verfügung.

Praxisempfehlung nach Aufgabentyp

Diese Tabelle ist unsere Schnellreferenz, wenn ein neuer Task im Backlog landet und niemand Lust auf eine Grundsatzdiskussion hat. Sie ist eine praktische Ausgangsbasis, die endgültige Einstellung sollte über eigene Evaluationen erfolgen.

Adaptive Thinking bei Fable 5, Opus 4.8 und Sonnet 4.6

Effort und Adaptive Thinking hängen eng zusammen, sind aber nicht dasselbe. Effort steuert die Bereitschaft des Modells, Tokens einzusetzen. Adaptive Thinking entscheidet dynamisch, ob und wie intensiv Claude für eine konkrete Anfrage intern analysiert. Wer beide verwechselt, baut sich Konfigurationen, die entweder still ohne Thinking laufen oder unnötig teuer sind.

Claude Fable 5: Adaptive Thinking ist immer aktiviert. Eine zusätzliche thinking-Konfiguration ist nicht erforderlich. Das Denken lässt sich bei diesem Modell nicht deaktivieren. Der Effort-Level steuert, wie tief und ausführlich das adaptive Denken ausfällt.

Claude Opus 4.8: unterstützt ausschließlich Adaptive Thinking. In API-Anfragen muss es jedoch explizit aktiviert werden:

thinking={"type": "adaptive"}

Wird die Thinking-Konfiguration weggelassen, läuft die Anfrage ohne Extended Thinking. Die ältere manuelle Konfiguration mit budget_tokens wird bei Opus 4.8 nicht unterstützt. Wer das aus alten Skripten kopiert, wundert sich sonst über fehlendes Denken.

Claude Sonnet 4.6: Adaptive Thinking ist der empfohlene Modus. Die ältere Steuerung funktioniert noch:

thinking={"type": "enabled", "budget_tokens": 10000}

Sie ist aber veraltet und soll in einer zukünftigen Modellversion entfernt werden. Für neue Implementierungen solltest du deshalb Adaptive Thinking zusammen mit dem Effort-Parameter verwenden.

Opus 4.8 mit XHigh konfigurieren

Hier der konkrete API-Aufruf für eine anspruchsvolle Coding-Aufgabe. So sieht eine xhigh-Konfiguration mit Adaptive Thinking aus, wie wir sie für agentische Refactorings einsetzen.

import anthropic

client = anthropic.Anthropic()

# Techiota: xhigh + adaptive thinking für agentisches Refactoring
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,
    thinking={
        "type": "adaptive"
    },
    output_config={
        "effort": "xhigh"
    },
    messages=[
        {
            "role": "user",
            "content": (
                "Analysiere die bestehende Anwendung, plane das "
                "Refactoring und prüfe anschließend alle Änderungen."
            )
        }
    ]
)
print(response.content)

Ein Detail, das im Alltag immer wieder beißt: Bei Opus 4.8 solltest du für xhigh und max einen ausreichend großen Wert für max_tokens wählen. max_tokens ist eine harte Obergrenze. Sie umfasst sowohl die Thinking-Tokens als auch den sichtbaren Antworttext. Ein hoher Effort-Level kann seine Wirkung nicht vollständig entfalten, wenn die Ausgabe frühzeitig durch ein zu niedriges max_tokens-Limit abgeschnitten wird. Wer xhigh setzt und dann bei 4000 Tokens deckelt, bezahlt für Denkbereitschaft, die nie sichtbar wird.

Opus 4.8 und Opus 4.8 [1M]: der Unterschied

In Claude Code begegnet dir Opus 4.8 an zwei Stellen, einmal als „Opus 4.8” und einmal als „Opus 4.8 [1M]”. Wichtig für alle, die gegen die API bauen: Das ist dasselbe Modell. Die Kennzeichnung [1M] betrifft ausschließlich das Kontextfenster, nicht die Intelligenz und nicht den Effort-Level.

Das Kontextfenster ist der Arbeitsspeicher der laufenden Sitzung. Darin liegen die bisherige Unterhaltung, eingelesene Dateien, Quellcode, Tool-Ergebnisse, Systemanweisungen und die aktuell erzeugte Antwort.

Was [1M] nicht bedeutet

Opus 4.8 [1M] ist nicht intelligenter als Opus 4.8, kein anderer Modell-Checkpoint, nicht automatisch gründlicher, kein höherer Effort-Level, nicht schneller und nicht mit mehr maximaler Ausgabe ausgestattet. Für die Denktiefe verwendest du weiterhin Effort-Level wie high, xhigh oder max. Kontextfenster und Effort-Level sind zwei getrennte Einstellungen.

Wann [1M] sinnvoll ist

Die 1M-Variante lohnt sich bei sehr großen Repositorys, langen Claude-Code-Sitzungen, Analysen über viele Dateien hinweg, umfangreichen Dokumentationen, großen Logs oder Datenbeständen und langlaufenden agentischen Workflows. Für eine normale Funktion, einen überschaubaren Bugfix oder ein kleines Repository bringt [1M] meist keinen Vorteil. Ein größerer Schreibtisch trifft schließlich nicht automatisch bessere Architekturentscheidungen.

Besonderheit auf der Anthropic API

Auf der direkten Anthropic API besitzt Claude Opus 4.8 bereits standardmäßig ein Kontextfenster von 1 Million Tokens. Zwischen claude-opus-4-8 und einer Claude-Code-Auswahl mit [1M] besteht dort hinsichtlich der maximalen Kontextgröße praktisch kein Unterschied. Die Kennzeichnung [1M] dient in Claude Code vor allem dazu, die erweiterte Kontextvariante ausdrücklich auszuwählen oder an den jeweiligen Anbieter weiterzugeben.

Für Claude-Code-Abonnements gilt laut Anthropic:

• Max, Team und Enterprise: 1M-Kontext für Opus ist enthalten und wird automatisch aktiviert.
• Pro: Die 1M-Variante benötigt Usage Credits.
• Anthropic API und Pay-as-you-go: voller 1M-Zugriff.
• Microsoft Foundry: Opus 4.8 ist auf 200.000 Tokens begrenzt.

Praktische Empfehlung

Nimm normales Opus 4.8, wenn dein Repository überschaubar ist, die Sitzung noch relativ kurz ist und Claude nur einen begrenzten Ausschnitt analysieren soll. Nimm Opus 4.8 [1M], wenn du ein großes Repository vollständig untersuchen lässt, Claude über eine lange Sitzung möglichst wenig verdichten oder vergessen soll und viele Dateien, Spezifikationen und Tool-Ergebnisse gleichzeitig relevant bleiben.

Mehr Kontext kann den Tokenverbrauch und teilweise die Latenz erhöhen. Außerdem weist Anthropic darauf hin, dass größere Kontextmengen nicht automatisch bessere Ergebnisse bedeuten, weil die Treffergenauigkeit bei sehr langen Kontexten abnehmen kann. Relevant und sauber strukturierter Kontext ist deshalb wertvoller als bloß maximal viel Kontext.

Was ist Claude Code Ultracode

ultracode erscheint im Effort-Menü von Claude Code. Es ist jedoch kein zusätzlicher API-Effort-Level. Ultracode kombiniert zwei Funktionen:

1. Claude arbeitet mit xhigh.
2. Claude Code erhält die grundsätzliche Berechtigung, dynamische Multi-Agenten-Workflows zu starten.

Dadurch kann Claude größere Aufgaben aufteilen und mehrere spezialisierte Arbeitsabläufe koordinieren. Ultracode eignet sich beispielsweise für umfangreiche Softwareprojekte, komplexe Migrationen, große Codebase-Analysen, parallele Implementierungs- und Prüfaufgaben und dynamische Agentenorchestrierung.

Wichtig für alle, die gegen die API bauen: Die API akzeptiert weiterhin nur die dokumentierten Effort-Werte low, medium, high, xhigh und max. Ultracode solltest du deshalb nicht mit xhigh gleichsetzen. Es nutzt xhigh, ergänzt diesen Level aber um zusätzliche Orchestrierungsrechte innerhalb von Claude Code. Wie wir solche Multi-Agenten-Workflows praktisch aufsetzen, zeigt unser Beitrag Multi-Agent-Websites bauen.

Wie Effort die Tool-Nutzung beeinflusst

Der Effort-Level beeinflusst nicht nur die Textausgabe, sondern auch Tool-Aufrufe. Das ist für agentische Workflows der eigentlich spannende Teil.

Bei niedrigem Effort tendiert Claude dazu, weniger Tools aufzurufen, Operationen stärker zusammenzufassen, ohne lange Einleitung zu handeln, kurze Abschlussmeldungen zu schreiben und sich enger auf die unmittelbare Aufgabe zu beschränken.

Bei hohem Effort kann Claude mehr Tools einsetzen, einen ausführlichen Plan erstellen, Zwischenergebnisse prüfen, Änderungen genauer zusammenfassen, mehr Kommentare erzeugen und weitere Randfälle untersuchen. Das ist bei agentischen Coding-Aufgaben besonders relevant. Ein zu niedriger Effort-Level kann dazu führen, dass Claude zu früh mit der Analyse aufhört. Ein unnötig hoher Level kann dagegen zu mehr Tool-Aufrufen führen, als die Aufgabe tatsächlich benötigt.

Claude Code Kosten mit Effort reduzieren

Effort ist ein wichtiger Hebel für die Tokenkosten. Ein niedriger Effort-Level reduziert typischerweise die Länge der Antworten, die Tiefe des Denkens, die Anzahl der Tool-Aufrufe, die Laufzeit und den Tokenverbrauch.

Die wirtschaftlich beste Strategie besteht aber nicht darin, immer low zu verwenden. Eine oberflächliche oder falsche Antwort kann mehr kosten, wenn anschließend mehrere Korrekturrunden nötig werden. Unser Vorgehen bei Techiota folgt deshalb dieser Schleife:

1. Klassifiziere die Aufgabe nach Komplexität und Risiko.
2. Wähle den niedrigsten realistisch geeigneten Effort-Level.
3. Messe Qualität, Tokenverbrauch und Laufzeit.
4. Erhöhe Effort, wenn wichtige Aspekte übersehen werden.
5. Reduziere Effort, wenn eine Aufgabe zuverlässig mit weniger Aufwand funktioniert.
6. Verwende max nur bei messbarem Mehrwert.

Dynamische Effort-Auswahl in Agenten-Workflows

In professionellen KI-Agenten muss der Effort-Level nicht statisch sein. Ein vorgeschalteter Model Router kann Aufgaben vorab einordnen:

• Einfache Aufgabe: Sonnet 4.6 mit low.
• Normale Coding-Aufgabe: Sonnet 4.6 mit medium.
• Komplexe Analyse: Opus 4.8 mit high.
• Agentische Entwicklungsaufgabe: Opus 4.8 mit xhigh.
• Kritische Architekturprüfung: Fable 5 mit max.

Dadurch muss nicht jede Anfrage mit dem teuersten Modell und dem höchsten Effort-Level bearbeitet werden. Eine dynamische Auswahl kann Kosten senken, Latenz reduzieren, Kapazitäten besser verteilen, kritische Aufgaben gründlicher bearbeiten und einfache Aufgaben schneller abschließen. Wie ein solcher Router in echten Projekten aussieht, zeigen wir unter Multi-Agent-Websites bauen.

Wann Effort erhöhen, wann reduzieren

Eine Erhöhung ist sinnvoll, wenn Claude einen wichtigen Teil der Aufgabe übersieht, die falsche Problemvariante löst, relevante Dateien nicht untersucht, Randfälle ignoriert, eine Analyse zu früh beendet, bei mehreren Versuchen oberflächlich bleibt, Nebenwirkungen einer Änderung nicht erkennt, notwendige Tool-Aufrufe nicht durchführt oder eine plausible, aber unvollständige Lösung liefert. Bei Opus 4.8 gilt besonders: Wenn komplexe Aufgaben bei medium oder low zu oberflächlich bearbeitet werden, solltest du den Effort-Level erhöhen, statt den Prompt immer weiter aufzublähen.

Eine Reduzierung ist sinnvoll, wenn die Aufgabe einfach und klar definiert ist, Claude unnötig ausführlich antwortet, zu viele Tools aufgerufen werden, die Bearbeitung länger dauert als erforderlich, die Qualität bei niedrigerem Effort gleich bleibt, sehr viele ähnliche Aufgaben verarbeitet werden oder Latenz wichtiger als maximale Analyse ist. Bei Fable 5 lohnt sich eine Reduzierung besonders dann, wenn eine Aufgabe zwar korrekt erledigt wird, aber unnötig viel Zeit beansprucht.

FAQ

Welche Claude Code Effort Levels gibt es?

Die Claude API unterstützt low, medium, high, xhigh und max. Nicht jedes Modell unterstützt alle Level. Sonnet 4.6 unterstützt beispielsweise kein xhigh.

Welcher Effort-Level ist der Standard?

Der allgemeine Standardwert ist high. Wird kein Effort-Parameter angegeben, entspricht das Verhalten einer expliziten Einstellung auf high.

Welcher Effort-Level ist für Sonnet 4.6 sinnvoll?

Für die meisten Anwendungen medium. Das gilt besonders für Codegenerierung, agentisches Coding und Tool-intensive Workflows. Für komplexe Denkaufgaben kann high genutzt werden.

Welcher Effort-Level ist für Opus 4.8 sinnvoll?

Für Coding und agentische Aufgaben empfiehlt Anthropic xhigh. Für andere anspruchsvolle Aufgaben ist high ein sinnvoller Ausgangspunkt.

Welcher Effort-Level ist für Fable 5 sinnvoll?

Für die meisten Aufgaben high. xhigh eignet sich für besonders leistungssensitive Workloads. Routineaufgaben können mit medium oder low bearbeitet werden.

Unterstützt Sonnet 4.6 XHigh?

Nein. xhigh steht bei den hier behandelten Modellen nur für Claude Fable 5 und Claude Opus 4.8 zur Verfügung.

Ist Max immer besser als XHigh?

Nein. Max kann deutlich mehr Tokens einsetzen, ohne bei jeder Aufgabe einen entsprechenden Qualitätsgewinn zu liefern. Bei einfachen oder stark strukturierten Aufgaben kann es sogar zu unnötiger Überanalyse kommen.

Was bedeutet das [1M] hinter Opus 4.8 in Claude Code?

[1M] kennzeichnet das erweiterte Kontextfenster von bis zu 1 Million Tokens, nicht ein stärkeres Modell. Intelligenz und Denktiefe steuert weiterhin der Effort-Level. Auf der direkten Anthropic API besitzt Opus 4.8 dieses 1M-Fenster bereits standardmäßig.

Ist Ultracode ein Effort-Level?

Nicht auf API-Ebene. Ultracode ist ein Claude-Code-Modus, der xhigh mit der Erlaubnis zur dynamischen Multi-Agenten-Orchestrierung kombiniert.

Ersetzt Effort die Einstellung budget_tokens?

Bei Fable 5 und Opus 4.8 wird kein manuelles Thinking-Budget verwendet. Bei Sonnet 4.6 ist budget_tokens noch funktionsfähig, aber veraltet. Anthropic empfiehlt Adaptive Thinking zusammen mit Effort.

Beeinflusst Effort auch Tool-Aufrufe?

Ja. Niedrige Effort-Level führen typischerweise zu weniger Tool-Aufrufen. Höhere Level können umfangreichere Planung, zusätzliche Tools und gründlichere Prüfungen auslösen.

Kann Effort dynamisch gewählt werden?

Ja. Eine Anwendung kann den Effort-Level abhängig von Komplexität, Risiko, Kosten oder Latenz einer Aufgabe festlegen.

Fazit

Die Claude Code Effort Levels ermöglichen eine gezielte Steuerung von Qualität, Geschwindigkeit und Tokenverbrauch. Die wichtigsten Empfehlungen aus der Entwicklerpraxis: Sonnet 4.6 mit medium für die meisten normalen Anwendungen. Opus 4.8 mit xhigh für Coding und agentische Workflows. Fable 5 mit high für die meisten anspruchsvollen Aufgaben. low für einfache, häufige und latenzkritische Anfragen. max nur für außergewöhnlich schwierige oder kritische Aufgaben. Die wirtschaftlich beste Einstellung ist die niedrigste Stufe, die eine Aufgabe zuverlässig, vollständig und mit akzeptabler Qualität erledigt. Bei Techiota ist das kein einmaliges Setup, sondern eine Messschleife pro Workflow.

Die offiziellen Werte und Modell-Hinweise findest du in der Anthropic-Dokumentation. Wenn ihr Effort-Routing, Adaptive Thinking oder agentische Pipelines mit der Claude API produktiv aufsetzen wollt, ohne dabei Tokens zu verbrennen, sprecht Techiota an. Wir verdrahten die Mechanik aus diesem Artikel regelmäßig in echten Projekten.