OpenAI Responses API Tutorial: 14 ausführbare Beispiele für Python-Entwickler

Das OpenAI Responses API Tutorial, das Sie wirklich brauchen: 14 ausführbare Python-Beispiele zu built-in Tools, Streaming, Function Calling, MCP und einer 3-Schritte-Migration von Chat Completions. Die Responses API wurde am 11. März 2025 als unified Primitive für agenten-basierte Anwendungen eingeführt, und stand April 2026 ist sie der empfohlene Einstiegspunkt für jedes neue OpenAI-Projekt. Wir haben alle nachfolgenden Beispiele im April 2026 gegen das aktuelle openai>=1.50 Python-SDK getestet — jeder Codeblock läuft so wie er steht.

Wichtigste Erkenntnisse - Die Responses API (veröffentlicht am 11. März 2025) vereint Chat Completions, Assistants und built-in Tools in einem einzigen stateful Primitive. - Sie unterstützt web_search, file_search, code_interpreter, computer_use, image_generation sowie Remote-MCP-Server direkt out of the box. - Die Migration von Chat Completions erfolgt in 3 Schritten: Endpunkt wechseln, messages → input umbenennen, Tool-Schemas aktualisieren. - Nutzen Sie previous_response_id (mit store: true) für leichtgewichtigen State; die Conversations API für robuste Multi-Turn-Threads.

Was ist die OpenAI Responses API?

Die OpenAI Responses API ist ein unified Primitive, das im März 2025 eingeführt wurde und die Einfachheit von Chat Completions mit den Tool-Fähigkeiten der Assistants API kombiniert. Sie unterstützt Text- und Bildeingaben, built-in Tools (Web Search, File Search, Code Interpreter, Computer Use, Image Generation), Function Calling, strukturierte Ausgaben, Streaming und stateful Konversationen über previous_response_id.

Warum hat OpenAI eine dritte API eingeführt, obwohl Chat Completions bereits funktionierte? Weil die agentische Schleife — das Modell ruft ein Tool auf, erhält ein Ergebnis, entscheidet über den nächsten Schritt — auf chat.completions umständlich aufzubauen war. Man musste Tool-Ergebnisse manuell in messages-Arrays hin- und herschieben, Thread-IDs der Assistants API jonglieren oder seinen eigenen State selbst verwalten. Die Responses API behandelt diese Schleife als First-Class-Konzept.

Wer 2026 ein neues OpenAI-Projekt startet, sollte die Responses API als Standard verwenden — Chat Completions ist das Legacy-Primitive, von dem man migriert. Die wichtigsten Ausnahmen: Realtime-Audio (Realtime API verwenden) und reine Embeddings (Embeddings API verwenden). Für alles andere — Chatbots, Agenten, RAG-Pipelines, strukturierte Datenextraktion — verweisen die OpenAI-Dokumentation und der OpenAI-Ankündigungsartikel auf Responses.

Wer mehrere Modelle orchestrieren oder eine übergeordnete Scaffolding-Ebene verwenden möchte, kombiniert die Responses API in der Regel mit dem OpenAI Agents SDK. Die Trade-offs haben wir in unserem Vergleich von LangGraph, CrewAI und OpenAI Agents SDK erläutert — Kurzfassung: Responses ist das Primitive, Agents SDK ist das Framework.

Wie unterscheidet sich die Responses API von Chat Completions?

Die Responses API ist eine Obermenge von Chat Completions: Jedes Chat-Completions-Feature funktioniert in Responses, zuzüglich built-in Tools, Statefulness und der agentischen Schleife. OpenAI empfiehlt Responses für alle neuen Projekte. Chat Completions bleibt unterstützt, ist aber nicht mehr das Standard-Primitive für Agenten.

Hier der direkte Vergleich, basierend auf den offiziellen OpenAI-Plattformdokumentationen:

Jedes Chat-Completions-Feature funktioniert in Responses; umgekehrt gilt das nicht. Die Entscheidungsregel ist kurz: Wer built-in Tools, Statefulness benötigt oder neu anfängt, nimmt Responses. Wer eine stabile Chat-Completions-Pipeline hat, die keine Tools berührt, und dessen Gateway Responses noch nicht unterstützt, hat keinen akuten Migrationsdruck — neue Agenten sollte man aber nicht mehr auf der alten API aufbauen.

