Denken steuern

Claudes Denken ist adaptiv: Das Modell bewertet jede Anfrage und entscheidet selbst, ob es denkt und wie viel. Du legst eine Absicht fest, gibst optional den Effort an, und das Modell weist das Reasoning dort zu, wo es einschätzt, dass Reasoning hilft.

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

Wie du das Denken aktivierst, wie du die Denkausgabe liest und Denkausgabe bei Claude Fable 5 und Claude Mythos 5 findest du in der Denken-Übersicht. Diese Seite behandelt, wie Claude entscheidet, wann es denkt, wie du diese Entscheidung steuerst, und die Caching-, Kosten- und Preismechanismen, die sich daraus ergeben.



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 kann eine direkte Antwort ganz ohne Denkblock erhalten; ein mehrstufiges Mathematikproblem oder eine knifflige Debugging-Aufgabe löst tieferes Reasoning aus.

Die Entscheidung erfolgt pro Anfrage. Dieselbe Konversation kann Turns mit und ohne Denken enthalten, und ein Turn, bei dem Claude sich gegen das Denken entschieden hat, enthält keinen Denkblock. Baue keine Anwendungslogik, die davon ausgeht, dass jeder Assistant-Turn mit einem beginnt.

Die primäre Kontrolle über diese Entscheidung ist der effort-Parameter, der als weiche Anleitung dafür dient, wie bereitwillig Claude denken sollte und wie tief; siehe Effort-Stufen auf dieser Seite für das, was jede Stufe bewirkt.

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

Denken verschränkt sich auch automatisch mit 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). Du brauchst dafür keinen Beta-Header oder zusätzliche Konfiguration.

Für das vollständige Bild, wie die Denkkonfiguration und der Effort-Parameter zusammenwirken, siehe Denken und Effort.



Steuern, wie oft Claude denkt

Ob Claude in einem bestimmten Turn denkt, ist promptbar. Effort legt die allgemeine Haltung fest, aber du kannst die Entscheidung auch direkt mit natürlichsprachlicher Anleitung formen, entweder global im System-Prompt oder pro Nachricht aus dem User-Turn.

Verwende die beiden Hebel zusammen in dieser Reihenfolge:

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

Für umfassendere Prompting-Anleitung mit Denken siehe 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 Claude denkt und wie tief:

Diese Tabelle beschreibt, wie jede Stufe das Denkverhalten verändert. Für Hinweise, welche Stufe du für einen bestimmten Workload wählen solltest, einschließlich modellspezifischer Empfehlungen, siehe 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-4-8",
  "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 die maßgebliche Quelle dafür, welche Stufen jedes Modell unterstützt.



System-Prompt-Anleitung

System-Prompt-Anleitung verschiebt Claudes Denkschwelle für jede Anfrage in der Konversation. Wenn Claude häufiger denkt, als dein Workload benötigt, 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 Formulierung reagieren. Wenn eine Formulierung nicht das gewünschte Verhalten erzeugt, probiere eine direktere Variante.



Steuerung pro Nachricht

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.

Steuerung pro Nachricht ist nützlich, wenn nur einige Anfragen in einer Konversation erweitertes Reasoning rechtfertigen. Ein Agent-Harness kann zum Beispiel die ermutigende Formulierung bei Planungsschritten und die unterdrückende Formulierung bei routinemäßigen Bestätigungen anhängen, ohne den System-Prompt anzufassen oder Anfrageparameter zwischen Turns zu ändern.



Steuerung auf deinem Workload verifizieren

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 das Denken ausgelöst wird (das Vorhandensein von Denkblöcken in Antworten), die Nutzung von Output-Token, die Latenz und die Antwortqualität in den Fällen, die für dich wichtig sind.



Mechanik

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



Turn-Validierung

Assistant-Turns müssen nicht mit einem Denkblock beginnen. (Modelle, die ein Legacy-Budget für manuelles Denken 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 der Form zurückgeben kannst, in der du ihn hast:

• Assistant-Turns, bei denen Claude sich gegen das Denken entschieden hat, sind als Verlauf unverändert gültig.
• Du kannst eine Konversation fortsetzen, die ohne Denken begann oder eine andere Denkkonfiguration verwendete, ohne ihren Verlauf umzuschreiben.
• Verlauf, der aus gemischten Quellen zusammengestellt wurde, benötigt keine am Anfang jedes Assistant-Turns wieder eingefügten Denkblöcke, um die Validierung zu bestehen.

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



Prompt-Caching

Aufeinanderfolgende Anfragen, die dieselbe Denkkonfiguration und Effort-Stufe beibehalten, erhalten das Prompt-Caching; siehe Denken und Prompt-Caching für die vollständigen Regeln. Der aufgelöste Effort-Wert wird in den Prompt gerendert, sodass eine Änderung zwischen Anfragen Cache-Breakpoints invalidiert, genauso wie eine Änderung des Legacy-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 eine Denkkonfiguration und eine Effort-Stufe pro Konversation und behalte sie bei. Wenn einige Turns mehr oder weniger Denken benötigen, steuere mit Prompting pro Nachricht: Anleitung, die an die neueste User-Nachricht angehängt wird, lässt frühere Cache-Breakpoints intakt, während eine Konfigurations- oder Effort-Änderung das nicht tut.

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



Kostenkontrolle

Du setzt kein Token-Budget für das Denken. Zwei Steuerungen 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 Anleitung dafür, wie viel dieser Ausgabe Claude dem Denken zuweist. Es formt das Verhalten, garantiert aber keine Token-Anzahl.

Da das 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 dimensioniert 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 eher aus. Wenn du stop_reason: "max_tokens" in Antworten siehst, hast du zwei Abhilfen:

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

Welche davon richtig 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.



Preise

Denken verursacht Kosten für:

• Token, die Claude während des Denkens verwendet (als Output-Token abgerechnet)
• Denkblöcke aus früheren Assistant-Turns, die im Kontext verbleiben, gemäß dem Aufbewahrungsstandard: standardmäßig alle Turns bei Keep-All-Modellen, nur der letzte Turn bei anderen (als Input-Token abgerechnet)
• Standard-Textausgabe-Token

Wofür du abgerechnet wirst, 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 zusammengefassten Text, der im Body zurückgegeben wird), und ist immer kleiner oder gleich output_tokens. Ziehe ihn von output_tokens ab, um den Nicht-Reasoning-Anteil der Ausgabe zu approximieren. Beim Streaming erscheint diese Aufschlüsselung nur beim finalen 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 für Observability. Vollständige Preisinformationen einschließlich Basistarifen, Cache-Writes, Cache-Hits und Output-Token findest du unter Preise.



Nächste Schritte