AIREITERUn agente de voz que espera a que termine el silencio antes de empezar a pensar puede ser rápido y, aun así, sonar robótico. GPT-Live ataca esa limitación desde la arquitectura: mantiene una escucha y una conversación continuas, mientras la búsqueda, las herramientas y el razonamiento profundo se ejecutan en paralelo, fuera del bucle de audio. El resultado es una interacción más natural, pero también un sistema bastante más complejo de operar.
La arquitectura de la API full-duplex de GPT-Live, en un minuto
GPT-Live no es simplemente un endpoint de voz a voz más rápido. OpenAI lo describe como un sistema de voz full-duplex capaz de procesar audio entrante mientras genera audio saliente, tomar decisiones de interacción varias veces por segundo y delegar el trabajo más profundo en un modelo frontier. Según el análisis técnico de OpenAI, el sistema se diseñó alrededor de inferencia en streaming, una conversación con estado, transporte WebRTC y trabajo asíncrono fuera de la ruta de medios.
El modelo práctico es el siguiente:
| Capa | Responsabilidad | Consecuencia de diseño |
|---|---|---|
| Ruta de medios | Mover los fotogramas de audio entre el cliente y el modelo de voz | Mantenerla breve, predecible e independiente de las API de negocio |
| Modelo de voz full-duplex | Escuchar, hablar, pausar, gestionar interrupciones y controlar el ritmo de la conversación | No convertir la detección de turnos basada en silencios en el controlador principal |
| Capa de delegación | Ejecutar búsquedas, razonamiento y herramientas de forma asíncrona | Tratar el trabajo delegado como una tarea en segundo plano sensible a la latencia |
| Capa de aplicación | Validar herramientas, permisos, confirmaciones y reglas de negocio | No permitir nunca que una respuesta fluida autorice una acción importante |
| Registro del producto | Conservar transcripciones, analítica y mensajes de la interfaz | Mantener separadas las vistas provisionales y definitivas de la conversación |
El cambio importante está en quién controla el tiempo. En un agente de voz convencional, la aplicación espera a que termine el turno del usuario, lo envía al modelo y después reproduce la respuesta. En el diseño de GPT-Live, la sesión de voz permanece activa mientras varios tipos de trabajo se ejecutan de forma simultánea.
La lógica basada en turnos debe pasar a segundo plano
Los sistemas de voz en cascada ejecutan, en secuencia, la conversión de voz a texto, un modelo de lenguaje y la conversión de texto a voz. Los modelos nativos de voz a voz eliminan algunos de esos pasos intermedios, pero un detector de actividad de voz independiente todavía puede decidir que el usuario ha terminado antes de iniciar la inferencia. Una breve pausa para pensar puede interpretarse como el final del turno; el ruido de fondo, como uno nuevo.
El enfoque full-duplex de GPT-Live traslada ese problema de sincronización al modelo de voz. Puede seguir escuchando mientras habla, detectar una interrupción, pausar, continuar o emitir una breve confirmación. Eso no elimina los límites entre turnos en todos los niveles. Significa que esos límites ya no pueden bloquear el bucle de audio en tiempo real.
Qué cambia GPT-Live en la ruta de tiempo real
La inferencia continua sustituye al bloqueo por turnos
En una sesión full-duplex, la entrada y la salida son flujos, no bloques de audio alternos. El modelo puede recibir una nueva intervención mientras todavía reproduce su respuesta anterior. También puede decidir si el audio entrante es una interrupción relevante, una breve confirmación o simplemente ruido de fondo.
Esto cambia la lógica del cliente. Debe estar preparado para enviar, recibir, cancelar y sustituir eventos de audio de forma simultánea. Una abstracción basada únicamente en await response() encaja mal con este comportamiento, porque oculta precisamente los eventos más importantes: inicio de la voz, inicio del audio del asistente, detección de una interrupción, solicitud de una herramienta, cancelación de la respuesta y cierre de la sesión.
Los desarrolladores deben conservar las señales de actividad de voz para la interfaz, la analítica y la seguridad. El error arquitectónico consiste en usar VAD como única autoridad para decidir cuándo puede comenzar la inferencia del modelo.
Audio rápido; trabajo pesado fuera de la ruta
El análisis técnico de OpenAI separa la ruta de audio dedicada de la lógica de aplicación. El audio viaja directamente entre el cliente y el modelo de voz, mientras que las llamadas a herramientas, las comprobaciones de políticas, la persistencia y las operaciones del backend atraviesan una frontera asíncrona.
Esa frontera impone una regla clara: una consulta lenta al CRM puede retrasar su propia respuesta, pero no debería impedir que los fotogramas de audio lleguen a tiempo. WebRTC proporciona el transporte de medios de baja latencia; los servicios de aplicación no deberían interponerse de forma síncrona entre cada fotograma del micrófono y el modelo.
La capa de voz puede decir algo breve mientras se ejecuta una tarea delegada, pero las frases de relleno no sustituyen a un trabajo con límites definidos. Establece plazos, reglas de cancelación y un estado de resultado seguro para cada herramienta.
La delegación separa la capacidad de respuesta de la inteligencia
GPT-Live puede delegar búsquedas, razonamiento profundo o tareas complejas en un modelo frontier. Los artículos de lanzamiento y de ingeniería de OpenAI identifican GPT-5.5 como el modelo delegado en el lanzamiento. El modelo de voz sigue siendo responsable de la interacción inmediata; el modelo frontier se ocupa del trabajo que no encaja bien en un bucle de conversación de baja latencia.
En producción, la delegación debería tratarse como una canalización independiente:
- Detectar que la petición necesita una búsqueda, razonamiento o una herramienta.
- Confirmar la recepción o pausar sin bloquear la ruta de medios.
- Iniciar el trabajo en segundo plano con el contexto relevante de la conversación.
- Cancelarlo si el usuario cambia de dirección o termina la sesión.
- Validar el resultado en la aplicación.
- Inyectar un resultado conciso en la sesión activa.
Inicializar por adelantado la sesión de inferencia delegada, mantener la afinidad de sesión y almacenar en caché el contexto repetido puede reducir el tiempo hasta que llega un resultado útil. El presupuesto de extremo a extremo incluye el enrutamiento, el procesamiento del prompt, la inferencia del modelo, las llamadas a herramientas y cada ida y vuelta entre el modelo y la herramienta, no solo la latencia de los tokens del modelo.
Las sesiones con estado necesitan una segunda arquitectura
Una llamada de voz larga no es una sucesión de peticiones desechables. El contexto crece, cambian los workers del modelo y puede ser necesario compactar la sesión. OpenAI describe un proceso en el que se prepara una nueva instancia del modelo, se carga en ella el contexto actual y se realiza el cambio solo cuando está lista. Así se evita que una transición de infraestructura sea audible para la persona que llama.
La compactación del contexto plantea un problema parecido. Resumir los turnos anteriores modifica el contexto que sostiene la caché de pares clave-valor del modelo. Reconstruir esa caché en primer plano provocaría una pausa. Un diseño más seguro compacta el contexto en paralelo, prepara una instancia de sustitución y mantiene la instancia antigua en servicio hasta que la transferencia está lista.
Por tanto, el estado de sesión de un backend para agentes de voz debería incluir algo más que una transcripción:
- Estado actual del audio y de la respuesta
- Llamadas a herramientas activas y tokens de cancelación
- Afinidad con la instancia del modelo o el worker
- Mensajes provisionales y definitivos
- Estado de la compactación del contexto
- Estado de reconexión y recuperación
- Estado de seguridad y confirmaciones
El contrato de la API es un sistema de eventos, no de petición y respuesta
El full-duplex cambia el protocolo interno, aunque la API externa acabe ofreciendo métodos familiares en sus SDK. La aplicación necesita distinguir explícitamente entre eventos que suelen mezclarse:
| Evento | Significado | Respuesta correcta |
|---|---|---|
| Cancelación | Detener una operación pendiente | Cancelar el trabajo y liberar recursos |
| Interrupción | El usuario habla mientras se reproduce la salida actual | Detener o modificar el audio del asistente sin cerrar la sesión |
| Finalización de sesión | La llamada o la conversación ha terminado | Cerrar el estado de medios, herramientas, persistencia y facturación |
| Fallo de herramienta | Una acción delegada no se ha completado | Explicarlo de forma segura y ofrecer una alternativa |
| Reconexión | La ruta de medios se ha interrumpido | Restaurar el estado sin duplicar acciones |
GPT-Live puede funcionar de forma continua, pero el resto del producto sigue necesitando mensajes para la interfaz, la analítica y los sistemas de seguridad. OpenAI describe el mantenimiento de una vista especulativa que puede revisarse a medida que llegan las transcripciones y de un registro autorizado que se consolida más tarde. Es un patrón útil: mostrar subtítulos con rapidez sin tratar cada transcripción parcial como un hecho inmutable.
Qué deben rediseñar los equipos de agentes de voz
Separa el adaptador de medios de la orquestación del agente
Encapsula el transporte específico del proveedor y la gestión de eventos en un adaptador. La aplicación debería consumir eventos normalizados como user_audio_started, assistant_interrupted, tool_requested, confirmation_required y response_completed.
Mantén el ID del modelo, la voz, los prompts, los esquemas de herramientas y los límites de coste en la configuración. No es solo una protección frente a futuras migraciones. También permite que el equipo pruebe hoy un modelo Realtime documentado y conserve al mismo tiempo un objetivo explícito para adoptar más adelante la semántica de GPT-Live.
Con las herramientas, el modelo propone y la aplicación valida. Los pagos, los cambios de cuenta, las cancelaciones, las modificaciones de direcciones, el triaje médico, las operaciones financieras y los flujos de identidad necesitan reglas de confirmación fuera de la confianza que transmita la voz del modelo.
Elige el transporte según dónde se controle el audio
WebRTC es la opción natural para clientes web y móviles que capturan y reproducen el audio directamente. WebSocket puede seguir siendo útil en canalizaciones de medios controladas por el servidor, pero los equipos no deberían asumir que todos los modelos en tiempo real aceptan la misma estructura de sesión a través de cualquier transporte.
Un problema de integración de OpenClaw documenta el fallo práctico: tratar gpt-live-1 como una sesión WebSocket Realtime GA convencional produjo una respuesta invalid_model, mientras que el flujo de navegador GPT-Live propuesto utilizaba una estructura de sesión WebRTC distinta. El problema es un informe de implementación, no un contrato de la API de OpenAI, pero refuerza una regla de diseño: detectar la familia del modelo y negociar explícitamente el tipo de sesión compatible.
Mide los fotogramas que llegan a tiempo, no solo la latencia de los tokens
El artículo de ingeniería de OpenAI informa de que un componente de streaming de soporte llegó al límite antes que la capacidad de GPU durante las pruebas de producción. La unidad de capacidad útil era el número de sesiones simultáneas sostenibles con entrega puntual de fotogramas, no las peticiones por GPU.
Como mínimo, mide:
- Retrasos y pérdidas de fotogramas de audio
- Tiempo hasta el primer audio reproducible
- Tiempo desde la interrupción hasta la detención
- Sesiones simultáneas por región
- Reconexiones y llamadas duplicadas a herramientas
- Tiempo de finalización de la delegación
- Tasas de timeout y cancelación de herramientas
- Correcciones entre la transcripción provisional y la definitiva
- Sesiones abandonadas y gasto por sesión
La naturalidad también plantea un problema de control. A algunos usuarios puede gustarles el comportamiento de interrupción y confirmación en un contexto, pero resultarles intrusivo en otro. Un informe temprano de un usuario resumió el riesgo sin rodeos: “It's literally cutting her off constantly lmao” (@AutismCapital). Tómalo como un recordatorio de que la política de intervención debe ajustarse con conversaciones reales, no con demostraciones guionizadas.
GPT-Live frente a la decisión de diseño Realtime actual
El catálogo oficial de modelos de OpenAI sitúa ahora GPT-Live 1 como modelo para conversaciones de voz naturales y expresivas, y destaca su gestión fluida de las interrupciones. Ese catálogo no equivale a un contrato de integración completo: la página independiente de la API de GPT-Live analizada aquí sigue siendo un formulario de notificación sin detalles sobre endpoints, límites de uso o cuotas. Verifica la documentación actual para desarrolladores y la disponibilidad en tu cuenta antes de comprometer un plan de lanzamiento.
| Necesidad | Elección práctica |
|---|---|
| Lanzar ahora un agente de voz documentado | Usar la pila Realtime documentada detrás de un adaptador |
| Conservar como requisito la superposición natural y la gestión de turnos controlada por el modelo | Diseñar para el modelo de eventos full-duplex de GPT-Live y validar primero el acceso |
| Audio en navegador o móvil | Priorizar la ruta WebRTC compatible con el proveedor |
| Acciones empresariales complejas | Mantener herramientas asíncronas y confirmaciones en la aplicación |
| Llamadas largas | Implementar antes del lanzamiento la transferencia, la compactación, la reconexión y la gestión de estado persistente |
Merece la pena adoptar esta arquitectura incluso antes de que el modelo esté disponible para todas las cuentas. Los medios continuos, los eventos normalizados, las herramientas asíncronas y la cancelación explícita mejoran cualquier agente de voz construido sobre un modelo realtime convencional.
Preguntas frecuentes sobre la API full-duplex de GPT-Live
¿GPT-Live es lo mismo que GPT-Realtime?
No. OpenAI presenta GPT-Live como una familia de modelos distinta para conversaciones de voz, mientras que GPT-Realtime es la familia de API realtime documentada. Que compartan capacidades de audio no garantiza que tengan la misma semántica de sesión, los mismos transportes o los mismos ID de modelo.
¿Full-duplex significa que el modelo nunca espera?
No. Significa que el sistema puede escuchar y hablar al mismo tiempo. El modelo puede pausar, permanecer en silencio, esperar una aclaración o retrasar un resultado delegado cuando sea más seguro o útil hacerlo.
¿Los desarrolladores siguen necesitando VAD?
Sí, para la experiencia de uso de los medios, la analítica, los subtítulos y las señales de seguridad. VAD no debería ser el único mecanismo que obligue al modelo a seguir una secuencia rígida de turno del usuario y turno del asistente.
¿Qué transporte debe usar un agente de voz?
Utiliza el transporte compatible con el cliente y el modelo concretos. WebRTC suele ser adecuado para el audio directo en navegador o móvil; las canalizaciones de medios del backend pueden utilizar WebSocket cuando esté documentado. No deduzcas la compatibilidad del transporte a partir del nombre del modelo.
¿Qué conviene construir antes de confirmar el acceso?
Construye el adaptador, el esquema de eventos normalizado, la capa de validación de herramientas, el modelo de cancelación, la telemetría de costes, las alternativas y la recuperación de sesiones largas. Estos componentes seguirán siendo útiles aunque cambie el contrato final de la API GPT-Live.
Elige la arquitectura, no el nombre del modelo
La decisión que perdura es dejar de tratar la voz como una simple capa de petición y respuesta alrededor de un modelo de texto. Mantén la ruta de audio disponible de forma continua, coloca el trabajo lento detrás de fronteras asíncronas, convierte las interrupciones y cancelaciones en elementos de primer nivel y conserva una transcripción que pueda revisarse antes de convertirse en el registro autorizado.
El compromiso de GPT-Live está claro: una superposición de voces más natural y la delegación exigen más estado, más observabilidad y menos control mediante simples límites entre turnos. Los equipos que acepten esa complejidad pueden diseñar desde ahora para el contrato full-duplex; los que necesiten un endpoint de producción documentado deberían lanzar su producto sobre Realtime, manteniendo las mismas separaciones orientadas a eventos.