Prix de l'API GPT Realtime : parler coûte 4x plus qu'écouter

Une conversation vocale via l’API Realtime d’OpenAI coûte $0.0192 par minute lorsque l’utilisateur parle, et $0.0768 par minute lorsque le modèle lui répond. Parler coûte exactement quatre fois plus cher qu’écouter. Ce rapport suffit à expliquer l’essentiel de la facture d’une session vocale. Précisons d’abord les noms des produits : « GPT Live » désigne la fonctionnalité grand public de ChatGPT et n’a pas d’API. Les produits API correspondants sont gpt-realtime-2.1 et gpt-realtime-2.1-mini. Ce sont eux que nous avons mesurés.

TL;DR

• gpt-realtime-2.1 facture exactement 1 token audio par tranche de 100 ms de parole utilisateur et 1 par tranche de 50 ms de parole du modèle : $0.0192 par minute en écoute, $0.0768 par minute en parole.
• Soixante secondes de silence avec le VAD côté serveur n’ont généré aucun token d’entrée facturé.
• Au 30e tour, le cache automatique couvrait 93 % de l’entrée. La suppression d’un seul élément de l’historique a triplé le volume d’entrée facturé au tarif plein pendant un tour.
• L’annulation d’une longue réponse vocale après 2 secondes a tout de même facturé 4 secondes d’audio.
• gpt-realtime-2.1-mini suit exactement les mêmes règles de facturation, avec des tarifs audio 3.2x moins élevés.

Tous les chiffres proviennent de sessions WebSocket instrumentées, exécutées sur les deux modèles le 2026-07-19, avec journalisation de chaque événement serveur. Les deux modèles sont disponibles sur l’endpoint /v1/realtime de la gateway Synthorai, utilisé pour ces tests. Le protocole et la facturation sont identiques à ceux d’une connexion directe à OpenAI. Le banc de test tient dans un unique fichier Python qui n’utilise que la bibliothèque standard. Chaque chiffre ci-dessous provient directement d’un enregistrement d’usage brut response.done.

Comment se connecter à l’API Realtime ?

Contrairement aux API de texte, Realtime ne fonctionne pas sur un échange requête-réponse HTTP. Une session utilise une seule connexion WebSocket et échange des événements JSON. Le client envoie le flux audio du microphone, le serveur renvoie l’audio de la réponse, et toute la conversation passe par la même connexion.

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

Voici les étapes du cycle de vie qui comptent pour la facturation : session.update définit les instructions, la voix, les tools et la détection des tours de parole, qui forment le préfixe pouvant être mis en cache ; input_audio_buffer.append / commit ajoutent l’audio utilisateur ; response.create déclenche une réponse ; chaque response.done contient le détail complet de l’usage correspondant. Attention à la variante du protocole : l’API GA utilise output_modalities et une configuration imbriquée audio.input/audio.output. L’ancien champ response.modalities de la version bêta est rejeté avec unknown_parameter.

Combien coûte GPT Realtime par minute ?

Les taux de conversion officiels correspondent exactement aux tokens mesurés : un extrait de 30.0 secondes a généré 300 tokens audio d’entrée, soit 1 toutes les 100 ms. Une réponse vocale de 4.5 secondes a généré 90 tokens audio de sortie, soit 1 toutes les 50 ms. La grille tarifaire par token donne donc les coûts par minute suivants :

Deux coûts ne figurent pas dans ce tableau. D’abord, une réponse vocale facture aussi des tokens de sortie texte : la transcription et les tokens de raisonnement (gpt-realtime-2.1 raisonne effectivement ; output_token_details.reasoning_tokens était non nul à chaque exécution). Sur notre courte réponse de test, cela ajoutait environ 24 % au coût des tokens audio, au tarif texte de $24/M.

Ensuite, la transcription constitue un flux de facturation distinct. Son enregistrement d’usage contient {"type": "duration", "seconds": 30} : elle est facturée à la durée, à $0.017 par minute, indépendamment des tokens. La transcription n’entre jamais dans l’input du modèle. L’activation de cette seule option double presque le coût d’entrée sur 2.1 et le multiplie presque par quatre sur mini. Ne l’activez que si une exigence produit ou de conformité impose réellement de disposer du texte.

