GPT Realtime API Preise: Sprechen kostet 4x so viel wie Zuhören

Ein Sprachgespräch über die Realtime API von OpenAI kostet $0.0192 pro Minute, solange der Nutzer spricht, und $0.0768 pro Minute, während das Modell antwortet. Sprechen ist damit exakt viermal so teuer wie Zuhören. Dieses Verhältnis erklärt den Großteil der Kosten einer Sprachsitzung. Vorab noch eine begriffliche Klarstellung: „GPT Live“ ist die Funktion für Endkunden in ChatGPT und bietet keine API. Die zugrunde liegenden API-Produkte heißen gpt-realtime-2.1 und gpt-realtime-2.1-mini. Um diese beiden Modelle geht es hier.

TL;DR

• gpt-realtime-2.1 berechnet exakt 1 Audio-Token je 100 ms Nutzersprache und 1 je 50 ms Modellsprache: $0.0192 pro Minute fürs Zuhören und $0.0768 pro Minute fürs Sprechen.
• Sechzig Sekunden Stille mit serverseitigem VAD erzeugten keine abrechenbaren Input-Token.
• Bis Turn 30 wurden automatisch 93 % des Inputs gecacht. Das Löschen eines einzigen Eintrags aus dem Verlauf verdreifachte den zum Vollpreis abgerechneten Input für einen Turn.
• Beim Abbruch einer langen gesprochenen Antwort nach 2 Sekunden wurden 4 Sekunden Audio abgerechnet.
• gpt-realtime-2.1-mini verwendet dieselbe Abrechnungslogik, die Audiopreise sind aber 3,2-mal niedriger.

Alle Zahlen stammen aus instrumentierten WebSocket-Sitzungen, die wir am 2026-07-19 mit beiden Modellen ausgeführt haben. Dabei wurde jedes Server-Event protokolliert. Beide Modelle sind am /v1/realtime-Endpoint des Synthorai-Gateways verfügbar, über den auch diese Sitzungen liefen. Protokoll und Abrechnung entsprechen einer direkten Verbindung zu OpenAI. Der Test-Harness besteht aus einer einzigen Python-Datei, die ausschließlich die Standardbibliothek verwendet. Jede der folgenden Zahlen lässt sich auf einen unverarbeiteten Usage-Eintrag aus response.done zurückführen.

Wie stellt man eine Verbindung zur Realtime API her?

Anders als die Text-APIs arbeitet Realtime nicht nach dem Request-Response-Prinzip über HTTP. Pro Sitzung wird eine WebSocket-Verbindung geöffnet, über die Client und Server JSON-Events austauschen. Der Client streamt das Mikrofonsignal zum Server, der Server streamt die gesprochene Antwort zurück. Das gesamte Gespräch läuft über dieselbe Verbindung.

import websocket, json

ws = websocket.create_connection(
    "wss://synthorai.io/v1/realtime?model=gpt-realtime-2.1",
    header=["Authorization: Bearer sk-..."])

ws.send(json.dumps({"type": "session.update", "session": {
    "type": "realtime", "output_modalities": ["audio"],
    "audio": {"input": {"format": {"type": "audio/pcm", "rate": 24000}}}}}))

# stream mic audio as base64 chunks: {"type": "input_audio_buffer.append", ...}
# then either let server VAD end the turn, or commit and ask for an answer:
ws.send(json.dumps({"type": "response.create"}))
# read events until "response.done": billing usage rides on that event

Für die Abrechnung sind folgende Schritte im Sitzungsablauf relevant: session.update legt Anweisungen, Stimme, Tools und Turn-Erkennung fest. Daraus entsteht der cachefähige Präfix. Mit input_audio_buffer.append / commit wird Nutzeraudio hinzugefügt, response.create löst eine Antwort aus und jedes response.done enthält die vollständige Usage-Aufschlüsselung dieser Antwort. Ein Hinweis zur API-Version: Die GA API verwendet output_modalities sowie eine verschachtelte Konfiguration unter audio.input/audio.output. Das aus der Beta bekannte Feld response.modalities wird mit unknown_parameter abgelehnt.

