Que GPT-6 Astra pueda manejar una interfaz no significa que el modelo tenga acceso directo a tu ordenador. En una integración por API, tu aplicación proporciona el navegador o escritorio, ejecuta lo solicitado y devuelve lo que ha ocurrido. También decide qué acciones requieren permiso y qué señal demuestra que la tarea terminó de verdad.
Hay otra cautela previa: a 4 de septiembre de 2026, Astra se está desplegando primero para empresas del Trusted Access Program. OpenAI anuncia el acceso para API, Plus, Pro, Business y Enterprise durante los días siguientes, pero no una apertura simultánea para todas las cuentas. La referencia correcta es la información actual del despliegue, seguida de una comprobación con las credenciales del proyecto que ejecutará la automatización.
Comprueba el acceso antes de construir el agente
El identificador de API es gpt-6-astra. Que aparezca en una noticia, en la documentación o en el selector de ChatGPT no demuestra que una API key pueda usarlo. Los permisos del workspace de ChatGPT y los de la organization/project a la que pertenece la clave son independientes, como aclara la guía de disponibilidad para workspaces.
Empieza con una llamada mínima, sin tools ni parámetros heredados:
bashcurl https://api.openai.com/v1/responses \ -H "Authorization: Bearer $OPENAI_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-6-astra", "input": "Responde exactamente: acceso confirmado" }'
Guarda el estado HTTP y el cuerpo completo. Una respuesta válida solo confirma que ese proyecto pudo invocar el modelo en ese momento; no demuestra que otra cuenta, región o aplicación tenga el mismo acceso. Si la llamada falla, resuelve primero la habilitación del modelo. Añadir un navegador, un runtime y permisos de escritura solo haría más difícil localizar el problema.
La ficha de GPT-6 Astra enumera Responses, Chat Completions y Batch, pero el uso de tools con Astra exige Responses API. La guía de actualización del modelo también limita reasoning.effort a low, medium, high, xhigh y max; none devuelve HTTP 400. Conviene validar el modelo con su configuración mínima antes de trasladar opciones antiguas.
Dos formas de actuar sobre una interfaz
OpenAI recomienda code execution para nuevas integraciones de computer use con Astra. El tool nativo computer sigue admitido como alternativa. No son dos nombres para el mismo mecanismo: cambia lo que produce el modelo y lo que debe devolver la aplicación.
| Decisión práctica | code execution | Tool computer |
|---|---|---|
| Qué solicita Astra | Una llamada a una función propia con código PyAutoGUI o Playwright | Un computer_call con una lista ordenada actions[] |
| Qué ejecuta tu sistema | El script dentro de un servicio aislado | Cada acción permitida de ratón, teclado o captura |
| Qué se devuelve | function_call_output con el call_id original | computer_call_output y un computer_screenshot actualizado |
| Ventaja principal | Puede agrupar lógica, condiciones y bucles en una sola ejecución | Las acciones quedan explícitas y pueden examinarse una a una |
| Control imprescindible | Restringir el lenguaje y los helpers expuestos al script | Filtrar el lote y detenerse antes de la primera acción sensible |
La opción adecuada depende de la ejecución, no del nombre de la tarea. Si una secuencia requiere leer la página, tomar una decisión y repetir varias operaciones dentro del mismo entorno, el código reduce viajes entre modelo y aplicación. Si necesitas inspeccionar y autorizar acciones elementales antes de ejecutarlas, computer ofrece una representación más directa. La guía oficial de computer use mantiene ambas posibilidades y también permite conservar interfaces existentes basadas en function calling o remote MCP.
Siempre que exista una API estructurada, un conector con permisos estrechos o una operación DOM fiable, suele ser preferible a mover el ratón por coordenadas. Reserva el control visual para estados que solo pueden observarse o modificarse a través de la interfaz.
code execution: el runtime es parte del producto
En la vía recomendada, Astra no ejecuta por sí mismo PyAutoGUI ni Playwright. Se le presenta una función, por ejemplo execute_in_sandbox, y la respuesta contiene un item function_call. La aplicación analiza los argumentos, aplica sus políticas, ejecuta el código y devuelve el resultado.
El bucle lógico puede expresarse así:
textresponse = crear_respuesta(model="gpt-6-astra", tools=[execute_in_sandbox], input=tarea) mientras exista un item de tipo function_call: validar(item.arguments) pedir_confirmacion_si_corresponde(item.arguments) resultado = sandbox.ejecutar(item.arguments) response = crear_respuesta( model="gpt-6-astra", previous_response_id=response.id, input=[{ "type": "function_call_output", "call_id": item.call_id, "output": resultado }], tools=[execute_in_sandbox] )
call_id enlaza una ejecución con la solicitud que la originó; previous_response_id continúa el contexto de Responses API. Ninguno de los dos conserva el proceso del navegador. Tu servicio debe mantener por separado la sesión, las cookies autorizadas, el tamaño de la ventana y cualquier variable que necesite el siguiente script.
El servicio execute_in_sandbox de los ejemplos de OpenAI pertenece a la aplicación del desarrollador: no es un endpoint alojado por OpenAI. Debe ejecutarse en un contenedor o máquina virtual desechable, con mínimos privilegios, separado del cliente de API y de sus credenciales. Restringe red, dominios, CPU, memoria, disco y duración real del proceso. Un timeout del cliente no detiene necesariamente un script que sigue corriendo en el servidor. Tampoco vm de Node.js ni unos globals recortados de Python constituyen por sí solos una barrera de seguridad, según la guía de integración.
Una función puede contener diez clics aunque Responses API muestre una sola llamada. Por eso la confirmación no debe limitarse al nombre del tool: los helpers que escriben datos, pulsan «Comprar», envían un formulario o cambian permisos deben bloquearse en el punto exacto donde producirían el efecto.
Tool computer: ejecuta el lote, devuelve la pantalla
La alternativa nativa se habilita con tools: [{ "type": "computer" }]. Astra puede responder con un computer_call que agrupa varias acciones en actions[]. La aplicación debe mantener el orden, rechazar acciones no permitidas y detener el lote antes de la primera que necesite consentimiento.
Tras ejecutar las acciones aceptadas, la siguiente petición conserva el previous_response_id y devuelve una observación con esta forma:
json{ "type": "computer_call_output", "call_id": "call_original", "output": { "type": "computer_screenshot", "image_url": "data:image/png;base64,..." } }
El call_id debe ser el del computer_call recibido. La captura debe representar la pantalla posterior a la ejecución, no una imagen anterior almacenada en caché. OpenAI recomienda normalmente detail: "original" para conservar precisión de coordenadas; si reduces la imagen, también debes transformar las coordenadas del modelo al espacio original. Las capturas grandes consumen más tokens y siguen sujetas a los límites de imagen, de modo que «máxima resolución» no es una regla universal.
Hay una diferencia crítica entre dos estados llamados completed: computer_call.status: "completed" indica que el modelo terminó de generar la llamada. No confirma que tu ejecutor haya realizado las acciones. Si la respuesta de API está incompleta, contiene una acción parcial o alcanza un límite de la aplicación, el bucle debe detenerse sin improvisar el resto.
La conversación continúa; el navegador puede haber desaparecido
Una integración fiable guarda al menos cuatro relaciones: el response.id, cada call_id, el identificador de la sesión del entorno y la observación resultante. Conviene registrar también si la llamada ya se ejecutó para que un reintento de red no repita un pago, un envío o un borrado.
previous_response_id permite a Astra razonar con los items anteriores, pero no restaura una pestaña cerrada, un login caducado ni las variables de un contenedor recreado. Si pierdes el entorno y continúas la conversación, el modelo puede razonar sobre una pantalla que ya no existe. En ese caso, vuelve a obtener el estado real y decide si puedes reanudar de forma segura; no presentes una captura nueva como si fuera continuación automática de la anterior.
Define límites propios de pasos, tiempo y coste. Son condiciones de parada de tu aplicación, no cifras que deban copiarse de un ejemplo. Cuando se alcance un límite, conserva el último estado observable y devuelve el control a una persona. Un mensaje final fluido del modelo no justifica ampliar el presupuesto ni ejecutar acciones pendientes.
El consentimiento debe llegar antes del efecto
Una página web, un correo, un PDF o la salida de otro tool puede contener instrucciones que intenten cambiar el objetivo del agente. Ese texto es contenido de terceros, no permiso del usuario. Trátalo como entrada no fiable aunque aparezca dentro de una aplicación legítima.
Solicita confirmación justo antes de cualquier acción con consecuencias: comprar, enviar datos, borrar, publicar, conceder permisos o cambiar una configuración de seguridad. Escribir un secreto o un dato personal en un formulario ya cuenta como transmisión; no esperes al clic final. La confirmación debe decir qué se hará, sobre qué cuenta o recurso y qué efecto tendrá. Si el estado cambia mientras esperas, vuelve a mostrar la decisión con la información actual.
Los controles prácticos se refuerzan entre sí:
- usa una cuenta de prueba y datos ficticios cuando sea posible;
- limita sitios, red y acciones disponibles;
- separa las credenciales de API del entorno que visita páginas;
- permite cancelar la ejecución y comprueba que la cancelación detiene el proceso real;
- guarda recibos de ejecución sin registrar secretos ni capturas innecesarias;
- exige intervención humana para contraseñas, barreras del navegador o del sitio y operaciones irreversibles.
El sistema de monitorización de seguridad de Astra puede detectar algunos problemas, pero puede avisar tarde, omitirlos o señalar una tarea legítima. Tampoco revierte lo ya ejecutado. La documentación de misalignment monitoring lo presenta como una señal adicional, no como sustituto de permisos, aislamiento y comprobaciones en la aplicación.
Verifica el resultado fuera del texto del modelo
Antes de ejecutar, traduce la tarea a una condición observable. «Subir el informe» no termina cuando aparece una llamada ni cuando Astra dice «hecho». Termina cuando el archivo correcto figura en la cuenta correcta, con el nombre esperado, y una lectura posterior confirma que está disponible. Si además existe un registro de servidor o una API de consulta, úsalo como segunda comprobación.
Después de la última llamada:
- captura o lee de nuevo el estado de la interfaz;
- comprueba la condición concreta de éxito y las prohibiciones acordadas;
- revisa si hubo efectos parciales o duplicados;
- conserva una referencia mínima que permita investigar el fallo;
- cierra o destruye el entorno cuando ya no deba persistir.
Una comprobación visual es adecuada cuando la interfaz es la fuente del estado. No sustituye una verificación estructurada cuando existe una fuente más fiable. Un banner de éxito puede aparecer aunque la operación posterior haya fallado; una respuesta HTTP 200 puede transportar una llamada que nunca llegó a ejecutarse.
No migres el preview directamente a Astra
La migración documentada para una integración antigua es específica: el modelo computer-use-preview pasa a gpt-5.6-sol, el tipo computer_use_preview pasa a computer, la acción individual se convierte en actions[] y deja de exigirse truncation: "auto". Esa tabla no indica una migración directa a GPT-6 Astra. Está recogida en el apartado de migración de la guía oficial de integración.
Para mantener una integración preview, migra primero según ese contrato y valida que conserva su comportamiento. Para una integración nueva con Astra, evalúa por separado la recomendación actual de code execution. Mezclar ambas decisiones puede producir un payload aparentemente razonable que no corresponde a ninguna de las dos interfaces.
Los modelos preview pueden retirarse con un aviso mucho más corto que los modelos estables, pero OpenAI no ha publicado en esta fuente una fecha concreta de retirada para computer-use-preview. No inventes un plazo: registra qué integración usa el modelo antiguo y prepara una migración que puedas ensayar sin afectar a producción.
Qué debe quedar demostrado antes de ampliar el uso
Un piloto está listo para crecer cuando la misma tarea puede repetirse con un resultado verificable, no cuando el modelo completa una demostración vistosa. Prueba también los fallos: ausencia de acceso a Astra, sesión caducada, captura desactualizada, respuesta incompleta, acción rechazada, solicitud de confirmación, cancelación, timeout y reintento de una llamada ya ejecutada.
La aceptación debe responder a preguntas sencillas: ¿se usó el proyecto correcto?, ¿cada call_id se ejecutó como máximo una vez?, ¿el navegador seguía en el estado esperado?, ¿las acciones sensibles esperaron autorización?, ¿los límites detuvieron el runtime?, ¿la comprobación final leyó el estado real? Solo entonces tiene sentido estimar coste y volumen; para ello, la guía de precios de GPT-6 Astra separa tokens, herramientas, procesamiento y coste por tarea aceptada.
Si Astra aún no está habilitado, la decisión correcta puede ser esperar, seguir con una integración compatible o mantener una persona en el circuito. Si está habilitado, el trabajo importante sigue fuera del nombre del modelo: proporcionar un entorno estrecho, ejecutar con consentimiento y demostrar qué cambió realmente.
