Denken

Ein Modell, das in einem einzigen Durchgang antwortet, muss alles beim ersten Versuch richtig machen: keine Nebenrechnungen, kein Überprüfen, kein Kurswechsel auf halbem Weg. Bei einem Beweis, einem kniffligen Bug oder einer langen agentischen Aufgabe ist der erste Ansatz oft nicht der beste.

„Thinking“ (Denken) hebt diese Einschränkung auf. Wenn Denken aktiv ist, arbeitet Claude das Problem in eigenen Worten durch, bevor es antwortet: Es formuliert neu, was gefragt wird, probiert Ansätze aus, prüft Zwischenergebnisse und verwirft Wege, die nicht tragen. Diese Überlegungen kommen in thinking-Inhaltsblöcken vor der Antwort an, und Claude stützt sich darauf, um die endgültige Antwort zu erzeugen. Deshalb verbessert Denken die Leistung bei komplexen Aufgaben wie Mathematik, Programmierung, Analyse und lang laufender agentischer Arbeit, bei denen die Qualität der Antwort von Zwischenarbeit abhängt, die sonst in die Antwort selbst komprimiert oder übersprungen würde.

Denken hat seinen Preis: Die Token, die Claude für das Überlegen aufwendet, werden als Ausgabe-Token abgerechnet, auch wenn der Denktext nicht an dich zurückgegeben wird, und sie zählen zusammen mit dem Antworttext auf max_tokens. Diese Seite behandelt, wie sich Denken über die gesamte API-Oberfläche hinweg verhält: wie du es einschaltest, seine Ausgabe liest und seine Wechselwirkungen mit Tools, Streaming, Caching und dem „context window“ (Kontextfenster) handhabst.

Wie Denken funktioniert

Ob Claude bei einer bestimmten Anfrage denkt und wie tief, hängt von deiner Denkkonfiguration und der Komplexität der Anfrage ab.

So sieht Denken in einer Antwort aus: Ein oder mehrere thinking-Inhaltsblöcke kommen vor den text-Blöcken an. Der Thinking-Block ist weiterhin generierter Inhalt, wie der darauf folgende text-Block, aber er ist von der kanonischen Antwort getrennt. Jeder Thinking-Block trägt außerdem ein signature-Feld, eine verschlüsselte Kopie der vollständigen Überlegungen, die du in Multi-Turn- und Tool-Use-Gesprächen unverändert zurückgibst (siehe Verschlüsselung des Denkens):

{
  "content": [
    {
      "type": "thinking",
      "thinking": "Let me break this down. The question has two parts, so I'll start with the simpler one and use its result to constrain the second...",
      "signature": "WaUjzkypQ2mUEVM36O2Txu...."
    },
    {
      "type": "text",
      "text": "Based on my analysis..."
    }
  ]
}

Du siehst diesen Text nicht immer, und was du siehst, ist nie die rohe Gedankenkette: Der Text in einem Thinking-Block ist eine Zusammenfassung von Claudes Überlegungen. Das Feld display in der Denkkonfiguration steuert, ob diese Zusammenfassung überhaupt zurückgegeben wird: "summarized" gibt sie zurück, während "omitted", der Standard bei vielen Modellen, Thinking-Blöcke mit einem leeren thinking-Feld zurückgibt. In beiden Fällen wird der Block gleich abgerechnet und in Multi-Turn-Gesprächen gleich zurückgegeben. Siehe Anzeige des Denkens steuern für modellspezifische Standardwerte und Details.

Wenn Claude Tools verwendet, kann Denken auch zwischen Tool-Aufrufen auftreten. Siehe Denken mit Tool-Nutzung. Das vollständige Antwortformat findest du in der Messages-API-Referenz.

Denken konfigurieren

Bei den meisten Modellen ist Denken standardmäßig eingeschaltet oder nur einen Parameter entfernt. Welche Konfiguration jedes Modell akzeptiert und was der jeweilige Standard ist, steht in der modellspezifischen Konfigurationstabelle auf der Seite zur Fehlerbehebung.

Bei Claude Opus 5, Claude Sonnet 5, Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5 und Claude Mythos Preview ist Denken bereits eingeschaltet und benötigt keine Konfiguration. display ist bei diesen Modellen standardmäßig "omitted", sodass der Denktext verborgen bleibt, bis du dich dafür entscheidest. Aktiviere ihn mit thinking: {"type": "adaptive", "display": "summarized"}, was genau der folgenden Anfrage mit ausgetauschtem Modell-String entspricht.

Bei Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6 und Claude Sonnet 4.6 ist Denken ausgeschaltet, bis du thinking: {type: "adaptive"} setzt, wodurch Claude anhand der Anfrage entscheidet, wann und wie tief es denkt. Die folgenden Beispiele tun genau das, setzen display: "summarized", damit der Denktext sichtbar ist, und verwenden ein großzügiges max_tokens:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
)

for block in response.content:
    if block.type == "thinking":
        print(f"\nThinking: {block.thinking}")
    elif block.type == "text":
        print(f"\nResponse: {block.text}")

Wenn du das Beispiel ausführst, wird zuerst das zusammengefasste Denken und dann die Antwort ausgegeben:

Thinking: Use Euclidean algorithm.
1071 = 2*462 + 147
462 = 3*147 + 21
147 = 7*21 + 0
GCD = 21

Response: ## Finding GCD of 1071 and 462

I'll use the **Euclidean algorithm**, repeatedly dividing and taking remainders...

Denk-Token zählen auf max_tokens, setze es also hoch genug, um Platz sowohl für das Denken als auch für den Antworttext zu lassen. Siehe Kostenkontrolle auf der Seite zur Steuerung und Denken und das Kontextfenster.

Denken ausschalten

Bei Claude Sonnet 5, wo Denken standardmäßig eingeschaltet ist, kannst du es ausschalten:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    thinking={"type": "disabled"},
    messages=[{"role": "user", "content": "Summarize this article in one sentence."}],
)

Auch bei Claude Opus 5 ist Denken standardmäßig eingeschaltet, und es akzeptiert thinking: {type: "disabled"} bei Effort high oder darunter. Bei Effort xhigh oder max kann Denken nicht ausgeschaltet werden: Anfragen, die thinking: {type: "disabled"} mit diesen Effort-Stufen kombinieren, geben einen 400-Fehler zurück. Diese Einschränkung gilt für Claude Opus 5 und spätere Modelle und wird bei jeder Anfrage durchgesetzt. Mit deaktiviertem Denken kann Claude Opus 5 gelegentlich Tool-Aufrufe als Klartext ausgeben oder interne XML-Tags in seine sichtbare Ausgabe aufnehmen. Siehe Betrieb mit deaktiviertem Denken für Prompting-Gegenmaßnahmen.

Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5 und Claude Mythos Preview lehnen thinking: {type: "disabled"} ab. Denken kann bei diesen Modellen nicht ausgeschaltet werden.

Wenn dein Modell nur „extended thinking“ (erweitertes Denken) unterstützt (siehe die modellspezifische Konfigurationstabelle), konfiguriere es stattdessen mit type: "enabled" und einem budget_tokens-Wert. Die Seite Erweitertes Denken behandelt diese Konfiguration. Und falls eine Denkkonfiguration mit einem 400-Fehler zurückkommt, ordnet Fehlerbehebung beim Denken jeder Fehlermeldung ihre Lösung zu.

Denkausgabe lesen

Anzeige des Denkens steuern

Das Feld display in der Denkkonfiguration steuert, wie Denkinhalte in API-Antworten zurückgegeben werden. display funktioniert in beiden Modi: Setze es zusammen mit type: "adaptive" oder type: "enabled". Es akzeptiert diese Werte:

• "summarized": Thinking-Blöcke enthalten Text mit zusammengefasstem Denken, eine lesbare Zusammenfassung von Claudes Überlegungen. Dies ist der Standard bei Claude Opus 4.6, Claude Sonnet 4.6 und früheren Modellen.
• "omitted": Thinking-Blöcke werden mit einem leeren thinking-Feld zurückgegeben. Das signature-Feld trägt weiterhin das verschlüsselte vollständige Denken für Multi-Turn-Kontinuität (siehe Verschlüsselung des Denkens). Dies ist der Standard bei Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Opus 5, Claude Sonnet 5, Claude Opus 4.8, Claude Opus 4.7 und Claude Mythos Preview.
• "updates" (Beta): Reasoning-Blöcke werden wie bei "omitted" mit einem leeren thinking-Feld zurückgegeben, und die kurzen Fortschrittsmeldungen, die manche Modelle zwischen Tool-Aufrufen schreiben, kommen als lesbarer Text zurück. Erfordert den Beta-Header thinking-display-updates-2026-08-18.

Setze display: "omitted", wenn deine Anwendung Denkinhalte nicht an Nutzer weitergibt. Der Hauptvorteil ist eine kürzere Zeit bis zum ersten Text-Token beim Streaming: Der Server überspringt das Streaming der Denk-Token vollständig und liefert nur die Signatur, sodass die endgültige Textantwort früher zu streamen beginnt.

Mit display: "omitted" enthält die Antwort thinking-Blöcke mit einem leeren thinking-Feld:

{
  "content": [
    {
      "type": "thinking",
      "thinking": "",
      "signature": "EosnCkYICxIMMb3LzNrMu..."
    },
    {
      "type": "text",
      "text": "The answer is 12,231."
    }
  ]
}

Beachte Folgendes, wenn du mit ausgelassenem Denken arbeitest:

• Dir werden weiterhin die vollständigen Denk-Token berechnet. Das Auslassen reduziert die Latenz, nicht die Kosten.
• Wenn du Thinking-Blöcke in Multi-Turn-Gesprächen zurückgibst, gib sie unverändert zurück. Der Server entschlüsselt die signature, um das ursprüngliche Denken für die Prompt-Konstruktion zu rekonstruieren (siehe Thinking-Blöcke beibehalten). Jeglicher Text, den du in das thinking-Feld eines zurückgereichten ausgelassenen Blocks setzt, wird ignoriert.
• display ist mit thinking.type: "disabled" ungültig (es gibt nichts anzuzeigen).
• Wenn du thinking.type: "adaptive" verwendest und das Modell das Denken bei einer einfachen Anfrage überspringt, wird unabhängig von display kein Thinking-Block erzeugt.
• Beim Streaming mit display: "omitted" werden keine thinking_delta-Events ausgegeben. Mit display: "updates" streamen nur Fortschrittsmeldungs-Blöcke thinking_delta-Events. Siehe Denken streamen für die Event-Abfolge.

Im Ruby SDK nehmen einfache Hashes display: entgegen, wie die Beispiele zeigen. Die typisierte Klasse ThinkingConfigAdaptive nennt den Parameter display_ (mit nachgestelltem Unterstrich, um Rubys Kernel#display nicht zu überschatten). In beiden Fällen heißt das Feld auf der Leitung weiterhin display.

Zusammengefasstes Denken

Wenn display auf "summarized" steht, ist der Denktext, den du erhältst, eine Zusammenfassung von Claudes vollständigem Denkprozess und nicht die rohe Gedankenkette. „Summarized thinking“ (zusammengefasstes Denken) bietet die vollen Intelligenzvorteile des Denkens und verhindert gleichzeitig Missbrauch. Keine display-Einstellung gibt die rohe Gedankenkette zurück.

Beachte Folgendes, wenn du mit zusammengefasstem Denken arbeitest:

• Dir werden die vollständigen Denk-Token berechnet, die von der ursprünglichen Anfrage erzeugt wurden, nicht die Token der Zusammenfassung. Die abgerechnete Anzahl der Ausgabe-Token stimmt nicht mit der Anzahl der Token überein, die du in der Antwort siehst.
• Bei Claude Opus 4.6, Claude Sonnet 4.6 und früheren Modellen sind die ersten Zeilen der Denkausgabe ausführlicher und liefern detaillierte Überlegungen, die besonders für Prompt-Engineering-Zwecke hilfreich sind. Claude Mythos Preview fasst ab dem ersten Token zusammen, daher zeigen seine Thinking-Blöcke diese ausführliche Einleitung nicht.
• Die Zusammenfassung bewahrt die Kernideen von Claudes Denkprozess mit minimaler zusätzlicher Latenz, sodass Zusammenfassungen streamen können, während sie eintreffen.
• Die Zusammenfassung wird von einem anderen Modell verarbeitet als dem, das du in deinen Anfragen ansprichst. Das denkende Modell sieht die zusammengefasste Ausgabe nicht.
• Da Anthropic die Denkfunktion verbessern möchte, kann sich das Zusammenfassungsverhalten ändern.

Um die Überlegungen des Modells zu sehen, lies die thinking-Blöcke, anstatt im Antworttext nach Überlegungen zu fragen. Bei Claude Fable 5.1 und Claude Fable 5 kann eine Anfrage, die versucht, die internen Überlegungen des Modells als Teil des Antworttexts hervorzulocken, mit stop_details.category: "reasoning_extraction" abgelehnt werden. Siehe Ablehnungskategorien für die Feldreferenz und Hinweise zur Handhabung.

Denken streamen

Denken funktioniert mit Streaming. Thinking-Blöcke streamen als thinking_delta-Events innerhalb von content_block_delta-Events, gefolgt von einem einzelnen signature_delta-Event direkt vor dem content_block_stop des Blocks. Text-Blöcke streamen danach wie gewohnt.

Die folgenden Beispiele streamen eine Antwort mit adaptivem Denken und geben Thinking- und Text-Deltas aus, während sie eintreffen:

client = anthropic.Anthropic()

with client.messages.stream(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
) as stream:
    for event in stream:
        if event.type == "content_block_start":
            print(f"\nStarting {event.content_block.type} block...")
        elif event.type == "content_block_delta":
            if event.delta.type == "thinking_delta":
                print(event.delta.thinking, end="", flush=True)
            elif event.delta.type == "text_delta":
                print(event.delta.text, end="", flush=True)

Um nach dem Streaming vollständige Thinking-Blöcke mit ihren Signaturen wieder zusammenzusetzen, verwende den Hilfsmechanismus deines SDKs zur Nachrichtenakkumulation, sofern vorhanden (zum Beispiel stream.get_final_message() in Python oder stream.finalMessage() in TypeScript), anstatt Deltas selbst zu verketten.

event: message_start
data: {"type": "message_start", "message": {"id": "msg_01...", "type": "message", "role": "assistant", "content": [], "model": "claude-opus-4-8", "stop_reason": null, "stop_sequence": null}}

event: content_block_start
data: {"type": "content_block_start", "index": 0, "content_block": {"type": "thinking", "thinking": "", "signature": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "I need to find the GCD of 1071 and 462 using the Euclidean algorithm.\n\n1071 = 2 × 462 + 147"}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "\n462 = 3 × 147 + 21\n147 = 7 × 21 + 0\n\nSo GCD(1071, 462) = 21"}}

// Additional thinking deltas...

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "signature_delta", "signature": "EqQBCgIYAhIM1gbcDa9GJwZA2b..."}}

event: content_block_stop
data: {"type": "content_block_stop", "index": 0}

