Extended Thinking: Reasoning-Effort bei Claude gezielt steuern

1. Was Extended Thinking technisch bedeutet

Extended Thinking ist ein separater Ausgabekanal, in dem Claude vor der eigentlichen Antwort einen strukturierten Denkprozess formuliert: Annahmen prüfen, Alternativen abwägen, Zwischenergebnisse verwerfen oder weiterverfolgen. Dieser Denktext ist kein Marketing-Gimmick, sondern ein echter Bestandteil der Inferenz. Das Modell nutzt die zusätzlichen Tokens, um vor der finalen Antwort mehrere Lösungswege im Kontext durchzuspielen, statt sofort auf den ersten plausiblen Pfad festzulegen.

Für Entwickler ist relevant, dass der Denktext von der finalen Antwort getrennt ist und je nach Client unterschiedlich behandelt wird. In Claude Code erscheint er als einklappbarer Block vor der eigentlichen Antwort, in der API als eigenes thinking-Content-Element neben dem text-Element. Wer die Denkschritte nachvollziehen will, etwa um zu verstehen, warum ein bestimmter Lösungsweg verworfen wurde, kann sie gezielt einblenden, statt sie nur als Blackbox-Verzögerung wahrzunehmen.

// Auszug aus einer API-Antwort mit Extended Thinking
{
  "content": [
    {
      "type": "thinking",
      "thinking": "Der Bug tritt nur bei gleichzeitigen Requests auf. Das deutet auf eine Race Condition beim Cache-Zugriff hin. Ich prüfe zuerst, ob der Read-Modify-Write-Zyklus atomar ist..."
    },
    {
      "type": "text",
      "text": "Die Ursache ist eine fehlende Sperre beim Cache-Zugriff..."
    }
  ]
}

2. Wann sich ein höherer Reasoning-Effort lohnt

Ein höherer Reasoning-Effort zahlt sich vor allem bei Aufgaben aus, bei denen es mehrere plausible, aber unterschiedlich gute Lösungswege gibt und ein falscher Weg teuer wird. Klassische Beispiele sind Architekturentscheidungen mit mehreren tragfähigen Optionen, etwa die Wahl zwischen Event-Sourcing und einer klassischen CRUD-Struktur für ein neues Modul, oder das Debugging vertrackter Bugs, bei denen die Ursache nicht offensichtlich ist und mehrere Hypothesen gegeneinander abgewogen werden müssen.

Auch bei Migrationsplanung, komplexer Nebenläufigkeit oder der Analyse von Performance-Regressionen in verteilten Systemen zeigt sich der Effekt deutlich: Das Modell verwirft in der Denkphase erkennbar falsche Ansätze, bevor sie in der Antwort landen. Das reduziert die Zahl der Iterationen, die ein Entwickler sonst selbst durchlaufen müsste, weil eine erste, zu schnell formulierte Antwort sich als Sackgasse herausstellt.

# Claude Code: hohen Reasoning-Effort für eine komplexe Aufgabe anfordern
claude "Analysiere, warum unser Checkout unter Last (200 req/s) \
  intermittierend Bestellungen dupliziert. Nutze extended thinking \
  mit hohem Effort, prüfe Idempotenz, Retries und Datenbank-Locks."

3. Wann hoher Effort nur Zeit und Tokens kostet

Bei einfachen, klar umrissenen Aufgaben bringt ein hoher Reasoning-Effort kaum messbaren Nutzen, verlängert aber die Antwortzeit spürbar und erhöht den Tokenverbrauch. Eine einfache CRUD-Aufgabe wie das Anlegen eines neuen Repository-Endpunkts nach einem bereits etablierten Muster im Projekt braucht keine minutenlange Abwägung mehrerer Lösungswege, denn der Lösungsweg ist durch die bestehende Codebasis bereits vorgegeben. Hier zahlt das Team lediglich für zusätzliche Denkschritte, die keine neue Erkenntnis liefern.

Auch bei Aufgaben mit eindeutig richtiger, mechanischer Antwort, etwa das Formatieren einer Datei, das Umbenennen einer Variable über mehrere Dateien hinweg oder das Ausfüllen eines bekannten Boilerplate-Musters, ist hoher Effort verschwendetes Budget. In interaktiven Sitzungen mit vielen kleinen Anfragen hintereinander summiert sich diese Verzögerung schnell zu spürbarer Wartezeit, ohne dass die Qualität der Antworten messbar steigt.

4. Das Denkbudget: Tokens, Zeit und Kosten im Zusammenspiel

