> Wie Effort, adaptives Thinking und Thinking-Level bei Claude, OpenAI und Gemini funktionieren, was Thinking-Tokens kosten und wie ein Effort-Sweep hilft.
>
> Web page: https://balazscsorba.com/de/blog/reasoning-models-effort-thinking-budget · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/reasoning-models-effort-thinking-budget.md) · [Magyar](https://balazscsorba.com/hu/blog/reasoning-models-effort-thinking-budget.md)
> Author: Balázs Csorba · Published: 2026-10-17 · Keywords: reasoning effort parameter, claude effort parameter, claude adaptive thinking, budget_tokens deprecated, openai reasoning effort, gemini thinking_level, thinking tokens cost, reasoning tokens billing, task budget claude, overthinking reasoning models, max_tokens thinking

[Blog](https://balazscsorba.com/de/blog)/LLMOps & Evals

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

Wie Effort, adaptives Thinking und Thinking-Level bei Claude, OpenAI und Gemini funktionieren, was Thinking-Tokens kosten und wie ein Effort-Sweep hilft.

[Balázs Csorba](https://balazscsorba.com/de/about)·17\. Oktober 2026·10 Min. Lesezeit

-   Reasoning models
-   Effort
-   LLMOps
-   Cost
-   Evals

![Vier aufrechte Balken steigen von kurz zu hoch auf einer Grundlinie, über dem höchsten hängt eine kleine Marke.](https://balazscsorba.com/images/blog/reasoning-models-effort-thinking-budget/cover.webp?v=86c39c5934)

## Das Wichtigste in Kürze

-   Claude, OpenAI und Gemini sind von Token-Budgets zu benannten Stufen gewechselt: Effort bei Claude und OpenAI, thinking\_level bei Gemini.
-   Thinking-Tokens werden als Output-Tokens abgerechnet, auch wenn man nur eine Zusammenfassung oder gar nichts sieht.
-   max\_tokens ist die einzige harte Grenze einer Anfrage; Effort und Task-Budgets sind Vorgaben, die das Modell überschreiten oder ignorieren kann.
-   Mehr Denken ist nicht immer besser: Studien zeigen Overthinking bei leichten Aufgaben und sinkende Genauigkeit bei manchen Aufgaben mit längerem Reasoning.
-   Die Stufe per Effort-Sweep auf eigenen Evals wählen und pro Konversation stabil halten, damit der Prompt-Cache nicht bricht.

Auf dieser Seite

1.  [Was Thinking-Tokens sind und was man bezahlt](https://balazscsorba.com/#what-you-pay-for)
2.  [Die Regler bei Claude, OpenAI und Gemini](https://balazscsorba.com/#three-apis)
3.  [Von budget\_tokens zu Effort](https://balazscsorba.com/#from-budget-tokens)
4.  [max\_tokens ist die einzige harte Grenze](https://balazscsorba.com/#max-tokens-hard-cap)
5.  [Mehr Denken ist nicht immer besser](https://balazscsorba.com/#more-is-not-better)
6.  [Eine Stufe wählen: der Effort-Sweep](https://balazscsorba.com/#effort-sweep)
7.  [Effort pro Anfrage routen, ohne den Cache zu brechen](https://balazscsorba.com/#per-request-routing)
8.  [Agent-Loops: Interleaved Thinking und Task-Budgets](https://balazscsorba.com/#agent-loops)
9.  [Thinking messen wie jeden anderen Kostenfaktor](https://balazscsorba.com/#measure-it)
10.  [Quellen](https://balazscsorba.com/#sources)

Diesen Artikel anhören

0:000:00

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.

API

Parameter

Werte

Standard

Claude Messages API

`output_config.effort`

`low`, `medium`, `high`, `xhigh`, `max`

`medium` bei Opus 5.5 und Haiku 5.5, sonst meist `high`

OpenAI Responses API

`reasoning.effort`

`none`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`

Modellabhängig, `medium` bei gpt-5.5

Gemini API

`thinking_level`

`minimal`, `low`, `medium`, `high`

Modellabhängig, `medium` bei gemini-3.8-flash

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`.

**Ein weggelassener Effort ist keine stabile Einstellung**

Claude Opus 5.5 steht standardmäßig auf `medium`, Claude Opus 5 stand auf `high`. Anthropic weist darauf hin, dass eine Anfrage ohne `effort` deshalb eine Stufe niedriger läuft als auf Opus 5. Wer Modell-IDs tauscht, ohne Effort explizit zu setzen, ändert zwei Variablen gleichzeitig. Die Stufe im Code festschreiben und ein Modell-Upgrade als Migration mit eigenem [Regressionslauf](https://balazscsorba.com/de/blog/llm-model-migration-regression-testing) behandeln.

## 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](https://balazscsorba.com/de/blog/structured-outputs-json-schema-llm), 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.

Der Sweep ist billig im Vergleich dazu, einen Monat lang die falsche Stufe in Produktion zu fahren. Bei jedem Wechsel der Modell-ID erneut laufen lassen.

```
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](https://balazscsorba.com/de/blog/llm-evals-for-product-features): 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](https://balazscsorba.com/de/blog/llm-cost-latency-prompt-caching-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](https://balazscsorba.com/de/blog/agent-loop-explained).

## 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](https://balazscsorba.com/de/blog/agent-observability-opentelemetry).

## Quellen

1.  [Claude Platform Docs: Effort](https://platform.claude.com/docs/en/build-with-claude/effort)
2.  [Claude Platform Docs: Extended thinking (manual budget\_tokens mode)](https://platform.claude.com/docs/en/build-with-claude/extended-thinking)
3.  [Claude Platform Docs: Steering thinking (cost, caching, pricing)](https://platform.claude.com/docs/en/build-with-claude/thinking-steering-and-cost)
4.  [Claude Platform Docs: Task budgets](https://platform.claude.com/docs/en/build-with-claude/task-budgets)
5.  [OpenAI API Docs: Reasoning models](https://developers.openai.com/api/docs/guides/reasoning)
6.  [Google AI for Developers: Gemini thinking](https://ai.google.dev/gemini-api/docs/thinking)
7.  [Chen et al.: Do NOT Think That Much for 2+3=? On the Overthinking of o1-Like LLMs (arXiv 2412.21187)](https://arxiv.org/abs/2412.21187)
8.  [Gema et al.: Inverse Scaling in Test-Time Compute (arXiv 2507.14417)](https://arxiv.org/abs/2507.14417)

## Häufige Fragen

Was ist der Unterschied zwischen Effort und einem Thinking-Budget?

Ein Thinking-Budget wie budget\_tokens bei älteren Claude-Modellen setzt ein Token-Ziel für das Reasoning vor der Antwort. Effort ist eine Verhaltensstufe, die alle Output-Tokens prägt, auch Text und Tool-Calls, und das Modell entscheiden lässt, ob es überhaupt denkt. Ab Claude 4.7 wird budget\_tokens mit einem 400-Fehler abgelehnt, Effort ist dann die Steuerung.

Werden Thinking-Tokens berechnet, auch wenn ich sie nicht sehe?

Ja. Anthropic rechnet die vollständigen Thinking-Tokens als Output-Tokens ab, egal ob display auf summarized oder omitted steht. OpenAI rechnet verborgene Reasoning-Tokens als Output ab, und Gemini berechnet eine Antwort mit Thinking als Summe aus Output- und Thinking-Tokens.

Mit welcher Effort-Stufe sollte ich anfangen?

Mit dem Standard des Modells beginnen und einen Sweep auf dem eigenen Eval-Set fahren. Die Standards unterscheiden sich: Claude Opus 5.5 und Haiku 5.5 stehen auf medium, die meisten anderen Claude-Modelle auf high, gpt-5.5 auf medium. Dort heruntergehen, wo die Qualität hält, und nur dort hochgehen, wo die Evals einen Gewinn zeigen.

Warum kam meine Antwort leer oder abgeschnitten zurück?

Das Modell hat max\_tokens oder max\_output\_tokens erreicht, während es noch dachte. Claude liefert stop\_reason max\_tokens, OpenAI status incomplete mit reason max\_output\_tokens, Gemini eine unvollständige Ausgabe. Die Grenze erhöhen oder die Effort-Stufe senken.

Bricht ein Effort-Wechsel das Prompt-Caching?

Bei Claude ja, wenn man den Top-Level-Wert ändert: Der Effort-Wert wird in den Prompt gerendert, ein neuer Wert macht Cache-Breakpoints ungültig. Mehrere aktuelle Claude-Modelle unterstützen in der Beta einen Effort-Wechsel pro Nachricht, der das gecachte Präfix erhält.

Geschrieben von Balázs Csorba

Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten.

[KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about)

## Weitere Artikel

-   [DeepSeek V4.1 Flash 1017: 890 Byte KV-Cache pro Token, und was ein Agent davon hat](https://balazscsorba.com/de/blog/deepseek-v4-1-flash-1017)
-   [LLM-Rate-Limits in Produktion: Retries, Backoff und Provider-Fallback](https://balazscsorba.com/de/blog/llm-rate-limits-retries-provider-fallback)
-   [Prompt-Versionierung in Produktion: Git, Registries, Labels und Rollbacks](https://balazscsorba.com/de/blog/prompt-versioning-management)
-   [LLM-Batch-APIs: Inferenz zum halben Preis für Arbeit, die warten kann](https://balazscsorba.com/de/blog/llm-batch-api-offline-workloads)

## Klingt nach dem, was du suchst?

Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören.

[Kontakt aufnehmen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)