Prezzi della Realtime API di GPT: parlare costa 4 volte l'ascolto (misurato)

Una conversazione vocale sulla Realtime API di OpenAI costa 0,0192$ al minuto mentre parla l’utente e 0,0768$ al minuto mentre risponde il modello. Parlare costa esattamente quattro volte l’ascolto, e questo solo rapporto spiega gran parte del conto di una sessione vocale. Una nota sui nomi prima dei numeri: “GPT Live” è la funzione consumer di ChatGPT e non ha una API. I prodotti API che ci stanno dietro sono gpt-realtime-2.1 e gpt-realtime-2.1-mini, ed è questo che misura questo post.

TL;DR

• gpt-realtime-2.1 fattura esattamente 1 token audio ogni 100 ms di parlato dell’utente e 1 ogni 50 ms di parlato del modello: 0,0192$ al minuto per ascoltare, 0,0768$ al minuto per parlare.
• Sessanta secondi di silenzio con la VAD lato server hanno fatturato zero token di input.
• Il caching automatico ha coperto il 93% dell’input entro il turno 30; eliminare un elemento della cronologia ha triplicato l’input a prezzo pieno per un turno.
• Annullare una risposta parlata lunga dopo 2 secondi ha fatturato 4 secondi di audio.
• gpt-realtime-2.1-mini ha meccaniche di fatturazione identiche con prezzi audio 3,2 volte più bassi.

Ogni numero qui viene da sessioni WebSocket strumentate eseguite su entrambi i modelli il 2026-07-19, con ogni evento del server loggato. Entrambi i modelli sono attivi sull’endpoint /v1/realtime del gateway Synthorai, dove sono state eseguite queste sessioni; il protocollo e la fatturazione sono gli stessi di quando parli direttamente con OpenAI. Il banco di prova è un singolo file Python che usa solo la stdlib, e ogni cifra qui sotto risale a un record response.done grezzo con i dati di utilizzo.

Come ci si connette alla Realtime API?

A differenza delle API testuali, Realtime non è request/response su HTTP. Apri un WebSocket per sessione e ci scambi eventi JSON: il client invia in streaming l’audio del microfono, il server invia in streaming l’audio parlato di ritorno, e una sola connessione trasporta l’intera conversazione.

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

Il ciclo di vita della sessione che conta per la fatturazione: session.update imposta istruzioni, voce, tool e turn detection (questo diventa il prefisso cacheable); input_audio_buffer.append / commit aggiungono l’audio dell’utente; response.create innesca una risposta; e ogni response.done porta con sé la ripartizione completa dell’utilizzo per quella risposta. Una nota sui dialetti: la API GA usa output_modalities e una config annidata audio.input/audio.output; il campo response.modalities dell’era beta viene rifiutato con unknown_parameter.

Quanto costa GPT Realtime al minuto?

I tassi di conversione ufficiali sono precisi al token: una clip di 30,0 secondi ha fatturato 300 token audio di input (1 ogni 100 ms), e una risposta parlata di 4,5 secondi ha fatturato 90 token audio di output (1 ogni 50 ms). Questo trasforma il listino per token in aritmetica al minuto:

Due costi restano nascosti fuori dalla tabella. Primo: una risposta parlata fattura anche l’output di testo, cioè la trascrizione più i token di reasoning (gpt-realtime-2.1 fa reasoning; output_token_details.reasoning_tokens è tornato diverso da zero a ogni run). Sulla nostra breve risposta di test questo ha aggiunto circa il 24% sopra i token audio, fatturato alla tariffa testo di $24/M.

Secondo: l’add-on di trascrizione ha una sua voce di fatturazione a parte. Il record d’uso riporta {"type": "duration", "seconds": 30}: fatturato a durata a $0.017 al minuto, indipendente dai token, e la trascrizione non entra mai nell’input del modello. Attivare quel singolo flag raddoppia grosso modo il costo lato input su 2.1 e lo quasi quadruplica su mini, quindi abilitalo solo dove un requisito di compliance o di prodotto ha davvero bisogno del testo.

