Prezzi della GPT Realtime API: parlare costa 4 volte più che ascoltare (dati misurati)

Una conversazione vocale tramite la 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 più che ascoltare: questo rapporto spiega gran parte del costo di una sessione vocale. Prima di passare ai numeri, chiariamo i nomi: “GPT Live” è la funzionalità consumer di ChatGPT e non dispone di un’API. I prodotti API sottostanti sono gpt-realtime-2.1 e gpt-realtime-2.1-mini, oggetto delle misurazioni riportate in questo articolo.

TL;DR

• gpt-realtime-2.1 addebita esattamente 1 audio token ogni 100 ms di parlato dell’utente e 1 ogni 50 ms di parlato del modello: $0.0192 al minuto per l’ascolto e $0.0768 al minuto per la voce.
• Sessanta secondi di silenzio con il VAD lato server non hanno generato alcun input token.
• Al turno 30, la cache automatica copriva il 93% dell’input; eliminando un elemento dalla cronologia, l’input a prezzo pieno è triplicato per un turno.
• Annullando una risposta vocale lunga dopo 2 secondi, sono stati addebitati 4 secondi di audio.
• gpt-realtime-2.1-mini applica gli stessi criteri di fatturazione, con prezzi audio 3.2 volte inferiori.

Tutti i numeri derivano da sessioni WebSocket strumentate, eseguite su entrambi i modelli il 2026-07-19, registrando ogni evento del server. Entrambi i modelli sono disponibili sull’endpoint /v1/realtime del gateway Synthorai, usato per questi test; protocollo e fatturazione sono identici a quelli di una connessione diretta a OpenAI. Il test harness è un singolo file Python basato esclusivamente sulla standard library, e ogni valore riportato di seguito è riconducibile a un record di utilizzo response.done grezzo.

Come ci si connette alla Realtime API?

A differenza delle API testuali, Realtime non usa il classico modello request/response su HTTP. Per ogni sessione si apre una connessione WebSocket e si scambiano eventi JSON: il client invia in streaming l’audio del microfono, il server restituisce l’audio parlato e l’intera conversazione passa sulla stessa connessione.

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

Ai fini della fatturazione, il ciclo di vita della sessione funziona così: session.update imposta istruzioni, voce, tool e rilevamento dei turni, creando il prefisso memorizzabile in cache; input_audio_buffer.append / commit aggiungono l’audio dell’utente; response.create avvia una risposta; ogni response.done contiene il dettaglio completo dell’utilizzo relativo a quella risposta. La versione GA dell’API usa output_modalities e una configurazione annidata audio.input/audio.output; il campo response.modalities della versione beta viene rifiutato con unknown_parameter.

Quanto costa GPT Realtime al minuto?

I tassi di conversione ufficiali corrispondono esattamente ai token misurati: una clip di 30.0 secondi ha generato 300 input audio token, cioè 1 ogni 100 ms, mentre una risposta vocale di 4.5 secondi ha generato 90 output audio token, cioè 1 ogni 50 ms. Applicando questi rapporti ai prezzi per token si ottengono i costi al minuto:

La tabella non include due voci di costo. Primo, una risposta vocale genera anche output testuale: la trascrizione più i reasoning token (gpt-realtime-2.1 esegue reasoning; output_token_details.reasoning_tokens era diverso da zero in ogni test). Nella nostra breve risposta di prova, questo ha aggiunto circa il 24% al costo degli audio token, con una tariffa testuale di $24/M.

Secondo, la trascrizione aggiuntiva viene fatturata separatamente. Il relativo record di utilizzo è {"type": "duration", "seconds": 30}: il costo è calcolato sulla durata, a $0.017 al minuto, indipendentemente dai token, e la trascrizione non entra mai nell’input del modello. Attivando questa sola opzione, il costo lato input quasi raddoppia su 2.1 e quasi quadruplica su mini. Conviene quindi abilitarla soltanto quando il testo è richiesto per motivi di compliance o dal prodotto.

Silenzio, interruzioni e chiamate ai tool hanno un costo?

