Reasoning Effort und Thinking-Budgets: Wie viel soll ein Modell denken?

Vor einem Jahr hieß Reasoning steuern, eine Zahl zu wählen: ein Thinking-Budget von 4.000 oder 16.000 Tokens. 2026 haben sich die drei großen APIs auf etwas anderes geeinigt. Claude und OpenAI bieten eine effort-Stufe, Gemini ein thinking_level, und das Modell entscheidet pro Anfrage, ob es überhaupt denkt. Das ist einfacher zu konfigurieren und schwerer zu durchschauen, denn der Regler entspricht keiner Token-Zahl mehr.

Dieser Beitrag zeigt, was jede API tatsächlich anbietet, was Thinking auf der Rechnung kostet, warum max_tokens die einzige harte Grenze ist, warum mehr Denken Antworten verschlechtern kann und wie ich eine Stufe für ein Feature wähle: ein Effort-Sweep auf einem echten Eval-Set, danach eine feste Einstellung pro Konversation, damit der Prompt-Cache überlebt.

Was Thinking-Tokens sind und was man bezahlt

Reasoning-Modelle erzeugen Tokens vor ihrer sichtbaren Antwort und ihren Tool-Calls, bei aktuellen Modellen auch dazwischen. Bei allen großen APIs werden diese Tokens als Output abgerechnet, also auf der teuren Seite der Preisliste. OpenAI sagt klar, dass Reasoning-Tokens über die API nicht sichtbar sind, aber Kontext belegen und als Output-Tokens berechnet werden. Gemini berechnet eine Antwort mit Thinking als Summe aus Output- und Thinking-Tokens. Anthropic rechnet das vollständige interne Thinking ab, auch wenn die Antwort nur eine Zusammenfassung enthält.

Bei Claude ändert die Einstellung display nur, was man sieht. Mit summarized kommt Zusammenfassungstext, mit omitted bleibt das Thinking-Feld leer, und in beiden Fällen sind die berechneten Output-Tokens das vollständige Thinking, das das Modell erzeugt hat. Anthropic warnt, dass die berechnete Zahl nicht der sichtbaren entspricht. Dazu kommt ein leiserer Kostenpunkt: Claude Opus 4.5 und Modelle ab 4.6 behalten Thinking-Blöcke früherer Turns im Kontext und berechnen sie bei jeder folgenden Anfrage als Input.

Die Regler bei Claude, OpenAI und Gemini

Aus der Ferne sehen die drei APIs ähnlich aus, sie unterscheiden sich aber in den Details, an denen Code bricht: wo der Parameter liegt, welche Werte ein Modell akzeptiert und was der Standard ist. Die Standards zählen am meisten, denn ein weggelassener Parameter ist auch eine Entscheidung.

Nicht jedes Modell akzeptiert jeden Wert. Bei Claude unterstützt nicht jedes Modell mit max auch xhigh, und die Effort-Doku enthält modellspezifische Empfehlungen, die die allgemeine Tabelle übersteuern: Für Opus 4.7 und 4.8 wird für Coding und Agenten ein Start bei xhigh empfohlen, für Sonnet 5.5 bei gut spezifiziertem agentischem Coding medium. Bei OpenAI lehnt GPT-6 Astra none mit HTTP 400 ab. Bei Gemini kennt gemini-3-pro-preview nur low und high.

Von budget_tokens zu Effort

Die alte Claude-Steuerung thinking: {type: "enabled", budget_tokens: N} ist bei den 4.6-Modellen veraltet und wird ab Claude 4.7 mit einem 400-Fehler abgelehnt. Relevant bleibt sie für Claude 4.5 und älter, wo sie der einzige Thinking-Modus ist: Das Budget muss mindestens 1.024 Tokens betragen und unter max_tokens liegen, und Anthropic empfiehlt für Budgets über 32k Batch-Verarbeitung, um Timeouts zu vermeiden. Die Migration ist im Code klein und im Verhalten groß.

// before: fixed budget, Claude thinks on every request
{ "model": "claude-sonnet-4-6", "max_tokens": 16000,
  "thinking": { "type": "enabled", "budget_tokens": 10000 } }

// after: adaptive thinking, depth controlled by effort
{ "model": "claude-sonnet-4-6", "max_tokens": 16000,
  "thinking": { "type": "adaptive" },
  "output_config": { "effort": "high" } }

Mit festem Budget denkt Claude bei jeder Anfrage. Mit adaptivem Thinking entscheidet es pro Anfrage und lässt das Denken bei niedrigem Effort und leichten Eingaben eventuell ganz weg; Code sollte also nicht annehmen, dass jeder Assistant-Turn mit einem Thinking-Block beginnt. Effort wirkt auch über das Thinking hinaus: Er prägt Text und Tool-Calls, niedrigere Stufen machen weniger und knappere Tool-Calls. Bei Opus 5.5 lässt sich adaptives Thinking gar nicht abschalten; thinking: {type: "disabled"} liefert einen 400.

