GPT Realtime API – Preise: Sprechen kostet das 4-Fache von Zuhören (gemessen)

Ein Sprachdialog über die Realtime API von OpenAI kostet $0,0192 pro Minute, während der Nutzer spricht, und $0,0768 pro Minute, während das Modell antwortet. Sprechen kostet exakt das Vierfache von Zuhören, und dieses eine Verhältnis erklärt den Großteil der Rechnung einer Sprachsitzung. Eine Anmerkung zur Benennung vorab: “GPT Live” ist das Consumer-Feature in ChatGPT und hat keine API. Die dahinterliegenden API-Produkte sind gpt-realtime-2.1 und gpt-realtime-2.1-mini, und die misst dieser Beitrag.

TL;DR

• gpt-realtime-2.1 berechnet exakt 1 Audio-Token pro 100 ms Nutzersprache und 1 pro 50 ms Modellsprache: $0,0192 pro Minute fürs Zuhören, $0,0768 pro Minute fürs Sprechen.
• Sechzig Sekunden Stille unter Server-VAD wurden mit null Input-Tokens berechnet.
• Automatisches Caching deckte bis Turn 30 rund 93 % des Inputs ab; das Löschen eines History-Eintrags verdreifachte für einen Turn den zum vollen Preis berechneten Input.
• Das Abbrechen einer langen gesprochenen Antwort nach 2 Sekunden wurde mit 4 Sekunden Audio berechnet.
• gpt-realtime-2.1-mini hat dieselbe Abrechnungsmechanik bei 3,2-fach niedrigeren Audio-Preisen.

Alle Zahlen hier stammen aus instrumentierten WebSocket-Sitzungen, die am 19.07.2026 gegen beide Modelle liefen, wobei jedes Server-Event protokolliert wurde. Beide Modelle laufen am Endpoint /v1/realtime des Synthorai-Gateways, wo diese Sitzungen abliefen; Protokoll und Abrechnung sind identisch mit einem direkten Zugriff auf OpenAI. Der Harness ist eine einzige Python-Datei nur mit der Standardbibliothek, und jede Zahl unten lässt sich auf einen rohen response.done-Usage-Record zurückführen.

Wie verbindet man sich mit der Realtime API?

Anders als bei den Text-APIs läuft Realtime nicht als Request/Response über HTTP. Man öffnet einen WebSocket pro Sitzung und tauscht darüber JSON-Events aus: Der Client streamt das Mikrofon-Audio hinein, der Server streamt gesprochenes Audio zurück, und eine Verbindung trägt das gesamte Gespräch.

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

Der für die Abrechnung relevante Sitzungslebenszyklus: session.update setzt Instructions, Voice, Tools und Turn-Detection (das wird zum cachebaren Präfix); input_audio_buffer.append / commit fügen Nutzer-Audio hinzu; response.create löst eine Antwort aus; und jedes response.done trägt die vollständige Usage-Aufschlüsselung für diese Antwort. Eine Anmerkung zum Dialekt: Die GA-API nutzt output_modalities und eine verschachtelte audio.input/audio.output-Konfiguration; das Feld response.modalities aus der Beta-Zeit wird mit unknown_parameter abgelehnt.

Was kostet GPT Realtime pro Minute?

Die offiziellen Umrechnungsraten stimmen bis aufs Token: Ein 30,0-Sekunden-Clip wurde mit 300 Input-Audio-Tokens abgerechnet (1 pro 100 ms), eine 4,5-Sekunden-Sprachantwort mit 90 Output-Audio-Tokens (1 pro 50 ms). Damit lässt sich die Preisliste pro Token in Kosten pro Minute umrechnen:

Zwei Kostenpunkte stehen nicht in der Tabelle. Erstens rechnet eine Sprachantwort auch Text-Output ab: das Transkript plus Reasoning-Tokens (gpt-realtime-2.1 denkt tatsächlich mit; output_token_details.reasoning_tokens kam bei jedem Durchlauf ungleich null zurück). Bei unserer kurzen Testantwort kamen dadurch rund 24 % oben auf die Audio-Tokens, abgerechnet zum Textpreis von $24/M.