Il silenzio non costa nulla. Abbiamo inviato 60 secondi di silenzio in streaming a una sessione con VAD lato server, quindi abbiamo posto una domanda: l’utilizzo era identico byte per byte a quello di una sessione di controllo che non aveva mai inviato audio. Il VAD esegue il commit soltanto dell’audio rilevato come parlato. Musica d’attesa, un cliente che legge un modulo o una linea aperta ma inattiva generano quindi zero input token. Il rumore di fondo reale può però attivare il VAD: il silenzio puro rappresenta il minimo possibile, non una garanzia per le chiamate rumorose.

Le interruzioni vengono fatturate fino al punto raggiunto dalla generazione, non fino a quanto ascoltato dall’utente, e mai per la parte non ancora generata. Abbiamo chiesto al modello di contare lentamente fino a quaranta e annullato la risposta dopo 2.0 secondi di ascolto: sono stati addebitati 81 audio token, equivalenti a 4.0 secondi. I 2 secondi aggiuntivi corrispondono all’anticipo accumulato dalla generazione rispetto alla riproduzione prima che arrivasse response.cancel. Su mini lo stesso esperimento ha generato un addebito di 6.3 secondi, perché il modello più piccolo produce audio con un anticipo maggiore rispetto al tempo reale. La regola pratica è inviare response.cancel non appena il client rileva un’interruzione dell’utente, perché il contatore continua a girare finché non arriva la richiesta di annullamento.

Le chiamate ai tool non incidono sulla fatturazione. In una sessione con una singola definizione di funzione, il modello ha emesso la chiamata e ricevuto il risultato inserito; nella risposta immediatamente successiva, il 99% dell’input è stato fatturato alla tariffa della cache. Gli elementi delle function call e i relativi output vengono memorizzati in cache come qualsiasi altro elemento aggiunto alla cronologia, mentre le definizioni dei tool fanno parte del prefisso statico, memorizzato in cache dal turno 2 in poi.

In che modo la cache riduce i costi delle sessioni lunghe?

Per ogni risposta, la Realtime API rilegge l’intera conversazione come input. Di conseguenza, l’input per turno cresce linearmente con la durata della sessione. I costi restano contenuti grazie al prefix caching automatico: la riproduzione dell’audio dalla cache costa $0.40/M anziché $32/M, ossia 1/80 del prezzo pieno. Nella nostra sessione di 30 turni, la quota in cache è aumentata progressivamente fino a raggiungere il 93% dell’input al turno 30:

La suddivisione dei token in cache è riportata in 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 }
  }
}

Abbiamo misurato tre caratteristiche non indicate nella documentazione ufficiale: la cache si attiva a circa 128 token di prefisso, contro il minimo documentato di 1,024 per l’API testuale; avanza in blocchi da 64 token; il prefisso statico può essere riutilizzato tra sessioni diverse con la stessa key. Quest’ultimo punto è rilevante per il limite di 60 minuti per sessione: già al primo turno di una nuova sessione, le istruzioni sono state fatturate alla tariffa della cache. La rotazione comporta quindi il pagamento a prezzo pieno solo della rilettura della cronologia, non del system prompt.

Modificare la cronologia fa perdere lo sconto. Abbiamo misurato con precisione l’effetto: eliminando un elemento precedente nel corso della sessione, la quota in cache è crollata per un solo turno, per poi ricostruirsi:

Un altro dato favorevole emerso dalle misurazioni: nelle richieste successive, le risposte vocali del modello rientrano nell’input come testo, non come audio. In una conversazione vocale di 8 turni, l’audio in input è cresciuto a ogni turno esattamente della dimensione della clip dell’utente, mentre le risposte dell’assistente sono ricomparse come token della trascrizione a $4/M. Nella componente cumulativa, la parte costosa è soltanto l’audio dell’utente.

