Wie verwendet man den Thinking Mode in Claude 4.5?

„Thinking mode“ (auch genannt extended thinking, thinking oder thinking blocks) in Claude 4.5 ist ein expliziter, konfigurierbarer Betriebsmodus, der das Modell anweist, eine separat budgetierte Anzahl von Tokens darauf zu verwenden, internes, schrittweises Denken (eine „chain-of-thought“) zu generieren, bevor die finale Antwort ausgegeben wird. Ziel ist es, die Leistung bei mehrschrittigem Reasoning, komplexem Coding und agentischen Workflows sowie Rechercheaufgaben zu verbessern, indem Latenz und Tokenkosten gegen tiefere interne Überlegungen eingetauscht werden. Claude 4.5 stellt diese Fähigkeit auf Ebene der Messages-API mit expliziten Parametern bereit (z. B. thinking / budget_tokens oder ein Effort-/„interleaved-thinking“-Header), bewahrt Thinking-Blöcke auf und verschlüsselt sie optional zur späteren Verifizierung oder Tool-Nutzung und führt Cache- sowie Token-Abrechnungsverhalten ein, die Sie beim Aufbau produktiver Workloads steuern müssen.

Was ist Claude 4.5? (Und welche Modelle sind relevant?)

Claude 4.5 ist Anthropic’s neueste Reihe von Claude-Modellen, veröffentlicht als inkrementelle „4.5“-Updates (zum Beispiel Sonnet 4.5 und Opus 4.5). Sonnet 4.5 bietet für die meisten Entwickler die beste Balance aus Intelligenz, Coding- und agentischer Leistung; Opus 4.5 konzentriert sich auf sehr aufwändiges Reasoning und bewahrt Thinking-Blöcke, um die Kontinuität über mehrere Turns zu verbessern. Beide Modelle unterstützen Claudes Extended Thinking, auch wenn sich manches Verhalten (z. B. zusammengefasstes vs. vollständiges Thinking) je nach Modell unterscheidet.

Die Leistungszuwächse in Claude 4.5, insbesondere in Sonnet 4.5, zeigen sich am deutlichsten im Benchmark SWE-bench Verified, der misst, wie gut eine KI reale GitHub-Issues lösen kann.

Diese Zahlen zeigen, dass Claude 4.5 nicht nur besser kurze Snippets schreibt; es ist deutlich fähiger, ganze Dateisysteme zu navigieren und autonome Aufgaben ohne menschliches Eingreifen auszuführen.

Warum das wichtig ist

• Coding & Agenten: Sonnet 4.5 zeigt starke Zuwächse bei realen Software-Aufgaben und langlaufender Coding-Arbeit – es ist daher prädestiniert für Code-Generierung, Code-Editing und autonome Agenten-Flows.
• Extended Thinking & Kontext: Modelle der Claude-4.5-Familie sind darauf ausgelegt, mit sehr großen internen Notizblöcken (Zehntausende Tokens oder mehr) zu denken und dadurch tieferes mehrschrittiges Reasoning zu ermöglichen. Das verändert, wie Sie Prompts, Tokenbudgets und Tool-Interaktionen gestalten.

Was ist der Thinking Mode in Claude 4.5?

Thinking Mode (offiziell „Extended Thinking“) erlaubt dem Modell, „seine Arbeit“ zunächst für sich auszuführen, bevor es das finale Ergebnis liefert. Anders als Standardmodelle, die sofort eine Antwort festlegen, nutzt Claude 4.5 einen dedizierten Reasoning-Bereich, um mehrere Hypothesen zu prüfen, potenzielle Logikfehler zu identifizieren und seine Strategie zu verfeinern.

Anatomie einer Antwort

In einer Standardinteraktion erhält das Modell ein Prompt und beginnt mit der Antwort. Im Thinking Mode ist die Antwort in zwei unterschiedliche Blöcke aufgeteilt:

Kerneigenschaften des Thinking Mode