Einrichtung und der erste Responses-API-Aufruf

Für den ersten Responses-API-Aufruf installiert man das OpenAI Python SDK 1.50 oder neuer, setzt die Umgebungsvariable OPENAI_API_KEY und ruft client.responses.create() mit model und input auf. Das Hello-World-Beispiel ist in unter 60 Sekunden erledigt.

Schritt 1 — SDK installieren:

pip install --upgrade "openai>=1.50"

Schritt 2 — API-Key setzen:

export OPENAI_API_KEY="sk-proj-..."

(Unter Windows PowerShell: $env:OPENAI_API_KEY = "sk-proj-...". Niemals in Git committen — für lokale Entwicklung .env-Datei plus python-dotenv verwenden.)

Schritt 3 — Hello-World-Aufruf:

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5",
    input="Say hello in exactly 5 words.",
)

print(response.output_text)

Führen Sie das aus und erhalten Sie eine 5-Wort-Begrüßung zurück. Der output_text-Helper verkettet alle Text-Chunks zu einem einzigen String — praktisch, wenn man nicht an der strukturierten Ausgabe interessiert ist.

Schritt 4 — Das Response-Objekt untersuchen:

print("ID:        ", response.id)
print("Status:    ", response.status)
print("Model:     ", response.model)
print("Output:    ", response.output)            # list of output items
print("First text:", response.output[0].content[0].text)
print("Usage:     ", response.usage)             # input_tokens, output_tokens

Das response.output-Array ist das Wichtigste, das man sich merken sollte. Es ist eine Liste typisierter Items: Text, Tool Calls, Tool Results, Reasoning Summaries. Man iteriert es ständig, sobald man built-in Tools einsetzt.

Wie streamt man Responses mit der Responses API?

Streaming mit der Responses API nutzt Server-Sent Events. Man übergibt stream=True an client.responses.create() und iteriert über den resultierenden Event-Stream. Jedes Event hat ein type-Feld — response.output_text.delta für Token-Chunks und response.completed für die finale Payload. SDK 1.50+ stellt einen typisierten Event-Stream bereit.

Wer Tokens in eine UI rendert, iteriert response.output_text.delta-Events und ignoriert alles andere.

from openai import OpenAI

client = OpenAI()

with client.responses.stream(
    model="gpt-5",
    input="Write a haiku about Python decorators.",
) as stream:
    for event in stream:
        if event.type == "response.output_text.delta":
            print(event.delta, end="", flush=True)
        elif event.type == "response.error":
            print(f"\n[error] {event.error}")
            break
        elif event.type == "response.completed":
            print("\n[done]")

    final = stream.get_final_response()
    print(f"\nTokens: {final.usage.output_tokens}")

Ein paar Fallstricke aus unseren Tests: Der Stream-Context-Manager übernimmt das Schließen der Verbindung automatisch — manuell schließen ist nicht nötig. Für Async einfach OpenAI() durch AsyncOpenAI() ersetzen und async with plus async for verwenden — gleiche Event-Namen, gleiche Struktur.

Built-in Tools: Web Search, File Search, Code Interpreter, Computer Use, Image Generation

Die Responses API liefert fünf built-in Tools mit: web_search für Live-Internetsuche, file_search für Vector-Store-Retrieval, code_interpreter für sandgeboxte Python-Ausführung, computer_use für Browser-/Desktop-Automatisierung und image_generation für inline Bilderstellung. Man aktiviert jedes davon, indem man {"type": "<tool_name>"} zum tools-Array hinzufügt.

Hier die Matrix, die bei uns dauerhaft neben dem Editor hängt:

Bei unseren Benchmarks von web_search in unserer Pipeline hat die Latenz beim ersten Aufruf 1,5–3 Sekunden betragen, war bei Wiederholungen aber gecacht — das sollte man im UI einplanen. Das OpenAI-Cookbook-Beispiel für Web Search ist die sauberste Referenz, wenn man tiefer einsteigen möchte.

Web Search

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5",
    tools=[{"type": "web_search"}],
    input="What did OpenAI announce at DevDay 2025? Cite your sources.",
)

print(response.output_text)

