Denken steuern

Claudes Denken ist adaptiv: Das Modell bewertet jede Anfrage und entscheidet selbst, ob und wie viel es denkt. Du legst eine Absicht fest, gibst optional den Effort an, und das Modell setzt Reasoning dort ein, wo es nach seiner Einschätzung hilft.

Das macht Denken zu einer guten Wahl für Workloads, die triviale und komplexe Anfragen mischen, sowie für agentische Workflows mit langem Horizont, bei denen die richtige Menge an Reasoning von Schritt zu Schritt variiert.

Um zu erfahren, wie du Denken aktivierst, wie du Denkausgaben liest und mehr über die Denkausgabe bei Claude Fable 5 und Claude Mythos 5, sieh dir die Übersicht Denken an. Diese Seite behandelt, wie Claude entscheidet, wann es denkt, wie du diese Entscheidung steuerst, und die daraus folgenden Mechaniken zu Caching, Kosten und Preisgestaltung.

Wie Claude entscheidet, wann es denkt

Denken ist für das Modell optional. Bei jeder Anfrage wägt Claude die Komplexität der Eingabe ab und entscheidet, ob tieferes Reasoning die Antwort verbessern würde. Eine einfache Faktenfrage erhält möglicherweise eine direkte Antwort ganz ohne Thinking-Block; eine mehrstufige Mathematikaufgabe oder eine knifflige Debugging-Aufgabe löst tieferes Reasoning aus.

Die Entscheidung fällt pro Anfrage. Dieselbe Konversation kann Turns mit und ohne Denken enthalten, und ein Turn, in dem Claude sich entschieden hat, nicht zu denken, enthält keinen Thinking-Block. Baue keine Anwendungslogik, die davon ausgeht, dass jeder Assistant-Turn mit einem beginnt.

Die primäre Kontrolle über diese Entscheidung ist der Parameter effort, der als weiche Vorgabe dafür dient, wie bereitwillig und wie tief Claude denken soll; siehe Effort-Stufen auf dieser Seite für die Wirkung jeder Stufe.

Wenn du möchtest, dass Claude seltener denkt, senke zuerst die Effort-Stufe, bevor du zu Prompt-basierter Steuerung greifst.

Denken verschränkt sich außerdem automatisch mit der „tool use“ (Tool-Nutzung): Claude kann zwischen Tool-Aufrufen denken und über jedes Tool-Ergebnis reflektieren, bevor es entscheidet, was als Nächstes zu tun ist (verschränktes Denken). Dafür benötigst du weder einen Beta-Header noch zusätzliche Konfiguration.

Das vollständige Bild, wie die Thinking-Konfiguration und der Effort-Parameter zusammenwirken, findest du unter Denken und Effort.

Steuern, wie oft Claude denkt

Ob Claude in einem bestimmten Turn denkt, lässt sich per Prompt beeinflussen. Effort legt die Grundhaltung fest, aber du kannst die Entscheidung auch direkt mit Anweisungen in natürlicher Sprache formen, entweder global im „system prompt“ (System-Prompt) oder pro Nachricht aus dem User-Turn.

Verwende die beiden Hebel gemeinsam in dieser Reihenfolge:

1. Setze die Effort-Stufe, die zur Standardbalance deines Workloads zwischen Qualität und Latenz passt.
2. Füge Prompt-Anleitungen nur hinzu, wenn Claudes Auslöseverhalten auf dieser Stufe immer noch nicht deinen Anforderungen entspricht.

Umfassendere Prompting-Hinweise zum Denken findest du unter Denk- und verschränkte Denkfähigkeiten nutzen.

Effort-Stufen

Effort ist der primäre Steuerungshebel für das Denken. Jede Stufe setzt einen anderen Standard dafür, wie oft und wie tief Claude denkt:

Diese Tabelle beschreibt, wie jede Stufe das Denkverhalten verändert. Hinweise dazu, welche Stufe du für einen bestimmten Workload wählen solltest, einschließlich modellspezifischer Empfehlungen, findest du unter Wann der Effort-Parameter angepasst werden sollte auf der Effort-Seite.

Effort wird unter output_config.effort gesetzt, nicht innerhalb des thinking-Objekts; vollständige Beispiele pro Sprache findest du unter Effort.