Wie viel kostet GPT Realtime pro Minute?

Die offiziellen Umrechnungsraten stimmen exakt auf Token-Ebene: Ein 30.0 Sekunden langer Clip wurde mit 300 Input-Audio-Token abgerechnet, also 1 je 100 ms. Eine gesprochene Antwort von 4.5 Sekunden erzeugte 90 Output-Audio-Token, also 1 je 50 ms. Aus den Tokenpreisen ergeben sich damit folgende Minutenpreise:

Zwei Kostenpunkte fehlen in der Tabelle. Erstens fallen bei einer gesprochenen Antwort zusätzlich Text-Output-Kosten an: für das Transkript und die Reasoning-Token. gpt-realtime-2.1 verwendet Reasoning; output_token_details.reasoning_tokens war in jedem Testlauf größer als null. Bei unserer kurzen Testantwort kamen dadurch zusätzlich etwa 24 % der Audiokosten hinzu, abgerechnet zum Textpreis von $24/M.

Zweitens bildet die Transkription einen eigenen Abrechnungskanal. Der Usage-Eintrag lautet {"type": "duration", "seconds": 30}: Die Abrechnung erfolgt unabhängig von Token nach Dauer zu $0.017 pro Minute. Das Transkript wird nicht Teil des Modell-Inputs. Das Aktivieren dieser einen Option verdoppelt bei 2.1 ungefähr die Input-Kosten und vervierfacht sie bei mini nahezu. Sie sollte daher nur aktiviert werden, wenn Compliance- oder Produktanforderungen den Text tatsächlich benötigen.

Kosten Stille, Unterbrechungen oder Tool-Aufrufe etwas?

Stille kostet nichts. Wir haben bei aktiviertem serverseitigem VAD 60 Sekunden Stille in eine Sitzung gestreamt und anschließend eine Frage gestellt. Die Usage-Daten waren bytegenau identisch mit denen einer Kontrollsitzung, die kein Audio gesendet hatte. VAD committet nur Audio, das als Sprache erkannt wird. Wartemusik, das Ausfüllen eines Formulars durch einen Kunden oder eine offene, inaktive Leitung erzeugen daher keine Input-Token. Echte Hintergrundgeräusche können VAD allerdings auslösen. Reine Stille markiert die Untergrenze, ist aber keine Garantie für laute Anrufumgebungen.

Bei Unterbrechungen wird bis zum erreichten Generierungsstand abgerechnet, nicht bis zu dem Punkt, den der Nutzer gehört hat. Der noch nicht generierte Rest kostet nichts. Wir ließen das Modell langsam bis vierzig zählen und brachen nach 2.0 Sekunden Wiedergabe ab. Abgerechnet wurden 81 Audio-Token beziehungsweise 4.0 Sekunden. Die zusätzlichen 2 Sekunden entstanden, weil die Generierung der Wiedergabe vorauslief, bevor response.cancel eintraf. Im selben Test wurden bei mini 6.3 Sekunden abgerechnet, da das kleinere Modell weiter als in Echtzeit vorgeneriert. Für die Praxis gilt: Sobald der Client eine Unterbrechung durch den Nutzer erkennt, muss er sofort response.cancel senden. Bis zum Eintreffen des Abbruchs läuft die Abrechnung weiter.

Tool-Aufrufe verursachen keine zusätzlichen Auswirkungen auf die Abrechnung. Eine Sitzung mit einer Funktionsdefinition gab den Aufruf aus, übernahm das eingespeiste Ergebnis und wies in der direkt folgenden Antwort 99 % des Inputs zum Cachepreis aus. Function-Call-Einträge und deren Ergebnisse werden wie jeder andere an den Verlauf angehängte Inhalt gecacht. Die Tool-Definitionen liegen im statischen Präfix, der ab Turn 2 gecacht wird.