• Aktivierung auf Anfrage: Sie übergeben in der API einen thinking-Block wie {"type":"enabled","budget_tokens":10000}, um Thinking zu aktivieren und dem Modell ein internes Tokenbudget für das Reasoning zu geben.
• Budgetierung: budget_tokens begrenzt die internen Reasoning-Tokens des Modells. Mehr Budget => potenziell tieferes Reasoning, aber höhere Kosten und Latenz. In Claude-4-Modellen werden Thinking-Tokens abgerechnet, auch wenn Sie nur eine zusammengefasste Ansicht erhalten.
• Zusammenfassung & Schwärzung: Bei vielen Claude-4-Modellen sieht der Nutzer eine zusammengefasste Version des Thinking-Inhalts; Teile des internen Reasonings können von Sicherheitssystemen geschwärzt (verschlüsselt) und als redacted_thinking zurückgegeben werden.
• Signaturen & Verifizierung: Thinking-Blöcke enthalten eine undurchsichtige signature zur Verifizierung bei der Rückgabe der Thinking-Blöcke an die API (insbesondere bei Tool-Nutzung notwendig). Behandeln Sie die Signatur als undurchsichtig – nicht parsen.
• Interleaved Thinking mit Tools: Claude 4 unterstützt das Verschachteln von Thinking-Blöcken mit Tool-Ausführungen (teils als Beta und flag-basiert). Das ist mächtig für agentische Arbeit (Tool ausführen, denken, weiteres Tool ausführen, usw.).

Für praktische Beispiele und die aktuellsten Parameter sind die Anthropic-Dokumente zu Messages/Extended Thinking die maßgebliche Referenz.

Wie gibt die Messages-API Thinking-Inhalte zurück

Zusammengefasstes vs. vollständiges Thinking; Verschlüsselung & Signaturen

Verschiedene Versionen der Claude-Modelle behandeln Thinking unterschiedlich: Neuere Claude-4-Modelle (wie Sonnet/Opus 4.5) liefern häufig eine zusammengefasste öffentliche Sicht auf das interne Reasoning, während der vollständige Notizblock verschlüsselt und nur über ein signature-Feld (oder geschwärzte Blöcke) verfügbar ist. Wenn Tools verwendet werden (oder Sie den internen Zustand über Tool-Aufrufe hinweg bewahren müssen), müssen Sie Thinking-Blöcke an die API zurückgeben oder den in den Docs beschriebenen Signaturmechanismus nutzen. Dieses Verfahren schützt sensibles internes Reasoning und ermöglicht gleichzeitig eine sichere Fortsetzung des Gedankengangs, wenn nötig.

Praktisches Handhabungsmuster

• Tool-Nutzung / Fortsetzung: Wenn Ihre nächste Anfrage denselben internen Zustand fortsetzen muss (z. B. Tools liefen basierend auf dem Thinking), fügen Sie die zurückgegebenen Thinking-Blöcke oder die Signatur erneut hinzu, wenn Sie die API wieder aufrufen, damit das Modell entschlüsseln und nahtlos fortsetzen kann.

• Request: Senden Sie thinking: {type: "enabled", budget_tokens: N}.

• Response: Sie erhalten eventuell (a) eine zusammengefasste öffentliche Ausgabe, (b) eine verschlüsselte signature oder redacted_thinking, oder (c) beides.

CometAPI bietet die Claude-4.5-API zu 20% des offiziellen API-Preises an und kann zudem über die Anthropic Messages aufgerufen werden. Sie benötigen vorab einen API-Schlüssel.

Beispiel 1 — einfaches curl (nicht-streaming) mit Thinking

curl https://api.cometapi.com/v1/messages \
  -H "x-api-key: $CometAPI_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "thinking": {
      "type": "enabled",
      "budget_tokens": 10000
    },
    "messages": [
      {"role": "user", "content": "Design a robust data validation strategy for CSV imports, show tests + code."}
    ]
  }'

