Tarifs de l'API GPT Realtime : parler coûte 4x plus cher qu'écouter (mesuré)

Une conversation vocale sur l’API Realtime d’OpenAI coûte 0,0192 $ par minute pendant que l’utilisateur parle, et 0,0768 $ par minute pendant que le modèle répond. Parler coûte exactement quatre fois plus cher qu’écouter, et ce seul rapport explique l’essentiel de la facture d’une session vocale. Une précision de nommage avant les chiffres : « GPT Live » est la fonctionnalité grand public de ChatGPT et n’a pas d’API. Les produits API sous-jacents sont gpt-realtime-2.1 et gpt-realtime-2.1-mini, et ce sont eux que mesure cet article.

TL;DR

• gpt-realtime-2.1 facture exactement 1 token audio par 100 ms de parole utilisateur et 1 par 50 ms de parole modèle : 0,0192 $ par minute pour écouter, 0,0768 $ par minute pour parler.
• Soixante secondes de silence sous VAD serveur ont été facturées zéro token d’entrée.
• Le cache automatique couvrait 93 % de l’entrée au tour 30 ; supprimer un élément d’historique a triplé l’entrée au prix plein pour un tour.
• Annuler une longue réponse orale au bout de 2 secondes a facturé 4 secondes d’audio.
• gpt-realtime-2.1-mini a une mécanique de facturation identique, avec des prix audio 3,2x plus bas.

Tous les chiffres proviennent de sessions WebSocket instrumentées, exécutées sur les deux modèles le 2026-07-19, avec chaque événement serveur journalisé. Les deux modèles sont disponibles sur l’endpoint /v1/realtime du gateway Synthorai, où ces sessions ont tourné ; le protocole et la facturation sont identiques à un dialogue direct avec OpenAI. Le harnais tient dans un seul fichier Python n’utilisant que la stdlib, et chaque valeur ci-dessous remonte à un enregistrement d’usage response.done brut.

Comment se connecter à l’API Realtime ?

Contrairement aux API texte, Realtime ne fonctionne pas en requête/réponse sur HTTP. On ouvre un WebSocket par session et on échange des événements JSON dessus : le client envoie l’audio du micro en flux, le serveur renvoie l’audio parlé en flux, et une seule connexion porte toute la conversation.

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

Le cycle de vie de session qui compte pour la facturation : session.update définit les instructions, la voix, les outils et la détection de tour (cela devient le préfixe cacheable) ; input_audio_buffer.append / commit ajoutent l’audio utilisateur ; response.create déclenche une réponse ; et chaque response.done porte le détail complet de l’usage pour cette réponse. Une note de dialecte : l’API GA utilise output_modalities et une config imbriquée audio.input/audio.output ; le champ response.modalities de l’ère bêta est rejeté avec unknown_parameter.

Combien coûte GPT Realtime à la minute ?

Les taux de conversion officiels tiennent au token près : un extrait de 30,0 secondes est facturé 300 input audio tokens (1 pour 100 ms), et une réponse parlée de 4,5 secondes est facturée 90 output audio tokens (1 pour 50 ms). De là, on passe du prix au token à un calcul à la minute :

Deux coûts échappent au tableau. D’abord, une réponse parlée facture aussi du text output : la transcription plus les reasoning tokens (gpt-realtime-2.1 raisonne bien ; output_token_details.reasoning_tokens remontait non nul à chaque exécution). Sur notre courte réponse de test, cela ajoutait environ 24 % au-dessus des audio tokens, facturés au tarif texte de $24/M.

Ensuite, l’option transcription constitue sa propre voie de facturation. Son enregistrement d’usage indique {"type": "duration", "seconds": 30} : facturation à la durée, $0.017 par minute, indépendante des tokens, et la transcription n’entre jamais dans l’input du modèle. Activer ce seul flag double à peu près le coût côté input sur 2.1 et le quadruple presque sur mini ; ne l’active donc que là où une exigence de conformité ou produit a réellement besoin du texte.

Le silence, une interruption ou un appel d’outil coûtent-ils quelque chose ?

Le silence ne coûte rien. On a streamé 60 secondes de silence dans une session avec le server VAD activé, puis posé une question : l’usage était identique au token près à une session témoin qui n’avait jamais envoyé d’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 inactive ouverte facturent donc zéro input token. La nuance : un vrai bruit de fond peut déclencher le VAD. Le silence pur est le plancher, pas une garantie sur un appel bruyant.

Les interruptions se facturent jusqu’à la frontière de génération, pas jusqu’à ce que l’utilisateur entend, et jamais pour le reste non généré. On a demandé un décompte parlé lent jusqu’à quarante, puis annulé après avoir entendu 2,0 secondes : la facture était de 81 audio tokens, soit 4,0 secondes. Ces 2 secondes de débordement correspondent à l’avance prise par la génération sur la lecture avant l’arrivée de response.cancel. Sur mini, la même expérience a facturé 6,3 secondes, parce que le plus petit modèle génère plus en avance sur le temps réel. Règle pratique : envoie response.cancel dès que ton client détecte le barge-in, car le compteur tourne jusqu’à ce que l’annulation arrive.

Les appels d’outils sont neutres en facturation. Une session avec une définition de fonction a émis l’appel, reçu le résultat injecté, et la réponse suivante affichait 99 % de son input facturé au tarif cache. Les éléments d’appel de fonction et leurs sorties se mettent en cache comme n’importe quel autre historique ajouté, et les définitions d’outils elles-mêmes se placent dans le préfixe statique, mis en cache à partir du tour 2.

Comment le cache maintient-il des sessions longues à un coût abordable ?