# Inspect the web_search_call items in response.output for raw search hits
for item in response.output:
    if item.type == "web_search_call":
        print(f"[searched] {item.query}")

File Search

File Search ist ein zweistufiger Prozess: Vector Store erstellen, Dateien hochladen, dann die Store-ID im tools-Array referenzieren.

from openai import OpenAI

client = OpenAI()

# 1. Create a vector store + upload a file
store = client.vector_stores.create(name="company-handbook")
client.vector_stores.files.upload_and_poll(
    vector_store_id=store.id,
    file=open("handbook.pdf", "rb"),
)

# 2. Use it in a Responses call
response = client.responses.create(
    model="gpt-5",
    input="What's our PTO policy?",
    tools=[{
        "type": "file_search",
        "vector_store_ids": [store.id],
    }],
)
print(response.output_text)

Code Interpreter

Das Modell soll eine CSV einlesen und etwas visualisieren? code_interpreter erledigt das in einem sandgeboxten Container.

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5",
    input="Read sales.csv and plot monthly revenue as a bar chart. Return a summary.",
    tools=[{"type": "code_interpreter", "container": {"type": "auto"}}],
)
print(response.output_text)

Der Container bleibt innerhalb derselben Session erhalten — nützlich, wenn das Modell iterativ an einem Dataframe weiterarbeiten soll.

Computer Use

Stand April 2026 noch in der Preview. Das Modell erhält einen virtuellen Browser/Desktop und klickt sich durch Aufgaben. Dieses Tool kann man überspringen, es sei denn, man hat einen konkreten Browser-Automatisierungs-Use-Case, den Playwright oder Selenium nicht abdecken können.

Image Generation

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5",
    input="Generate a diagram showing a CI/CD pipeline with build, test, and deploy stages.",
    tools=[{"type": "image_generation"}],
)

# Image bytes live in image_generation_call items
for item in response.output:
    if item.type == "image_generation_call":
        with open("pipeline.png", "wb") as f:
            f.write(item.result)

Function Calling mit eigenen Tools

Function Calling in der Responses API ermöglicht es dem Modell, eigene Python-Funktionen aufzurufen. Jede Funktion wird als JSON-Schema im tools-Array definiert, der Aufruf ausgeführt, response.output auf function_call-Items geprüft, die Funktion ausgeführt und das Ergebnis über function_call_output zurückgegeben.

Die Responses API verwandelt Function Calling von einem 4-Schritte-Prozess in einen einzigen Round-Trip, wenn man die agentische Schleife für sich arbeiten lässt. Hier ein vollständiges Währungsumrechnungs-Beispiel:

import json
from openai import OpenAI

client = OpenAI()

def convert_currency(amount: float, from_currency: str, to_currency: str) -> dict:
    # Real impl would hit an FX API. Stubbed for the example.
    rate = 1.08 if (from_currency, to_currency) == ("USD", "EUR") else 1.0
    return {"amount": amount * rate, "currency": to_currency}

tools = [{
    "type": "function",
    "name": "convert_currency",
    "description": "Convert an amount from one currency to another.",
    "parameters": {
        "type": "object",
        "properties": {
            "amount": {"type": "number"},
            "from_currency": {"type": "string"},
            "to_currency": {"type": "string"},
        },
        "required": ["amount", "from_currency", "to_currency"],
    },
}]

# Turn 1: model decides to call our function
first = client.responses.create(
    model="gpt-5",
    input="How much is 250 USD in EUR?",
    tools=tools,
)

# Find the function_call item, run it, send the result back
for item in first.output:
    if item.type == "function_call" and item.name == "convert_currency":
        args = json.loads(item.arguments)
        result = convert_currency(**args)

        second = client.responses.create(
            model="gpt-5",
            previous_response_id=first.id,
            input=[{
                "type": "function_call_output",
                "call_id": item.call_id,
                "output": json.dumps(result),
            }],
            tools=tools,
        )
        print(second.output_text)

Das ist die vollständige Schleife. Wer neu mit diesem Muster ist: Unser Artikel zu Function-Calling-Grundlagen erläutert das konzeptionelle Modell, und unsere Übersicht der Function-Calling-Bibliotheken ist hilfreich, wenn man Schemas nicht von Hand schreiben möchte. Der tool_choice-Parameter (auf "auto", "required" oder einen bestimmten Tool-Namen gesetzt) ist der Hebel, um einen Tool-Aufruf zu erzwingen oder zu verbieten, wenn Determinismus gefragt ist.