Die Antwort enthält content-Blöcke. Untersuchen Sie jeden Block und bevorzugen Sie die text-Blöcke für die finale Ausgabe; thinking-Blöcke enthalten die zusammengefasste interne Analyse des Modells.

Beispiel 2 — Python: Request, Thinking- und Text-Blöcke parsen

import os, requests

API_KEY = os.environ["CometAPI_API_KEY"]
URL = "https://api.cometapi.com/v1/messages"
HEADERS = {
    "x-api-key": API_KEY,
    "anthropic-version": "2023-06-01",
    "content-type": "application/json"
}

payload = {
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "thinking": {"type": "enabled", "budget_tokens": 8000},
    "messages": [{"role": "user", "content": "Explain how to do property-based testing in Python; include example code."}]
}

r = requests.post(URL, headers=HEADERS, json=payload)
r.raise_for_status()
resp = r.json()

# Parse blocks
for block in resp.get("content", []):
    if block.get("type") == "thinking":
        thinking_summary = block.get("thinking")
        print("=== THINKING (summary) ===")
        print(thinking_summary[:1000])  # truncate for logs
        print("signature:", block.get("signature")[:64], "...")
    elif block.get("type") == "text":
        print("=== FINAL TEXT ===")
        print(block.get("text"))

Dieser Code extrahiert und druckt das zusammengefasste Thinking und die finale Antwort. Wenn Sie in mehrstufigen Agenten-Flows die Kontinuität bewahren müssen, fügen Sie die unveränderten Thinking-Blöcke in das messages-Array des nächsten Requests ein (siehe nächstes Beispiel).

Beispiel 3 — Thinking-Blöcke in einem Multi-Turn-Flow wiederverwenden (Python-Pseudocode)

# After initial response (resp above):
# Add the assistant message including the thinking block back into the conversation
assistant_message = {
  "role": "assistant",
  "content": resp["content"]  # include raw content array (contains thinking + text blocks)
}

# Next user turn: ask follow-up and include previous assistant message
payload2 = {
  "model": "claude-opus-4-5",  # Opus preserves thinking blocks better across turns
  "max_tokens": 20000,
  "thinking": {"type": "enabled", "budget_tokens": 12000},
  "messages": [
    {"role": "user", "content": "Now adapt the validation logic for an avro pipeline."},
    assistant_message
  ]
}
r2 = requests.post(URL, headers=HEADERS, json=payload2)

Die exakte, unveränderte Bewahrung von Thinking-Blöcken ist entscheidend bei Tool-integrierten oder langen Agenten-Workflows. Opus 4.5 hat verbesserte Defaults für die Bewahrung und das Caching von Thinking-Blöcken.

Wie streame ich Thinking-Ausgaben und zeige Fortschritt in einer UI?

Streaming-Best Practices

• Nutzen Sie die Streaming-Endpunkte der SDKs (die Python/TypeScript-SDKs bieten Stream-Helper). Für langlaufende oder hoch budgetierte Reasoning-Jobs verhindert Streaming HTTP-Timeouts und liefert partielle Texte während der Berechnung. Übliche Implementierungen verwenden einen Iterator über text_stream (Python) oder Event-Parsing (JS).
• Rechnen Sie teilweise mit zweiphasigen Streams: Das Modell kann zunächst sichtbare Reasoning-Schnipsel senden und dann mit der Antwort finalisieren. Bauen Sie Ihre UI so, dass sie gestückelte Inhalte handhabt und „Denkt …“ vs. „Finale Antwort“-Zustände anzeigen kann.
• Wenn die API beim Streaming ein signature_delta oder content_block_delta zurückgibt, erfassen Sie es und hängen es gemäß Spezifikation an nachfolgende Aufrufe an.

Wenn Sie in einer UI den Fortschritt des internen Reasonings anzeigen müssen, streamen Sie die Antwort. Der Server sendet thinking_delta-Events, gefolgt von text_delta-Events.