Le silence, les interruptions ou les appels de tools coûtent-ils quelque chose ?

Le silence ne coûte rien. Nous avons envoyé 60 secondes de silence dans une session utilisant le VAD côté serveur, puis posé une question. L’usage était identique octet pour octet à celui d’une session témoin n’ayant reçu aucun audio. Le VAD ne valide que l’audio détecté comme parole. La musique d’attente, un client qui lit un formulaire ou une ligne ouverte mais inactive ne génèrent donc aucun token d’entrée facturé. Du bruit de fond réel peut toutefois déclencher le VAD : le silence pur correspond au coût minimal, mais ne garantit pas la gratuité d’un appel bruyant.

En cas d’interruption, la facturation s’arrête là où en est la génération, pas là où en est l’écoute par l’utilisateur. La partie qui n’a pas encore été générée n’est jamais facturée. Nous avons demandé au modèle de compter lentement jusqu’à quarante, puis annulé après 2.0 secondes d’écoute. La facture comportait 81 tokens audio, soit 4.0 secondes. Ce dépassement de 2 secondes correspond à l’avance prise par la génération sur la lecture avant la réception de response.cancel. Avec mini, la même expérience a facturé 6.3 secondes, car le modèle plus petit génère davantage en avance sur le temps réel. En pratique, envoyez response.cancel dès que le client détecte que l’utilisateur reprend la parole : la facturation continue jusqu’à l’arrivée de l’annulation.

Les appels de tools n’ont aucun effet propre sur la facturation. Dans une session comportant une définition de fonction, le modèle a émis l’appel, reçu le résultat injecté, puis affiché 99 % d’entrée facturée au tarif du cache dès la réponse suivante. Les éléments d’appel de fonction et leurs résultats sont mis en cache comme tout autre élément ajouté à l’historique. Les définitions des tools font partie du préfixe statique, mis en cache à partir du deuxième tour.

Comment le cache maîtrise-t-il le coût des longues sessions ?

À chaque réponse, l’API Realtime relit l’intégralité de la conversation en entrée. Le volume d’entrée par tour augmente donc linéairement avec la durée de la session. Le cache automatique du préfixe maintient le coût sous contrôle : la relecture d’audio en cache coûte $0.40/M au lieu de $32/M, soit 1/80e du tarif plein. Dans notre session de 30 tours, la part en cache a progressé régulièrement jusqu’à atteindre 93 % de l’entrée au 30e tour :

Chaque événement response.done indique la répartition entre cache et tarif plein :

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

Nos mesures révèlent trois caractéristiques absentes de la documentation officielle : le cache s’active à partir d’environ 128 tokens de préfixe, contre un minimum documenté de 1,024 pour l’API de texte ; il progresse par blocs de 64 tokens ; le préfixe statique peut être réutilisé entre plusieurs sessions partageant la même clé. Ce dernier point compte pour la limite de 60 minutes : dès le premier tour d’une nouvelle session, les instructions étaient déjà facturées au tarif du cache. La rotation ne fait payer au tarif plein que la relecture de l’historique de conversation, pas celle du prompt système.

La modification de l’historique est le seul moyen de perdre cette réduction. Nous en avons mesuré précisément le coût. La suppression d’un ancien élément en cours de session a fait chuter la part en cache pendant exactement un tour, après quoi le cache s’est reconstruit :

Autre résultat favorable : les réponses vocales du modèle reviennent dans les entrées suivantes sous forme de texte, et non d’audio. Au cours d’une conversation vocale de 8 tours, l’audio d’entrée augmentait exactement de la taille de l’extrait utilisateur à chaque tour. Les réponses de l’assistant réapparaissaient sous forme de tokens de transcription facturés à $4/M. Seul l’audio utilisateur alimente donc la partie coûteuse de l’accumulation.