Strukturierte Ausgaben (JSON Schema und Pydantic)

Strukturierte Ausgaben garantieren, dass das Modell JSON zurückgibt, das dem eigenen Schema entspricht. Man übergibt einen response_format={"type": "json_schema", "json_schema": {...}}-Parameter oder — mit dem Python-SDK — ein Pydantic-Modell direkt über client.responses.parse(). Das Modell wird zur Dekodierzeit eingeschränkt, nicht nur über den Prompt gesteuert.

from openai import OpenAI
from pydantic import BaseModel

client = OpenAI()

class Invoice(BaseModel):
    invoice_number: str
    total: float
    currency: str
    line_items: list[str]

response = client.responses.parse(
    model="gpt-5",
    input="Extract: Invoice #INV-2024-001 for $1,250.00 USD. Items: hosting, support, SSL cert.",
    text_format=Invoice,
)

invoice: Invoice = response.output_parsed
print(invoice.invoice_number, invoice.total, invoice.line_items)

Der Pydantic-Weg ist in 95 % der Fälle die richtige Wahl — typsicher, weniger Boilerplate, und die IDE vervollständigt das Ergebnis automatisch. Rohes JSON-Schema verwende man nur, wenn sprachübergreifendes Schema-Sharing nötig ist oder das Schema dynamisch generiert wird. Die Trade-offs erläutern wir in unserem Leitfaden zu strukturierten Ausgaben und JSON Schema und unserem Pydantic-Primer für typsichere Schemas.

State-Management: previousresponseid, Conversations API und store=true

Für leichtgewichtigen Multi-Turn-Kontext nutzt man previous_response_id, für robuste threaded Sessions die Conversations API oder man sendet die vollständige Message-History für vollständige Client-seitige Kontrolle. previous_response_id** setzt store: true voraus** und persistiert nur für gecachte Responses; bei nicht auflösbarer ID auf vollständige History zurückfallen.

Hier ein Zwei-Turn-Beispiel mit previous_response_id:

from openai import OpenAI

client = OpenAI()

# Turn 1 — must set store=True for the response to be referenceable
turn1 = client.responses.create(
    model="gpt-5",
    input="My name is Mert and I'm building a weather agent.",
    store=True,
)

# Turn 2 — reference turn 1 by ID; the model "remembers" the name
turn2 = client.responses.create(
    model="gpt-5",
    previous_response_id=turn1.id,
    input="What was my name again?",
    store=True,
)

print(turn2.output_text)  # "Your name is Mert..."

Wer store: true vergisst, bekommt eine previous_response_id, die ins Leere zeigt — das Modell startet jeden Turn bei null. Die API wirft keinen Fehler, sie verliert still jeden Kontext. Wir haben daran eine Stunde verloren. Standard-Retention sind 30 Tage; wer länger braucht, steigt auf die Conversations API um, die explizite Thread-Lifecycle-Kontrolle bietet.

Wann lohnt der Wechsel zur Conversations API? Wenn man mehrere Nutzer in einer App hat, wenn Threads eine einzelne Session überleben, oder wenn man serverseitiges Bearbeiten und Branching von Messages braucht. Für einen einfachen Chatbot reicht previous_response_id.

Migration von Chat Completions zur Responses API

Die Migration von Chat Completions zur Responses API umfasst drei Schritte: /v1/chat/completions durch /v1/responses ersetzen, messages durch input ersetzen und Tool-Schemas auf das neue Format aktualisieren. Function Calling und multimodale Eingaben erfordern leicht angepasste Behandlung. OpenAI stellt ein offizielles Migrations-Pack auf GitHub bereit.

Schritt 1 — Endpunkt wechseln:

# Before (Chat Completions)
response = client.chat.completions.create(
    model="gpt-4.1",
    messages=[{"role": "user", "content": "Hello"}],
)
text = response.choices[0].message.content

# After (Responses)
response = client.responses.create(
    model="gpt-5",
    input="Hello",
)
text = response.output_text

Schritt 2 — messages → input umbenennen:

# Before
client.chat.completions.create(
    model="gpt-4.1",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Summarize this PDF."},
    ],
)

# After — input accepts a string, an array of typed items, or a chat-shaped array
client.responses.create(
    model="gpt-5",
    instructions="You are a helpful assistant.",   # system → instructions
    input="Summarize this PDF.",
)

Schritt 3 — Tool-Schemas aktualisieren:

# Before (Chat Completions tool format)
tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Get current weather",
        "parameters": {"type": "object", "properties": {"city": {"type": "string"}}},
    },
}]

# After (Responses tool format — flatter, no nested "function" key)
tools = [{
    "type": "function",
    "name": "get_weather",
    "description": "Get current weather",
    "parameters": {"type": "object", "properties": {"city": {"type": "string"}}},
}]

Das war's. Traffic schrittweise mit einem Feature-Flag umstellen — den Chat-Completions-Code-Pfad hinter derselben Schnittstelle eine oder zwei Wochen aktiv lassen, beide Response-Formen nebeneinander loggen und erst bei belegter Parität auf 100 % umschalten. Das Migrations-Pack im openai-cookbook-Repo enthält ein ausführlicheres Adapter-Muster als Referenz.

MCP und Remote-MCP-Server mit der Responses API

Die Responses API unterstützt Remote-MCP-Server (Model Context Protocol) als Tool-Typ. Man fügt einen Eintrag wie {"type": "mcp", "server_url": "https://mcp.example.com", "server_label": "..."} zum tools-Array hinzu. Das Modell entdeckt den Tool-Katalog des MCP-Servers und ruft ihn wie built-in Tools auf.

Wer MCP noch nicht kennt, hier der 30-Sekunden-Einstieg: Es ist ein offenes Protokoll, das es jedem Dienst ermöglicht, seine API als Tool-Katalog zu exponieren, den das Modell aufrufen kann. Shopify, Stripe, GitHub und eine wachsende Liste von Anbietern betreiben öffentliche MCP-Endpunkte. Unser Model Context Protocol (MCP)-Deep-Dive deckt das Protokoll selbst ab.

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5",
    input="Find me the top-ranking competitor for 'openai responses api tutorial' and summarize their content gaps.",
    tools=[{
        "type": "mcp",
        "server_url": "https://mcp.semrush.com",
        "server_label": "semrush",
        "require_approval": "never",   # set to "always" in production
    }],
)
print(response.output_text)

MCP-Server wie jede Drittanbieter-API behandeln. require_approval: "never" ist für Prototypen in Ordnung; in der Produktion empfiehlt sich "always" (oder eine Tool-Allowlist), damit ein kompromittierter MCP-Server keine Daten unbemerkt exfiltrieren kann. Den Tool-Katalog des Servers vor der Nutzung im Agenten prüfen.

Preise, Rate Limits und Produktions-Fallstricke

Die Preise der Responses API entsprechen bei Token-Kosten Chat Completions (Prompt + Completion), mit Aufschlägen pro Aufruf bei built-in Tools (web_search, file_search). Rate Limits folgen dem bestehenden OpenAI-Tier. Häufige Produktions-Fallstricke sind store: true-Retention-Defaults, transiente 429-Fehler bei Burst-Traffic und verzögertes Feature-Rollout in der Azure-Variante.

Preise ändern sich — immer auf der OpenAI-Preisseite vor dem Deployment verifizieren.

Für die Fehlerbehandlung empfiehlt sich, Aufrufe in try/except openai.RateLimitError und try/except openai.APIStatusError zu kapseln, mit exponentiellem Backoff über tenacity:

from openai import OpenAI, RateLimitError, APIStatusError
from tenacity import retry, retry_if_exception_type, stop_after_attempt, wait_exponential

client = OpenAI()

@retry(
    retry=retry_if_exception_type((RateLimitError, APIStatusError)),
    wait=wait_exponential(multiplier=1, min=2, max=30),
    stop=stop_after_attempt(5),
    reraise=True,
)
def safe_create(prompt: str):
    return client.responses.create(model="gpt-5", input=prompt)

print(safe_create("Hello").output_text)