{
  "model": "claude-opus-5",
  "max_tokens": 4096,
  "output_config": { "effort": "medium" },
  "messages": [{ "role": "user", "content": "..." }]
}

Die Verfügbarkeit der Stufen variiert je nach Modell; die Effort-Verfügbarkeitstabelle auf der Effort-Seite ist maßgeblich dafür, welche Stufen jedes Modell unterstützt.

System-Prompt-Anleitungen

Anleitungen im System-Prompt verschieben Claudes Denkschwelle für jede Anfrage in der Konversation. Wenn Claude häufiger denkt, als dein Workload es erfordert, füge deinem System-Prompt eine Anleitung wie diese hinzu:

Extended thinking adds latency and should only be used when it
will meaningfully improve answer quality, typically for problems
that require multistep reasoning. When in doubt, respond directly.

Um stattdessen zum Denken zu ermutigen, verwende eine Formulierung wie:

This task involves multistep reasoning. Think carefully before responding.

Die Wirksamkeit der Steuerung kann empfindlich auf die genaue Wortwahl reagieren. Wenn eine Formulierung nicht das gewünschte Verhalten erzeugt, probiere eine direktere Variante.

Nachrichtenbezogene Steuerung

Du kannst das Denken auch pro Nachricht aus dem User-Turn steuern, unabhängig vom System-Prompt. Das Anhängen von "Please think hard before responding." an eine User-Nachricht ermutigt Claude, in diesem Turn zu denken; "Answer directly without deliberating." unterdrückt es.

Nachrichtenbezogene Steuerung ist nützlich, wenn nur einige Anfragen in einer Konversation ausgedehntes Reasoning rechtfertigen. Ein Agent-Harness kann beispielsweise die ermutigende Formulierung bei Planungsschritten und die unterdrückende Formulierung bei Routinebestätigungen anhängen, ohne den System-Prompt anzufassen oder Anfrageparameter zwischen den Turns zu ändern.

Steuerung an deinem Workload überprüfen

Prompt-basierte Steuerung verändert das Modellverhalten, behandle sie also wie jede andere Prompt-Änderung: Miss, bevor du auslieferst. Führe eine repräsentative Stichprobe deines Traffics mit und ohne die Anleitung aus und vergleiche, wie oft Denken ausgelöst wird (das Vorhandensein von Thinking-Blöcken in Antworten), die Nutzung von Output-Token, die Latenz und die Antwortqualität bei den Fällen, die dir wichtig sind.

Mechaniken

Drei Mechaniken ergeben sich daraus, dass Claude sein Denken selbst verwaltet: Turn-Validierung, Prompt-Caching und wie du die Kosten begrenzt.

Turn-Validierung

Assistant-Turns müssen nicht mit einem Thinking-Block beginnen. (Modelle, die ein veraltetes manuelles Thinking-Budget verwenden, erzwingen, dass der letzte Assistant-Turn einer Anfrage mit aktiviertem Denken mit einem beginnt; siehe Turn-Struktur im manuellen Modus.)

Für Multi-Turn-Anwendungen bedeutet das, dass du den Konversationsverlauf in beliebiger Form zurückgeben kannst:

• Assistant-Turns, in denen Claude sich entschieden hat, nicht zu denken, sind unverändert gültiger Verlauf.
• Du kannst eine Konversation fortsetzen, die ohne Denken begonnen hat oder eine andere Thinking-Konfiguration verwendet hat, ohne ihren Verlauf umzuschreiben.
• Ein aus gemischten Quellen zusammengesetzter Verlauf benötigt keine wieder eingefügten Thinking-Blöcke am Anfang jedes Assistant-Turns, um die Validierung zu bestehen.

Die Lockerung betrifft die Validierung, nicht das, was du senden solltest. Wenn du Thinking-Blöcke hast, gib sie unverändert zurück, insbesondere während der Tool-Nutzung, wo sie das Reasoning hinter Claudes Tool-Aufrufen tragen. Die vollständigen Regeln findest du in der Übersicht Denken.

Prompt-Caching