Zweitens ist das Transkriptions-Add-on ein eigener Abrechnungsbereich. Sein Usage-Record liest sich als {"type": "duration", "seconds": 30}: nach Dauer abgerechnet zu $0.017 pro Minute, unabhängig von Tokens, und das Transkript landet nie im Input des Modells. Setzt man dieses eine Flag, verdoppeln sich die Input-Kosten bei 2.1 ungefähr und vervierfachen sich bei mini fast. Aktiviere es also nur dort, wo eine Compliance- oder Produktanforderung den Text wirklich braucht.

Kostet Stille, Unterbrechung oder Tool-Calling etwas?

Stille kostet nichts. Wir haben 60 Sekunden Stille in eine Session mit aktivierter Server-VAD gestreamt und danach eine Frage gestellt: Die Usage war Byte für Byte identisch mit einer Kontroll-Session, die nie Audio gesendet hat. VAD committet nur Audio, das es als Sprache erkennt, also berechnen Wartemusik, ein Kunde, der ein Formular vorliest, oder eine offene Leerleitung null Input-Tokens. Der Haken: Echtes Hintergrundrauschen kann die VAD auslösen. Reine Stille ist die Untergrenze, keine Garantie für einen lauten Call.

Unterbrechungen werden bis zur Generierungsgrenze abgerechnet, nicht bis zu dem, was der User hört, und nie für den nicht generierten Rest. Wir haben ein langsames gesprochenes Zählen bis vierzig angefordert und nach 2,0 Sekunden Hörzeit abgebrochen: Die Rechnung lag bei 81 Audio-Tokens, also 4,0 Sekunden. Die 2 Sekunden Überhang zeigen, wie weit die Generierung der Wiedergabe vorausgelaufen war, bevor response.cancel ankam. Bei mini rechnete dasselbe Experiment 6,3 Sekunden ab, weil das kleinere Modell weiter der Echtzeit vorauseilt. Die praktische Regel: Sende response.cancel in dem Moment, in dem dein Client ein Barge-in erkennt, denn der Zähler läuft, bis der Cancel eintrifft.

Tool-Calls sind abrechnungsneutral. Eine Session mit einer Funktionsdefinition setzte den Call ab, nahm das eingespeiste Ergebnis entgegen, und die direkt darauffolgende Response zeigte 99 % ihres Inputs zum Cached-Preis abgerechnet. Function-Call-Items und ihre Outputs cachen wie jede andere angehängte History, und die Tool-Definitionen selbst liegen im statischen Prefix, der ab Turn 2 gecacht wird.

Wie halten Caches lange Sessions bezahlbar?

Die Realtime API liest bei jeder Antwort die komplette Konversation erneut als Input ein. Der Input pro Turn wächst also linear mit der Länge der Session. Bezahlbar bleibt das dank automatischem Prefix-Caching: Gecachtes Audio wird zu 0,40 $/M statt 32 $/M abgerechnet, also zu einem Achtzigstel des vollen Preises. In unserer Session über 30 Turns stieg der gecachte Anteil kontinuierlich an und lag bei Turn 30 bei 93 % des Inputs:

Die Aufteilung wird bei jedem response.done mitgeliefert:

"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 }
  }
}

Drei Details, die die offizielle Doku nicht nennt, wir aber gemessen haben: Das Caching greift schon bei etwa 128 Tokens Prefix (das dokumentierte Minimum der Text-API liegt bei 1.024), es rückt in 64-Token-Blöcken vor, und der statische Prefix lässt sich über Sessions hinweg auf demselben Key wiederverwenden. Letzteres ist wichtig wegen des 60-Minuten-Limits pro Session: Der allererste Turn einer neuen Session rechnet die Instructions bereits zum Cache-Preis ab. Bei einer Rotation zahlst du also nur für das erneute Einlesen der Konversationshistorie den vollen Preis, nicht für den System-Prompt.

Der einzige Weg, den Rabatt zu verlieren, ist das Editieren der Historie – und wir haben die genaue Strafe gemessen. Das Löschen eines frühen Items mitten in der Session ließ den gecachten Anteil für genau einen Turn einbrechen, danach baute sich der Cache wieder auf:

Noch eine gemessene Entlastung: Die gesprochenen Antworten des Modells fließen in spätere Inputs als Text zurück, nicht als Audio. In einer Voice-Konversation über 8 Turns wuchs das Input-Audio pro Turn exakt um die Clip-Größe des Users, während die Assistant-Seite als Transkript-Tokens zu 4 $/M wieder auftauchte. Der teure Teil des wachsenden Inputs ist also allein das User-Audio.