max_tokens ist die einzige harte Grenze

Effort ist eine Vorgabe, kein Budget. Anthropic nennt ihn ein Verhaltenssignal, die harte Obergrenze ist max_tokens, und die umfasst Thinking und Antwort zusammen. Denkt eine schwere Anfrage lange, kann sie an diese Grenze stoßen, bevor die Antwort geschrieben ist. Claude stoppt dann mit stop_reason: "max_tokens". OpenAI liefert status: "incomplete" mit dem Grund max_output_tokens, womöglich vor jeder sichtbaren Ausgabe, und das Reasoning wird trotzdem berechnet. Gemini verhält sich genauso und berechnet die erzeugten Thinking-Tokens.

OpenAI empfiehlt, zu Beginn mindestens 25.000 Tokens für Reasoning und Ausgabe zu reservieren, Anthropic schlägt für xhigh und max bei seinen größeren Modellen einen Start um 64k vor. Bei Abbrüchen entscheiden, welche Korrektur passt: Brauchten die abgeschnittenen Anfragen das Reasoning, die Grenze erhöhen; waren sie überdacht, den Effort senken. In jedem Fall den abgeschnittenen Fall im Code behandeln, statt eine halbe Antwort auszuliefern.

// Claude: treat truncation as a failure, not as an answer
const res = await client.messages.create({
  model: "claude-opus-5-5",
  max_tokens: 32000,
  output_config: { effort: "high" },
  messages,
});
if (res.stop_reason === "max_tokens") {
  metrics.increment("llm.truncated", { effort: "high" });
  // retry once with a larger cap, or fall back to a lower effort
}
const thinking = res.usage.output_tokens_details?.thinking_tokens ?? 0;

Mehr Denken ist nicht immer besser

Die intuitive Annahme, mehr Reasoning heiße bessere Antworten, trägt bei schweren Problemen und versagt an den Rändern. Chen und Kollegen dokumentierten Ende 2024 Overthinking bei Modellen im Stil von o1: übermäßiger Rechenaufwand für einfache Aufgaben mit minimalem Nutzen, etwa lange Ketten für 2+3. Im Juli 2025 veröffentlichten Forschende aus dem Umfeld von Anthropic Aufgaben, bei denen längeres Reasoning die Genauigkeit senkt, eine inverse Skalierung zwischen Test-Time-Compute und Qualität, darunter Modelle, die sich von irrelevanten Informationen ablenken lassen und zu Scheinkorrelationen abdriften.

Die Herstellerdokus sagen dasselbe in operativen Begriffen. Anthropics Hinweise zu Opus 4.7 halten fest, dass max bei den meisten Workloads erhebliche Kosten für kleine Gewinne bringt und bei Structured-Output- oder wenig intelligenzkritischen Aufgaben zu Overthinking führen kann. OpenAI empfiehlt xhigh nur, wenn Evals einen klaren Nutzen zeigen. Für ein Extraktions- oder Klassifikations-Feature ist die richtige Antwort oft die niedrigste Stufe, die die Qualität hält, kombiniert mit Structured Outputs, damit das Format nicht davon abhängt, wie lange das Modell nachgedacht hat.

Eine Stufe wählen: der Effort-Sweep

Jeder Anbieter schließt seine Hinweise mit derselben Anweisung: auf dem eigenen Workload testen. Anthropic sagt ausdrücklich, einen frischen Sweep zu fahren, statt Einstellungen von einem älteren Modell zu übernehmen, weil die Stufen zwischen Generationen neu kalibriert werden. Praktisch ist das ein kleines Skript: dasselbe Eval-Set, dasselbe Modell, jede unterstützte Stufe und vier Zahlen pro Stufe.

for (const effort of ["low", "medium", "high", "xhigh"]) {
  const runs = await Promise.all(evalSet.map(async (c) => {
    const t0 = Date.now();
    const r = await client.messages.create({
      model, max_tokens: 64000, output_config: { effort },
      messages: c.messages,
    });
    return { ms: Date.now() - t0, out: r.usage.output_tokens,
             truncated: r.stop_reason === "max_tokens",
             score: await grade(c, r) };
  }));
  report(effort, runs); // pass rate, mean output tokens, p95 ms, truncation rate
}

Das Ergebnis als Kurve lesen, nicht als Sieger. Besteht medium dieselben Fälle wie high mit einem Bruchteil der Output-Tokens, gewinnt medium. Behebt high genau die geschäftskritischen Fälle, sind die zusätzlichen Tokens billig. Schwierig ist das Bewerten, und das ist dieselbe Arbeit wie bei jedem LLM-Eval für ein Produkt-Feature: gelabelte Fälle aus echtem Traffic und ein Grader, dem man vertraut.

