Precios de GPT Realtime API: hablar cuesta 4x más que escuchar

Una conversación de voz mediante 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. Esta proporción explica la mayor parte de la factura de una sesión de voz. Antes de entrar en cifras, conviene aclarar los nombres: «GPT Live» es la función de ChatGPT para usuarios finales 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 los que medimos en este artículo.

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 y $0.0768 por minuto para hablar.
• Sesenta segundos de silencio con VAD del servidor generaron cero tokens de entrada facturables.
• En el turno 30, la caché automática cubría el 93% de la entrada; eliminar un elemento del historial triplicó la entrada a precio completo durante un turno.
• Al cancelar una respuesta larga tras 2 segundos de audio, se facturaron 4 segundos.
• gpt-realtime-2.1-mini aplica el mismo sistema de facturación, con precios de audio 3.2 veces menores.

Todas las cifras proceden de sesiones WebSocket instrumentadas que ejecutamos con ambos modelos el 2026-07-19, registrando cada evento del servidor. Los dos modelos están disponibles en el endpoint /v1/realtime del gateway de Synthorai, donde ejecutamos estas sesiones. Tanto el protocolo como la facturación son iguales que al conectarse directamente a OpenAI. El arnés de pruebas es un único archivo Python que solo usa la biblioteca estándar, y cada cifra se puede rastrear hasta un registro de uso response.done sin procesar.

¿Cómo se conecta un cliente a la Realtime API?

A diferencia de las API de texto, Realtime no utiliza un modelo de petición y respuesta sobre HTTP. Se abre un WebSocket por sesión y se intercambian eventos JSON: el cliente transmite el audio del micrófono, el servidor devuelve audio hablado en streaming y una sola conexión transporta 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

Este es el ciclo de vida relevante para la facturación: session.update define las instrucciones, la voz, las herramientas y la detección de turnos, que pasan a formar el prefijo cacheable; input_audio_buffer.append / commit añaden el audio del usuario; response.create solicita una respuesta; y cada response.done incluye el desglose completo del uso de esa respuesta. Hay una diferencia de sintaxis que debe tenerse en cuenta: la API GA utiliza output_modalities y una configuración anidada audio.input/audio.output; el campo response.modalities de la beta se rechaza con unknown_parameter.

¿Cuánto cuesta GPT Realtime por minuto?

Las tasas de conversión oficiales se cumplen token por token: un clip de 30.0 segundos facturó 300 tokens de audio de entrada, 1 por cada 100 ms, y una respuesta hablada de 4.5 segundos facturó 90 tokens de audio de salida, 1 por cada 50 ms. Al aplicar estas conversiones a los precios por token, el coste por minuto queda así:

Hay dos costes que no aparecen en la tabla. Primero, una respuesta hablada también factura salida de texto: la transcripción y los tokens de razonamiento (gpt-realtime-2.1 sí razona; output_token_details.reasoning_tokens devolvió un valor distinto de cero en todas las ejecuciones). En nuestra respuesta corta de prueba, esto añadió aproximadamente un 24% al coste de los tokens de audio, facturado según la tarifa de texto de $24/M.

Segundo, la transcripción adicional se factura por separado. Su registro de uso contiene {"type": "duration", "seconds": 30}: se cobra por duración a $0.017 por minuto, independientemente de los tokens, y la transcripción nunca entra en el input del modelo. Activar esta única opción casi duplica el coste de entrada en 2.1 y casi lo cuadruplica en mini. Solo debe habilitarse cuando un requisito de cumplimiento o del producto necesite realmente el texto.

¿El silencio, las interrupciones o las llamadas a herramientas tienen coste?

El silencio no cuesta nada. Enviamos 60 segundos de silencio a una sesión con el VAD del servidor habilitado y después hicimos una pregunta. El uso fue idéntico, byte por byte, al de una sesión de control que nunca envió audio. El VAD solo confirma el audio que detecta como voz, por lo que la música de espera, un cliente leyendo un formulario o una línea abierta e inactiva generan cero tokens de entrada facturables. El ruido de fondo real sí puede activar el VAD; el silencio puro marca el mínimo, pero no garantiza el mismo resultado en una llamada ruidosa.

Las interrupciones se facturan hasta el punto al que llegó la generación, no hasta lo que oyó el usuario, y nunca por la parte que no llegó a generarse. Pedimos un recuento hablado y lento hasta cuarenta y lo cancelamos tras escuchar 2.0 segundos. Se facturaron 81 tokens de audio, equivalentes a 4.0 segundos. Los 2 segundos adicionales corresponden al audio que la generación había adelantado respecto a la reproducción cuando llegó response.cancel. En mini, el mismo experimento facturó 6.3 segundos porque el modelo pequeño genera con más adelanto respecto al tiempo real. La regla práctica es enviar response.cancel en cuanto el cliente detecte que el usuario interrumpe, ya que el contador sigue corriendo hasta que llega la cancelación.

Las llamadas a herramientas no afectan a la facturación. Una sesión con la definición de una función emitió la llamada, recibió el resultado inyectado y mostró en la respuesta siguiente que el 99% de la entrada se había facturado a precio de caché. Los elementos de llamada a función y sus resultados se almacenan en caché como cualquier otro historial añadido. Las definiciones de las herramientas forman parte del prefijo estático, que queda cacheado a partir del segundo turno.

¿Cómo mantiene la caché un coste razonable en sesiones largas?