Das daraus abgeleitete Vorgehen ist kurz: Historie nur anhängen, Instructions und Tool-Definitionen über die gesamte Session (und über Sessions hinweg) byte-identisch halten, alles Dynamische in die letzte User-Message statt in den Prefix packen, und wenn gekürzt werden muss, selten und in großen Schritten kürzen statt bei jedem Turn. Zur allgemeinen Mechanik über verschiedene Provider hinweg siehe unseren Guide zum Prompt-Caching und die Studie zu den gemessenen Cache-Minimums.

gpt-realtime-2.1 oder mini: Was solltest du wählen?

Die Abrechnung funktioniert bei beiden Modellen gleich: gleiche Umrechnungssätze, gleiche 64-Token-Cache-Quantisierung, gleiche Kurvenform. Unterschiedlich sind Preis und Verhalten:

Zwei Dinge fallen auf. Beim Cached-Replay schrumpft der Preisunterschied fast auf null ($0.40 gegen $0.30). Eine stark gecachte, lange Session verringert den Vorsprung von mini also leicht, wobei frische Tokens weiterhin den Gesamtpreis bestimmen. Und mini’s Geschwindigkeit wird bei Unterbrechungen zum Nachteil: mini generiert weiter über die Wiedergabe hinaus, sodass jedes Barge-in etwa doppelt so viel bereits generiertes Audio verwirft. In Dollar gerechnet gewinnt mini trotzdem in jedem von uns gemessenen Szenario; der 3,2-fache Preisunterschied fängt beide Effekte auf.

Nimm standardmäßig mini für Assistenten mit kurzen Kommandos, IVR und Support mit hoher Parallelität. Nimm 2.1, wenn die Session komplexe Tool-Orchestrierung oder mehrstufiges Reasoning braucht; OpenAI positioniert es als Flaggschiff fürs Instruction Following, was unser Cost-Harness bewusst nicht bewertet.

Was kosten typische Voice-Szenarien wirklich?

Bei Szenarien mit vielen Unterbrechungen rechne den Barge-in-Overhang in deine Kosten pro Interaktion ein: jede Unterbrechung kostet das vom Nutzer gehörte Audio plus ein paar Sekunden generativen 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. Wer diese Erfahrung programmatisch nutzen will, greift zu den Realtime-API-Modellen gpt-realtime-2.1 und gpt-realtime-2.1-mini, deren Preise dieser Beitrag misst.

Wie lange darf eine Realtime-Session laufen?

Sechzig Minuten sind die harte Grenze, und eine geschlossene Session lässt sich nicht fortsetzen. Text-History kann man in eine neue Session zurückspielen (einmalig zum vollen Preis abgerechnet, während der statische Prompt gecacht bleibt), aber Assistant-Audio lässt sich nicht erneut abspielen. Sprachprodukte mit langer Laufzeit brauchen deshalb einen Rotationsplan vor Minute 60.

Gibt es zwischen den Turns ein Idle-Timeout?

Ein Idle-Timeout ist nicht dokumentiert, und Stille kostet bei server VAD in unserer Messung null Tokens. Eine Leitung zwischen zwei Interaktionen offen zu halten kostet also nichts außer der Verbindung selbst. Bei Produkten mit seltener Nutzung ist eine lange Session damit günstiger und schneller als eine erneute Verbindung pro Interaktion, denn der Aufbau lag gemessen bei rund 2,5 Sekunden.

Welches Audioformat erwartet die API?

PCM16 bei 24 kHz mono ist der Standard für Ein- und Ausgabe, konfiguriert über audio.input.format und audio.output.format in session.update. Die Abrechnung hängt nicht vom Format ab: Audio-Tokens richten sich allein nach der Dauer, 1 Token pro 100 ms eingehend und 1 pro 50 ms ausgehend.

Die Engineering-Muster für den Umgang mit der 60-Minuten-Grenze (Rotation, History-Übergabe, was ein Reconnect überlebt) sind ein eigenes Thema, und die Zahlen aus diesem Beitrag sind die Eingaben für diese Rechnung. Wie sich abgerechnete Tokens über die Familien hinweg in der Text-API aufschlüsseln, zeigt der Begleitartikel Anatomie der Token-Nutzung.

← Zurück zum Blog