+160 XP

Die OpenAI-Modellfamilie: GPT, Reasoning-Modelle und wann Sie welches einsetzen

# Die OpenAI-Modellfamilie: GPT, Reasoning-Modelle und wann Sie welches einsetzen

OpenAI liefert unter einem Dach zwei grundverschiedene Verhaltensweisen: schnelles allgemeines Antworten und überlegtes Reasoning, das nachdenkt, bevor es antwortet. Der falsche Modus kostet Sie entweder Geld oder Genauigkeit. In dieser Lektion geht es um Routing: die Aufgabe dem Modell (oder der Reasoning-Stufe) zuordnen, damit Sie für triviale Arbeit nicht zu viel zahlen und schwere Arbeit nicht unterversorgen.

Zwei Verhaltensweisen, die in einem Produkt zusammenlaufen

Historisch hat OpenAI das in zwei benannte Reihen getrennt: die GPT-„Chat“-Modelle (GPT-4o und Verwandte) und die Reasoning-Modelle der „o“-Serie (o3, o4-mini). Mit der GPT-5-Familie ist diese Trennung weitgehend in ein einziges Modell übergegangen, das selbst entscheidet, wie intensiv es denkt. Der zugrundeliegende Tradeoff ist aber genau derselbe, deshalb gilt die Routing-Logik unten weiter.

Schnelles allgemeines Antworten ist auf Breite und Latenz optimiert. Sie senden einen Prompt, die Tokens kommen fast sofort zurück. Dieser Modus ist stark bei Schreiben, Zusammenfassen, Klassifikation, Formatierung, Code-Vervollständigung und Konversation.

Reasoning investiert zusätzliche verborgene Rechenleistung, um ein Problem durchzuarbeiten, bevor die endgültige Antwort kommt. Diese verborgene Arbeit heißt *Reasoning-Tokens*: interne Schritte, für die Sie zahlen und die Sie nie sehen. Es tauscht Latenz und Kosten gegen Genauigkeit bei mehrstufigen Problemen: Mathematik, schwieriges Debugging, Planung, wissenschaftliche Analyse und alles, wo ein falscher Zwischenschritt das Ergebnis ruiniert.

Die Familie gibt es auch in kleineren Varianten (mini- und nano-Stufen). Gleiches allgemeines Fähigkeitsprofil, niedrigere Kosten, niedrigere Latenz, etwas weniger Tiefe. Ein mini-Modell mit hochgedrehtem Reasoning „denkt“ weiterhin, nur günstiger.

Die offizielle Übersicht, wer wer ist und worauf jedes Modell getrimmt ist, steht in der Modell-Dokumentation. Schauen Sie dort nach, wenn sich Namen ändern; die Routing-Logik unten ändert sich nicht.

Die Routing-Entscheidung in einer Frage

Fragen Sie: Hat diese Aufgabe eine überprüfbare Kette von Schritten, bei der ein früher Fehler das Ergebnis zerstört?

  • Nein → schnelles allgemeines Antworten. Umschreiben, Tonalitätsänderungen, Entwürfe, Extraktion, Zusammenfassung, einfache Q&A, lockerer Chat.
  • Ja → Reasoning hochdrehen. Analysen mit mehreren Constraints, mathematische Beweise, unklare Fehlersuche, Synthese mehrerer Dokumente mit Logik, Planung einer Handlungsfolge.

Dann stellen Sie eine zweite Frage zu den Kosten: Ist das hochvolumig oder latenzkritisch? Wenn ja, gehen Sie auf eine mini/nano-Variante runter.

Konkretes Beispiel: Umschreiben vs. Analyse

Aufgabe A: „Schreibe diesen Absatz knapper und selbstbewusster um.“

Das ist eine einmalige Transformation. Es gibt keine Kette, bei der etwas schiefgehen kann. Halten Sie Reasoning niedrig (oder aus) und lassen Sie schnell antworten.

python
from openai import OpenAI
client = OpenAI()

resp = client.responses.create(
    model="gpt-5",
    reasoning={"effort": "minimal"},
    input="Rewrite to be concise and confident:\n\n" + paragraph,
)
print(resp.output_text)