La Realtime API vuelve a leer toda la conversación como entrada en cada respuesta, por lo que el input de cada turno crece linealmente con la duración de la sesión. La caché automática de prefijos evita que ese crecimiento dispare el coste: reproducir audio cacheado cuesta $0.40/M en lugar de $32/M, es decir, 1/80 del precio completo. En nuestra sesión de 30 turnos, la proporción cacheada aumentó de forma constante hasta alcanzar el 93% de la entrada en el turno 30:

El desglose de la 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 }
  }
}

Medimos tres aspectos que la documentación oficial no especifica: la caché empieza a aplicarse a partir de unos 128 tokens de prefijo, frente al mínimo documentado de 1,024 en la API de texto; avanza en bloques de 64 tokens; y el prefijo estático puede reutilizarse entre sesiones que usen la misma clave. Este último punto es relevante por el límite de 60 minutos por sesión: el primer turno de una sesión nueva ya facturó sus instrucciones a precio de caché. Al rotar la sesión, solo se paga el precio completo por volver a leer el historial de la conversación, no por el prompt del sistema.

Editar el historial es la única forma de perder el descuento, y medimos la penalización exacta. Al eliminar un elemento antiguo a mitad de la sesión, la proporción cacheada se desplomó durante un solo turno y después se reconstruyó:

También medimos otro efecto favorable: las respuestas habladas del modelo vuelven a entrar en turnos posteriores como texto, no como audio. En una conversación de voz de 8 turnos, el audio de entrada aumentó exactamente en el tamaño del clip del usuario en cada turno, mientras que la parte del asistente reapareció como tokens de transcripción a $4/M. En el componente acumulativo, solo el audio del usuario se paga a la tarifa más alta.

Las recomendaciones son sencillas: mantener el historial en modo append-only; conservar las instrucciones y las definiciones de herramientas idénticas byte por byte durante toda la sesión y entre sesiones; colocar cualquier dato dinámico en el último mensaje del usuario, no en el prefijo; y, si hay que recortar, hacerlo pocas veces y en bloques grandes, no en cada turno. Para consultar el funcionamiento general en distintos proveedores, vea nuestra guía sobre caché de prompts y el estudio de mínimos de caché medidos.

gpt-realtime-2.1 frente a mini: ¿cuál conviene elegir?

El sistema de facturación es idéntico en ambos modelos: mismas tasas de conversión, misma cuantización de caché en bloques de 64 tokens y curvas con la misma forma. Cambian el precio y el comportamiento:

Hay dos detalles relevantes. En la reproducción desde caché, la diferencia de precio casi desaparece ($0.40 frente a $0.30), por lo que una sesión larga con una proporción alta de caché reduce ligeramente la ventaja de mini, aunque los tokens nuevos siguen dominando el total. Además, la velocidad de mini juega en su contra durante las interrupciones: genera con más adelanto respecto a la reproducción, de modo que cada interrupción descarta aproximadamente el doble de audio generado. Aun así, mini fue más barato en todos los escenarios que medimos; la diferencia de precio de 3.2 veces compensa ambos efectos.

Mini es la opción predeterminada para asistentes de comandos breves, IVR y soporte con alta concurrencia. 2.1 encaja mejor cuando la sesión requiere una coordinación compleja de herramientas o razonamiento en varios pasos. OpenAI lo presenta como su modelo principal para seguir instrucciones, un aspecto que nuestro arnés de costes no evalúa deliberadamente.

¿Cuánto cuestan realmente los casos de uso habituales de voz?

En escenarios con muchas interrupciones, debe añadirse el audio generado de más al cálculo por interacción: cada interrupción cobra el audio que oyó el usuario más unos segundos de adelanto de la generación.

Preguntas frecuentes

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

No. GPT Live es la función de voz de las aplicaciones de ChatGPT y no tiene una API ni una página de precios propia. Para ofrecer esa experiencia mediante programación, se usan los modelos de la Realtime API gpt-realtime-2.1 y gpt-realtime-2.1-mini, cuyos precios medimos en este artículo.

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

El límite estricto es de sesenta minutos y una sesión cerrada no puede reanudarse. El historial de texto puede reinyectarse en una sesión nueva, donde se factura una vez a precio completo mientras el prompt estático permanece cacheado. El audio del asistente no puede reproducirse de nuevo, por lo que 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, según nuestra medición, el silencio genera cero tokens facturables con el VAD del servidor. Mantener una línea abierta entre interacciones no cuesta nada, aparte de la propia conexión. Para productos de uso esporádico, una única sesión larga resulta más barata y rápida que reconectar en cada interacción, ya que el establecimiento tardó unos 2.5 segundos.

¿Qué formato de audio espera la API?

PCM16 mono a 24 kHz es el formato predeterminado tanto para la entrada como para la salida. Se configura mediante audio.input.format y audio.output.format en session.update. La facturación no depende del formato: los tokens de audio se calculan únicamente a partir de la duración, a razón de 1 token por cada 100 ms de entrada y 1 por cada 50 ms de salida.

Los patrones de ingeniería para trabajar con el límite de 60 minutos, rotación, transferencia del historial y datos que sobreviven a una reconexión, merecen un artículo aparte. Las cifras de este artículo son la base para hacer esos cálculos. Para consultar cómo se descomponen los tokens facturados entre las distintas familias de la API de texto, vea el artículo complementario sobre la anatomía del uso de tokens.

← Volver al blog