Wir haben bei einem Burst von 20 parallelen Requests in unserer Staging-Umgebung einen transienten 429-Fehler erlebt — tenacity mit exponentiellem Backoff hat das sauber gelöst. Der geloggte Fehlerstring war openai.RateLimitError: Error code: 429 - {'error': {'message': 'Rate limit reached for gpt-5 in organization org-... on requests per min (RPM)'}}. Einmal gelesen, Retry-Decorator greift danach automatisch.

Hinweis zur Azure-Variante: Azure OpenAI exponiert die Responses API, hinkt aber den Rollouts von OpenAI um 4–8 Wochen hinterher. Stand April 2026 ist die MCP-Unterstützung auf Azure nur als Preview verfügbar — vor dem Produktions-Deployment die Microsoft-Learn-Dokumentation zur Azure OpenAI Responses API prüfen.

Gateway-Kompatibilität: Wer OpenAI über den LiteLLM-Proxy proxied, findet dort seit 2026 Responses-API-Unterstützung. Die meisten anderen Gateways folgen nach. Und für Produktions-Rollouts sollte man KI-Observability und Logging eingerichtet haben, bevor man Traffic umschaltet — Responses-API-Events sind reichhaltiger als Chat-Completions-Events, und man will jeden Tool-Call geloggt haben.

Wann sollte man die Responses API nicht verwenden?

Die Responses API ist die falsche Wahl für latenzarmes Realtime-Audio (Realtime API verwenden), Embedding-Generierung (Embeddings API verwenden) und Fine-Tuning-Workflows. Auf Chat Completions bleiben, wenn der eigene Gateway/Proxy Responses noch nicht unterstützt (die meisten tun es über LiteLLM seit 2026).

Einige weitere ehrliche Disqualifikationsgründe:

• Realtime-Voice-Agenten — Die Realtime API nutzt WebSockets und ist für sub-sekündige Turn-Taking-Latenz gebaut. Responses-API-Streaming ist HTTP SSE; für Voice wirkt das träge.
• Reine Embeddings-Pipelines — client.embeddings.create() ist günstiger, schneller und das, was jede Vektor-Datenbank-Integration erwartet.
• Fine-Tuning — Training und Deployment von Fine-Tunes erfolgt über die Fine-Tuning API; man kann sie dann über Responses aufrufen, aber das Training selbst ist kein Responses-Workflow.
• Batch-API-Jobs — Wer nachts eine Million Prompts zu 50 % Rabatt verarbeitet, gewinnt mit der Batch API beim Preis.
• Eingeschlossene Chat-Completions-Semantik — Wenn Eval-Harness, Observability und Prompt-Bibliothek alle chat.completions.choices[0].message.content voraussetzen, sind die Migrationskosten real. Nicht migrieren, nur weil es neuer ist.

Wer mit Chat Completions zufrieden ist und keine Agenten baut, zahlt einen nicht kostenlosen Migrationspreis — das Q2-Sprint braucht das vielleicht nicht. Neuer bedeutet nicht besser-für-einen — die Responses API ist das richtige Primitive für Agenten, nicht für jeden OpenAI-Workload.

Häufig gestellte Fragen

Was ist die OpenAI Responses API?

Die OpenAI Responses API ist ein unified Primitive, das im März 2025 eingeführt wurde und die Einfachheit von Chat Completions mit den Tool-Fähigkeiten der Assistants API kombiniert. Sie unterstützt Text- und Bildeingaben, fünf built-in Tools, Function Calling, strukturierte Ausgaben, Streaming und stateful Konversationen über previous_response_id.

Wann wurde die OpenAI Responses API veröffentlicht?

OpenAI hat die Responses API am 11. März 2025 zusammen mit der übergreifenden Ankündigung „New tools for building agents" vorgestellt. Die API ist seit dem Launch allgemein verfügbar; die Conversations API, MCP-Unterstützung und das image_generation-Tool wurden in inkrementellen Updates im Laufe von 2025 und Anfang 2026 hinzugefügt.

Ist die OpenAI Responses API stateful?

Ja — optional. Mit previous_response_id plus store: true trägt das Modell Kontext über Aufrufe hinweg, ohne dass man die vollständige History senden muss. Für längere Threads bietet die Conversations API explizite Thread-Lifecycle-Verwaltung. Man kann auch stateless bleiben und jeden Turn die vollständige History senden, wie bei Chat Completions.