Aufgabe B: „Hier sind drei Lieferantenverträge. Finde jede Klausel, in der sich die Verlängerungsbedingungen widersprechen, und sag mir, welcher Vertrag nach den Vorrangregeln in Abschnitt 12 gewinnt.“

Das ist mehrstufig: Klauseln extrahieren, vergleichen, Vorranglogik anwenden, Konflikte auflösen. Ein frühes Missverständnis pflanzt sich fort. Drehen Sie Reasoning hoch und lassen Sie das Modell Tokens ausgeben.

python
resp = client.responses.create(
    model="gpt-5",
    reasoning={"effort": "high"},
    input=contracts_text + "\n\nFind conflicting renewal clauses and resolve per section 12.",
)
print(resp.output_text)

Zwei Dinge fallen auf. Erstens nutzen beide Aufrufe die Responses API (responses.create), OpenAIs aktuelle Hauptschnittstelle. Zweitens tauscht der Regler reasoning.effort (minimal / low / medium / high) Tiefe gegen Kosten und Latenz. In der GPT-5-Familie ist das Ihr wichtigster Hebel: gleiches Modell, unterschiedlich viel Denken. Wenn Sie noch ein älteres Reasoning-Modell wie o3 oder o4-mini ansprechen, gilt derselbe Parameter, auch wenn das in den meisten Workflows inzwischen Legacy-Optionen sind.

In ChatGPT: der Picker in einfachen Worten

In den ChatGPT-Apps ist der Standard jetzt ein einziges GPT-5-Modell mit Auto-Routing: Es entscheidet intern, ob es schnell antwortet oder intensiver nachdenkt. Manuelle Kontrolle haben Sie weiterhin:

  • Der Standard deckt rund 80 % der täglichen Arbeit ab, ohne dass Sie etwas anfassen müssen.
  • Eine explizite Thinking-Option erzwingt überlegtes Reasoning. Wechseln Sie dorthin, wenn eine schnelle Antwort immer wieder oberflächlich oder subtil falsch zurückkommt.
  • Bei aktivem Auto-Routing ist Ihr echter Hebel der Prompt („denke sorgfältig nach und prüfe jeden Schritt“) und nicht ein Dropdown, weil das Modell das als Signal liest, mehr Reasoning zu investieren.

Ältere o-Serien-Namen (o3, o4-mini) können bei manchen Plänen noch unter Legacy- oder Advanced-Menüs erscheinen, aber die GPT-5-Familie ist der Standardweg nach vorn.

Eine praktische Gewohnheit: schnell starten und nur dann auf explizites Thinking eskalieren, wenn Sie das Modell beim Überspringen von Logik erwischen. Thinking kostet mehr und ist langsamer, machen Sie es also nicht zum Standard.

Wo das mit den ChatGPT-Features zusammenspielt

Die Modellwahl, oder wie intensiv Sie es denken lassen, verändert, wie sich der Rest des ChatGPT-Werkzeugkastens verhält.

Advanced Data Analysis (Code Interpreter). Wenn Sie eine CSV hochladen und um Analyse bitten, schreibt und führt das Modell Python in einer Sandbox aus. Hoher Reasoning-Effort ist deutlich besser darin, eine korrekte mehrstufige Analyse zu planen (bereinigen, joinen, aggregieren, validieren), bevor der Code geschrieben wird. Für „mach mir schnell ein Balkendiagramm“ genügt eine schnelle Antwort.

Canvas. Bei Langtexten und Code, die Sie parallel bearbeiten, hält schnelles Antworten die Schleife kurz. Drehen Sie Reasoning nur hoch, wenn der *Inhalt selbst* harte Logik verlangt, etwa die Herleitung eines Algorithmus.

Custom GPTs und Projects. Ihre Custom Instructions und Memory prägen das Verhalten in beiden Fällen, aber ein Modell, das intensiver denkt, folgt mehrteiligen Anweisungen zuverlässiger, weil es um sie herum planen kann. Wenn Ihr Custom GPT ständig Constraint #4 von 6 ignoriert, kann die Reasoning-Stufe der Engpass sein.