Les bonnes pratiques qui en découlent sont simples : ajoutez les éléments à l’historique sans modifier l’existant ; conservez des instructions et des définitions de tools identiques octet pour octet pendant toute la session, ainsi que d’une session à l’autre ; placez les données dynamiques dans le dernier message utilisateur plutôt que dans le préfixe ; si vous devez réduire l’historique, faites-le rarement et en une seule fois, plutôt qu’à chaque tour. Pour comprendre le fonctionnement général chez les différents fournisseurs, consultez notre guide du prompt caching et notre étude des seuils minimaux de cache mesurés.

gpt-realtime-2.1 ou mini : lequel choisir ?

Les règles de facturation sont identiques pour les deux modèles : mêmes taux de conversion, même quantification du cache par blocs de 64 tokens et mêmes courbes. Les prix et le comportement diffèrent :

Deux points méritent attention. Pour la relecture depuis le cache, l’écart de prix devient minime ($0.40 contre $0.30). Une longue session utilisant massivement le cache réduit donc légèrement l’avantage de mini, même si les nouveaux tokens restent majoritaires dans le coût total. La vitesse de mini le pénalise aussi lors des interruptions : il génère davantage en avance sur la lecture, ce qui fait perdre environ deux fois plus d’audio généré à chaque reprise de parole. En coût réel, mini reste gagnant dans tous les scénarios mesurés : l’écart tarifaire de 3.2x absorbe ces deux effets.

Choisissez mini par défaut pour les assistants à commandes courtes, les serveurs vocaux interactifs et le support à forte concurrence. Préférez 2.1 lorsque la session exige une orchestration complexe de tools ou un raisonnement en plusieurs étapes. OpenAI le présente comme son modèle phare pour le suivi d’instructions, un aspect que notre banc de test des coûts n’évalue volontairement pas.

Quel est le coût réel des scénarios vocaux courants ?

Pour les scénarios comportant beaucoup d’interruptions, ajoutez le dépassement lié à la reprise de parole au calcul du coût par interaction : chaque interruption facture l’audio entendu par l’utilisateur, plus quelques secondes d’avance de génération.

FAQ

GPT Live et l’API GPT Realtime sont-ils la même chose ?

Non. GPT Live est la fonctionnalité vocale intégrée aux applications ChatGPT. Elle n’a ni API ni page tarifaire propre. Pour proposer cette expérience par programme, les développeurs utilisent les modèles de l’API Realtime gpt-realtime-2.1 et gpt-realtime-2.1-mini, dont cet article mesure les prix.

Quelle est la durée maximale d’une session Realtime ?

La limite stricte est de soixante minutes. Une session fermée ne peut pas être reprise. Il est possible de réinjecter l’historique texte dans une nouvelle session, avec une facturation unique au tarif plein tandis que le prompt statique reste en cache. L’audio de l’assistant ne peut en revanche pas être rejoué. Les produits vocaux destinés à fonctionner longtemps doivent donc prévoir une rotation avant la 60e minute.

Existe-t-il un délai d’expiration en cas d’inactivité entre deux tours ?

La documentation ne mentionne aucun délai d’expiration pour inactivité. Avec le VAD côté serveur, le silence n’a généré aucun token facturé pendant nos mesures. Garder une ligne ouverte entre deux interactions ne coûte donc rien, en dehors de la connexion elle-même. Pour les produits utilisés ponctuellement, une longue session unique est moins chère et plus rapide qu’une reconnexion à chaque interaction, puisque l’initialisation mesurée prenait environ 2.5 secondes.

Quel format audio l’API attend-elle ?

Par défaut, l’entrée et la sortie utilisent du PCM16 mono à 24 kHz, configuré via audio.input.format et audio.output.format dans session.update. Le format n’a aucun effet sur la facturation : le nombre de tokens audio dépend uniquement de la durée, à raison de 1 token par tranche de 100 ms en entrée et de 1 par tranche de 50 ms en sortie.

Les méthodes permettant de gérer la limite de 60 minutes, notamment la rotation, le transfert d’historique et les données qui survivent à une reconnexion, feront l’objet d’un article distinct. Les chiffres présentés ici servent de base à ces calculs. Pour comprendre comment les tokens facturés se répartissent entre les différentes familles de l’API de texte, consultez notre article complémentaire sur l’anatomie de l’usage des tokens.

← Retour au blog