Anbieter stellen Reasoning unterschiedlich bereit. OpenAI verwendet Reasoning-Aufwand und -Modi bei unterstützten Modellen, Anthropic dokumentiert Adaptive und Extended Thinking, und Google beschreibt Thinking Levels oder Budgets für unterstützte Gemini-Modelle. Produktbezeichnungen und Parameter ändern sich. Entscheiden Sie daher anhand aktueller Anbieterdokumentation und gemessener Aufgabenleistung statt einer festen Modellliste.
Einige Reasoning-Modelle profitieren von einem anderen Prompting-Stil als Konfigurationen ohne Reasoning. Für OpenAI-Reasoning-Modelle empfiehlt die aktuelle Anleitung, mit direkten Prompts zu beginnen und keine Gedankenkette anzufordern. Behandeln Sie weitergehende Aussagen über Gerüste, Rollen und Selbstkritik als Hypothesen, die Sie mit Ihrem Modell und Ihrer Arbeitslast testen, nicht als automatisch übertragbare Anbieterregeln.
Dieser Artikel erklärt, was Reasoning-Modelle sind, wann Sie sie einsetzen sollten, wie Sie gute Prompts dafür schreiben und welche Fallstricke selbst erfahrene KI-Nutzer betreffen.
Was Reasoning-Einstellungen verändern
Anbieter verwenden Bezeichnungen wie Reasoning, Thinking, Aufwand und Budget für Kontrollen, die Token-Nutzung, Latenz und Ausgabequalität verändern können. Je nach Anbieter und Konfiguration können Reasoning-Inhalte verborgen, zusammengefasst, ausgelassen oder in separaten Blöcken zurückgegeben werden. Leiten Sie den verborgenen Prozess eines Anbieters weder aus einer Bezeichnung noch aus dem Stil der endgültigen Antwort ab.
Reasoning kann die Ergebnisse bei manchen schwierigen, mehrstufigen Aufgaben verbessern. Der Gewinn hängt jedoch von Modell, Aufwandseinstellung, Prompt und Evaluierung ab. Reasoning kann außerdem Latenz und abgerechnete Reasoning-Tokens erhöhen. Die Wahl zwischen einer Konfiguration mit geringerer Latenz und mehr Reasoning ist deshalb eine zu benchmarkende Architekturentscheidung, kein universelles Upgrade.
Beispiele für Reasoning-Produktfamilien im Jahr 2026:
- OpenAI-Reasoning-Modi. OpenAI hat Modelle der o-Serie und GPT-Reasoning-Modi veröffentlicht. Verfügbarkeit und Ausmusterungsdaten unterscheiden sich nach Produkt und Tarif. Prüfen Sie vor einer Standardisierung die aktuelle Modellanleitung.
- Claude-Modelle mit Thinking. Laut aktueller Anthropic-Dokumentation ist Thinking bei aktuellen Claude-Modellen verfügbar, die unterstützte Konfiguration unterscheidet sich jedoch: Einige verwenden Adaptive Thinking, bei anderen wird manuelles
budget_tokensnicht unterstützt oder ist veraltet. Folgen Sie der Tabelle für das jeweilige Modell statt eines allgemeinen Parameterrezepts. - DeepSeek R1. Das R1-Paper beschreibt die Modellfamilie und den Trainingsansatz. Prüfen Sie DeepSeeks aktuelle offizielle Dokumentation für unterstützte Modelle und Zugriffsmethoden.
- Gemini-Thinking-Modi. Unterstützte Gemini-API-Modelle stellen anbieterspezifische Thinking-Kontrollen bereit, die der Gemini-Thinking-Leitfaden dokumentiert.
- Angebote anderer Anbieter. Behandeln Sie Produktnamen, Berechtigungen und Kontrollen als zeitabhängig. Prüfen Sie sie in der aktuellen offiziellen Anbieterdokumentation, bevor Sie sie einsetzen oder empfehlen.
Diese Produkte unterscheiden sich bei Modellverhalten, unterstützten Kontrollen, Kosten, Latenz und Sichtbarkeit der Reasoning-Ausgabe. Gehen Sie nicht davon aus, dass sich ein Parameter oder eine Prompting-Regel unverändert zwischen Anbietern übertragen lässt.
Wann mehr Reasoning getestet werden sollte
Ein Reasoning-Modell oder eine Einstellung mit höherem Aufwand kann eine relevante Vergleichsoption sein. Nutzen Sie beim Definieren des Experiments diese Aufgabensignale und Grenzen:
- Das Problem aus mehreren aufeinander aufbauenden Schritten besteht. Mathematik, Logik, mehrstufige Planung oder Code, bei dem Zustandsänderungen nachverfolgt werden müssen.
- Eine Konfiguration mit weniger Reasoning scheitert wiederholt an denselben evaluierten Fällen. Ein Reasoning-Modell oder höherer Aufwand ist dann ein sinnvolles Experiment. Vergleichen Sie beide Konfigurationen an denselben Fällen.
- Die Aufgabe einen sorgfältigen Vergleich oder eine Abwägung erfordert. Entscheidungen nach mehreren Kriterien, Architekturentscheidungen oder Anbieterbewertungen.
- Ihre Evaluierung Randfälle enthält, die Konfigurationen mit weniger Reasoning übersehen. Messen Sie diese Fälle direkt, statt Reasoning-Qualität aus flüssigem Text abzuleiten.
- Die Aufgabe folgenreich ist. Wählen Sie nicht allein wegen der Tragweite mehr Reasoning. Nutzen Sie in Finanzwesen, Recht, Medizin, Sicherheit oder Produktivbetrieb maßgebliche Quellen, qualifizierte Prüfung, validierte Kontrollen und eine dokumentierte Entscheidungsgrenze. Testen Sie anschließend, ob die Reasoning-Konfiguration die relevanten Fälle verbessert.
Fälle, in denen eine Basis mit weniger Reasoning konkurrenzfähig sein kann:
- Latenzsensible Gesprächsaufgaben. Verwenden Sie mehr Reasoning nur, wenn der gemessene Qualitätsgewinn die langsamere Interaktion rechtfertigt.
- Generieren und Entwerfen, wenn Evaluierungen keinen Vorteil zeigen. Für kreative Iteration kann eine Konfiguration mit geringerer Latenz geeigneter sein. Vergleichen Sie die Ausgabequalität, statt Nutzen oder Schaden von mehr Reasoning vorauszusetzen.
- Einfache Informationsabfrage. Eine quellengebundene Suche oder eine Konfiguration mit weniger Reasoning kann das Qualitätsziel bei geringerer Latenz und niedrigeren Kosten erreichen. Prüfen Sie die Quelle in beiden Fällen.
- Schnelle iterative Verfeinerung. Eine geringere Latenz kann die Interaktion verbessern. Vergleichen Sie jedoch den endgültigen Aufgabenerfolg, statt nur die Zahl der Nachrichten zu betrachten.
- Aufgaben, die prüfbare Zwischenbelege benötigen. Fordern Sie Berechnungen, Quellen, Testergebnisse oder andere überprüfbare Artefakte an. Eine sichtbare Gedankenkettenerzählung belegt nicht, dass die Schlussfolgerung korrekt ist.
Eine nützliche Entscheidungsregel: Erhöhen Sie den Reasoning-Aufwand nur, wenn der erwartete Qualitätsgewinn die gemessene Latenz und die Kosten dieses Workflows rechtfertigt.
Zu vergleichende Prompt-Muster
Beginnen Sie mit einem direkten, ergebnisorientierten Prompt. Vergleichen Sie danach diese Muster, wenn sie das Ergebnis wesentlich beeinflussen könnten:
1. Verwenden Sie für OpenAI einen direkten Prompt als Basis
Für OpenAI-Reasoning-Modelle erklären die Best Practices von OpenAI, dass Aufforderungen wie „Denken Sie Schritt für Schritt“ unnötig sind und die Leistung mitunter beeinträchtigen können. Andere Anbieter stellen andere Kontrollen bereit. Vergleichen Sie deshalb einen direkten Prompt mit jeder stärker strukturierten Variante, die Sie erwägen.
Schlecht: Denken Sie Schritt für Schritt. Lösen Sie die Aufgabe sorgfältig. Zeigen Sie Ihren Lösungsweg. [problem]
Gut: [problem]
Formulieren Sie das Problem klar und prüfen Sie die Schlussfolgerung. Folgen Sie bei anderen Anbietern der aktuellen Dokumentation und testen Sie den unterstützten Prompt oder die unterstützte Kontrolle.
2. Vergleichen Sie direkte Prompts mit einem Verfahrensgerüst
Ein umfangreiches Gerüst kann Arbeit wiederholen, die ein Reasoning-Modell bereits intern erledigt. Beginnen Sie mit Ziel, relevantem Kontext, festen Einschränkungen, geforderten Belegen und Ausgabeformat. Entfernen Sie Verfahrensschritte nur, wenn eine Evaluierung zeigt, dass der einfachere Prompt das benötigte Verhalten bewahrt.
Kandidat mit Verfahrensgerüst: Zuerst die wichtigsten Einschränkungen auflisten. Dann die Optionen auflisten. Dann jede Option gegen jede Einschränkung bewerten. Dann auswählen. Dann rechtfertigen. Ausgabeformat: …
Direkter Kandidat: Helfen Sie mir, zwischen Option A und B zu entscheiden. Kontext: […]
Der einfachere Prompt lässt dem Modell Raum für die Wahl eines Ansatzes und bewahrt zugleich die tatsächlichen Einschränkungen und den erforderlichen Ausgabevertrag.
3. Testen Sie die Kombination von Techniken, statt ihren Nutzen vorauszusetzen
Prompts mit Gedankenkette, Selbstkritik und Baumsuche ergänzen Anweisungen und Tokens. Gehen Sie nicht davon aus, dass ihre Kombination die evaluierte Antwort verbessert.
Enthält Ihr Prompt „Denken Sie Schritt für Schritt, kritisieren Sie anschließend Ihre Antwort und überarbeiten Sie sie“, vergleichen Sie ihn mit einer einfacheren Fassung. Behalten Sie die Version, die bei repräsentativen Fällen besser abschneidet.
4. Verwenden Sie Rollen nur, wenn sie Aufgabeninformationen vermitteln
Ausführliche Personas fügen häufig nicht überprüfbare Details hinzu, ohne die Aufgabe zu verändern. Verwenden Sie eine Rolle, wenn sie Umfang, Zielgruppe, Richtlinie oder Terminologie festlegt. Beschreiben Sie die Arbeit andernfalls direkt. Wenn die Rolle das Ergebnis zu verbessern scheint, bestätigen Sie diesen Gewinn an denselben Evaluierungsfällen, statt ihn intuitiv der Persona zuzuschreiben.
Eine kurze Rolle kann nützlich sein, um Ton und Sprachregister festzulegen. Vergleichen Sie sie mit gleichwertigen konkreten Anweisungen, wenn Konsistenz wichtig ist.
Schlecht: Sie sind ein erstklassiger Senior Backend Engineer mit mehr als 20 Jahren Erfahrung …
Gut: Helfen Sie mir, dieses Problem mit verteilten Systemen zu durchdenken. [problem]
5. Fordern Sie Belege statt verborgenem Denken an
Manche Produkte verbergen oder fassen internes Reasoning zusammen. Mit der Aufforderung „Zeigen Sie Ihre Gedankengänge“ verlangen Sie eine generierte Erklärung, nicht zwangsläufig die private Verarbeitung des Modells oder einen Korrektheitsbeleg.
Wenn Sie Prüfbarkeit benötigen, fordern Sie eine knappe Begründung und kontrollierbare Belege. Die aktuelle Anthropic-API kann je nach Modell und Konfiguration zusammengefasstes Reasoning zurückgeben oder es auslassen. Beides ersetzt nicht die Prüfung des Ergebnisses.
Was der Prompt enthalten sollte
Ein brauchbarer Ausgangspunkt enthält:
Konkrete Angaben. Geben Sie Zahlen, Daten, genaue Einschränkungen, Dateien und andere Eingaben an, die zum Lösen und Prüfen der Aufgabe erforderlich sind.
Offene Fragestellung, sofern der Ausgabevertrag sie zulässt. „Das ist die Situation. Das möchte ich herausfinden. Wie schätzen Sie es ein?“ kann ein sinnvoller Ausgangspunkt für den Vergleich mit einer strengeren Vorlage sein.
Ehrliche Unsicherheit. Sagen Sie dem Modell, was Sie nicht wissen. „Ich bin mir nicht sicher, ob X oder Y zutrifft. Helfen Sie mir, die Belege zu bestimmen, mit denen sich beides unterscheiden lässt“ ist hilfreicher als verborgene Mehrdeutigkeit.
Erlaubnis zum Widerspruch. „Widersprechen Sie mir, wenn meine Fragestellung falsch ist“ oder „Sagen Sie mir, was ich übersehe“ liefert deutlich bessere Ergebnisse als die Bitte, Ihre bestehende Position zu bestätigen.
Konkrete Daten. Tabellen, Code und Dokumente geben dem Modell reale Artefakte zur Prüfung. Teilen Sie sie nur, wenn das Werkzeug für diese Daten zugelassen ist, und entfernen Sie Informationen, die die Aufgabe nicht benötigt.
Beispiele
Beispiel 1: Eine Debugging-Aufgabe
Angenommen, Sie haben einen schwierigen Bug.
Prompt mit Verfahrensgerüst:
Sie sind ein Senior-Software-Entwickler mit Spezialisierung auf TypeScript. Denken Sie Schritt für Schritt über diesen Bug nach.
Erstens, identifizieren Sie die relevanten Codeabschnitte. Zweitens, verfolgen Sie den Datenfluss. Drittens, identifizieren Sie wahrscheinliche Ursachen. Viertens, empfehlen Sie eine Lösung.
Hier ist der Bug: [description] Hier ist der Code: [code]
Direkter Prompt:
Helfen Sie mir, diesen Bug zu finden.
Symptome: [description] Relevanter Code: [code] Was ich bereits versucht habe: [list]
Vergleichen Sie den direkten Prompt mit der Version mit Verfahrensgerüst an repräsentativen Fehlern. Messen Sie Korrektheit, erforderliche Belege, Latenz und Kosten. Leiten Sie aus diesem Beispiel allein nicht ab, dass die direkte Version besser ist.
Beispiel 2: Eine strategische Entscheidung
Strukturierter Prompt:
Sie sind ein Senior-Strategieberater. Ich versuche zu entscheiden, ob Produkt X gestartet werden soll. Wenden Sie das Framework [framework name] an. Erstens, … [long structured prompt]
Direkter Prompt:
Ich versuche zu entscheiden, ob Produkt X gestartet werden soll. Kontext:
- Wir sind ein Unternehmen mit 50 Mitarbeitern und 5 Mio. USD ARR.
- Die Entwicklung des Produkts würde zwei Quartale dauern.
- Es grenzt an unser Hauptprodukt an, steht aber nicht in direkter Konkurrenz dazu.
- Zwei unserer Top-10-Kunden haben danach gefragt.
- Unsere Teamkapazität ist bereits strapaziert.
Helfen Sie mir, das zu durchdenken. Widersprechen Sie mir, wenn meine Fragestellung falsch ist. Sagen Sie mir, was ich übersehe.
Der direkte Prompt lässt dem Modell Raum, die Analysestruktur zu wählen. Vergleichen Sie ihn mit der strukturierten Variante anhand derselben Entscheidungskriterien, bevor Sie eine davon als Vorlage übernehmen.
Beispiel 3: Komplexe Codeanalyse
Prompt mit Verfahrensgerüst:
Analysieren Sie diesen Code auf Leistungsprobleme. Denken Sie Schritt für Schritt. Identifizieren Sie zuerst die Datenstrukturen, ermitteln Sie dann die algorithmische Komplexität und benennen Sie anschließend konkrete Engpässe. [code]
Direkter Prompt:
Was ist an diesem Code langsam? Es benötigt derzeit etwa 3 Sekunden bei einer typischen Eingabe; ich möchte es unter 500 ms haben.
[code]
Testen Sie, ob der direkte Prompt den relevanten Engpass identifiziert und eine gültige Korrektur erzeugt. Prüfen Sie jeden Vorschlag mit Profiling-Daten, Tests und Benchmarks.
Fallen, die spezifisch für Reasoning-Modelle sind
Eine kurze Liste von Dingen, die sogar erfahrene Nutzer erwischen:
Die Latenz. Mehr Reasoning kann die Antwortzeit, mitunter deutlich, erhöhen. Messen Sie die tatsächliche Verteilung für Ihr Modell und Ihren Workflow einschließlich Zeitüberschreitungen, statt mit einer pauschalen Schätzung zu planen.
Die Kosten. Anbieter rechnen Reasoning unterschiedlich ab, und Modellpreise ändern sich. Messen Sie abgerechnete Eingabe-, Ausgabe- und Reasoning-Tokens an repräsentativen Anfragen und vergleichen Sie die Gesamtkosten der Aufgabe, statt einen festen Multiplikator anzunehmen.
Eine Antwort erreicht ihre Generierungsgrenze. Reasoning- und Antwort-Tokens teilen sich Grenzen je nach Anbieter unterschiedlich. Stoppt eine Antwort vorzeitig, prüfen Sie Stop-Grund und Token-Abrechnung des Anbieters. Grenzen Sie danach die Aufgabe ein oder passen Sie nur die vom jeweiligen Modell unterstützten Kontrollen an. Gehen Sie nicht davon aus, dass jede API ein allgemeines Thinking-Budget akzeptiert.
Lange, festgefahrene oder unproduktive Antworten. Sie können ungewöhnlich lange Latenzen, Zeitüberschreitungen, Wiederholungen oder eine endgültige Antwort beobachten, die die Aufgabe verfehlt. Erfassen Sie den beobachtbaren Fehler und die Konfiguration. Versuchen Sie es anschließend innerhalb Ihrer Richtlinien erneut, grenzen Sie die Aufgabe ein oder vergleichen Sie eine andere unterstützte Einstellung. Behaupten Sie nicht allein anhand der Ausgabe, die verborgene Ursache zu kennen.
Flüssige, aber unbelegte Schlussfolgerungen. Mehr Reasoning beweist keine Korrektheit. Fordern Sie bei kritischen Ergebnissen Quellen, Berechnungen, Tests und die Annahmen oder neuen Belege, die die Schlussfolgerung ändern würden. Die Selbsteinschätzung des Modells ist keine kalibrierte Garantie.
Variable Kosten zwischen Anfragen. Der Verbrauch von Reasoning-Tokens kann je nach Aufgabe und Konfiguration schwanken. Verfolgen Sie die tatsächliche Nutzung, statt gleiche Anfragekosten oder eine vorhersehbare Skalierung mit der subjektiven Schwierigkeit vorauszusetzen.
Ein zu testender gestufter Workflow
Eine mögliche Variante ist eine gestufte Route:
- Konfiguration mit geringerer Latenz, um die Aufgabe einzugrenzen und die Teilfragen zu bestimmen.
- Konfiguration mit mehr Reasoning für die evaluierten Teilfragen, bei denen die Basis Anforderungen verfehlt.
- Zugelassene Produktivkonfiguration, um das geprüfte Ergebnis für sein Ziel zu formatieren.
Vergleichen Sie diese Route mit einer Basis aus einer einzigen Konfiguration. Messen Sie die Bestehensquote der Aufgaben, die Vollständigkeit der Belege, Übergabefehler, die Einhaltung der Serviceziele, die End-to-End-Latenz und die Gesamtkosten. Zusätzliche Stufen sind nur sinnvoll, wenn der abschließende Workflow so viel besser abschneidet, dass seine betriebliche Komplexität gerechtfertigt ist.
Ein Anwendungsbeispiel ist eine Marktanalyse.
- Eingrenzung: „Ich möchte den Markt für X verstehen. Helfen Sie mir, die Analyse einzugrenzen: Was sollte ich untersuchen, welche Daten benötige ich und welche Fragen sind wichtig?“
- Analyse: „Was bedeuten die von mir erhobenen und geprüften Daten für [specific strategic question]? Benennen Sie Annahmen und Beleglücken.“
- Formatierung: „Überführen Sie die geprüften Erkenntnisse in eine einseitige Kurzdarstellung für unser Führungsteam. Bewahren Sie Quellen und Unsicherheit.“
Diese Aufteilung ist ein testbarer Workflow und kein garantiertes Optimum. Vergleichen Sie ihn hinsichtlich Qualität, Latenz und Kosten mit einer Ein-Modell-Basis.
Einige praktische Gewohnheiten
Definieren Sie die zulässige Basis. Der Vergleich muss dieselben Anforderungen an Daten, Sicherheit, Werkzeuge und Ausgabe erfüllen wie der Reasoning-Kandidat.
Legen Sie die Entscheidungsregel vorab fest. Bestimmen Sie Qualitätsmetrik, Serviceziel, Kostengrenze und erforderliche Mindestverbesserung, bevor Sie die Ergebnisse sehen.
Behalten Sie die Kosten im Blick. Ob über die Nutzungsanzeige Ihres Abonnements oder die API-Abrechnung: Verschaffen Sie sich ein Gefühl für Ihre monatlichen Reasoning-Kosten und passen Sie die Nutzung entsprechend an.
Achten Sie auf wiederholte Fehler der Ausgangslösung mit geringerer Latenz. Das ist ein sinnvoller Anlass, mehr Reasoning an denselben Fällen zu testen.
Vergleichen Sie jeweils nur eine Prompt-Änderung. Testen Sie bei einer schwachen Antwort einen kürzeren Prompt, zusätzlichen Kontext oder eine andere unterstützte Reasoning-Einstellung getrennt, damit das Ergebnis interpretierbar bleibt.
Auf Grundlage von Evidenz entscheiden
Reasoning-Konfigurationen sind nicht automatisch besser oder schlechter. Beginnen Sie mit einem klaren, direkten Prompt, behalten Sie reale Einschränkungen und Beleganforderungen bei und erhöhen Sie Struktur oder Reasoning-Aufwand nur, wenn repräsentative Evaluierungen dies rechtfertigen.
Setzen Sie Reasoning bewusst ein und beginnen Sie mit einem einfachen Prompt. Ein Modell mit geringerer Latenz für die Erkundung und mehr Reasoning für evaluierte Engpässe ist ein Muster, das Sie mit einem Ein-Modell-Workflow vergleichen sollten.