Der ChatGPT-Agent und geplante Tasks. Autonome, mehrstufige Arbeit (browsen, klicken, synthetisieren) setzt von Haus aus auf schwereres Reasoning, weil jeder Schritt vom vorherigen abhängt.

Choosing Between GPT and Reasoning Models

Watch on YouTube

Kosten und Latenz: der echte Tradeoff

Die Preisdetails ändern sich, argumentieren Sie also qualitativ (die aktuellen Zahlen stehen auf der Pricing-Seite):

  • Reasoning kostet pro Aufgabe mehr, als der Token-Preis vermuten lässt, weil es zusätzlich zur sichtbaren Antwort unsichtbare Reasoning-Tokens erzeugt. Hoher Effort bei einem schweren Problem kann ein Mehrfaches einer schnellen Antwort auf eine leichte Frage kosten.
  • mini/nano-Varianten existieren genau deshalb, damit Sie Reasoning im Maßstab betreiben können, ohne dass die Kosten explodieren. Für die Batch-Klassifikation von 100k Support-Tickets ist ein mini-Modell fast immer die richtige Wahl gegenüber dem Flaggschiff.
  • Latenz folgt derselben Achse. Hoher Reasoning-Effort fühlt sich langsam an, weil das Modell denkt. Das ist der Zweck, kein Bug. Setzen Sie es nicht hinter ein UI, das Antworten unter einer Sekunde braucht, außer Sie begrenzen effort auf minimal oder low.

Eine einfache interne Regel für Teams: standardmäßig schnell antworten, hohen Reasoning-Effort nur für eine explizite Allowlist von Aufgabentypen erlauben und das Flaggschiff mit hohem Effort für Arbeit mit geringem Volumen und hohem Einsatz reservieren.

Wissenscheck

1. Was ist der grundlegende Unterschied zwischen allgemeinen GPT-Modellen und Reasoning-Modellen?

2. Welche einzelne Frage bestimmt laut Lektion am besten, ob eine Aufgabe an ein Reasoning-Modell geroutet wird?

3. Was sind „Reasoning-Tokens“, wie sie in der Lektion beschrieben werden?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aufgaben aus, die besser zu einem allgemeinen GPT-Modell als zu einem Reasoning-Modell passen.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE korrekten Aussagen über die `mini`- und `nano`-Varianten.

Wählen Sie alle richtigen Antworten aus.

Reasoning verändert, wie Sie prompten

Sobald Sie Reasoning hochdrehen, sollte sich Ihr Prompting-Stil ändern, sonst verschenken Sie seine Stärke.

Hören Sie auf, die Schritte vorzukauen. Bei schnellem Antworten ergänzen Sie oft „denke Schritt für Schritt“. Ein Modell, das intern schon reasont, macht das von selbst, und die Schritte auszuschreiben kann es sogar einschränken. Nennen Sie stattdessen das Ziel, die Constraints und die Erfolgskriterien, und dann halten Sie sich raus.

Schwacher Prompt bei hohem Reasoning:

> Liste zuerst die Klauseln auf. Vergleiche sie dann. Wende dann Abschnitt 12 an. Ziehe dann ein Fazit.

Stärker:

> Löse alle Konflikte bei den Verlängerungsbedingungen über diese Verträge hinweg auf. Erfolg = jeder Konflikt identifiziert, mit Nennung des maßgeblichen Vertrags und der Regel aus Abschnitt 12, die entscheidet. Markiere Unklarheiten, anstatt zu raten.

Geben Sie ihm Raum und eine klare Ziellinie. Ein Reasoning-Modell belohnt eine präzise Definition von „fertig“ und explizite Anweisungen zum Umgang mit Unsicherheit („markieren, nicht raten“). Es beachtet auch Structured Outputs gut, kombinieren Sie es also mit einem JSON-Schema, wenn die Antwort in ein anderes System einfließt.

