OpenAI GPT 2026: Function Calling, Structured Outputs und JSON Schema

Stand 18. August 2026. Felder und Verhalten richten sich nach dem OpenAI Function-Calling-Guide und dem Structured-Outputs-Guide. Dieser Artikel erfindet keine Latenzen, Preise oder Erfolgsquoten. Wo die öffentliche Doku nichts festschreibt, steht ausdrücklich: „an Live-Traffic-Replay prüfen“.

Wenn ihr ein OpenAI-kompatibles Backend auf ein anderes Modell umzieht, müssen Structured Output und Tool-Loop separat abgenommen werden — ein neuer Base URL reicht nicht. Siehe die interne Abnahmeliste: OpenAI API nach Kimi K3 migrieren.

Kurzfassung: drei Dinge ändern sich gleichzeitig

Viele Repos hängen noch im Denkmodell von 2024: im Prompt „bitte JSON zurückgeben“, danach Regex auf Codeblöcke. In der Produktionskette 2026 zerlegt das den Parser durch Schema-Verletzungen, fehlende Felder und Enum-Halluzinationen.

Geändert werden müssen drei Schichten — nicht der nächstgrößere Modellname:

Liefervertrag

Das Objekt für Nutzer oder Downstream-Service kommt über Structured Outputs (text.format in Responses, response_format.json_schema in Chat Completions).

Ausführungsvertrag

Wenn das Modell eure Tools aufruft, müssen die Argumente zum JSON Schema des Tools passen. Das ist Function Calling — Constrained Decoding wie bei Structured Outputs.

Kompatibilitätsvertrag

Altes JSON Mode (json_object) garantiert nur „es sieht nach JSON aus“, nicht Felder, Typen oder Enums gegen Schema. Offiziell ist es der Vorläufer von Structured Outputs. Neue Projekte sollten es nicht als Hauptpfad nutzen.

Dazu kommt ein Produktlinienwechsel, den viele übersehen: neuer Code sollte die Responses API nutzen. Chat Completions bleibt verfügbar, aber die Default-Strategie für strict ist anders — Responses versucht, das Schema in den strikten Modus zu normalisieren und fällt nur bei Fehlschlag zurück; Chat Completions bleibt per Default non-strict / best effort.

Modell und API-Hauptpfad: gpt-5.6 + Responses

Structured Outputs gibt es seit der GPT-4o-Generation. Für neue Projekte empfiehlt die Doku direkt gpt-5.6. Ältere Snapshots wie gpt-4-turbo und davor verweisen weiterhin auf JSON Mode, nicht auf volles striktes json_schema.

Zwei Einstiege klar trennen

Auf SDK-Seite lohnt die Gewohnheit: Schema nicht von Hand schreiben (leicht fehlt additionalProperties), sondern mit den offiziellen Helpern aus Typen erzeugen. Python: client.responses.parse(..., text_format=YourModel); JavaScript: zodTextFormat. Bei handgeschriebenem Schema und strict: true führt ein Verstoß zur abgelehnten Anfrage — nicht zu „Modell gibt irgendwas aus, ihr retried“.

Im Vergleich zur Gemini-Linie bedeutet „OpenAI-SDK-kompatibel“ nicht dasselbe Schema-Verhalten. Googles Fähigkeits-Upgrades: 10 neue Funktionen von Gemini 3.5 Pro. Beim Kopieren desselben JSON Schema über Anbieter hinweg ist die additionalProperties-Regel an nested objects oft der erste Knallpunkt.

JSON Mode, Structured Outputs, Function Calling

Typischer Produktionsirrtum: im Log steht JSON, also sei Structured Outputs aktiv. Offizielle Semantik:

Wann Function Calling die falsche Wahl ist

Wenn das Modell euer System nicht anfassen muss (kein Bestand, keine Tickets, keine Skripte) und die Antwort nur in Karten, Schritte oder Scores zerlegt werden soll: Structured Outputs. Sobald die Ausgabe „bitte führe diesen Side Effect aus“ ist, gehören tools dazu — Funktionsargumente nicht als finales Antwort-Schema tarnen.

Refusal ist kein „kaputtes JSON“

Bei Safety-Refusal zwängt das Modell nichts in euer Schema. Responses / Chat Completions liefern ein eigenes refusal-Feld. Die Parse-Schicht muss Refusal als First-Class behandeln: zuerst refusal, dann output_parsed — leeres Objekt ist kein Erfolg.

Harte Regeln für Strict JSON Schema

Mit strict akzeptiert OpenAI ein Subset von JSON Schema, nicht jedes beliebige Draft-2020-12-Dokument. Drei Request-Fehler, die am häufigsten knallen:

1. Jedes Feld in properties muss in required stehen.
2. Jedes object (auch nested) braucht additionalProperties: false.
3. Das Wurzelobjekt darf kein anyOf sein; Optionalität als „required + null erlaubt“, z. B. ["string", "null"].

Heißt: Feld aus required nehmen und so tun, als wäre es optional — dieser alte Trick liefert unter strict direkt 400. Korrekt: Feld bleibt required, Typ ist eine nullable Union, die Anwendung behandelt null als „nicht gesetzt“.

Typisches Produktionsobjekt „Ticket extrahieren“ — nested object ebenfalls mit additionalProperties:

from openai import OpenAI
from pydantic import BaseModel

client = OpenAI()

class Ticket(BaseModel):
    title: str
    priority: str
    assignee: str | None
    tags: list[str]

response = client.responses.parse(
    model="gpt-5.6",
    input=[
        {"role": "system", "content": "Extrahiere Ticket-Felder aus der Nutzerbeschreibung."},
        {"role": "user", "content": "Login-Seite 500, zuweisen an Noah, Priorität hoch, Tags auth und api."},
    ],
    text_format=Ticket,
)
ticket = response.output_parsed
print(ticket.title, ticket.priority, ticket.assignee)

Wird die Anfrage abgelehnt, zuerst in der Fehlermeldung nachschauen, welche Constraint fehlt — nicht sofort das Modell downgraden. Playground-Schemas kommen mit strict; 1:1 ins Repo kopieren ist meist schneller als ein Umbau alter json_object-Prompts.

Cross-Vendor nochmal prüfen: dasselbe Schema mit „jedes object false“ kann an manchen kompatiblen Gateways oder anderen Modellen HTTP 400 werden. Dann pro Anbieter transformieren, nicht drei fachliche Schemas pflegen.

Function Calling 2026: strict, tool_search, Custom Tools

Function Calling und Tool Calling sind offiziell dieselbe Sache: JSON Schema beschreibt aufrufbare Funktionen, der App-Executor führt Side Effects aus. Einige 2026 betonte Punkte ändern die Agent-Schleife direkt.

strict-Default nicht raten

• Immer explizit strict: true.
• Responses: ohne strict versucht der Server, das Schema zu normalisieren; schlägt das fehl, Fallback non-strict, das Tool in der Response zeigt strict: false.
• Chat Completions: ohne Angabe Default non-strict.
• Bei Fine-Tunes mit mehreren Funktionsaufrufen in einer Runde kann die Doku strict für diese Runde deaktivieren.

Tool-Definitionen liegen im Kontext und werden als Input-Tokens abgerechnet. Zu lange Descriptions und 40 Tools auf einmal treiben Kosten und senken die Tool-Auswahl. Bei vielen Tools: tool_search für seltene Tools lazy laden — nur gpt-5.4 und neuer. In der Schleife können zuerst tool_search_call / tool_search_output kommen, danach erst der echte function_call.

Custom Tools: DSL nicht in JSON-Objekte zwängen

Function Tools passen zu strukturierten Parametern; Custom Tools zu Freitext-I/O, optional mit kontextfreier Grammatik (CFG). SQL-Fragmente, interne Query-Sprachen, Formate mit sich gegenseitig ausschließenden Terminals: CFG ist stabiler als „string-Feld plus Prompt-Essay“. Bei unexpected tokens zuerst überlappende Terminals prüfen, nicht das Modell beschuldigen.

tools = [{
    "type": "function",
    "name": "get_order",
    "description": "Bestellstatus anhand der Bestellnummer abfragen. Nur aufrufen, wenn der Nutzer eine eindeutige Bestellnummer nennt.",
    "strict": True,
    "parameters": {
        "type": "object",
        "properties": {
            "order_id": {"type": "string"},
            "locale": {"type": ["string", "null"]},
        },
        "required": ["order_id", "locale"],
        "additionalProperties": False,
    },
}]

Die Ausführungsschleife ist unverändert: Tool-Call anhand finish_reason / Item-Typ → lokale Funktion → Ergebnis als Tool-Rolle zurück → nächster Request. Neu: Argumente müssen nicht mehr mit json.loads auf Glück geparst werden. Die vollständige Assistant-Nachricht (inkl. tool_calls) muss gespeichert bleiben, sonst gehen Call-IDs in Runde zwei verloren.

Migrationsliste für Altprojekte

„Läuft“ und „ist lieferbar“ getrennt abnehmen. Alten Backend-Schalter behalten, zuerst echte Traffics in einer Isolierumgebung replayen.

1. Modell: neue Kette fest auf gpt-5.6 (oder die bei euch freigeschaltete gleichwertige Stufe); Gateway darf nicht still auf alte Snapshots mappen.
2. Output: json_object durch json_schema + strict: true ersetzen, oder Responses text.format.
3. Tools: jedes Function-Tool mit vollständigem required und nested additionalProperties: false; optionale Felder als nullable Union.
4. Parse: parse() und refusal-Zweig; im Streaming prüfen, dass inkrementelles JSON und finales parsed-Objekt zusammenpassen.
5. Tool-Fläche: ab mehr als einem Dutzend Tools tool_search bewerten; zuerst Descriptions kürzen, dann Lazy Load.
6. Vergleich: gleiche feste Tasks — Retry-Rate, fehlende Felder, manuelle Nacharbeit zwischen altem JSON Mode und neuem Schema-Pfad.

Bestehen heißt nicht HTTP 200, sondern: Parser ohne Regex-Fallback, stabile Tool-Parametertypen, beobachtbare Refusals, geübter Rollback-Schalter. Lange SDK-Sessions, Replay-Skripte und Browser-Tabs sterben, wenn das Notebook zuklappt — genau dort setzt die Cloud-Mac-mini an.

FAQ