Silenzio, interruzioni o chiamate a tool hanno un costo?

Il silenzio non costa nulla. Abbiamo inviato in streaming 60 secondi di silenzio in una sessione con server VAD abilitato, poi abbiamo posto una domanda: l’uso è risultato identico al byte rispetto a una sessione di controllo che non aveva mai inviato audio. Il VAD committa solo l’audio che riconosce come parlato, quindi musica d’attesa, un cliente che legge un modulo o una linea inattiva aperta fatturano zero token di input. L’avvertenza è che del rumore di fondo reale può far scattare il VAD; il silenzio puro è il pavimento, non una garanzia per una chiamata rumorosa.

Le interruzioni si fatturano fino al fronte di generazione, non fino a ciò che sente l’utente, e mai per la parte non ancora generata. Abbiamo chiesto un conteggio parlato lento fino a quaranta e abbiamo annullato dopo aver sentito 2,0 secondi: la fattura è stata di 81 token audio, ovvero 4,0 secondi. Quei 2 secondi di sfasamento sono quanto la generazione era andata avanti rispetto alla riproduzione prima che arrivasse response.cancel. Su mini lo stesso esperimento ha fatturato 6,3 secondi, perché il modello più piccolo genera più avanti rispetto al tempo reale. La regola pratica: invia response.cancel nell’istante in cui il client rileva il barge-in, perché il contatore gira finché il cancel non arriva.

Le chiamate a tool sono neutre in termini di fatturazione. Una sessione con una definizione di funzione ha emesso la chiamata, ricevuto il risultato iniettato, e la risposta immediatamente successiva ha mostrato il 99% del suo input fatturato alla tariffa di cache. Gli item di function-call e i loro output vengono messi in cache come qualsiasi altra history aggiunta, e le definizioni dei tool stesse stanno nel prefisso statico che va in cache dal turno 2 in poi.

Come fa il caching a mantenere le sessioni lunghe economiche?

La Realtime API rilegge l’intera conversazione come input per ogni risposta, quindi l’input per turno cresce in modo lineare con la lunghezza della sessione. A rendere il tutto sostenibile è il prefix caching automatico: l’audio in cache viene rieseguito a $0,40/M invece di $32/M, cioè 1/80 del prezzo pieno. Nella nostra sessione da 30 turni la quota in cache è salita costantemente fino al 93% dell’input al turno 30:

La suddivisione della cache viene riportata su ogni 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 }
  }
}

Tre dettagli che la documentazione ufficiale non riporta, tutti misurati: la cache si attiva intorno ai 128 token di prefisso (il minimo documentato per la text API è 1.024), avanza a blocchi di 64 token, e il prefisso statico è riutilizzabile tra sessioni diverse sulla stessa key. Quest’ultimo punto conta per il limite di 60 minuti a sessione: il primo turno in assoluto di una nuova sessione fattura già le sue istruzioni alla tariffa in cache, quindi la rotazione paga il prezzo pieno solo per rileggere la cronologia della conversazione, non il system prompt.

L’unico modo per perdere lo sconto è modificare la cronologia, e abbiamo misurato la penalità esatta. Cancellare un elemento iniziale a metà sessione ha azzerato la quota in cache per un solo turno, poi la cache si è ricostruita:

Un altro sollievo misurato: le risposte parlate del modello rientrano negli input successivi come testo, non come audio. In una conversazione vocale da 8 turni, l’audio di input cresceva esattamente della dimensione della clip dell’utente ad ogni turno, mentre il lato assistente riappariva come token di trascrizione a $4/M. La parte costosa del termine composto è solo l’audio dell’utente.