curl https://api.cometapi.com/v1/messages \
  --header "x-api-key: $CometAPI_API_KEY" \
  --header "anthropic-version: 2023-06-01" \
  --header "content-type: application/json" \
  --data '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "stream": true,
    "thinking": { "type": "enabled", "budget_tokens": 8000 },
    "messages": [ { "role": "user", "content": "Walk me through debugging this failing unit test and propose fixes." } ]
  }'

Beim Streaming verarbeiten Sie content_block_start, content_block_delta (enthält thinking_delta und text_delta) und content_block_stop in dieser Reihenfolge. So können Sie das schrittweise Reasoning des Modells live anzeigen.

Wie interagiert Claude Code mit dem Thinking Mode? (Terminal + VS Code)

Claude Code ist das interaktive, agentische Coding-Terminal, das die Messages-API und Tool-Runner integriert. Die CLI/IDE-Oberfläche stellt Thinking auf zwei Arten dar:

• Globale / sessionbezogene Einstellungen: Claude Code bietet ein /config-Settings-Panel zur Anpassung des Verhaltens (wie der Agent um Erlaubnis fragt, ob Thinking-Blöcke bewahrt werden usw.). Nutzen Sie diese UI statt rohem JSON, wenn Sie persistente Verhaltensänderungen möchten.
• Modellauswahl & CLI-Kommandos: Sie können claude-sonnet-4-5 oder claude-opus-4-5 als aktives Modell im REPL wählen; Tools und Thinking-Verhalten folgen dann der Messages-API-Semantik. Der Changelog und die Release Notes zeigen, dass Thinking für manche Opus-4.5-Deployments standardmäßig aktiviert ist und die Thinking-Konfiguration über /config sichtbar ist.

Praktischer Flow in Claude Code:

1. Starten Sie ein Projekt im REPL.
2. Nutzen Sie /config, um Thinking-bezogene Flags zu prüfen (Bewahrung, Ausführlichkeit etc.).
3. Bitten Sie den Agenten, eine lange Aufgabe auszuführen — er wird Thinking-Inhalte erzeugen und bei Bedarf um Erlaubnis für bestimmte Bash-Schritte bitten. Bewahren Sie Thinking-Blöcke, wenn Sie Entscheidungen später verifizieren oder erneut ausführen möchten.

Installation und Setup

Claude Code benötigt Node.js und kann global installiert werden.

# Install Claude Code CLI
npm install -g @anthropic/claude-code

# Authenticate
claude-code --init

Thinking im Terminal aktivieren

Claude Code unterstützt verschiedene Flags und natürlichsprachliche Trigger, um die Reasoning-Tiefe zu steuern.

Tipps:

• Verwenden Sie „think“/„think harder“, wenn der Agent alternative Implementierungen ausloten soll.
• Wenn Claude Code Tool-Aufrufe durchführt (Tests ausführen, Git-Operationen), bewahren Sie ggf. zurückgegebene thinking-Blöcke; andernfalls kann der Agent Kontext zwischen den Schritten verlieren.

Vorteile von verschachteltem Thinking und Block-Bewahrung

Für fortgeschrittene agentische Workflows führt Claude 4.5 zwei Beta-Features ein, die Multi-Turn-Interaktionen und Tool-Nutzung erheblich verbessern: Interleaved Thinking und Thinking Block Preservation.

Interleaved Thinking (Beta)

Standard-Reasoning erfolgt einmal vor der Ausgabe. Interleaved Thinking (aktiviert via interleaved-thinking-2025-05-14-Header) ermöglicht Claude, „zwischen“ Tool-Aufrufen zu denken.

Stellen Sie sich vor, Claude debuggt einen Server:

1. Think: „Ich sollte zuerst die Logs prüfen.“
2. Tool Call: read_file(logs.txt)
3. Think: „Die Logs zeigen ein Datenbank-Timeout. Jetzt muss ich die Connection-Pool-Einstellungen prüfen.“
4. Tool Call: read_file(db_config.yml)

