Claude Extended Thinking: Wann sich das Budget lohnt

Das erste Mal, als ich Claude Extended Thinking für einen echten Agent aktiviert habe, ging der Lauf von 4 Sekunden auf 47. Der Output war besser. Die Rechnung schlechter. Dieser Tradeoff ist die ganze Geschichte.

Claude Extended Thinking lässt Opus oder Sonnet einen Block sichtbarer Reasoning-Tokens vor der finalen Antwort erzeugen. Sie geben ein Budget, das Modell verbraucht es beim Nachdenken, und Sie zahlen für jeden Thinking-Token zum Output-Satz. Der Vorteil: messbare Qualitätsgewinne bei Multi-Step-Problemen. Der Nachteil: Latenz und Kosten, die mit dem Budget skalieren.

Mein Fazit nach dem Einsatz in Agent-Loops, Code-Generierung und Planning-Tasks: Default off, selektiv aktivieren. Extended Thinking ist ein Power-Tool, kein universelles Upgrade. Der Post geht durch, was es tut, was es kostet und die exakten Task-Formen, in denen das Budget sich auszahlt.

Was Extended Thinking tatsächlich macht

Beim Aufruf der Claude API mit thinking-Parameter erzeugt das Modell einen thinking-Content-Block vor dem normalen text-Block. Sie sehen das Reasoning. Das Modell sieht es auch, im nächsten Turn, wenn Sie es in der History halten.

Die API-Form ist minimal:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

const response = await client.messages.create({
  model: "claude-opus-4-7",
  max_tokens: 16000,
  thinking: { type: "enabled", budget_tokens: 10000 },
  messages: [
    { role: "user", content: "Refactor this function to be pure without changing its signature: ..." }
  ]
});

for (const block of response.content) {
  if (block.type === "thinking") {
    console.log("reasoning:", block.thinking);
  } else if (block.type === "text") {
    console.log("answer:", block.text);
  }
}

Drei Constraints vorab:

1. Nur Opus und Sonnet. Haiku unterstützt kein Thinking. Für Reasoning zum Haiku-Preis haben Sie Pech.
2. Thinking-Tokens werden als Output-Tokens abgerechnet. Ein 10.000-Token-Budget auf Opus ist ein echter Posten.
3. budget_tokens muss kleiner als max_tokens sein. Das Thinking-Budget wird aus Ihrem Output-Allocation geschnitzt.

Das Modell kann früh stoppen. Wenn es in 2.400 Tokens fertig reasoned ist, zahlen Sie 2.400, nicht 10.000. Das Budget ist ein Cap, kein Ziel. In der Praxis nutzt Opus 40 bis 90 Prozent des Budgets bei Tasks, die es wirklich brauchen — und fast nichts bei Tasks, die es nicht brauchen.

Die Kosten von Thinking

Output-Tokens auf Opus sind grob 5× der Input-Preis. Diese Ratio ist, warum Thinking-Budgets zählen.

So sieht ein Single-Request bei jedem üblichen Tier aus, Opus 4.7 bei aktuellem Pricing (Output 75 $ pro Million Tokens) angenommen:

Das ist pro Request, vor den finalen Antwort-Output-Tokens. Auf Sonnet 4.6 sind die Zahlen etwa ein Fünftel von Opus — deshalb fahren viele produktive Thinking-Setups Sonnet, selbst wenn das Team sonst Opus als Default nutzt.

Bei 10.000 Requests pro Tag mit 10k-Budget auf Opus sind Sie bei 7.500 $ pro Tag nur für Thinking. Für ein customer-facing Feature geht die Rechnung nicht auf. Für einen einmal-pro-Tag-Architektur-Planning-Agenten: trivial.

Die andere versteckte Kosten-Komponente ist Latenz. Ein 10k-Token-Think dauert grob 15 bis 30 Sekunden auf Opus, je nach Last. Ein 64k-Think kann über eine Minute laufen. Ihr p99 wird nicht mehr in Sekunden gemessen.

Tasks, wo Thinking sich rechnet

Ich habe Thinking über mehrere produktive Systeme an und aus gefahren. Das Muster ist klar: es hilft, wo ein falscher Schritt kaskadiert, und verbrennt Geld überall sonst.

Agent-Loops mit Tool Use. Wenn ein Agent zwischen fünf Tools mit unterschiedlichen Parameter-Formen wählen muss, reduziert ein Thinking-Block vor dem Tool-Call falsche Tool-Picks und Parameter-Halluzinationen. Meine Graffiti-Profiling-Pipeline ruft drei sequenzielle Tools pro Kunden auf — und die Aktivierung eines 4k-Thinking-Budgets am Planning-Schritt hat die Retry-Rate sichtbar gesenkt. Die Thinking-Kosten sind klein, weil es einmal pro Agent-Session läuft, nicht pro Tool-Call.

