El cambio importante de GPT-6 Astra no es otro liderazgo en benchmarks. Es que un agente de larga duración puede recibir una corrección mientras todavía está trabajando.
OpenAI lanzó Astra el 3 de septiembre de 2026, con tres controles para trabajo intensivo en herramientas: mid-turn steering, llamadas asíncronas a herramientas y un modo WebSocket persistente para Responses API. Juntos cambian la forma de una ejecución. Tu aplicación ya no tiene que tratar una solicitud como una caja sellada que solo puede aceptar o descartar cuando el modelo termina.
Esto importa cuando un agente navega, edita código u opera software durante varios minutos. Cuanto más dura una ejecución, más probable es que sus supuestos queden obsoletos. Un cliente cambia la prioridad. Una persona detecta el registro equivocado. Una herramienta devuelve un resultado que hace inútil el plan original. Esperar hasta el final no es control.
La ejecución se convierte en un proceso vivo
El mid-turn steering permite que una aplicación envíe nuevas instrucciones mientras una respuesta está en curso. El modelo incorpora esa entrada en la misma ejecución en lugar de comenzar otra vez desde una solicitud vacía.
Parece una función de chat. En términos operativos, se parece más a modificar un trabajo mientras se ejecuta. Si un agente compara proveedores y descubres que la fecha de entrega importa más que el precio unitario, la acción útil es redirigir la búsqueda pendiente. Cancelar cuando la investigación ya terminó desperdicia tiempo y llamadas a herramientas. Dejar que el plan obsoleto continúe produce una respuesta pulida a la pregunta equivocada.
La consecuencia de diseño es fácil de pasar por alto: el steering necesita una superficie de producto. Una persona debe ver suficiente del plan actual y de la actividad de las herramientas para saber cuándo conviene intervenir. Un campo que acepta una corrección pero no muestra qué hace el agente es técnicamente controlable y prácticamente opaco.
Las herramientas ya no tienen que formar una cola
Las llamadas asíncronas a herramientas separan el inicio de una herramienta de la espera por su resultado. Un agente puede lanzar una tarea cuyo resultado llegará después, continuar con pasos independientes y consumirlo cuando sea relevante.
Esto resulta especialmente útil con sistemas lentos: una exportación de datos, un análisis de repositorio, una tarea de navegador o una aprobación interna. El patrón anterior convierte cada espera en parte de una cadena serial. El patrón asíncrono expone un pequeño planificador dentro de la ejecución.
Eso crea una responsabilidad para tu aplicación. Las llamadas paralelas necesitan identificadores, plazos y una política clara para resultados tardíos. Si una instrucción nueva vuelve irrelevante una llamada pendiente, debes cancelarla cuando sea posible o marcar su resultado futuro como obsoleto. De lo contrario, la concurrencia solo hace que el trabajo equivocado ocurra más rápido.
También cambia la evaluación. Una respuesta final puede parecer correcta aunque el recorrido haya lanzado llamadas duplicadas, ignorado un timeout o usado un resultado obsoleto. Las pruebas deben registrar la secuencia de eventos, no solo calificar el último párrafo.
Una conexión puede conservar el estado de trabajo
El modo WebSocket de OpenAI mantiene una conexión persistente con Responses API para flujos largos e intensivos en herramientas. Admite conversaciones paralelas, bifurcaciones y entradas incrementales. Un cliente continúa un turno con elementos nuevos y el identificador de una respuesta anterior en lugar de reenviar todo el intercambio.
La ventaja práctica no es que WebSocket sea nuevo. Es que el transporte ahora encaja con un agente que permanece activo, bifurca trabajo y recibe instrucciones durante la ejecución. Según la documentación de lanzamiento, el sistema también conserva prompt caching cuando cambia el nivel de razonamiento a mitad de conversación.
El estado persistente crea problemas conocidos de sistemas distribuidos. Las conexiones se caen. Los clientes se reconectan. Los eventos pueden llegar dos veces o en un orden diferente al que espera la interfaz. Una implementación de producción todavía necesita un estado de ejecución duradero fuera del socket, idempotencia para efectos laterales de herramientas y una estrategia de reproducción para la interfaz.
No permitas que una conexión persistente sea el único registro de lo ocurrido. Guarda el identificador de la ejecución, las instrucciones de steering, las solicitudes y resultados de herramientas y la disposición final. Ese registro permite explicar por qué un agente cambió de dirección o actuó sobre una versión concreta del brief.
Qué cambia para los equipos que entregan este trimestre
Empieza por separar intervención y cancelación. Un botón de parada sigue siendo necesario, especialmente antes de un efecto lateral, pero no debe ser el único control. Añade una forma de corregir el objetivo, reducir el alcance o sustituir un supuesto incorrecto sin perder el trabajo útil ya completado.
Después, define qué llamadas pueden solaparse. La investigación de solo lectura suele ser más fácil de paralelizar que pagos, despliegues o actualizaciones de registros. Las herramientas con efectos laterales necesitan orden explícito y confirmación incluso cuando el modelo puede llamarlas de forma asíncrona.
Por último, evalúa la recuperación. Interrumpe el WebSocket durante una ejecución. Entrega una instrucción de steering después de lanzar una herramienta lenta. Devuelve dos resultados en el orden opuesto. Reinicia el cliente y verifica que el usuario todavía pueda entender el estado actual. Estas pruebas revelan más que otro conjunto de prompts ideales.
OpenAI informa que Astra completó sus tareas de OSWorld en aproximadamente 40 minutos frente a unos 75 minutos de GPT-5.6 Sol, con una puntuación también superior en esa evaluación. Son resultados de benchmarks y simulaciones del proveedor, no una garantía de latencia para tu flujo. Tu métrica útil es cuánto trabajo sobrevive a una corrección, una desconexión o un cambio de requisitos.
Lo que esto no cambia
La capacidad de interrupción no es control de permisos. Un agente controlable todavía puede acceder a una herramienta que nunca debería usar. Mantén la autorización, la confirmación y el privilegio mínimo fuera del modelo.
Tampoco es fiabilidad por sí sola. Las llamadas asíncronas y las sesiones persistentes añaden estados que tu aplicación debe observar y recuperar. Sin un registro de eventos y herramientas idempotentes, los nuevos controles pueden hacer que los fallos sean más difíciles de reconstruir.
La disponibilidad también es limitada durante el despliegue, y las funciones de API requieren Responses API. Los equipos que usan otra interfaz no obtienen estos controles por cambiar solamente el nombre del modelo.
El lanzamiento ofrece mejores primitivas para un hecho incómodo: el trabajo útil de un agente dura lo suficiente para que la realidad cambie debajo de él. El trabajo de ingeniería consiste en hacer ese cambio visible, corregible y seguro.
Escrito por Dandelion Labs