Precios de la GPT Realtime API: hablar cuesta 4x más que escuchar (medido)

Una conversación de voz en la Realtime API de OpenAI cuesta $0,0192 por minuto mientras habla el usuario y $0,0768 por minuto mientras responde el modelo. Hablar cuesta exactamente cuatro veces más que escuchar, y esa sola proporción explica casi toda la factura de una sesión de voz. Una aclaración de nombres antes de los números: “GPT Live” es la función de consumo de ChatGPT y no tiene API. Los productos de API que hay detrás son gpt-realtime-2.1 y gpt-realtime-2.1-mini, y son esos los que mide este post.

TL;DR

• gpt-realtime-2.1 factura exactamente 1 token de audio por cada 100 ms de voz del usuario y 1 por cada 50 ms de voz del modelo: $0,0192 por minuto para escuchar, $0,0768 por minuto para hablar.
• Sesenta segundos de silencio con server VAD facturaron cero tokens de entrada.
• El caché automático cubrió el 93% de la entrada en el turno 30; borrar un elemento del historial triplicó la entrada a precio completo durante un turno.
• Cancelar una respuesta hablada larga a los 2 segundos facturó 4 segundos de audio.
• gpt-realtime-2.1-mini tiene la misma mecánica de facturación con precios de audio 3,2x más bajos.

Todos los números vienen de sesiones WebSocket instrumentadas ejecutadas contra ambos modelos el 2026-07-19, con cada evento del servidor registrado. Ambos modelos están disponibles en el endpoint /v1/realtime del gateway de Synthorai, que es donde corrieron estas sesiones; el protocolo y la facturación son iguales que hablando directamente con OpenAI. El harness es un único archivo Python que solo usa la stdlib, y cada cifra de abajo se remonta a un registro de uso response.done en crudo.

¿Cómo te conectas a la Realtime API?

A diferencia de las APIs de texto, Realtime no es request/response sobre HTTP. Abres un WebSocket por sesión e intercambias eventos JSON por él: el cliente envía en streaming el audio del micrófono, el servidor devuelve en streaming el audio hablado, y una sola conexión lleva toda la conversación.

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

El ciclo de vida de la sesión que importa para la facturación: session.update define instructions, voz, tools y detección de turno (esto se convierte en el prefijo cacheable); input_audio_buffer.append / commit añaden audio del usuario; response.create dispara una respuesta; y cada response.done lleva el desglose completo de uso de esa respuesta. Una nota sobre el dialecto: la API GA usa output_modalities y una config anidada audio.input/audio.output; el campo response.modalities de la etapa beta se rechaza con unknown_parameter.

¿Cuánto cuesta GPT Realtime por minuto?

Las tarifas de conversión oficiales cuadran token a token: un clip de 30.0 segundos facturó 300 input audio tokens (1 por cada 100 ms), y una respuesta hablada de 4.5 segundos facturó 90 output audio tokens (1 por cada 50 ms). Con esto la lista de precios por token se convierte en cálculos por minuto:

Hay dos costos que quedan fuera de la tabla. Primero, una respuesta hablada también factura text output: la transcripción más los reasoning tokens (gpt-realtime-2.1 sí razona; output_token_details.reasoning_tokens volvió distinto de cero en todas las ejecuciones). En nuestra respuesta de prueba, corta, eso añadió alrededor de un 24% sobre los audio tokens, facturado a la tarifa de texto de $24/M.

Segundo, el complemento de transcripción es su propia vía de facturación. Su registro de uso dice {"type": "duration", "seconds": 30}: se factura por duración a $0.017 por minuto, independiente de los tokens, y la transcripción nunca entra al input del modelo. Activar ese único flag casi duplica el costo del lado de input en 2.1 y lo cuadruplica casi por completo en mini, así que actívalo solo donde un requisito de cumplimiento o de producto realmente necesite el texto.

¿El silencio, las interrupciones o las llamadas a herramientas cuestan algo?

El silencio no cuesta nada. Transmitimos 60 segundos de silencio a una sesión con server VAD activado y luego hicimos una pregunta: el uso fue idéntico byte a byte al de una sesión de control que nunca envió audio. VAD solo confirma el audio que detecta como habla, así que la música de espera, un cliente leyendo un formulario o una línea abierta e inactiva facturan cero input tokens. La salvedad es que el ruido de fondo real puede disparar el VAD; el silencio puro es el mínimo, no una garantía en una llamada ruidosa.

Las interrupciones se facturan hasta el frente de la generación, no hasta el oído del usuario, y nunca por el resto que no se generó. Pedimos una cuenta hablada lenta hasta cuarenta y cancelamos tras oír 2.0 segundos: la factura fue de 81 audio tokens, o 4.0 segundos. Esos 2 segundos de más son lo que la generación se adelantó a la reproducción antes de que llegara response.cancel. En mini el mismo experimento facturó 6.3 segundos, porque el modelo más pequeño genera más por delante del tiempo real. La regla práctica: envía response.cancel en cuanto tu cliente detecte barge-in, porque el contador corre hasta que llega la cancelación.

Las llamadas a herramientas son neutrales en facturación. Una sesión con una definición de función emitió la llamada, tomó el resultado inyectado, y la respuesta inmediatamente siguiente mostró el 99% de su input facturado a la tarifa de cache. Los elementos de function-call y sus salidas entran en cache como cualquier otro historial añadido, y las propias definiciones de herramientas quedan en el prefijo estático que se cachea a partir del turno 2.