Technisch wird Extended Thinking über ein Tokenbudget gesteuert, das dem Modell für den Denkprozess zur Verfügung steht. Ein größeres Budget erlaubt mehr Zwischenschritte, mehr verworfene Ansätze und mehr explizite Selbstkorrektur, kostet aber proportional mehr Rechenzeit und mehr Tokens, die in der Abrechnung genauso zählen wie die sichtbare Antwort. Ein zu knapp bemessenes Budget kann dazu führen, dass der Denkprozess mitten in einer Abwägung abgeschnitten wird, was die Qualität der finalen Antwort spürbar verschlechtert.

In der Praxis lohnt sich ein gestuftes Vorgehen: niedriges oder gar kein Denkbudget als Standard für den Entwickleralltag, ein mittleres Budget für Aufgaben mit mehreren Lösungswegen und ein hohes Budget gezielt für die wenigen Aufgaben pro Woche, bei denen eine falsche Entscheidung teuer würde. Diese Staffelung spiegelt sich unmittelbar in den Kosten wider, weshalb Teams mit hohem Anfragevolumen die Effort-Stufe bewusst pro Aufgabentyp festlegen sollten, statt sie dem Zufall der jeweiligen Sitzung zu überlassen.

5. Reasoning-Effort in Claude Code praktisch steuern

In Claude Code lässt sich der Reasoning-Effort über die Modellwahl und über explizite Hinweise im Prompt beeinflussen. Ein einfacher Zusatz wie think hard oder think longer im Prompt signalisiert dem Modell, dass ein größeres Denkbudget angemessen ist, während ein knapper, direkter Prompt ohne solche Hinweise das Standardverhalten mit geringerem Effort auslöst. Für wiederkehrende Aufgabentypen lohnt es sich, diese Formulierungen als Konvention im Team festzuhalten, statt sie bei jeder Anfrage neu zu erfinden.

Zusätzlich beeinflusst die Wahl des Modells selbst den sinnvollen Effort-Bereich: Ein größeres Modell mit hohem Reasoning-Effort ist für seltene, kritische Architekturfragen gedacht, während ein schnelleres, kleineres Modell mit niedrigem Effort für die vielen kleinen Zwischenschritte im Alltag, etwa das Schreiben eines einzelnen Tests, die bessere Wahl bleibt. Diese Kombination aus Modellwahl und Effort-Hinweis ist der eigentliche Hebel, nicht ein einzelner globaler Schalter.

# Niedriger Effort: schnelle, mechanische Aufgabe ohne Denkbudget-Hinweis
claude "Benenne die Variable userDta in userData um, projektweit."

# Höherer Effort: expliziter Hinweis für eine Architekturentscheidung
claude "Think hard: Sollen wir für das neue Reporting-Modul auf \
  Read-Replicas setzen oder einen separaten Event-Stream aufbauen? \
  Wäge Konsistenz, Betriebsaufwand und Latenz gegeneinander ab."

6. Der thinking-Parameter in der API im Detail

Wer die Claude API direkt anspricht statt Claude Code zu nutzen, steuert Extended Thinking über einen expliziten Parameter im Request, der ein Tokenbudget für den Denkprozess festlegt. Dieses Budget ist getrennt vom regulären max_tokens-Limit der Antwort zu verstehen und muss im eigenen Kostenmodell separat eingeplant werden, weil Denk-Tokens und Antwort-Tokens getrennt abgerechnet werden. Für automatisierte Pipelines, etwa einen CI-Schritt, der Commit-Nachrichten bewertet, lohnt sich ein bewusst niedriges Budget, weil die Aufgabe repetitiv und mechanisch ist.

Für Agenten-Workflows, die selbstständig mehrere Werkzeuge nacheinander aufrufen und Zwischenergebnisse bewerten müssen, ist ein höheres Budget dagegen oft gerechtfertigt, weil Fehlentscheidungen in einer frühen Phase sich sonst über mehrere nachfolgende Werkzeugaufrufe fortpflanzen. Wichtig ist, das Budget nicht statisch für die gesamte Anwendung zu setzen, sondern es pro Aufgabentyp zu parametrisieren, etwa über eine Konfigurationsdatei, die verschiedene Endpunkte unterschiedlichen Effort-Stufen zuordnet.

from anthropic import Anthropic

client = Anthropic()

response = client.messages.create(
    model="claude-opus-4-6",
    max_tokens=4096,
    thinking={"type": "enabled", "budget_tokens": 8000},
    messages=[{
        "role": "user",
        "content": "Entwirf eine Migrationsstrategie für den Wechsel "
                    "von einer monolithischen Order-Pipeline zu einer "
                    "ereignisbasierten Architektur mit Kafka.",
    }],
)