Effort pro Anfrage routen, ohne den Cache zu brechen

Eine Stufe pro Feature ist die Grundlinie. Der nächste Schritt ist, sie pro Anfrage zu variieren: low für eine Routinebestätigung, high für den Planungsschritt. Anthropic führt dynamischen Effort als Best Practice, mit einem Haken. Der aufgelöste Effort-Wert wird in den Prompt gerendert, eine Änderung des Top-Level-Werts zwischen Anfragen macht Cache-Breakpoints ungültig. Anthropics eigenes Beispiel zeigt einen vollen Cache-Read bei der zweiten Anfrage und einen neuen Cache-Write bei der dritten, nachdem Effort von medium auf low gesenkt wurde.

Zwei Auswege. Zwischen Workloads an der Feature-Grenze routen, wo Konversationen ohnehin keinen Cache teilen; die Logik ist dieselbe wie beim Modell-Routing. Innerhalb einer Konversation unterstützen aktuelle Claude-Modelle wie Opus 5.5, Sonnet 5.5 und Haiku 5.5 in der Beta einen Effort-Wechsel pro Nachricht hinter dem Header mid-conversation-output-config-2026-07-01: Eine leere System-Nachricht mit output_config.effort ändert die Stufe ab dem nächsten User-Turn und lässt das frühere Präfix im Cache.

Steuerung per Prompt ist der dritte Hebel. Anthropic dokumentiert Formulierungen wie "Answer directly without deliberating." für Routine-Turns, warnt aber, dass das wortlautabhängig und weniger verlässlich als Effort ist; bei Haiku 5.5 hat die bremsende Formulierung das Thinking nicht zuverlässig reduziert. Ich nutze das erst, wenn die Stufe stimmt.

Agent-Loops: Interleaved Thinking und Task-Budgets

In einem Agenten wird aus einer User-Nachricht eine Reihe von Anfragen, und max_tokens begrenzt nur jede einzelne Anfrage, nicht den ganzen Turn. Aktuelle Modelle denken automatisch zwischen Tool-Calls. Anthropic hält fest, dass die erste Anfrage nach neuer User-Eingabe meist den Großteil des Reasonings trägt und Folgeanfragen, die nur Tool-Ergebnisse verarbeiten, das Denken selbst bei xhigh auslassen können. OpenAI verlangt, Reasoning-Items mit den Function-Call-Ausgaben zurückzugeben, per previous_response_id oder mit den vollständigen Output-Items, damit das Modell weiterdenken kann, statt neu anzufangen.

Für die ganze Schleife hat Claude Task-Budgets in der Beta (task-budgets-2026-03-13): output_config.task_budget mit type: "tokens" und einem total von mindestens 20.000. Das Modell sieht einen serverseitigen Countdown und teilt sich die Arbeit ein, um sauber abzuschließen. Das ist eine Empfehlung, keine Durchsetzung, und ein klar zu kleines Budget kann Claude dazu bringen, die Aufgabe zu verkleinern oder abzulehnen. Anthropic schlägt vor, es am p99 der gemessenen Ausgaben pro Aufgabe auszurichten. Effort steuert die Tiefe pro Schritt, das Task-Budget die gesamte Breite. Die Mechanik der Agent-Schleife steht in Der Agent-Loop, erklärt.

Thinking messen wie jeden anderen Kostenfaktor

Alle drei APIs weisen Thinking separat aus, Raten ist also unnötig. Claude liefert usage.output_tokens_details.thinking_tokens, immer kleiner oder gleich output_tokens und beim Streaming im letzten message_delta-Event. OpenAI meldet output_tokens_details.reasoning_tokens, Gemini total_thought_tokens. Das Feld an jeden Trace hängen, neben Effort-Stufe und Modell-ID.

Drei Diagramme reichen: Thinking-Tokens pro Anfrage nach Feature, Abbruchrate nach Effort-Stufe und Qualitäts-Score nach Effort-Stufe aus den Stichproben-Evals. Steigt das Thinking pro Anfrage nach einer Prompt-Änderung, sieht man es am selben Tag statt auf der Rechnung. Die Tracing-Seite steht in Observability für LLM-Agenten mit OpenTelemetry.

Quellen

1. Claude Platform Docs: Effort
2. Claude Platform Docs: Extended thinking (manual budget_tokens mode)
3. Claude Platform Docs: Steering thinking (cost, caching, pricing)
4. Claude Platform Docs: Task budgets
5. OpenAI API Docs: Reasoning models
6. Google AI for Developers: Gemini thinking
7. Chen et al.: Do NOT Think That Much for 2+3=? On the Overthinking of o1-Like LLMs (arXiv 2412.21187)
8. Gema et al.: Inverse Scaling in Test-Time Compute (arXiv 2507.14417)