OpenAI hat GPT-Live-1 als API für Entwicklerinnen und Entwickler freigegeben. Das Modell ist aus ChatGPT bekannt und arbeitet im sogenannten Full-Duplex-Betrieb: Es kann zuhören und sprechen, ohne dass sich beide Richtungen gegenseitig blockieren. Technisch klingt das nach einem Detail, in der Praxis entscheidet genau dieses Detail darüber, ob sich ein Sprachdialog natürlich anfühlt oder wie ein Sprechfunkgerät.

Was Full-Duplex konkret bedeutet

Klassische Sprachassistenten arbeiten in Zügen: Der Mensch spricht, das System erkennt ein Ende der Äußerung, verarbeitet, antwortet. Wer dazwischenredet, stört den Ablauf — entweder wird der Einwurf ignoriert oder er bricht die Antwort komplett ab.

Full-Duplex heißt, dass beide Kanäle dauerhaft offen sind. Das System registriert Zwischenrufe, Rückfragen und kurze Bestätigungen, während es selbst noch spricht, und kann darauf reagieren. Das Gespräch bekommt dadurch ein Timing, das dem menschlichen Wechselspiel näher kommt.

OpenAI nennt in Benchmarks einen Vorsprung von 30 Prozentpunkten gegenüber dem Vorgängermodell. Aus der Praxis liegt eine Angabe der Sprachlern-App Speak vor: 80 Prozent weniger Unterbrechungen. Beide Zahlen stammen von den beteiligten Parteien und sind entsprechend einzuordnen — die Richtung ist aber plausibel, weil genau das Unterbrechungsverhalten der Schwachpunkt bisheriger Sprachschnittstellen war.

Die Kostenseite: 0,05 Dollar pro Minute

Der Preis liegt bei 0,05 Dollar pro Gesprächsminute. Das ist kein Betrag, der bei einzelnen Dialogen ins Gewicht fällt, aber er skaliert linear mit der Nutzungsdauer — und das unterscheidet Sprach-APIs grundlegend von textbasierten Schnittstellen.

Ein Rechenbeispiel als Orientierung, bewusst grob: Ein Support-Dialog von fünf Minuten kostet an reiner Modellnutzung rund einen Viertel-Dollar. Bei tausend solchen Gesprächen im Monat entstehen Modellkosten im niedrigen dreistelligen Bereich. Das ist für einen Support-Kanal durchaus vertretbar. Für ein offenes Sprachwidget auf einer Startseite, das von jedem Besucher beliebig lange bespielt werden kann, sieht die Rechnung anders aus — dort hängt das Budget an einer Größe, die Sie nur begrenzt steuern.

Hinzu kommen Kosten, die nicht auf der Preisliste stehen: Anbindung an bestehende Systeme, Protokollierung, Testaufwand und der Betrieb einer Echtzeitverbindung, die deutlich empfindlicher ist als ein gewöhnlicher HTTP-Aufruf.

Wo Sprachbedienung im Web tatsächlich trägt

Sprache ist kein besseres Interface, sondern ein anderes. Sie gewinnt dort, wo Hände oder Augen gebunden sind, wo Tippen umständlich ist oder wo ein Vorgang von Natur aus dialogisch verläuft.

  • Telefonnaher Support: Vorqualifizierung, Statusabfragen, Terminvereinbarungen. Hier ersetzt Sprache keine bestehende Oberfläche, sondern eine Warteschleife.
  • Mobile Nutzung unterwegs: Auftragserfassung im Außendienst, Rückmeldungen von der Baustelle, Lagerabfragen mit Handschuhen an den Händen.
  • Barrierearme Zugänge: Sprachbedienung als zusätzlicher Kanal für Nutzergruppen, denen Formularbedienung schwerfällt.
  • Lern- und Trainingsszenarien: Übungsdialoge, in denen das natürliche Unterbrechen selbst Teil der Aufgabe ist — das Beispiel der Sprachlern-App zeigt in diese Richtung.

Weniger überzeugend ist Sprache dort, wo strukturierte Eingaben gefragt sind. Eine Adresse, eine Artikelnummer oder ein Datum diktiert man nicht schneller, als man sie tippt — und die Fehlerkorrektur im Sprachkanal ist mühsam. Ein Sprachinterface, das vor ein Formular geschaltet wird, macht den Vorgang in der Regel länger, nicht kürzer.

Technische Konsequenzen für die Umsetzung

Eine Full-Duplex-Verbindung verändert die Architektur einer Webanwendung an mehreren Stellen. Sie brauchen eine dauerhafte Verbindung zwischen Browser und Server, typischerweise über WebSockets oder WebRTC, und Sie brauchen serverseitig eine Stelle, die diese Verbindung hält. Klassische, zustandslose Anfrage-Antwort-Muster reichen dafür nicht.

Drei Punkte, die in der Planung erfahrungsgemäß unterschätzt werden:

  1. Session-Begrenzung: Definieren Sie früh, wie lange ein Sprachdialog maximal laufen darf und was danach passiert. Ohne harte Grenzen ist das Kostenrisiko nicht kalkulierbar.
  2. Fallback auf Text: Jede Sprachfunktion braucht einen gleichwertigen Weg ohne Mikrofon — aus Gründen der Barrierefreiheit, wegen lauter Umgebungen und für den Fall, dass der Dienst nicht erreichbar ist.
  3. Datenschutz und Protokollierung: Sprachdaten sind personenbezogen und oft besonders sensibel. Klären Sie vor der Umsetzung, was aufgezeichnet wird, wie lange es gespeichert bleibt und wie Nutzerinnen und Nutzer darüber informiert werden.

Einordnung: Prototyp vor Ausbaustufe

Die technische Hürde für natürlich wirkende Sprachdialoge ist mit dieser API spürbar gesunken. Das heißt nicht, dass jedes Portal jetzt eine Sprachbedienung braucht. Die sinnvolle Reihenfolge lautet: einen konkreten Prozess identifizieren, bei dem Sprache einen realen Umweg abkürzt, diesen Prozess als schmalen Prototyp bauen und an echten Nutzungsdaten prüfen, wie lange ein typischer Dialog dauert und wie oft er zum Ziel führt.

Erst aus diesen Zahlen ergibt sich, ob die Minutenkosten im Verhältnis zum eingesparten Aufwand stehen. Diese Rechnung fällt je nach Anwendungsfall sehr unterschiedlich aus — ein automatisierter Rückruf im Support hat eine ganz andere Wirtschaftlichkeit als ein Sprachassistent auf einer Produktseite.

Was das für Web- und Softwareprojekte bedeutet

Sprachbedienung wechselt damit von der Machbarkeitsfrage zur Architektur- und Kostenfrage. Wer sie einplant, sollte die Verbindungslogik, die Session-Begrenzung und den textbasierten Alternativweg von Anfang an im Konzept haben statt sie nachträglich anzubauen. Am tragfähigsten sind zunächst klar abgegrenzte Anwendungsfälle mit messbarem Nutzen — allgemeine Sprachassistenten auf Websites bleiben ein teures Experiment mit unklarem Ertrag.

Quellen