L’API Realtime relit toute la conversation en entrée pour chaque réponse : l’input par tour croît donc linéairement avec la durée de la session. Ce qui garde ce coût acceptable, c’est le cache automatique de préfixe : l’audio en cache est refacturé à 0,40 $/M au lieu de 32 $/M, soit 1/80e du plein tarif. Sur notre session de 30 tours, la part en cache a grimpé régulièrement pour atteindre 93 % de l’input au tour 30 :

Le détail du cache est reporté à chaque response.done :

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

Trois caractéristiques absentes de la doc officielle, toutes mesurées : le cache s’active vers 128 tokens de préfixe (le minimum documenté de l’API texte est de 1 024), il avance par blocs de 64 tokens, et le préfixe statique est réutilisable entre les sessions d’une même clé. Ce dernier point compte pour la limite de 60 minutes par session : le tout premier tour d’une nouvelle session facture déjà ses instructions au tarif du cache. La rotation ne paie donc le plein tarif que pour relire l’historique de conversation, pas le system prompt.

Modifier l’historique est la seule façon de perdre la remise, et nous avons mesuré la pénalité exacte. Supprimer un élément ancien en cours de session a fait chuter la part en cache sur un seul tour, puis le cache s’est reconstruit :

Un autre allègement mesuré : les réponses vocales du modèle reviennent dans les inputs suivants sous forme de texte, pas d’audio. Sur une conversation vocale de 8 tours, l’audio d’entrée augmentait à chaque tour exactement de la taille du clip utilisateur, tandis que le côté assistant réapparaissait en tokens de transcription à 4 $/M. Seul l’audio utilisateur constitue la partie coûteuse du terme cumulé.

La marche à suivre est courte : garder l’historique en append-only, garder les instructions et les définitions d’outils octet pour octet identiques sur toute la session (et entre les sessions), placer tout élément dynamique dans le dernier message utilisateur plutôt que dans le préfixe, et lorsqu’il faut élaguer, le faire rarement et par grandes étapes plutôt qu’à chaque tour. Pour les mécanismes généraux selon les fournisseurs, voir notre guide du prompt caching et l’étude sur les minimums de cache mesurés.

gpt-realtime-2.1 ou mini : lequel choisir ?

Le mécanisme de facturation est identique sur les deux modèles : mêmes taux de conversion, même quantification du cache par tranches de 64 tokens, mêmes formes de courbe. Ce qui change, c’est le prix et le comportement :

Deux détails à remarquer. Sur le canal de relecture depuis le cache, l’écart de prix se referme presque (0,40 $ contre 0,30 $) : une session longue fortement mise en cache réduit donc légèrement l’avantage de mini, même si les tokens frais restent majoritaires dans le total. Et la rapidité de mini se retourne contre lui sur les interruptions : il génère plus en avance de la lecture, donc chaque interruption jette environ deux fois plus d’audio généré. En dollars, mini reste gagnant dans tous les scénarios que nous avons mesurés ; l’écart de prix de 3,2x absorbe les deux effets.

Choisissez mini par défaut pour les assistants à commandes courtes, l’IVR et le support à forte concurrence. Choisissez 2.1 quand la session exige une orchestration d’outils complexe ou du raisonnement en plusieurs étapes ; OpenAI le positionne comme le modèle phare pour le suivi des instructions, un point que notre banc de test de coûts ne cherche délibérément pas à évaluer.

Combien coûtent réellement les scénarios vocaux courants ?

Pour les scénarios avec beaucoup d’interruptions, ajoutez le débordement d’interruption à votre calcul par interaction : chaque interruption coûte l’audio que l’utilisateur a entendu, plus quelques secondes d’avance de génération.

FAQ

GPT Live et l’API GPT Realtime, c’est la même chose ?

Non. GPT Live est la fonctionnalité vocale intégrée aux applications ChatGPT ; elle n’a ni API ni page de tarification propre. Pour reproduire cette expérience par programmation, on utilise les modèles de l’API Realtime gpt-realtime-2.1 et gpt-realtime-2.1-mini, dont ce billet mesure les tarifs.

Combien de temps une session Realtime peut-elle durer ?

La limite absolue est de soixante minutes, et une session fermée ne peut pas être reprise. On peut réinjecter l’historique texte dans une nouvelle session (facturé une fois au plein tarif, le prompt statique restant en cache), mais l’audio de l’assistant ne peut pas être rejoué. Les produits vocaux de longue durée ont donc besoin d’un plan de rotation avant la 60ᵉ minute.

Y a-t-il un timeout d’inactivité entre les tours de parole ?

Aucun timeout d’inactivité n’est documenté, et dans nos mesures le silence facture zéro token sous le VAD serveur. Garder une ligne ouverte entre deux interactions ne coûte donc rien de plus que la connexion elle-même. Pour les produits à usage sporadique, une seule session longue revient moins cher et plus vite qu’une reconnexion à chaque interaction, puisque l’établissement de session prend environ 2,5 secondes dans nos mesures.

Quel format audio l’API attend-elle ?

PCM16 en 24 kHz mono est le format par défaut, aussi bien en entrée qu’en sortie, configuré via audio.input.format et audio.output.format dans session.update. La facturation ne dépend pas du format : les tokens audio ne sont fonction que de la durée, soit 1 token par 100 ms en entrée et 1 par 50 ms en sortie.

Les patterns d’ingénierie pour composer avec le mur des 60 minutes (rotation, transfert d’historique, ce qui survit à une reconnexion) forment un sujet à part entière, et les chiffres de ce billet sont les données d’entrée de ce calcul. Pour comprendre comment les tokens facturés se décomposent par famille dans l’API texte, voir notre article associé : anatomie de l’usage des tokens.

← Retour au blog