event: content_block_start
data: {"type": "content_block_start", "index": 1, "content_block": {"type": "text", "text": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 1, "delta": {"type": "text_delta", "text": "The greatest common divisor of 1071 and 462 is **21**."}}

// Additional text deltas...

event: content_block_stop
data: {"type": "content_block_stop", "index": 1}

event: message_delta
data: {"type": "message_delta", "delta": {"stop_reason": "end_turn", "stop_sequence": null}}

event: message_stop
data: {"type": "message_stop"}

Wenn display: "omitted" gesetzt ist, öffnet sich der Thinking-Block, ein einzelnes signature_delta trifft ein, und der Block schließt sich ohne jegliche thinking_delta-Events. Das Text-Streaming beginnt unmittelbar danach:

event: content_block_start
data: {"type":"content_block_start","index":0,"content_block":{"type":"thinking","thinking":"","signature":""}}

event: content_block_delta
data: {"type":"content_block_delta","index":0,"delta":{"type":"signature_delta","signature":"EosnCkYICxIMMb3LzNrMu..."}}

event: content_block_stop
data: {"type":"content_block_stop","index":0}

event: content_block_start
data: {"type":"content_block_start","index":1,"content_block":{"type":"text","text":""}}

Mit display: "updates" (Beta) streamen Reasoning-Blöcke wie unter "omitted". Jeder Fortschrittsmeldungs-Block streamt seinen Text als thinking_delta-Events vor dem tool_use-Block, den er einleitet. Eine Pause von mehreren Sekunden, bevor sich der Fortschrittsmeldungs-Block öffnet, ist normal:

event: content_block_start
data: {"type":"content_block_start","index":1,"content_block":{"type":"thinking","thinking":"","signature":""}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"thinking_delta","thinking":"Confirmed the retry path never refreshes the expired token. Editing auth.py to add the refresh call."}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"signature_delta","signature":"Es8CCkYICxIM..."}}

event: content_block_stop
data: {"type":"content_block_stop","index":1}

event: content_block_start
data: {"type":"content_block_start","index":2,"content_block":{"type":"tool_use","id":"toolu_01D7FLrfh4GYq7yT1ULFeyMV","name":"edit_file","input":{}}}

Behandle unter "updates" einen Block als Fortschrittsmeldung, sobald eines seiner thinking_delta-Events nicht-leeren Text trägt.

Zur allgemeinen Streaming-Mechanik siehe Nachrichten streamen.

Denken und Effort

Der Parameter thinking steuert, ob Claude vor dem Antworten in Thinking-Blöcken nachdenkt; der Parameter effort steuert, wie viel Arbeit Claude in die gesamte Antwort steckt, was im adaptiven Modus auch umfasst, wie oft und wie tief es nachdenkt. Übergib adaptive nicht als effort-Wert: adaptive ist ein Denkmodus, keine Effort-Stufe.

Um zu erfahren, was jede Effort-Stufe mit dem Denkverhalten macht, siehe die Tabelle zum Denkverhalten pro Stufe auf der Seite Denken steuern. Die Seite Effort dokumentiert den Parameter selbst, einschließlich der Stufen, die jedes Modell unterstützt. Bei Claude Opus 4.5, dem einzigen Modell nur mit erweitertem Denken, das Effort unterstützt, wirkt Effort mit budget_tokens zusammen. Siehe Budget-Regeln und Feinabstimmung.

Da die beiden Steuerungen auf diese Weise getrennt sind, wähle diejenige, die zu deinem Ziel passt:

• Geringere Kosten oder Latenz bei einem Workload mit aktiviertem Denken: Senke zuerst effort. Es skaliert die gesamte Antwort herunter, Denken eingeschlossen.
• Claude denkt zu selten oder zu oberflächlich: Erhöhe effort, oder siehe Steuern, wie oft Claude denkt auf der Seite zur Steuerung.
• Du brauchst Denken vollständig aus: Verwende thinking: {type: "disabled"} bei Modellen, die es erlauben (siehe die modellspezifische Konfigurationstabelle).
• Du brauchst eine harte Obergrenze für die Ausgaben: Verwende max_tokens. Effort ist eine weiche Vorgabe. max_tokens ist ein striktes Limit.

Denken mit Tool-Nutzung

Denken funktioniert zusammen mit „tool use“ (Tool-Nutzung) und lässt Claude die Tool-Auswahl durchdenken und Tool-Ergebnisse verarbeiten. Zwei Einschränkungen gelten:

1. Einschränkung bei der Tool-Wahl (manueller Modus): Tool-Nutzung mit manuellem erweitertem Denken (thinking: {type: "enabled"}) unterstützt nur tool_choice: {"type": "auto"} (den Standard) oder tool_choice: {"type": "none"}. Die Verwendung von tool_choice: {"type": "any"} oder tool_choice: {"type": "tool", "name": "..."} führt zu einem Fehler, weil diese Optionen Tool-Nutzung erzwingen, was mit manuellem erweitertem Denken unvereinbar ist. Adaptives Denken, auch bei Modellen, bei denen Denken standardmäßig eingeschaltet ist, unterstützt erzwungene Tool-Nutzung, außer bei Claude Fable 5.1 und Claude Mythos 5.1 (siehe Antwort-Prefill und erzwungene Tool-Nutzung).
2. Thinking-Blöcke beibehalten: Wenn du Tool-Ergebnisse zurückgibst, musst du die Thinking-Blöcke aus der Assistant-Nachricht vollständig und unverändert an die API zurückgeben. Siehe Thinking-Blöcke beibehalten.

Eine Tool-Use-Schleife ist ein einziger Assistant-Turn. Aus Sicht des Modells ist ein Assistant-Turn erst abgeschlossen, wenn Claude seine vollständige Antwort beendet hat, die mehrere Tool-Aufrufe und Ergebnisse umfassen kann. Diese gesamte Abfolge ist ein einziger Assistant-Turn:

User: "What's the weather in Paris?"
Assistant: [thinking] + [tool_use: get_weather]
User: [tool_result: "20°C, sunny"]
Assistant: [text: "The weather in Paris is 20°C and sunny"]

Der gesamte Turn läuft in einem einzigen Denkmodus: Du kannst Denken nicht mitten in einem Turn umschalten, auch nicht während der Tool-Use-Schleife. Im erweiterten (manuellen) Modus erzwingt die API zusätzlich, dass der letzte Assistant-Turn einer Anfrage mit aktiviertem Denken mit einem Thinking-Block beginnt. Der adaptive Modus lockert dies: Kein Assistant-Turn muss mit einem beginnen.

Konflikte mitten im Turn werden sanft abgefangen. Wenn du Denken mitten im Turn umschaltest (zum Beispiel zwischen dem Senden eines Tool-Aufrufs und der Rückgabe seines Ergebnisses), gibt die API keinen Fehler aus. Stattdessen deaktiviert sie das Denken für diese Anfrage stillschweigend. Um die Modellqualität zu wahren, kann die API Thinking-Blöcke entfernen, die eine ungültige Turn-Struktur erzeugen würden, oder das Denken deaktivieren, wenn der Gesprächsverlauf mit aktiviertem Denken unvereinbar ist. Um zu bestätigen, ob Denken aktiv war, prüfe, ob thinking-Blöcke in der Antwort vorhanden sind.

Schalte zwischen Turns um, nicht innerhalb. Plane deine Denkstrategie zu Beginn jedes Turns. Schließe den Assistant-Turn ab und ändere dann die Denkkonfiguration für den nächsten:

User: "What's the weather?"
Assistant: [tool_use] (thinking disabled)
User: [tool_result]
Assistant: [text: "It's sunny"]
User: "What about tomorrow?"
Assistant: [thinking] + [text: "..."] (thinking enabled - new turn)

Das Umschalten der Denkmodi macht außerdem das Prompt-Caching ungültig. Siehe Denken und Prompt-Caching.

Thinking-Blöcke beibehalten

Wenn Claude ein Tool aufruft, pausiert es den Aufbau seiner Antwort, um auf externe Informationen zu warten. Wenn du das Tool-Ergebnis zurückgibst, baut Claude dieselbe Antwort weiter auf, daher müssen seine früheren Überlegungen noch vorhanden sein. Gib jeden thinking-Block vollständig und unverändert an die API zurück, zusammen mit dem tool_use-Block, den er begleitet hat. Das ist aus zwei Gründen wichtig:

1. Kontinuität der Überlegungen: Die Thinking-Blöcke erfassen die schrittweisen Überlegungen, die zu den Tool-Anfragen geführt haben. Sie einzubeziehen lässt Claude dort weiterdenken, wo es aufgehört hat.
2. Kontexterhalt: Tool-Ergebnisse erscheinen in der API-Struktur als User-Nachrichten, sind aber Teil eines durchgehenden Gedankenflusses. Das Beibehalten der Thinking-Blöcke erhält diesen Fluss über API-Aufrufe hinweg.

Kurz gesagt:

• Erforderlich: Innerhalb eines Tool-Use-Turns Thinking-Blöcke zurückgeben.
• Empfohlen: Über Turns hinweg alles zurückgeben.
• Erlaubt: Außerhalb der Tool-Nutzung das Denken früherer Turns weglassen.

Du musst altes Denken nicht selbst ausdünnen. Gib in Multi-Turn-Gesprächen alle Thinking-Blöcke zurück, und die API filtert sie automatisch, behält die Blöcke, die zum Erhalt der Überlegungen des Modells nötig sind, und berechnet Eingabe-Token nur für die Blöcke, die Claude tatsächlich gezeigt werden. Welche Blöcke früherer Turns behalten werden, ist modellabhängig. Siehe Beibehaltung von Thinking-Blöcken nach Modell. Um den Standard zu überschreiben, verwende die Context-Editing-Strategie clear_thinking_20251015.

Innerhalb der letzten Assistant-Nachricht muss die Abfolge aufeinanderfolgender thinking-Blöcke dem entsprechen, was das Modell in der ursprünglichen Anfrage erzeugt hat: Du kannst sie nicht umordnen, bearbeiten oder teilweise weglassen. Das schließt redacted_thinking-Blöcke ein.

Eine vollständige Schritt-für-Schritt-Anleitung über zwei Turns mit Code in jedem SDK findest du unter Denken in Tool- und Multi-Turn-Workflows. Sie definiert ein Tool, empfängt eine Antwort mit Denken plus Tool-Nutzung und gibt den Assistant-Turn zusammen mit dem Tool-Ergebnis zurück.

Verschachteltes Denken

„Interleaved thinking“ (verschachteltes Denken) lässt Claude zwischen Tool-Aufrufen denken und über jedes Tool-Ergebnis nachdenken, bevor es darauf reagiert. Mit verschachteltem Denken kann Claude:

• Über die Ergebnisse eines Tool-Aufrufs nachdenken, bevor es entscheidet, was als Nächstes zu tun ist
• Mehrere Tool-Aufrufe mit Denkschritten dazwischen verketten
• Differenziertere Entscheidungen auf Basis von Zwischenergebnissen treffen

Mit adaptivem Denken ist verschachteltes Denken bei jedem Modell, das adaptives Denken unterstützt, automatisch. Es wird kein Beta-Header benötigt. Bei Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Mythos Preview, Claude Opus 5, Claude Opus 4.8 und Claude Opus 4.7 erscheinen Überlegungen zwischen Tool-Aufrufen immer in Thinking-Blöcken. Claude Haiku 4.5 unterstützt kein verschachteltes Denken. Bei Modellen mit manuellem erweitertem Denken erfordert die Verschachtelung einen Beta-Header und ändert, wie das Denkbudget gezählt wird. Verschachteltes Denken im manuellen Modus behandelt die modellspezifischen Regeln und das plattformspezifische Header-Verhalten.

Mit verschachteltem Denken kann sich die Denkzuteilung über den gesamten Assistant-Turn erstrecken statt über eine einzelne Antwort. Verschachteltes Denken wird nur für Tools unterstützt, die über die Messages API verwendet werden.

Einen ausgearbeiteten Vergleich, der zeigt, was verschachteltes Denken in einem Workflow mit zwei Tools ändert, findest du unter Wie verschachteltes Denken den Ablauf ändert.

Fortschrittsmeldungen zwischen Tool-Aufrufen

Bei Claude Fable 5.1, Claude Mythos 5.1 und Claude Fable 5 kann das Modell zwischen Tool-Aufrufen ein „progress update“ (Fortschrittsmeldung) schreiben. Eine Fortschrittsmeldung besteht aus einem oder zwei Sätzen darüber, was das Modell gerade gefunden hat und was es als Nächstes tun wird, geschrieben für die Person, die den Agenten beobachtet, und nicht als Überlegung. Jede kommt als eigener thinking-Block mit eigener signature zurück, getrennt von jedem Reasoning-Block an derselben Stelle. Sie steht unmittelbar vor dem tool_use- oder server_tool_use-Block, den sie einleitet. Höchstens eine Fortschrittsmeldung geht jedem Tool-Aufruf voraus, und das Modell kann jede davon auslassen. Fortschrittsmeldungen sind kein verschachteltes Denken: Sie erscheinen unabhängig davon, ob Reasoning-Blöcke zwischen Tool-Aufrufen erscheinen, und eine Antwort kann beides enthalten.

Was ein Fortschrittsmeldungs-Block enthält, hängt von display ab:

Verwende display: "updates" für eine Agenten-Oberfläche, die Überlegungen verborgen hält und dem Nutzer bei jedem Schritt eine Statuszeile zeigt. Darunter ist jeder thinking-Block mit nicht-leerem Text eine Fortschrittsmeldung, rendere also diese und nichts anderes. Es befindet sich in der Beta und erfordert den Beta-Header thinking-display-updates-2026-08-18 (auf Amazon Bedrock, Google Cloud und Microsoft Foundry übergib den Beta-Wert wie in Beta-Header beschrieben). Ohne ihn wird der Wert mit demselben 400-invalid_request_error abgelehnt wie ein unbekannter display-Wert.

{
  "model": "claude-fable-5-1",
  "max_tokens": 16000,
  "thinking": { "type": "adaptive", "display": "updates" },
  "tools": [
    {
      "name": "edit_file",
      "description": "Replace the contents of a file in the repository.",
      "input_schema": {
        "type": "object",
        "properties": {
          "path": { "type": "string" },
          "content": { "type": "string" }
        },
        "required": ["path", "content"]
      }
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "The login test fails after an hour of uptime. Find out why and fix it."
    }
  ]
}

Unter "updates" sieht der Anfang der Antwort, die auf ein tool_result folgt, so aus. Der erste Block ist eine Überlegung und bleibt leer, wie er es unter "omitted" wäre. Der zweite trägt Text, ist also eine Fortschrittsmeldung. Unter "summarized" tragen beide Blöcke Text, und unter "omitted" sind beide leer.

{
  "content": [
    {
      "type": "thinking",
      "thinking": "",
      "signature": "EqMBCkYICxIM..."
    },
    {
      "type": "thinking",
      "thinking": "Confirmed the retry path never refreshes the expired token. Editing auth.py to add the refresh call.",
      "signature": "Es8CCkYICxIM..."
    },
    {
      "type": "tool_use",
      "id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
      "name": "edit_file",
      "input": { "path": "auth.py", "content": "..." }
    }
  ]
}

Beachte Folgendes, wenn du mit Fortschrittsmeldungen arbeitest:

• Gib Fortschrittsmeldungs-Blöcke unverändert mit dem Rest des Assistant-Turns zurück, wie jeden anderen thinking-Block.
• Der Text, den du erhältst, ist eine Zusammenfassung der Fortschrittsmeldung, normalerweise ein oder zwei Sätze. Verlasse dich nicht auf seine Länge. Die Fortschrittsmeldung zählt in voller Länge auf usage.output_tokens, nicht in der Länge der Zusammenfassung.
• Ein Fortschrittsmeldungs-Block kann unter jedem display-Wert mit einem leeren thinking-Feld zurückkommen. Rendere für einen leeren Block nichts. Unter "updates" sieht er genauso aus wie ein leerer Reasoning-Block und benötigt keine gesonderte Behandlung.
• Wenn eine Antwort kurz nach einem Tool-Aufruf oder Tool-Ergebnis bei max_tokens, model_context_window_exceeded oder stop_sequence stoppt, kann ihr letzter Block ein Fortschrittsmeldungs-Block sein, der für die Arbeit steht, die das Modell nicht abgeschlossen hatte. Unter "updates" und "summarized" lautet sein Text genau This part of the response was interrupted before it finished. und du kannst ihn wie jede andere Meldung anzeigen. Unter "omitted" ist er leer. Um fortzufahren, gib den Assistant-Turn unverändert zurück und hänge eine neue user-Nachricht an (mit einem tool_result für jeden tool_use-Block in diesem Turn).
• Beim Streaming ist eine Pause von mehreren Sekunden zu erwarten, bevor sich ein Fortschrittsmeldungs-Block öffnet. Siehe den "updates"-Trace unter Denken streamen.
• Diese Modelle schreiben bei höherem Effort und in langen Tool-Ketten weniger Fortschrittsmeldungen. Wenn deine Oberfläche davon abhängt, siehe Nach nutzerseitigen Fortschrittsmeldungen fragen.

Beibehaltung von Thinking-Blöcken nach Modell

Ob Thinking-Blöcke aus früheren Assistant-Turns standardmäßig im Kontext bleiben, hängt vom Modell ab:

• Alle früheren Turns behalten: Claude Opus 4.5 und spätere Opus-Modelle, Claude Sonnet 4.6 und spätere Sonnet-Modelle, Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5 und Claude Mythos Preview.
• Nur den letzten Turn behalten: frühere Opus- und Sonnet-Modelle sowie alle Haiku-Modelle bis einschließlich Claude Haiku 4.5. Wenn du ältere Thinking-Blöcke zurückgibst, entfernt die API sie automatisch. Du musst sie nicht selbst entfernen.

Die Beibehaltung bringt zwei Vorteile:

• Cache-Optimierung: Beibehaltene Thinking-Blöcke ermöglichen Cache-Treffer während der Tool-Nutzung, da sie mit Tool-Ergebnissen zurückgegeben und über den Assistant-Turn hinweg inkrementell gecacht werden, was in mehrstufigen Workflows zu Token-Einsparungen führt.
• Keine Auswirkung auf die Intelligenz: Das Beibehalten von Thinking-Blöcken hat keinen negativen Effekt auf die Modellleistung.

Der Kompromiss ist die Kontextnutzung: Lange Gespräche verbrauchen bei Modellen, die alles behalten, mehr Kontextplatz, weil behaltene Thinking-Blöcke wie jeder andere Gesprächsverlauf als Eingabe zählen (siehe Denken und das Kontextfenster). Das Verhalten ist in beiden Regimen automatisch. Es sind keine Code-Änderungen oder Beta-Header erforderlich, und du solltest weiterhin vollständige, unveränderte Thinking-Blöcke zurückgeben, wie unter Thinking-Blöcke beibehalten beschrieben. Um den Standard in die eine oder andere Richtung zu überschreiben, verwende das Löschen von Thinking-Blöcken.

Modellwechsel mitten im Gespräch. Gib Thinking-Blöcke weiterhin unverändert zurück, wenn du das Modell wechselst, zum Beispiel nach einem Fallback bei Klassifikator-Ablehnung. Ein Thinking-Block ist nur von dem Modell lesbar, das ihn erzeugt hat, oder von einem neueren, und die API ignoriert oder verwirft die Blöcke, die das Zielmodell nicht lesen kann. Bei Claude Fable 5.1 und Claude Mythos 5.1 kommt es auf die Richtung an: Sie lesen die Thinking-Blöcke jedes früheren Modells, und kein früheres Modell liest ihre, sodass ein Wechsel hinauf zu ihnen die Überlegungen des Gesprächs erhält und ein Wechsel hinunter sie verwirft (siehe Beibehaltenes Denken für die genaue Liste und dafür, wie verworfene Blöcke abgerechnet und gemeldet werden). Entferne frühere thinking- und redacted_thinking-Blöcke nur selbst, um Eingabe-Token bei Modellen zu sparen, die sie ignorieren statt verwerfen, und niemals beim Einlösen eines Fallback-Guthabens, das den Body unverändert erfordert.

Beibehaltenes Denken

Claude behält einen Thinking-Block, sodass er in späteren Turns nutzbar bleibt, nur unter den Bedingungen bei, unter denen er erstellt wurde. Ab Claude Fable 5.1 und Claude Mythos 5.1 wird ein thinking- oder redacted_thinking-Block nur beibehalten:

• Für das Modell, das ihn erzeugt hat, oder ein neueres. Ein früheres Modell kann den Block nicht verwenden, und die API verwirft ihn aus dieser Anfrage. Siehe Nur für das Modell, das ihn erzeugt hat, oder ein neueres.
• In dem Gespräch, das ihn erzeugt hat (nur Claude Fable 5.1). Wenn sich der system-Prompt, die tools oder eine frühere Nachricht ändert, ist der Block nicht mehr gültig, und die API lehnt die Anfrage ab oder verwirft den Block. Siehe Nur in dem Gespräch, das ihn erzeugt hat.

Die signature des Blocks hält bei beiden Modellen beide Bedingungen fest. Die API prüft sie, wann immer der Block in einer späteren Anfrage zurückkommt, einschließlich einer Anfrage an ein anderes Modell; Claude Mythos 5.1 prüft nur die Modellbedingung.

Gib Blöcke unverändert zurück. Sende jeden Assistant-Turn genau so, wie du ihn erhalten hast, Thinking-Blöcke eingeschlossen, und lass die API entscheiden, welche Blöcke das Modell verwenden kann.

Nur für das Modell, das ihn erzeugt hat, oder ein neueres

Diese Bedingung gilt nur in eine Richtung: Claude Fable 5.1 und Claude Mythos 5.1 lesen die Thinking-Blöcke früherer Modelle, und kein früheres Modell liest ihre.

• Ein Gespräch, das zu Claude Fable 5.1 oder Claude Mythos 5.1 wechselt, behält seine Überlegungen. Die Thinking-Blöcke des früheren Modells bleiben lesbar, sodass das Modell ab dem ersten Turn nach dem Wechsel wie gewohnt denkt.
• Ein Gespräch, das von ihnen zu einem beliebigen früheren Modell wechselt, verliert sie. Das frühere Modell kann ihre Blöcke nicht lesen, die API verwirft sie für diese Anfrage, und das frühere Modell überlegt erneut anhand der sichtbaren Nachrichten. Wenn das Gespräch später mit demselben Verlauf zu Claude Fable 5.1 zurückkehrt, sind dessen eigene Blöcke wieder lesbar.

Vollständig aufgezählt lesen Claude Fable 5.1 und Claude Mythos 5.1 Thinking-Blöcke, die voneinander, von Claude Opus 5, Claude Fable 5 und Claude Mythos 5 sowie von Claude Opus 4.8 und früheren Opus-Modellen, Claude-Sonnet-Modellen und Claude Haiku 4.5 erzeugt wurden. Kein anderes Modell als diese beiden kann einen Block lesen, der von Claude Fable 5.1 oder Claude Mythos 5.1 erzeugt wurde.