Diese „kontinuierliche Reflexion“ stellt sicher, dass das Modell seine Strategie basierend auf den Ergebnissen der Tools anpasst, statt einem starren, vorab festgelegten Plan zu folgen.

Thinking Block Preservation

In mehrstufigen Gesprächen, insbesondere bei Tool-Nutzung, ist es entscheidend, die vorherigen thinking-Blöcke erneut an die API zu übergeben.

• Reasoning-Kontinuität: Indem Claude seine vorherigen Gedanken erhält, behält es den logischen Kontext seines Vorgehens.
• Opus-4.5-Optimierung: In Claude Opus 4.5 ist dieses Verhalten automatisiert. Das Modell bewahrt standardmäßig alle vorherigen Thinking-Blöcke im Kontext, sodass es selbst in 30+ Stunden dauernden Sessions nicht „vergisst“, warum es vor zehn Turns bestimmte Architekturentscheidungen getroffen hat.

Best Practices für die Nutzung des THINKING Mode mit Claude 4.5

Wählen Sie das richtige Modell und Budget für die Aufgabe:

Verwenden Sie Sonnet 4.5 für Coding- und agentische Workflows, bei denen Sie das beste Verhältnis aus Geschwindigkeit, Kosten und starker Coding-Fähigkeit benötigen; nutzen Sie Opus 4.5 für das tiefste Reasoning und die größten Kontextfenster oder wenn Sie lange autonome Sessions planen. Beide unterstützen Extended Thinking. Wählen Sie budget_tokens proportional zur Komplexität der Aufgabe (klein starten; Budget nur erhöhen, wenn Sie spürbare Qualitätsgewinne beobachten).

Kosten & Latenz überwachen und steuern

Sie werden für die vollständigen Thinking-Tokens berechnet, die Claude produziert, nicht für die zusammengefasste Ausgabe, die Sie erhalten. Das bedeutet: Lange interne Überlegungen erhöhen die Kosten, selbst wenn Sie nur eine kurze Zusammenfassung sehen. Verfolgen Sie den Tokenverbrauch und erwägen Sie schrittweises Tuning (z. B. 2k → 8k → 32k), wenn Sie von Exploration zu Produktion übergehen.

Thinking-Blöcke nur bei Bedarf bewahren

Thinking-Blöcke können kryptografisch signiert und zur späteren Verifizierung sowie für verschachtelte Tool-Nutzung bewahrt werden. Vermeiden Sie es, Thinking-Blöcke in jeder nachfolgenden Anfrage zu spiegeln, es sei denn, Ihr Workflow erfordert, dass das Modell seine vorherigen Überlegungen beibehält (z. B. wenn ein Agent Schritte erneut ausführt und die Begründungen benötigt). Ständige Bewahrung erhöht das Kontextvolumen und kann die Token-Abrechnung verkomplizieren.

Wann Thinking zu Nutzern streamen

Gestreamtes Thinking ist hervorragend für Entwickler-Tools und Bildungs-UIs (Anzeige von „Work in Progress“, während das Modell überlegt). Streamen Sie kein rohes Thinking in produktionsnahen Consumer-Apps, ohne Sicherheit und Schwärzung zu berücksichtigen: Zusammengefasstes Thinking existiert genau aus diesem Grund. Wenn Sie streamen, kennzeichnen Sie internes Reasoning klar (z. B. „Assistant-Reasoning — intern“) und steuern Sie, ob der finale Nutzer die Zusammenfassung oder das vollständige Reasoning sieht.

Tool-Nutzung und Verschachtelung

Wenn Sie Thinking mit Tools kombinieren (Codeausführung, Webabfragen, lokale Prozesse), nutzen Sie das Design des „interleaved thinking“, wenn das Modell Tools auswählen, sie ausführen und innerhalb desselben Turns über die Ergebnisse nachdenken soll. Verschachtelung erhöht die Komplexität (und kann Feature-Flags erfordern), ist aber mächtig für agentische Automatisierung. Seien Sie explizit, welches Thinking Sie bewahren, und testen Sie, wie das Modell Tools unter aktiviertem Thinking auswählt.