Code-Generierung mit Constraints. “Refactor diese Function zu pure, ohne die Type-Signatur zu ändern” ist genau die Art von Problem, bei dem Opus ohne Thinking manchmal trotzdem die Signatur neu schreibt. Mit Thinking bemerkt es den Constraint, reasoned darüber, welche Zeilen ihn verletzen, und produziert Output, der die Original-Tests besteht. Mein stärkster Use Case für Thinking.

Multi-Hop-Reasoning über strukturierte Daten. Wenn die Frage lautet “gegeben diese JSON mit 40 Customer-Events, welcher User churnt am wahrscheinlichsten und warum”, hilft Thinking. Das Modell läuft durch die Events, bildet Hypothesen, verwirft welche, commitet. Ohne Thinking latcht es häufig am ersten Signal fest.

Komplexe Planung. Einen Agent-Plan bauen, eine Migrations-Strategie schreiben, einen API-Contract designen. Überall, wo Output interne Konsistenz über 10+ Entscheidungen braucht. Ich fahre meinen wöchentlichen Planning-Cron einmal pro Woche mit 16k-Thinking-Budget auf Opus. Kosten bei der Kadenz: vernachlässigbar.

Tasks, wo es reiner Overhead ist

Die, bei denen ich Thinking nach Messung wieder abgeschaltet habe:

Customer-facing Chat. Die Latenz killt das Gefühl. Eine 15-Sekunden-Wartezeit ohne Streaming lässt User glauben, der Service sei down. Selbst mit Streaming (mehr unten) ist die Time-to-First-Visible-Text zu lang für jede interaktive UX.

Summarization und Extraction. “Fasse diese E-Mail in drei Bullets zusammen” braucht kein Reasoning. Das Modell kann das. Sie zahlen extra Tokens, um zuzusehen, wie es über eine Aufgabe nachdenkt, die es ohnehin richtig macht.

High-Volume-Classification. Wenn Sie 100k Support-Tickets am Tag labeln, zählen Kosten pro Item mehr als der Qualitätssprung durch Thinking. Haiku ohne Thinking oder Sonnet ohne Thinking fahren und den kleinen Accuracy-Hit akzeptieren.

Simple Retrieval und Formatting. “Zieh den Total aus dieser Rechnung” oder “konvertiere dieses Markdown nach HTML” hat keine Reasoning-Oberfläche. Thinking fügt Kosten hinzu und null Qualität.

Das Muster: Wenn die Aufgabe einen offensichtlichen Pfad hat, ist Thinking Verschwendung. Wenn die Aufgabe Entscheidungspunkte hat, an denen falsch zu wählen echtes Geld downstream kostet, zahlt sich das Budget aus.

Thinking an User streamen

Beim Streamen einer Response mit aktiviertem Thinking kommt der Thinking-Block zuerst, Token für Token, dann der finale Text-Block. Drei Optionen:

1. Thinking komplett verstecken. Einen “denkt nach…”-Spinner zeigen. User wartet. Funktioniert für Background-Jobs, nicht für interaktive UIs.
2. Thinking live anzeigen. Das Reasoning rendern, während es streamt. Das tut Claude.ai in seiner UI. Wirkt transparent und manchmal lehrreich — aber die meisten User wollen keine 10.000 Tokens Reasoning lesen.
3. Zusammenfassen und Progress-Puls zeigen. Thinking in ein eingeklapptes Panel streamen, Ein-Zeiler “analysiere Inputs… wäge Tradeoffs ab…” summary anzeigen. Die beste UX, die ich für produktive Apps gefunden habe.

Das SDK gibt Ihnen thinking_delta-Events im Stream, getrennt von text_delta. An unterschiedliche UI-Flächen routen:

const stream = await client.messages.stream({
  model: "claude-opus-4-7",
  max_tokens: 16000,
  thinking: { type: "enabled", budget_tokens: 8000 },
  messages: [{ role: "user", content: prompt }]
});

for await (const event of stream) {
  if (event.type === "content_block_delta") {
    if (event.delta.type === "thinking_delta") {
      renderReasoningPanel(event.delta.thinking);
    } else if (event.delta.type === "text_delta") {
      renderAnswer(event.delta.text);
    }
  }
}

Eine Regel: Thinking-Output niemals verbatim an Endnutzer in einem professionellen Kontext zeigen. Es ist roh, rambelt manchmal und kann System-Prompt-Details offenbaren. Zusammenfassen oder verstecken.

Wie Thinking mit anderen Features interagiert

Prompt-Caching. Thinking-Output ist nicht cachebar (es wird pro Turn frisch generiert) — aber sobald ein Thinking-Block in der Message-History steht, zählt er als Input für den nächsten Turn und kann wie jeder andere Input gecacht werden. Bei fortlaufenden Konversationen wird das vorherige Turn-Thinking zu gecachtem Kontext. Siehe Claude-API-Prompt-Caching für das vollständige Caching-Modell.