Ein Block, den das empfangende Modell nicht lesen kann, wird verworfen. Die API entfernt ihn, bevor der Prompt das Modell erreicht. Er zählt nicht auf input_tokens und wird nicht abgerechnet. Wenn du mitten im Gespräch von Claude Fable 5.1 auf ein älteres Modell zurückfällst, zum Beispiel nach einem Fallback bei Klassifikator-Ablehnung, überlegt das ältere Modell erneut anhand des sichtbaren Gesprächs. Mit dem Controls-Beta-Header wird das Verwerfen in input_transformations als model_binding_mismatch gemeldet. Ohne ihn geschieht das Verwerfen stillschweigend. Ein serverseitiger Fallback verwirft unlesbare Blöcke auf dieselbe Weise.

Nur in der Konversation, die ihn erzeugt hat

Ein Thinking-Block von Claude Fable 5.1 bleibt nur erhalten, solange das Konversationspräfix, aus dem er erzeugt wurde, unverändert bleibt. Seine signature deckt den system-Prompt, die tools und die Nachrichten ab, die dem Block vorausgingen. Claude Mythos 5.1 zeichnet dieselbe signature auf, führt diese Prüfung aber nicht durch.

Diese Prüfung wird für neue Konten durchgesetzt, die am oder nach dem 31. August 2026 erstellt wurden. Für früher erstellte Konten zeichnet die API die Bedingung in der Signatur auf, reagiert aber nicht auf eine Abweichung, es sei denn, die Anfrage setzt thinking.block_binding.prefix_mismatch_behavior, womit die Durchsetzung aktiviert wird. Anthropic plant, diese Bedingung bei zukünftigen Modellen für jede Organisation durchzusetzen. Wenn dein Konto früher erstellt wurde, mache deine Anwendung jetzt kompatibel: Dieselben Append-only-Muster halten den Prompt-Cache warm, und du kannst gegen die Prüfung testen, indem du prefix_mismatch_behavior: "error" sendest. Wenn du ein Tool oder Framework auslieferst, das andere mit ihrem eigenen API-Key ausführen, teste auf diese Weise: Deine Nutzer mit neuen Konten unterliegen der Durchsetzung, bevor du es tust. Preserved Thinking (bewahrtes Denken) enthält die Integrations-Checkliste: wie du erkennst, ob dein Code den Verlauf bearbeitet, und welches API-Feature jede Art von Bearbeitung ersetzt.

Wo die Prüfung durchgesetzt wird, wird eine Anfrage, die einen Block gegen ein geändertes Präfix erneut einspielt, mit einem 400 invalid_request_error abgelehnt:

messages.5.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block". That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

Der letzte Satz erscheint nur, wenn die Anfrage den Beta-Header nicht gesendet hat. Die Meldung kann mit einem weiteren Satz enden, der die erste geänderte Nachricht benennt. Ein erneuter Versuch mit demselben Anfrage-Body schlägt auf dieselbe Weise fehl. Um stattdessen ohne die ungültig gewordene Argumentation fortzufahren, sende den Beta-Header thinking-binding-controls-2026-08-01 und setze prefix_mismatch_behavior auf "drop_block". Die API verwirft dann den fehlschlagenden Block und jeden Thinking-Block danach in der Konversation und meldet jeden einzelnen in input_transformations als prefix_binding_mismatch. Der Endpunkt für die Token-Zählung führt dieselbe Prüfung durch und gibt denselben 400-Fehler zurück.

Was spätere Thinking-Blöcke ungültig macht:

• Das Bearbeiten, Umordnen oder Entfernen einer früheren Nachricht, einschließlich des Entfernens einer pro Turn eingefügten Erinnerung, die du in einen früheren User-Turn injiziert hast.
• Das Ändern des Inhalts des system-Prompts auf oberster Ebene oder das Hinzufügen, Entfernen oder Bearbeiten eines Tools im tools-Array zwischen Anfragen.
• Clientseitige Kompaktierung oder Kürzung, die aktuelle Assistant-Turns wortwörtlich beibehält, einschließlich Thinking, während die Turns davor umgeschrieben werden.
• Eine Bild- oder Dokument-URL in einem früheren Turn, die bei einer späteren Anfrage andere Bytes liefert. Die Prüfung deckt die Bytes ab, nicht den URL-String, daher ist eine rotierende signierte URL für dieselbe Datei in Ordnung. Für Inhalte, auf die du über mehrere Turns hinweg verweist, lade sie einmal mit der Files API hoch und sende die file_id, oder sende base64.

Was nicht:

• Das Entfernen einer führenden Folge von Thinking-Blöcken, älteste zuerst: der erste Thinking-Block in der Konversation (oder der erste nach dem jüngsten Kompaktierungsblock), dann der nächste und so weiter. Das Entfernen eines Thinking-Blocks an einer beliebigen anderen Stelle macht jeden Thinking-Block danach ungültig, in diesem Turn und in jedem späteren Turn.
• Das Ändern von output_config.effort, max_tokens oder anderen Sampling-Einstellungen zwischen Anfragen.
• cache_control-Markierungen, wo auch immer du sie platzierst oder verschiebst.
• Serverseitige Kompaktierung und Kontextbearbeitung: Sie zählen nicht als Bearbeitungen, weil die Prüfung die Konversation so vergleicht, wie du sie gesendet hast, nicht die bearbeitete Kopie des Servers. Nach einer Kompaktierung beginnt das geprüfte Präfix ab dem Kompaktierungsblock.

Muster, die Thinking-Blöcke gültig halten:

• Nur anhängen. Füge neue Nachrichten am Ende von messages hinzu und lasse frühere Turns Byte für Byte unverändert.
• Verwende System-Nachrichten mitten in der Konversation und Tool-Änderungen mitten in der Konversation, um unterwegs Anweisungen hinzuzufügen oder die Tool-Verfügbarkeit zu ändern, anstatt das system-Feld auf oberster Ebene oder das tools-Array zu bearbeiten. Für eine Erinnerung, die nur für einen Turn gelten soll, sende sie als Turn-bezogene System-Nachricht und belasse sie im Verlauf, anstatt sie später zu löschen. Dies bewahrt auch den Prompt-Cache.
• Verwende serverseitiges Kontextmanagement, anstatt den Verlauf selbst zu kürzen.
• Wenn eine Anfrage wegen einer Präfix-Abweichung abgelehnt wird und du den Verlauf nicht reparieren kannst, sende sie erneut mit dem Beta-Header und prefix_mismatch_behavior: "drop_block", oder entferne jeden thinking- und redacted_thinking-Block aus dem Verlauf und versuche es einmal erneut.

Wenn früheres Thinking verworfen wird, beantwortet das Modell diesen Turn ohne diese Blöcke. Ein Client, der wiederholt seinen eigenen Verlauf ungültig macht, startet den Prompt-Cache jedes Mal neu, was die Kosten erhöht.

Clientseitige Kompaktierung. Diese Prüfung schließt Kompaktierung auf dem Client nicht aus. Die Regel ist enger: Behalte keinen Thinking-Block hinter einem Präfix, das du umgeschrieben hast. Serverseitige Kompaktierung ist der einfachste Weg, sie zu erfüllen. Wenn du auf dem Client kompaktierst, verwende eine dieser Formen:

• Einfache Kompaktierung (empfohlen): Fasse die Konversation in einer Nachricht zusammen und beginne die nächste Anfrage mit dieser Zusammenfassung plus dem neuen User-Turn, ohne frühere Turns und ohne frühere Thinking-Blöcke erneut einzuspielen. Es bleibt kein früheres Thinking übrig, also schlägt nichts fehl, und das Modell denkt auf der kompaktierten Konversation neu. Claude-Modelle werden mit diesem Schema auf Aufgaben mit langem Horizont trainiert, und es schneidet für die meisten Workloads vergleichbar mit aufwendigeren Schemata ab. Es setzt den Prompt-Cache zurück, wie jede Kompaktierung.
• Keep-Tail-Kompaktierung: Fasse ältere Turns zusammen und behalte die jüngsten Turns wortwörtlich. Die Thinking-Blöcke der behaltenen Turns wurden gegen den vollständigen Verlauf erzeugt und schlagen hinter der Zusammenfassung fehl. Entferne thinking und redacted_thinking aus jedem Turn, den du übernimmst (deren Text und Tool-Aufrufe können bleiben), oder setze prefix_mismatch_behavior: "drop_block" und lass die API sie verwerfen.
• Hintergrund-Kompaktierung: Erstelle die Zusammenfassung abseits des kritischen Pfads und tausche sie ein, während die Konversation weiterläuft. Jeder in der Zwischenzeit erzeugte Turn hat Thinking, das vor dem Austausch entstanden ist. Sende "drop_block" bei jeder Anfrage, die noch Thinking-Blöcke enthält, die vor dem Austausch erzeugt wurden (oder entferne diese Blöcke selbst; input_transformations in der ersten Antwort nach dem Austausch listet genau auf, welche), oder kompaktiere synchron.