Praktische Fehlersuche und betriebliche Hinweise

Häufige Fehler und ihre Bedeutung

• Ungültiges Thinking + erzwungene Tool-Wahl: Wenn Sie Thinking anfordern, aber gleichzeitig bestimmte Tool-Use-Modi erzwingen, die mit Thinking unvereinbar sind, gibt die API einen Fehler zurück — mischen Sie kein tool_choice: {"type":"tool","name":"..."} mit Thinking.
• Budget > max_tokens: Für verschachtelte Thinking-Szenarien unterscheiden sich die effektiven Tokenregeln — die Plattformdokumente erklären, wann budget_tokens max_tokens überschreiten darf. Lesen Sie den Abschnitt „interleaved thinking“ sorgfältig, bevor Sie große Budgets testen.
• Signaturvalidierung: Wenn Sie Thinking-Blöcke für spätere Aufrufe bewahren, fügen Sie die zurückgegebene signature bei, damit die API prüfen kann, dass sie von Claude stammen; das verhindert Manipulation und hält die Kette verifizierbar.

Observability & Instrumentierung

Loggen Sie: (1) die model-Auswahl, (2) thinking.budget_tokens, (3) den tatsächlichen Thinking-Tokenverbrauch (dafür werden Sie abgerechnet), (4) Streaming-Latenzen (Zeit bis zum ersten thinking_delta) und (5) finale Text-Tokens. Nutzen Sie diese Metriken zur Budgetierung und für SLOs in nutzerorientierten Flows.

Progressive Einführung & Human-in-the-Loop

Führen Sie Thinking-aktivierte Modelle hinter Feature-Flags ein. Starten Sie mit einem Prozentsatz an Entwickler- oder internem Traffic, sammeln Sie Fehler oder Schwärzungen und iterieren Sie Prompts und Budgets. In sensiblen Domänen verlangen Sie eine menschliche Prüfung von Ausgaben mit umfangreichem internem Reasoning vor der Freigabe.

Debugging-Tipps

• Klein anfangen: Aktivieren Sie ein niedriges budget_tokens und skalieren Sie schrittweise hoch, um inkrementelle Verbesserungen zu verstehen.
• Streaming einschalten und content_block_delta-/Signatur-Events loggen, um zu verstehen, wann das Modell Thinking-Blöcke produziert.
• Bei Claude Code: Prüfen Sie /config und Projekteinstellungen; konsultieren Sie den Claude-Code-Changelog, wenn das Verhalten nicht den erwarteten Defaults entspricht.

Fazit:

Claude 4.5, kombiniert mit der Kraft von Extended Thinking und der Claude Code CLI, stellt den bedeutendsten Sprung in der Entwicklerproduktivität seit der Erfindung der IDE dar. Indem das Modell „seine Arbeit zeigt“ und komplexe Probleme überlegt, geht Anthropic über die „Chatbot“-Ära hinaus in die „agentische“ Ära.

Ob Sie die Messages-API in ein eigenes Dev-Tool integrieren oder Claude Code zur Verwaltung Ihrer täglichen PRs nutzen — das Beherrschen des Thinking Mode ist essenziell. Er bietet die Transparenz für Vertrauen und die Reasoning-Tiefe für Exzellenz.

Entwickler können auf Claude 4.5 (Claude Sonnet 4.5, Claude Haiku 4.5, Claude Opus 4.5) über CometAPI zugreifen. Beginnen Sie, indem Sie die Modellfähigkeiten von CometAPI im Playground erkunden und den API-Guide für detaillierte Anweisungen konsultieren. Stellen Sie sicher, dass Sie bei CometAPI eingeloggt sind und einen API-Schlüssel erhalten haben. CometAPI bietet einen Preis, der deutlich unter dem offiziellen Preis liegt, um die Integration zu erleichtern.

Bereit? → Kostenlose Testversion von Claude 4.5!