Tool Use. Thinking passiert vor Tool-Calls. Das Modell reasoned, dann entscheidet, welches Tool aufgerufen wird. Da glänzt Thinking für Agents, weil das Reasoning die Tool-Wahl beeinflusst. Das Claude-Code-SDK-Agenten-Pattern nutzt genau diese Kombination: Thinking für Planning, Tool-Calls für Execution.

Structured Output. Thinking nicht mit Prefill-basierter JSON-Extraktion kombinieren. Der Thinking-Block bricht die Prefill-Erwartung. Das Tool-Use-Pattern nutzen: ein Tool mit Ihrem JSON-Schema definieren, das Modell thinken lassen, dann das Tool aufrufen. Siehe Claude-API-Structured-Output, warum Tool Use Prefill schlägt, wenn Thinking im Spiel ist.

Ein Agent-Loop, der Thinking selektiv nutzt

Das Pattern, das ich in Produktion fahre. Thinking ist nur am Planning-Schritt aktiviert, nicht für jede Tool-Execution. Das hält Kosten und Latenz gedeckelt.

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

const tools = [
  {
    name: "fetch_customer_events",
    description: "Fetch recent events for a customer by ID",
    input_schema: {
      type: "object",
      properties: { customer_id: { type: "string" } },
      required: ["customer_id"]
    }
  },
  {
    name: "score_churn_risk",
    description: "Score a customer's churn risk given their event history",
    input_schema: {
      type: "object",
      properties: { events: { type: "array", items: { type: "object" } } },
      required: ["events"]
    }
  }
];

async function runAgent(userPrompt: string) {
  const messages: Anthropic.MessageParam[] = [
    { role: "user", content: userPrompt }
  ];

  // First turn: thinking enabled for planning
  let response = await client.messages.create({
    model: "claude-opus-4-7",
    max_tokens: 16000,
    thinking: { type: "enabled", budget_tokens: 4000 },
    tools,
    messages
  });

  // Subsequent turns: no thinking, just tool execution
  while (response.stop_reason === "tool_use") {
    const toolUse = response.content.find(b => b.type === "tool_use");
    if (!toolUse || toolUse.type !== "tool_use") break;

    const toolResult = await executeTool(toolUse.name, toolUse.input);

    messages.push({ role: "assistant", content: response.content });
    messages.push({
      role: "user",
      content: [{ type: "tool_result", tool_use_id: toolUse.id, content: toolResult }]
    });

    response = await client.messages.create({
      model: "claude-opus-4-7",
      max_tokens: 4000,
      tools,
      messages
    });
  }

  return response.content.find(b => b.type === "text");
}

async function executeTool(name: string, input: unknown): Promise<string> {
  // your real tool dispatch
  return JSON.stringify({ ok: true });
}

Der erste Call kostet mehr (Thinking-Budget plus Planning-Output). Jeder Follow-up ist billig und schnell, weil Thinking für Tool-Dispatch aus ist. Ich habe gesehen, dass dieses Pattern die Session-Gesamtkosten um 60 Prozent gegenüber naiven “Thinking auf jedem Turn”-Setups senkt — bei gleichbleibendem Qualitäts-Benefit da, wo er zählt.

Wann aktivieren

Mein Entscheidungsfluss:

Ist die Aufgabe interaktiv (User wartet)?

Ja > Thinking aus. Nein > weiter.

Kostet ein falscher Schritt downstream echtes Geld?

Ja > Thinking an mit kleinem Budget (2k bis 8k) aktivieren und messen. Nein > Thinking aus.

Fahren Sie mehr als 1.000 davon pro Tag?

Ja > Kostendelta vor dem Ship sorgfältig messen. Nein > frei budgetieren, Kleinvolumen spielt keine Rolle.

Bei 4.000 Tokens starten. Nur erhöhen, wenn das Modell das Budget-Ceiling trifft (stop_reason: "max_tokens" am Thinking-Block prüfen). Senken, wenn es konsistent weniger als die Hälfte nutzt.

Thinking nicht als Default über die ganze Application aktivieren. Die Rechnung überrascht Sie, die p99-Latenz verschlechtert sich, und für die meisten Tasks ist der Qualitätsgewinn nicht da. Die zwei oder drei Schritte in Ihrem System picken, an denen eine kaskadierende Falschwahl teuer ist — dort einschalten, überall sonst aus lassen.

Weiterführendes

• Claude-API-Prompt-Caching: wie Thinking-Blöcke in Folge-Turns in den Cache gelangen
• Claude-API-Structured-Output: warum Tool Use Prefill schlägt, wenn Thinking aktiv ist
• Claude-Code-SDK-Agenten: volles Agent-Loop-Pattern mit selektivem Thinking
• Claude-API-Tool-Use-Leitfaden: Tool-Schemas und das Planning-then-Dispatch-Pattern