Das Herausschneiden einzelner Turns aus der Mitte des Transkripts macht jeden Thinking-Block danach ungültig, und keine clientseitige Form vermeidet das. Verwende eine System-Nachricht mitten in der Konversation für die Anweisungsänderung, die du vornehmen wolltest, oder serverseitige Kontextbearbeitung für selektives Entfernen.

Steuerungen für Blöcke, die nicht erhalten bleiben (Beta)

Sende den Beta-Header thinking-binding-controls-2026-08-01, um zwei Dinge zu erhalten: ein input_transformations-Array in jeder Antwort, das alle Thinking-Blöcke auflistet, die die API verworfen hat, und ein block_binding-Objekt in der Thinking-Konfiguration mit einem Feld.

block_binding wird zusammen mit thinking.type: "adaptive" und thinking.type: "enabled" akzeptiert. Es ohne den Beta-Header zu senden, gibt einen 400-Fehler zurück. Modelle, die die Konversationsprüfung nicht durchführen, akzeptieren das Objekt und melden nur Verwerfungen durch die Modellprüfung, sodass ein Anfrage-Body über Modelle hinweg funktioniert. Auf Amazon Bedrock und Google Cloud übergibst du Beta-Namen wie in Beta-Header beschrieben.

Die folgende Anfrage aktiviert das Verwerfen statt des Ablehnens. Bei einem ersten Turn gibt es nichts erneut einzuspielen, daher kommt input_transformations leer zurück:

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={
        "type": "adaptive",
        "block_binding": {"prefix_mismatch_behavior": "drop_block"},
    },
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
    betas=["thinking-binding-controls-2026-08-01"],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

print(f"Input transformations: {len(response.input_transformations or [])}")

The greatest common divisor of 1071 and 462 is 21.
Input transformations: 0

Verworfene Blöcke werden in input_transformations gemeldet. Unter dem Beta-Header trägt jede Antwort eines Thinking-fähigen Modells dieses Array auf oberster Ebene. Es ist leer, wenn nichts verworfen wurde, und niemals null. Jeder Eintrag benennt die Position eines verworfenen Blocks und die Prüfung, die er nicht bestanden hat:

{
  "input_transformations": [
    {
      "type": "thinking_dropped",
      "path": "messages.1.content.0",
      "reason": "model_binding_mismatch"
    }
  ]
}

Das Feld reason ist model_binding_mismatch oder prefix_binding_mismatch. Ignoriere Einträge, deren type oder reason du nicht erkennst, da spätere Prüfungen Werte hinzufügen. Beim Streaming kommt input_transformations im message-Objekt des message_start-Events an. Nach einem serverseitigen Fallback mitten im Stream trägt das abschließende message_delta-Event das Array erneut mit den Einträgen des ausliefernden Modells. Ohne den Beta-Header fehlt das Feld.

Eine manipulierte oder nicht entschlüsselbare Signatur ist ein anderer Fehler: Sie gibt immer einen 400-Fehler zurück (Invalid `signature` in `thinking` block, ohne Begründungsklausel), und prefix_mismatch_behavior gilt dafür nicht. In einem Message Batch wird ein Element, dessen Block die Konversationsprüfung unter "error" nicht besteht, als errored aufgelöst.

Thinking und Prompt-Caching

Prompt-Caching interagiert auf einige spezifische Weisen mit Thinking. Die folgenden Regeln gelten in beiden Thinking-Modi.

Konfigurationsänderungen machen das Caching ungültig. Die Thinking-Konfiguration und die aufgelöste effort-Stufe werden in den Prompt selbst gerendert, sodass das Ändern einer davon ein neues Cache-Präfix beginnt. Das Wechseln zwischen adaptive, enabled und disabled, das Ändern von budget_tokens und das Ändern des Effort-Werts machen alle Cache-Breakpoints ungültig: Breakpoints auf Nachrichtenebene verfehlen immer, und Tool- und System-Prompt-Breakpoints können ebenfalls verfehlen, je nachdem, wo das Modell die Konfiguration rendert. Behandle jede Thinking- oder Effort-Änderung auf oberster Ebene so, als würde der Cache neu beginnen. Auf Modellen, die Effort pro Nachricht unterstützen, lässt eine Effort-Änderung, die in einer role: "system"-Nachricht innerhalb von messages übertragen wird, das gecachte Präfix intakt. Aufeinanderfolgende Anfragen, die dieselbe Konfiguration beibehalten, bewahren den Cache, und das explizite Setzen eines Parameters auf seinen Standardwert ist gleichbedeutend mit dem Weglassen. Ein Thinking-Block, den die API unter einer der beiden Preserved-Thinking-Bedingungen verwirft, ändert das gecachte Präfix ab der Position dieses Blocks. Unverändert zurückgegebene Blöcke halten den Cache intakt. Eine ausgearbeitete Demonstration mit Usage-Ausgabe findest du auf der Seite Thinking steuern.

Thinking-Blöcke werden mit Tool-Ergebnissen gecacht. Während einer Tool-Nutzungs-Schleife erfolgt das Caching, wenn du eine Folgeanfrage stellst, die Tool-Ergebnisse enthält. Zu diesem Zeitpunkt kann der vorherige Konversationsverlauf, einschließlich seiner Thinking-Blöcke, gecacht werden, und diese gecachten Thinking-Blöcke zählen in deinen Usage-Metriken als Input-Token, wenn sie aus dem Cache gelesen werden. Dies geschieht automatisch, auch ohne explizite cache_control-Markierungen, und verhält sich für reguläres und verschachteltes Thinking gleich. Der Kompromiss: Thinking-Blöcke, die du in Antworten nie wieder siehst, tragen dennoch zur Input-Token-Nutzung bei, wenn sie aus dem Cache gelesen werden.

Ob frühere Blöcke überhaupt im Kontext sind, ist modellabhängig. Der Bewahrungsstandard regelt dies. Auf Keep-all-Modellen bleiben die Thinking-Blöcke früherer Turns gecacht und im Kontext. Auf Last-turn-only-Modellen werden, sobald du eine User-Nachricht sendest, die kein Tool-Ergebnis ist, alle vorherigen Thinking-Blöcke aus dem Kontext entfernt. Auf diesen Modellen wird eine Konversation wie diese:

User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [thinking_block_2] + [text block 2],
User: [Text response, cache=True]

so verarbeitet, als wären die Thinking-Blöcke nie da gewesen:

User: ["What's the weather in Paris?"],
Assistant: [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [text block 2],
User: [Text response, cache=True]

Auf Keep-all-Modellen behält dieselbe Anfrage thinking_block_1 und thinking_block_2 im Kontext und im Cache.

Degradation entfernt Thinking aus dem cachebaren Verlauf. Wenn Thinking mitten im Turn deaktiviert wird und du Thinking-Inhalt im aktuellen Tool-Nutzungs-Turn übergibst, wird der Thinking-Inhalt entfernt und Thinking bleibt für diese Anfrage deaktiviert (siehe Graceful Degradation). Verschachteltes Thinking verstärkt die Effekte der Cache-Invalidierung, da Thinking-Blöcke zwischen mehreren Tool-Aufrufen auftreten können.

Thinking und das Kontextfenster

max_tokens, das alles Thinking einschließt, das Claude im aktuellen Turn generiert, wird als striktes Limit durchgesetzt. Auf Claude 4.5-Modellen und neuer akzeptiert die API die Anfrage, wenn Input-Token plus max_tokens die Größe des Kontextfensters überschreiten. Wenn die Generierung dann das Kontextfenster-Limit erreicht, stoppt sie mit stop_reason: "model_context_window_exceeded", anstatt einen Fehler zurückzugeben. Auf früheren Modellen gibt die API stattdessen einen Validierungsfehler zurück. Siehe Umgang mit Stop-Reasons.

Wie Thinking gegen das Fenster zählt, hängt davon ab, wann es generiert wurde:

• Thinking des aktuellen Turns zählt immer zu max_tokens, wird als Output-Token abgerechnet und belegt Platz im Kontextfenster für den Turn, der es generiert hat.
• Thinking früherer Turns hängt vom Bewahrungsstandard ab. Auf Modellen, die alle früheren Turns behalten, bleiben vorherige Thinking-Blöcke im Kontext, zählen zum Fenster und werden wie der Rest des Konversationsverlaufs als Input-Token abgerechnet. Auf Modellen, die nur den letzten Turn behalten, entfernt die API ältere Thinking-Blöcke automatisch, wenn du sie zurückgibst, sodass sie weder Fensterplatz noch Input-Token verbrauchen.

In der Praxis:

• Auf Keep-all-Modellen plane dein Kontextfenster so, als wäre Thinking gewöhnlicher Konversationsverlauf, denn das ist es. Lange agentische Sitzungen sammeln Thinking im Kontext an. Verwende das Löschen von Thinking-Blöcken, wenn du Platz zurückgewinnen musst.
• Auf Last-turn-only-Modellen ist Thinking nur ein Kostenfaktor pro Turn: Das Thinking jedes Turns zählt gegen das max_tokens dieses Turns und fällt dann aus dem Fenster heraus.

Die folgenden Diagramme veranschaulichen das Last-turn-only-Regime (Stripping). Das erste zeigt eine Multi-Turn-Konversation: Der Thinking-Block jedes Turns wird im Output generiert, aber nicht in den Input späterer Turns übernommen.

Das zweite zeigt dasselbe Regime mit Tool-Nutzung („tool use“): Thinking bleibt für die Dauer des Assistant-Turns zusammen mit seinem Tool-Ergebnis („tool result“) im Kontext und fällt dann beim nächsten User-Turn heraus.

Verwende die Token-Counting-API, um genaue Zählungen für deinen spezifischen Anwendungsfall zu erhalten, insbesondere für Multi-Turn-Konversationen, die Thinking enthalten.

Thinking-Verschlüsselung

Der vollständige Thinking-Inhalt wird verschlüsselt und im Feld signature jedes Thinking-Blocks zurückgegeben. Die API verwendet die Signatur, um zu verifizieren, dass Thinking-Blöcke von Claude generiert wurden, wenn du sie zurückgibst.

Beachte Folgendes, wenn du mit Signaturen arbeitest:

• Es ist nur dann zwingend notwendig, Thinking-Blöcke zurückzusenden, wenn du Tools mit Thinking verwendest. Andernfalls kannst du Thinking-Blöcke aus früheren Turns weglassen. Wenn du sie doch zurückgibst, hängt es vom Modell ab, ob die API sie behält oder entfernt (siehe Bewahrung von Thinking-Blöcken nach Modell). Verwende Kontextbearbeitung, um dies zu konfigurieren.
• Wenn du Thinking-Blöcke zurücksendest, gib alles genau so zurück, wie du es erhalten hast, aus Konsistenzgründen und um potenzielle Probleme zu vermeiden.
• Beim Streaming von Antworten kommt die Signatur als signature_delta innerhalb eines content_block_delta-Events direkt vor dem content_block_stop-Event an.
• signature-Werte sind in Claude 4 und späteren Modellen deutlich länger als in früheren Modellen.
• Das Feld signature ist opak: Interpretiere oder parse es nicht.
• signature-Werte sind plattformübergreifend kompatibel (die Claude API, Amazon Bedrock und Google Cloud). Auf einer Plattform generierte Werte funktionieren auf einer anderen.

Redigierte Thinking-Blöcke

Zusätzlich zu regulären thinking-Blöcken kann die API redacted_thinking-Blöcke zurückgeben, wenn Teile von Claudes Argumentation aus Sicherheitsgründen redigiert werden. Ein redacted_thinking-Block enthält verschlüsselten Thinking-Inhalt in einem data-Feld, ohne lesbaren Text:

{
  "type": "redacted_thinking",
  "data": "..."
}

Das Feld data ist opak und verschlüsselt. Wie das Feld signature bei regulären Thinking-Blöcken gibst du redacted_thinking-Blöcke unverändert an die API zurück, wenn du eine Multi-Turn-Konversation mit Tools fortsetzt.

Limits und Feature-Kompatibilität

Sampling-Parameter

Auf Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Mythos Preview, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7 und Claude Sonnet 5 geben nicht standardmäßige Werte für temperature, top_p oder top_k bei jeder Anfrage einen 400-Fehler zurück, unabhängig davon, ob Thinking verwendet wird. Auf älteren Modellen gilt die Einschränkung nur, solange Thinking aktiv ist: temperature und top_k sind mit Thinking inkompatibel, und top_p ist bei Werten zwischen 0,95 und 1 erlaubt.

Antwort-Prefill und erzwungene Tool-Nutzung

Du kannst die Assistant-Antwort nicht vorbefüllen, solange Thinking aktiv ist. Erzwungene Tool-Nutzung (tool_choice: {"type": "any"} oder {"type": "tool", ...}) ist mit manuellem erweitertem Denken inkompatibel, funktioniert aber mit adaptivem Thinking. Die Ausnahmen sind Claude Fable 5.1 und Claude Mythos 5.1, die erzwungene Tool-Nutzung bei jeder Anfrage mit einem 400-Fehler ablehnen. Verwende auf diesen Modellen stattdessen tool_choice: {"type": "auto"} mit strikter Tool-Nutzung oder strukturierten Ausgaben. Siehe Thinking mit Tool-Nutzung.

Output-Limits

Jedes Modell akzeptiert max_tokens bis zur hier aufgeführten Obergrenze. Auf der Message Batches API hebt der Beta-Header output-300k-2026-03-24 diese Obergrenze für die Modelle an, bei denen eine Batches-Obergrenze aufgeführt ist.

Siehe die Modellübersicht für Limits bei veralteten Modellen.

Lange Anfragen

Die SDKs erfordern Streaming, wenn max_tokens größer als 21.333 ist, um HTTP-Timeouts bei lang laufenden Anfragen zu vermeiden. Dies ist eine clientseitige Validierung, keine API-Einschränkung. Wenn du Events nicht inkrementell verarbeiten musst, verwende .stream() mit .get_final_message() (Python) oder .finalMessage() (TypeScript), um das vollständige Message-Objekt zu erhalten, ohne einzelne Events zu behandeln. Siehe Streaming von Nachrichten. Rechne mit längeren Antwortzeiten, wenn Thinking aktiv ist, da das Generieren von Thinking-Blöcken Verarbeitungszeit hinzufügt. Für Workloads, die Thinking auf über etwa 32k Token pro Anfrage treiben, verwende Batch-Verarbeitung, um Netzwerkprobleme zu vermeiden: Solche Anfragen können lange genug laufen, um System-Timeouts und Limits für offene Verbindungen zu erreichen.

Nächste Schritte