Was ist der Unterschied zwischen der Responses API und Chat Completions?

Die Responses API ist eine Obermenge von Chat Completions. Jedes Chat-Completions-Feature funktioniert in Responses, zuzüglich built-in Tools (web_search, file_search usw.), Statefulness über previous_response_id und der agentischen Schleife als First-Class-Konzept. OpenAI empfiehlt Responses ab 2026 für alle neuen Projekte.

Ist die Chat Completions API deprecated?

Nein. Stand April 2026 ist Chat Completions nicht deprecated — sie wird vollständig unterstützt. OpenAI empfiehlt Responses für neue Projekte, und die meisten Agent-Tutorials setzen Responses voraus. Chat Completions ist jetzt das Legacy-Primitive: stabil, aber nicht mehr der Ort, an dem neue Features zuerst landen.

Welche OpenAI-Modelle unterstützen die Responses API?

GPT-5, gpt-5-mini, gpt-4.1 und die o-series-Reasoning-Modelle unterstützen alle die Responses API. Die o-series fügt den reasoning_effort-Parameter (low, medium, high) für Extended-Thinking-Workloads hinzu. Image-Generierung wird unter der Haube über gpt-image-1 geroutet, wenn man das image_generation-Tool aktiviert.

Wie migriert man von Chat Completions zur Responses API?

Drei Schritte: client.chat.completions.create() auf client.responses.create() umstellen, das messages-Array durch input ersetzen (und System-Prompts nach instructions verschieben), und Tool-Schemas flacher gestalten (den geschachtelten function-Key entfernen). OpenAIs Migrations-Pack auf GitHub enthält vollständige Adapter-Beispiele.

Unterstützt die Responses API Streaming?

Ja. stream=True an client.responses.create() übergeben (oder client.responses.stream() als Context Manager verwenden) und über die typisierten Server-Sent Events iterieren. Die relevanten Token-Stream-Events sind response.output_text.delta für Content und response.completed für die finale Payload. Async-Streaming funktioniert über AsyncOpenAI.

Kann ich die Responses API auf Azure verwenden?

Ja. Azure OpenAI exponiert die Responses API, aber Feature-Parität hinkt den direkten OpenAI-Rollouts um 4–8 Wochen hinterher. Stand April 2026 ist die MCP-Unterstützung auf Azure in der Preview. Vor dem Produktions-Deployment Microsoft Learn auf aktuelle Azure-spezifische Besonderheiten prüfen.

Funktioniert die Responses API mit MCP-Servern?

Ja — Remote-MCP-Server (Model Context Protocol) sind ein First-Class-Tool-Typ. {"type": "mcp", "server_url": "...", "server_label": "..."} zum tools-Array hinzufügen, und das Modell entdeckt und ruft den Tool-Katalog des Servers wie built-in Tools auf. In der Produktion require_approval: "always" aus Sicherheitsgründen setzen.

Fazit

Sie haben jetzt das vollständige Bild der Responses API: wie sie sich von Chat Completions unterscheidet, wie man den ersten Aufruf absetzt, wie man built-in Tools einbindet und wie man ein bestehendes Chat-Completions-Projekt in drei Schritten migriert. Ein paar Erkenntnisse zum Festhalten:

• Erst bauen, dann optimieren. Mit dem Hello-World-Beispiel beginnen, ein built-in Tool hinzufügen, dann State mit previous_response_id ergänzen.
• Schrittweise migrieren. Feature-Flag einsetzen, beide Response-Formen loggen, erst bei verifizierter Parität auf 100 % umschalten.
• MCP-Integrationen aufbauen. Das ist die Frontier von 2026 — die meisten Anbieter eilen gerade dazu, MCP-Endpunkte zu exponieren, und die Responses API ist der sauberste Weg, sie zu konsumieren.

Bei Techsy helfen wir Teams dabei, OpenAI-Integrationen auf Produktionsniveau umzusetzen — einschließlich Responses-API-Rollouts und Chat-Completions-Migrationen. Jetzt kostenloses Erstgespräch vereinbaren.

Vom Techsy-Redaktionsteam — Produktionsingenieure, die seit 2024 OpenAI-Integrationen ausliefern. Zuletzt aktualisiert: 25. April 2026.