Wie hält Caching lange Sitzungen bezahlbar?

Die Realtime API liest für jede Antwort das gesamte Gespräch erneut als Input ein. Der Input pro Turn wächst deshalb linear mit der Sitzungsdauer. Bezahlbar bleibt das durch automatisches Prefix Caching: Gecachtes Audio kostet bei erneuter Verarbeitung $0.40/M statt $32/M, also 1/80 des Vollpreises. In unserer Sitzung mit 30 Turns stieg der Cacheanteil kontinuierlich an und erreichte in Turn 30 insgesamt 93 % des Inputs:

Die Aufteilung nach Cache-Status wird in jedem response.done gemeldet:

"usage": {
  "input_tokens": 891,
  "input_token_details": {
    "text_tokens": 891, "audio_tokens": 0,
    "cached_tokens": 832,
    "cached_tokens_details": { "text_tokens": 832, "audio_tokens": 0 }
  }
}

Unsere Messungen zeigen drei Eigenschaften, die nicht in der offiziellen Dokumentation stehen: Caching greift ab ungefähr 128 Token Präfixlänge, während das dokumentierte Minimum der Text-API bei 1,024 liegt. Der Cache wächst in Blöcken von 64 Token. Außerdem lässt sich der statische Präfix sitzungsübergreifend mit demselben Key wiederverwenden. Letzteres ist wegen des Sitzungslimits von 60 Minuten relevant: Bereits im ersten Turn einer neuen Sitzung wurden die Anweisungen zum Cachepreis abgerechnet. Bei einer Sitzungsrotation wird also nur das erneute Einlesen des Gesprächsverlaufs zum Vollpreis berechnet, nicht der System-Prompt.

Das Bearbeiten des Verlaufs ist die einzige Möglichkeit, diesen Rabatt zu verlieren. Wir haben die genaue Auswirkung gemessen. Nachdem wir mitten in der Sitzung einen frühen Eintrag gelöscht hatten, brach der Cacheanteil für genau einen Turn ein und baute sich danach wieder auf:

Eine weitere Entlastung zeigte sich in den Messungen: Die gesprochenen Antworten des Modells gehen bei späteren Turns als Text und nicht als Audio in den Input ein. In einem Sprachgespräch mit 8 Turns wuchs der Audio-Input pro Turn exakt um die Größe des jeweiligen Nutzerclips. Die Antwort des Assistenten tauchte dagegen als Transkript-Token zu $4/M wieder auf. Beim teuren, kumulativ wachsenden Anteil zählt also nur das Nutzeraudio.

Daraus ergibt sich eine kurze Praxisempfehlung: Den Verlauf nur ergänzen, nicht nachträglich bearbeiten. Anweisungen und Tool-Definitionen müssen innerhalb einer Sitzung und sitzungsübergreifend bytegenau identisch bleiben. Dynamische Inhalte gehören in die jeweils neueste Nutzernachricht, nicht in den Präfix. Falls der Verlauf gekürzt werden muss, sollte das selten und in größeren Schritten geschehen, statt nach jedem Turn. Die allgemeinen Mechanismen bei verschiedenen Providern erklären unser Leitfaden zu Prompt Caching und unsere Untersuchung der gemessenen Cache-Mindestgrößen.

gpt-realtime-2.1 oder mini: Welches Modell ist die richtige Wahl?

Die Abrechnungslogik ist bei beiden Modellen identisch: gleiche Umrechnungsraten, gleiche Cache-Quantisierung in Blöcken von 64 Token und gleich verlaufende Kurven. Unterschiede gibt es beim Preis und beim Verhalten:

Zwei Punkte fallen auf. Bei gecachten Wiederholungen schrumpft der Preisunterschied stark auf $0.40 gegenüber $0.30. In einer langen Sitzung mit hohem Cacheanteil wird der Kostenvorteil von mini dadurch etwas kleiner, auch wenn neue Token die Gesamtkosten weiterhin dominieren. Bei Unterbrechungen wirkt sich die Geschwindigkeit von mini nachteilig aus: Das Modell generiert weiter im Voraus, sodass bei jeder Unterbrechung ungefähr doppelt so viel bereits erzeugtes Audio verworfen wird. In Dollar blieb mini trotzdem in jedem gemessenen Szenario günstiger. Der Preisunterschied von Faktor 3,2 gleicht beide Effekte aus.

Für Assistenten mit kurzen Befehlen, IVR und Supportsysteme mit hoher Parallelität ist mini die Standardwahl. 2.1 eignet sich besser, wenn eine Sitzung komplexe Tool-Orchestrierung oder mehrstufiges Reasoning erfordert. OpenAI positioniert es als Spitzenmodell für Instruction Following; unser Kosten-Harness bewertet diese Qualität bewusst nicht.

Was kosten typische Sprachszenarien tatsächlich?

Bei Szenarien mit häufigen Unterbrechungen muss der Generierungsvorlauf in die Kosten pro Interaktion einfließen: Jede Unterbrechung kostet das vom Nutzer gehörte Audio plus einige Sekunden vorgenerierten Vorlauf.

FAQ

Ist GPT Live dasselbe wie die GPT Realtime API?

Nein. GPT Live ist die Sprachfunktion in den ChatGPT-Apps und hat weder eine eigene API noch eine eigene Preisseite. Für eine vergleichbare programmatische Nutzung stehen die Realtime-API-Modelle gpt-realtime-2.1 und gpt-realtime-2.1-mini bereit. Deren Preise haben wir hier gemessen.

Wie lange kann eine Realtime-Sitzung laufen?

Das harte Limit liegt bei sechzig Minuten. Eine geschlossene Sitzung kann nicht fortgesetzt werden. Der Textverlauf lässt sich in eine neue Sitzung einspeisen und wird dabei einmal zum Vollpreis abgerechnet, während der statische Prompt gecacht bleibt. Assistentenaudio kann dagegen nicht erneut eingespielt werden. Sprachprodukte mit langen Laufzeiten brauchen deshalb vor Minute 60 eine Strategie für die Sitzungsrotation.

Gibt es zwischen Turns einen Idle-Timeout?

Ein Idle-Timeout ist nicht dokumentiert. Bei aktiviertem serverseitigem VAD erzeugte Stille in unserer Messung keine abrechenbaren Token. Eine Verbindung zwischen Interaktionen offenzuhalten kostet daher außer der Verbindung selbst nichts. Bei Produkten mit sporadischer Nutzung ist eine lange Sitzung günstiger und schneller als eine Neuverbindung pro Interaktion, denn der Verbindungsaufbau dauerte in unseren Messungen etwa 2.5 Sekunden.

Welches Audioformat erwartet die API?

Standardmäßig verwendet die API PCM16 mit 24 kHz und einem Kanal, sowohl für Input als auch für Output. Konfiguriert wird das Format in session.update über audio.input.format und audio.output.format. Das Format hat keinen Einfluss auf die Abrechnung: Die Zahl der Audio-Token hängt ausschließlich von der Dauer ab, mit 1 Token je 100 ms Input und 1 je 50 ms Output.

Die technischen Muster für den Umgang mit dem 60-Minuten-Limit - Sitzungsrotation, Übergabe des Verlaufs und die Frage, welche Daten eine Neuverbindung überstehen - sind ein eigenes Thema. Die hier ermittelten Zahlen bilden die Grundlage für diese Berechnungen. Wie sich abgerechnete Token in der Text-API über verschiedene Modellfamilien hinweg zusammensetzen, erklärt der ergänzende Beitrag zur Anatomie der Token-Nutzung.

← Zurück zum Blog