¿Cómo mantiene el caché las sesiones largas a un precio razonable?

La Realtime API vuelve a leer toda la conversación como input en cada respuesta, así que el input por turno crece linealmente con la longitud de la sesión. Lo que evita que esto se dispare de precio es el caché automático de prefijos: el audio cacheado se reproduce a $0.40/M en vez de $32/M, un 1/80 del precio completo. En nuestra sesión de 30 turnos, la fracción cacheada subió de forma constante hasta el 93% del input en el turno 30:

El desglose del caché aparece en cada 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 }
  }
}

Hay tres detalles que la documentación oficial no menciona, todos medidos: el caché se activa a partir de unos 128 tokens de prefijo (el mínimo documentado de la API de texto es 1,024), avanza en bloques de 64 tokens, y el prefijo estático se reutiliza entre sesiones sobre la misma key. Esto último importa para el límite de 60 minutos por sesión: el primer turno de una sesión nueva ya factura sus instructions a la tarifa cacheada, así que la rotación solo paga precio completo por releer el historial de la conversación, no el system prompt.

Editar el historial es la única forma de perder el descuento, y medimos la penalización exacta. Borrar un item temprano a mitad de sesión hizo caer la fracción cacheada durante exactamente un turno; luego el caché se reconstruyó:

Un alivio más que medimos: las propias respuestas habladas del modelo vuelven a entrar en inputs posteriores como texto, no como audio. En una conversación de voz de 8 turnos, el audio de input creció cada turno exactamente lo que ocupaba el clip del usuario, mientras que el lado del asistente reaparecía como tokens de transcripción a $4/M. La parte cara del término compuesto es únicamente el audio del usuario.

El manual que se deduce de esto es corto: mantén el historial en modo append-only, mantén las instructions y las definiciones de tools byte a byte idénticas durante toda la sesión (y entre sesiones), pon todo lo dinámico en el último mensaje del usuario en vez de en el prefijo, y cuando tengas que recortar, hazlo pocas veces y en pasos grandes en lugar de cada turno. Para el funcionamiento general entre proveedores, consulta nuestra guía de prompt caching y el estudio de los mínimos de caché medidos.

gpt-realtime-2.1 o mini: ¿cuál elegir?

Los dos modelos facturan igual: mismas tasas de conversión, misma cuantización de caché de 64 tokens, mismas formas de curva. Lo que cambia es el precio y el comportamiento:

Hay dos detalles que conviene mirar. En el carril de reproducción cacheada la diferencia de precio casi desaparece ($0,40 frente a $0,30), así que una sesión larga con mucha caché reduce un poco la ventaja de mini, aunque los tokens frescos siguen dominando el total. Y la velocidad de mini juega en su contra en las interrupciones: genera más adelantado respecto a la reproducción, de modo que cada barge-in descarta alrededor del doble de audio generado. En dólares mini gana igualmente en todos los escenarios que medimos; la diferencia de precio de 3,2x absorbe ambos efectos.

Elige mini por defecto para asistentes de comandos cortos, IVR y soporte con alta concurrencia. Elige 2.1 cuando la sesión requiera orquestación compleja de herramientas o razonamiento en varios pasos; OpenAI lo posiciona como el buque insignia para seguimiento de instrucciones, algo que nuestro banco de pruebas de costes deliberadamente no evalúa.

¿Cuánto cuestan de verdad los escenarios de voz habituales?

Para escenarios con muchas interrupciones, suma el solapamiento de barge-in a tu cálculo por interacción: cada interrupción cuesta el audio que oyó el usuario más unos segundos de adelanto de generación.

Preguntas frecuentes

¿GPT Live es lo mismo que la Realtime API de GPT?

No. GPT Live es la función de voz dentro de las apps de ChatGPT y no tiene API ni página de precios propia. Quien quiere esa experiencia por código usa los modelos de la Realtime API gpt-realtime-2.1 y gpt-realtime-2.1-mini, cuyos precios mide este post.

¿Cuánto puede durar una sesión de Realtime?

El tope duro son sesenta minutos, y una sesión cerrada no se puede reanudar. El historial de texto se puede reinyectar en una sesión nueva (se cobra una vez a precio completo, y el prompt estático se mantiene en caché), pero el audio del asistente no se puede reproducir de nuevo. Por eso los productos de voz de larga duración necesitan un plan de rotación antes del minuto 60.

¿Hay un timeout por inactividad entre turnos?

No hay ningún timeout por inactividad documentado, y en nuestra medición el silencio cobra cero tokens bajo server VAD. Mantener una línea abierta entre interacciones no cuesta nada más allá de la propia conexión. Para productos de uso esporádico, una sola sesión larga sale más barata y rápida que reconectar en cada interacción, ya que el setup medido rondó los 2,5 segundos.

¿Qué formato de audio espera la API?

PCM16 a 24 kHz mono es el valor por defecto tanto para entrada como para salida, configurado con audio.input.format y audio.output.format en session.update. El cobro no depende del formato: los tokens de audio son función únicamente de la duración, 1 token por cada 100 ms de entrada y 1 por cada 50 ms de salida.

Los patrones de ingeniería para convivir con el muro de los 60 minutos (rotación, traspaso de historial, qué sobrevive a una reconexión) son un tema aparte, y los números de este post son los insumos de esa cuenta. Para ver cómo se descomponen los tokens cobrados entre familias en la API de texto, el artículo complementario es nuestra anatomía del uso de tokens.

← Volver al blog