Ne esce una strategia breve: mantieni la cronologia in sola aggiunta, tieni istruzioni e definizioni degli strumenti byte-identiche per tutta la sessione (e tra sessioni), metti tutto ciò che è dinamico nell’ultimo messaggio dell’utente invece che nel prefisso, e quando devi tagliare, taglia di rado e a grandi passi anziché ad ogni turno. Per i meccanismi generali tra i vari provider, vedi la nostra guida al prompt caching e lo studio sui minimi di cache misurati.

gpt-realtime-2.1 o mini: quale scegliere?

La meccanica di fatturazione è identica sui due modelli: stessi tassi di conversione, stessa quantizzazione della cache a 64 token, stesse forme delle curve. Quel che cambia è il prezzo e il comportamento:

Due dettagli da notare. Sul percorso di replay cache la forbice di prezzo quasi si chiude ($0.40 contro $0.30), quindi una sessione lunga con cache molto sfruttata riduce leggermente il vantaggio di mini, anche se i token nuovi restano la voce dominante del totale. La velocità di mini lavora contro di lui sulle interruzioni: genera più avanti rispetto alla riproduzione, quindi ogni barge-in scarta circa il doppio dell’audio generato. In dollari mini vince comunque in ogni scenario misurato; la forbice di prezzo di 3,2x assorbe entrambi gli effetti.

Scegli mini di default per assistenti a comandi brevi, IVR e supporto ad alta concorrenza. Scegli 2.1 quando la sessione richiede orchestrazione complessa di tool o ragionamento multi-step; OpenAI lo posiziona come il modello di punta per il rispetto delle istruzioni, cosa che il nostro banco di prova sui costi deliberatamente non valuta.

Quanto costano davvero gli scenari vocali più comuni?

Per gli scenari con molte interruzioni, aggiungi l’overhang del barge-in al conto per interazione: ogni interruzione costa l’audio che l’utente ha sentito più qualche secondo di anticipo di generazione.

FAQ

GPT Live è la stessa cosa della Realtime API di GPT?

No. GPT Live è la funzione vocale integrata nelle app di ChatGPT e non ha né un’API né una pagina di prezzi dedicata. Chi vuole quell’esperienza a livello programmatico usa i modelli della Realtime API gpt-realtime-2.1 e gpt-realtime-2.1-mini, i cui prezzi sono l’oggetto di questo post.

Quanto può durare una sessione Realtime?

Il limite massimo è sessanta minuti, e una sessione chiusa non si può riprendere. Lo storico testuale può essere reiniettato in una nuova sessione (fatturato una volta a prezzo pieno, mentre il prompt statico resta in cache), ma l’audio dell’assistente non si può riprodurre di nuovo. Quindi i prodotti vocali di lunga durata devono prevedere una strategia di rotazione prima del minuto 60.

C’è un timeout di inattività tra un turno e l’altro?

Non è documentato alcun timeout di inattività, e nelle nostre misurazioni il silenzio fattura zero token con il VAD lato server. Tenere aperta una linea tra un’interazione e l’altra non costa nulla, se non la connessione stessa. Per i prodotti a uso sporadico questo rende una singola sessione lunga più economica e più veloce rispetto a riconnettersi a ogni interazione, dato che l’avvio misurato è di circa 2,5 secondi.

Che formato audio si aspetta l’API?

PCM16 a 24 kHz mono è il default sia in ingresso che in uscita, configurato tramite audio.input.format e audio.output.format in session.update. La fatturazione non dipende dal formato: i token audio dipendono solo dalla durata, 1 token ogni 100 ms in ingresso e 1 ogni 50 ms in uscita.

I pattern di progettazione per convivere con il muro dei 60 minuti (rotazione, passaggio dello storico, cosa sopravvive a una riconnessione) sono un argomento a sé, e i numeri di questo post sono gli ingressi di quel calcolo. Per capire come i token fatturati si scompongono tra le varie famiglie nell’API testuale, l’articolo complementare è la nostra anatomia dell’utilizzo dei token.

← Torna al blog