for block in response.content:
    if block.type == "thinking":
        print("Denkprozess:", block.thinking[:200], "...")
    elif block.type == "text":
        print("Antwort:", block.text)

7. Praxisbeispiel: Eine Race Condition mit Extended Thinking aufspüren

Ein realistisches Beispiel aus dem Entwickleralltag: Ein Team meldet, dass unter Last vereinzelt doppelte Zahlungsbuchungen entstehen, obwohl der Code auf den ersten Blick idempotent wirkt. Ohne Extended Thinking liefert Claude häufig eine plausible, aber zu oberflächliche erste Vermutung, etwa einen fehlenden Unique-Index. Mit hohem Reasoning-Effort arbeitet das Modell im sichtbaren Denkprozess systematisch mehrere Hypothesen durch: fehlende Transaktionsgrenzen, ein zu großzügig konfigurierter Retry-Mechanismus im Zahlungs-Gateway und ein Wettlauf zwischen zwei Worker-Prozessen, die denselben Idempotenz-Schlüssel gleichzeitig lesen.

Im sichtbaren Denktext lässt sich nachvollziehen, welche Hypothese aus welchem Grund verworfen wurde, etwa weil der Datenbank-Log keine parallelen Schreibvorgänge im relevanten Zeitfenster zeigt. Diese Nachvollziehbarkeit ist der eigentliche Mehrwert gegenüber einer Blackbox-Antwort: Ein erfahrener Entwickler kann die Argumentation gezielt prüfen und korrigieren, statt eine falsche Antwort ungeprüft zu übernehmen oder eine richtige Antwort aus Misstrauen zu verwerfen.

8. Typische Antipatterns bei der Effort-Steuerung

Das häufigste Antipattern ist die pauschale Einstellung eines Projekts auf maximalen Reasoning-Effort nach dem Motto, mehr Denken könne schließlich nicht schaden. In der Praxis führt das zu spürbar längeren Wartezeiten bei trivialen Anfragen und zu einem aufgeblähten Tokenbudget, das sich am Monatsende in der Abrechnung zeigt, ohne dass die Antwortqualität bei den meisten Aufgaben tatsächlich profitiert hätte. Das zweite häufige Antipattern ist das genaue Gegenteil: Reasoning-Effort komplett zu deaktivieren, auch für die seltenen, wirklich kritischen Entscheidungen, nur um die Team-Konvention einfach zu halten.

Ein drittes, subtileres Antipattern ist es, den Denktext zwar anzufordern, ihn aber nie zu lesen. Wenn niemand im Team die sichtbaren Denkschritte prüft, geht der eigentliche Vorteil von Extended Thinking verloren, nämlich die Möglichkeit, eine fragwürdige Argumentationskette zu erkennen, bevor sie in produktiven Code übernommen wird. Der Denktext sollte bei kritischen Entscheidungen als Teil des Code-Reviews behandelt werden, nicht als optionales Beiwerk, das ungelesen weggeklickt wird.

9. Teamkonventionen für den Umgang mit Reasoning-Effort

Teams, die Claude Code regelmäßig einsetzen, profitieren von einer kurzen, dokumentierten Konvention, welche Aufgabentypen welchen Effort-Grad rechtfertigen. Eine solche Konvention lässt sich direkt in der projektweiten CLAUDE.md festhalten, sodass jedes Teammitglied und jeder automatisierte Aufruf dieselbe Grundlage nutzt, statt die Entscheidung bei jeder einzelnen Anfrage neu zu treffen. Das reduziert nicht nur Kosten, sondern auch die Streuung in der Antwortqualität zwischen unterschiedlichen Entwicklern im selben Projekt.

Sinnvoll ist eine dreistufige Einteilung: Standardeffort für alltägliche Aufgaben wie Refactoring nach bekanntem Muster, mittlerer Effort für Aufgaben mit mehreren gleichwertigen Optionen, und hoher Effort ausschließlich für Architekturentscheidungen, Sicherheitsanalysen und das Debugging produktionskritischer Fehler. Diese Einteilung sollte regelmäßig überprüft werden, weil sich sowohl die Fähigkeiten der Modelle als auch die Anforderungen eines wachsenden Projekts über die Zeit verändern.

10. Zusammenfassung

11. FAQ: Extended Thinking und Reasoning-Effort: Das Wichtigste auf einen Blick