python
schema = {
    "name": "conflict_report",
    "schema": {
        "type": "object",
        "properties": {
            "conflicts": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "clause": {"type": "string"},
                        "winning_contract": {"type": "string"},
                        "rule": {"type": "string"},
                    },
                    "required": ["clause", "winning_contract", "rule"],
                    "additionalProperties": False,
                },
            }
        },
        "required": ["conflicts"],
        "additionalProperties": False,
    },
    "strict": True,
}

resp = client.responses.create(
    model="gpt-5",
    reasoning={"effort": "high"},
    input=contracts_text + "\n\nReturn the conflict report.",
    text={"format": {"type": "json_schema", **schema}},
)

strict: True garantiert, dass das Modell genau diese Form zurückgibt, was besonders zählt, wenn der Output in nachgelagerten Code läuft.

Reasoning innerhalb von Agents

Wenn Sie mit dem Agents SDK bauen oder Function Calling verdrahten, lässt sich der Tradeoff sauber auf Rollen abbilden:

  • Der Planner (entscheidet, welche Tools in welcher Reihenfolge aufgerufen werden) profitiert von hohem Reasoning-Effort. Tool-Auswahl ist genau die Art mehrstufiger Entscheidung, die er gut beherrscht.
  • Die Worker (ein Tool, das eine abgerufene Seite zusammenfasst, ein Ergebnis formatiert, eine Antwort entwirft) können schnell oder auf einem günstigeren mini-Modell laufen. Sie erledigen enge, einmalige Jobs.

Diese Aufteilung hält einen Agent gleichzeitig schlau und bezahlbar: hart nachdenken über *was zu tun ist*, günstig handeln bei *jedem Schritt*. Ein verbreitetes Anti-Pattern ist, das Flaggschiff mit hohem Effort für jeden Tool-Aufruf laufen zu lassen, was Agents langsam und teuer macht, ohne Genauigkeit zu gewinnen.

Eine kurze mentale Checkliste

Vor jeder nicht-trivialen Aufgabe gehen Sie das durch:

1. Kette abhängiger Schritte? → Reasoning-Effort hochsetzen. Einzelne Transformation? → schnell halten.

2. Hohes Volumen oder Tempo nötig? → runter auf mini/nano.

3. Output fließt in Code oder ein anderes Tool? → Structured Outputs ergänzen.

4. Reasoning hochgedreht? → Ziel + Constraints + „fertig“ nennen, nicht die Schritte.

5. Sie bauen einen Agent? → hart denken zum Planen, schnell handeln zum Ausführen.

Die wichtigsten Erkenntnisse

  • Routen Sie nach Struktur, nicht nach Hype. Eine einzelne Transformation soll schnell antworten; eine Kette abhängiger Schritte, bei der ein Fehler das Ergebnis zerstört, soll intensiver reasonen. In der GPT-5-Familie ist das der Regler reasoning.effort und kein separates Modell.
  • mini/nano-Varianten sind Ihr Kostenhebel. Bei hochvolumiger oder latenzkritischer Arbeit schlägt ein kleineres Modell mit dem richtigen Effort das Flaggschiff jedes Mal.
  • Reasoning kostet pro Aufgabe mehr, als der Token-Preis nahelegt, wegen der unsichtbaren Reasoning-Tokens. Standardmäßig schnell, bewusst eskalieren und effort begrenzen, wenn Latenz zählt.
  • Prompten Sie anders, wenn Reasoning hoch ist: Ziel, Constraints und eine Definition von „fertig“ geben und sagen, dass Unsicherheit markiert und nicht geraten wird. Das manuelle „Schritt für Schritt“ können Sie weglassen.
  • In Agents die Rollen trennen: hoher Effort zum Planen, schnelle Modelle für einzelne Tool-Aufrufe. Kombinieren Sie Reasoning-Output mit Structured Outputs, wann immer er in anderen Code fließt.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Reasoning-Modelle für die Planung und günstige, schnelle Modelle für die Ausführung der Schritte einsetzen
  • Reasoning Models mit Ziel, Constraints und Definition of Done prompten
  • Reasoning Effort begrenzen und standardmäßig schnelle Modelle nutzen, Eskalation nur bewusst
Vollständiges Action Playbook ansehen

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.