Aufeinanderfolgende Anfragen, die dieselbe Thinking-Konfiguration und Effort-Stufe beibehalten, erhalten das „prompt caching“ (Prompt-Caching); die vollständigen Regeln findest du unter Denken und Prompt-Caching. Der aufgelöste Effort-Wert wird in den Prompt gerendert, sodass eine Änderung zwischen Anfragen Cache-Breakpoints invalidiert, genau wie eine Änderung des veralteten Parameters budget_tokens bei Modellen, die ihn verwenden. effort explizit auf den Standardwert des Modells zu setzen, ist gleichbedeutend mit dem Weglassen und bricht den Cache nicht.

Die praktische Konsequenz: Wähle pro Konversation eine Thinking-Konfiguration und eine Effort-Stufe und behalte sie bei. Wenn einige Turns mehr oder weniger Denken benötigen, steuere mit nachrichtenbezogenem Prompting: An die neueste User-Nachricht angehängte Anleitungen lassen frühere Cache-Breakpoints intakt, eine Konfigurations- oder Effort-Änderung hingegen nicht.

Das folgende Beispiel demonstriert die Invalidierung mit einem Multi-Turn-Skript, das du selbst ausführen kannst:

Kostenkontrolle

Du legst kein Thinking-Token-Budget fest. Zwei Kontrollen begrenzen die Kosten:

• max_tokens ist eine harte Obergrenze für die gesamte Ausgabe der Anfrage, Denken und Antworttext zusammen. Claude generiert nie darüber hinaus. In einer Tool-Use-Schleife hat jede Anfrage im Turn ihr eigenes max_tokens, sodass es nicht die Ausgaben des gesamten Turns begrenzt.
• effort ist eine weiche Vorgabe dafür, wie viel dieser Ausgabe Claude dem Denken zuweist. Es formt das Verhalten, garantiert aber keine Token-Anzahl.

Da Denken auf max_tokens angerechnet wird, setze es hoch genug, um Platz sowohl für das Reasoning als auch für die Antwort zu lassen. Ein max_tokens, das für eine Antwort ohne Denken bemessen ist, ist oft zu klein, sobald Claude bei schwierigen Anfragen zu denken beginnt.

Bei Effort high und darüber kann Claude ausgiebig denken und schöpft das Budget mit höherer Wahrscheinlichkeit aus. Wenn du stop_reason: "max_tokens" in Antworten siehst, hast du zwei Abhilfen:

• Erhöhe max_tokens, um dem Modell mehr Platz für Denken plus Antwort zu geben.
• Senke die Effort-Stufe, damit Claude weniger denkt und mehr vom Budget für Antworttext übrig lässt.

Welche die richtige ist, hängt davon ab, ob die abgeschnittenen Antworten das Reasoning benötigten. Wenn die Qualität bei diesen Anfragen wichtig ist, erhöhe die Obergrenze; wenn sie überdacht waren, senke den Effort.

Preisgestaltung

Denken verursacht Kosten für:

• Token, die Claude beim Denken verwendet (als Output-Token abgerechnet)
• Thinking-Blöcke aus früheren Assistant-Turns, die im Kontext verbleiben, gemäß dem Standard zur Beibehaltung: standardmäßig alle Turns bei Keep-All-Modellen, andernfalls nur der letzte Turn (als Input-Token abgerechnet)
• Standardmäßige Text-Output-Token

Was dir in Rechnung gestellt wird, ist unabhängig von der display-Einstellung gleich; nur was du siehst, ändert sich:

Um zu sehen, wie viele abgerechnete Output-Token für internes Reasoning aufgewendet wurden, lies usage.output_tokens_details.thinking_tokens in der Antwort. Dieser Wert spiegelt das rohe Reasoning wider, das das Modell generiert hat (nicht den im Body zurückgegebenen zusammengefassten Text), und ist immer kleiner oder gleich output_tokens. Ziehe ihn von output_tokens ab, um den Nicht-Reasoning-Anteil der Ausgabe anzunähern. Beim Streaming erscheint diese Aufschlüsselung nur im abschließenden message_delta-Event.

{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 348,
    "output_tokens_details": {
      "thinking_tokens": 312
    }
  }
}

output_tokens bleibt die inklusive, maßgebliche Gesamtsumme, die für die Abrechnung verwendet wird. output_tokens_details ist eine schreibgeschützte Aufschlüsselung zur Beobachtbarkeit. Vollständige Preisinformationen einschließlich Basistarifen, Cache-Writes, Cache-Hits und Output-Token findest du unter Preisgestaltung.

Nächste Schritte