Le regole operative sono semplici: gestire la cronologia in modalità append-only; mantenere istruzioni e definizioni dei tool identiche byte per byte per l’intera sessione, e anche tra sessioni diverse; inserire i dati dinamici nell’ultimo messaggio utente anziché nel prefisso; quando occorre ridurre la cronologia, farlo raramente e in blocchi consistenti, non a ogni turno. Per il funzionamento generale sui diversi provider, consulta la nostra guida al prompt caching e lo studio sulle soglie minime della cache misurate.

gpt-realtime-2.1 o mini: quale scegliere?

I criteri di fatturazione sono identici per entrambi i modelli: stessi tassi di conversione, stessa quantizzazione della cache in blocchi da 64 token e stesse curve. Cambiano prezzi e comportamento:

Due aspetti meritano attenzione. Per la riproduzione dalla cache, la differenza di prezzo si riduce quasi del tutto ($0.40 contro $0.30). In una sessione lunga con un’elevata percentuale di cache, il vantaggio di mini diminuisce leggermente, anche se i token nuovi continuano a dominare il totale. Inoltre, la velocità di mini diventa uno svantaggio in caso di interruzione: genera con maggiore anticipo rispetto alla riproduzione, quindi ogni interruzione scarta circa il doppio dell’audio già prodotto. In termini di costo, mini resta comunque più conveniente in tutti gli scenari misurati; il divario di prezzo di 3.2 volte assorbe entrambi gli effetti.

Scegli mini come opzione predefinita per assistenti con comandi brevi, IVR e supporto ad alta concorrenza. Scegli 2.1 quando la sessione richiede un’orchestrazione complessa dei tool o reasoning in più passaggi; OpenAI lo presenta come modello di punta per il rispetto delle istruzioni, un aspetto che il nostro test harness per i costi non valuta volutamente.

Quanto costano davvero gli scenari vocali più comuni?

Negli scenari con molte interruzioni, aggiungi al calcolo per interazione l’audio generato in eccesso: ogni interruzione costa l’audio ascoltato dall’utente più alcuni secondi di anticipo della generazione.

FAQ

GPT Live e la GPT Realtime API sono la stessa cosa?

No. GPT Live è la funzionalità vocale delle app ChatGPT e non dispone di un’API né di una pagina prezzi dedicata. Gli sviluppatori che vogliono offrire la stessa esperienza via API usano i modelli Realtime gpt-realtime-2.1 e gpt-realtime-2.1-mini, i cui prezzi sono oggetto di questo articolo.

Quanto può durare una sessione Realtime?

Il limite massimo è di sessanta minuti e una sessione chiusa non può essere ripresa. La cronologia testuale può essere reinserita in una nuova sessione, con un singolo addebito a prezzo pieno mentre il prompt statico resta in cache, ma l’audio dell’assistente non può essere riprodotto di nuovo. I prodotti vocali di lunga durata devono quindi prevedere una strategia di rotazione prima del minuto 60.

Esiste un timeout per inattività tra un turno e l’altro?

Non è documentato alcun timeout per inattività. Nelle nostre misurazioni, con il VAD lato server il silenzio ha generato zero token. Tenere aperta una connessione tra un’interazione e l’altra non costa quindi nulla, a parte la connessione stessa. Per i prodotti usati sporadicamente, una singola sessione lunga è più economica e veloce rispetto a una nuova connessione per ogni interazione, dato che la configurazione richiede circa 2.5 secondi.

Quale formato audio richiede l’API?

Il formato predefinito per input e output è PCM16 mono a 24 kHz, configurato tramite audio.input.format e audio.output.format in session.update. La fatturazione non dipende dal formato: gli audio token dipendono esclusivamente dalla durata, con 1 token ogni 100 ms in input e 1 ogni 50 ms in output.

I pattern architetturali necessari per gestire il limite dei 60 minuti, come rotazione, trasferimento della cronologia e dati che sopravvivono alla riconnessione, richiedono una trattazione separata. I numeri di questo articolo sono la base per quei calcoli. Per capire come si suddividono i token fatturati tra le varie famiglie dell’API testuale, consulta l’articolo correlato sulla composizione dell’utilizzo dei token.

← Torna al blog