GPT-6 Astra: por qué usar herramientas exige migrar a la API de Responses

Las decisiones prácticas son cuánto trabajo de ingeniería exige la migración y si los nuevos controles pueden reducir el costo de esperar, corregir y reiniciar las ejecuciones de agentes.

Qué cambia con la API de Responses

Antes del lanzamiento, Astra era un modelo de investigación en fase previa al que solo se accedía bajo autorización. La versión de septiembre ya tiene un identificador público, gpt-6-astra, precios definidos y disponibilidad tanto en Chat Completions como en Responses. El acceso comienza por las empresas que participan en el Trusted Access Program de OpenAI; la API y otros planes se habilitarán durante los próximos días.

La elección del endpoint depende de lo que haga la aplicación. Una integración de Chat Completions que solo genera texto puede usar Astra. Si la integración permite que Astra llame funciones propias o herramientas alojadas por OpenAI, tendrá que utilizar la API de Responses.

Responses establece un contrato de aplicación distinto. Chat Completions recibe una lista de mensajes y devuelve una lista de opciones. Responses, en cambio, trabaja con Items tipados: un mensaje es un Item, una function_call es otro y el resultado de la herramienta regresa como function_call_output, asociado al call_id original.

Hay dos trampas de migración fáciles de pasar por alto. Las instructions de nivel superior no se conservan al encadenar solicitudes con previous_response_id, así que hay que enviarlas de nuevo. Structured Outputs también cambia de response_format a text.format. La guía de migración detalla todos los cambios en el parser, el estado, las herramientas y el streaming.

Por qué importa: ahora hay que presupuestar dos cambios

El primer presupuesto es el tiempo de ingeniería. Un bucle de herramientas en producción afecta al endpoint, el esquema de solicitud, el parser de salida, las definiciones de funciones, la correlación de resultados, la gestión del estado, los eventos de streaming, los registros, los reintentos y las evaluaciones. Cambiar solo el nombre del modelo deja casi todo ese trabajo pendiente.

El segundo es el costo por tarea terminada. Con contexto corto y tarifa Standard, GPT-6 Astra cuesta $10.00 por 1 millón de tokens de entrada, $1.00 por entrada en caché, $12.50 por escritura en caché y $50.00 por salida. Las tarifas promocionales vigentes de GPT-5.6 Sol son $4.00, $0.40, $5.00 y $20.00 para esas mismas cuatro categorías. A igual volumen de tokens, el precio de Astra equivale a 2.5 veces el de Sol en cada una.

El endpoint no tiene una tarifa independiente. La factura reúne los tokens del modelo, las herramientas integradas con precio propio, la infraestructura de herramientas de la aplicación, los reintentos y el trabajo descartado. Cuando un prompt supera los 272,000 tokens de entrada, toda la solicitud de Astra pasa a costar el doble en entrada y caché, y 1.5 veces la tarifa de salida. Son las cifras que deben entrar en el presupuesto del piloto según la página de precios vigente.

Hay un posible contrapeso, pero solo los datos de cada carga de trabajo pueden confirmarlo. OpenAI informa de una mejora de entre 40% y 80% en el uso de caché con Responses frente a Chat Completions en pruebas internas. También afirma que Astra obtuvo un costo estimado por tarea más bajo en varias evaluaciones de API porque generó menos tokens de salida, pese al mayor precio por token. Ninguno de esos resultados garantiza un ahorro universal.

Lo que conviene medir es esto:

cost per completed job = model tokens + built-in tool fees + your tool costs + retries + operator time

El denominador es decisivo. Una ejecución barata que debe reiniciarse tras una corrección tardía puede terminar costando más por resultado final que otra más cara que conserva el trabajo útil.

Las herramientas asíncronas cambian el ciclo de espera

Una llamada de función normal detiene el modelo hasta que la aplicación devuelve un resultado. Con Astra, una función ejecutada por la aplicación o una herramienta personalizada puede incluir async: true. El modelo puede emitir la llamada y seguir razonando, invocar otra herramienta independiente o responder una parte autónoma de la solicitud mientras la aplicación completa la tarea.

El servidor de la aplicación sigue siendo responsable del trabajo. Tiene que iniciarlo, mantener un registro, guardar el call_id original y entregar el resultado en una solicitud posterior a Responses. Si se producen otros turnos antes de recibir ese resultado, la continuación debe usar el ID de respuesta más reciente, mientras que la salida de la herramienta sigue apuntando al ID de la llamada original.

En un producto de investigación, una consulta lenta a un proveedor de datos puede ejecutarse mientras Astra organiza las fuentes disponibles. En un agente de operaciones interno, dos consultas independientes de cuentas pueden comenzar pronto, mientras el modelo redacta la parte del informe que no depende de ellas. La ventaja es reducir el tiempo inactivo, no obtener ejecución gratuita.

La intervención a mitad de turno cambia el ciclo de reinicio

La intervención a mitad de turno permite corregir una tarea mientras Astra todavía trabaja. La aplicación envía un evento response.steer por el mismo WebSocket de Responses, lo dirige a la respuesta activa mediante previous_response_id y añade la nueva instrucción. El servidor termina el Item de salida actual y cualquier trabajo ya iniciado por una herramienta alojada; después crea una continuación que incorpora el cambio.

Esto ayuda, por ejemplo, cuando alguien que supervisa una cuenta en una agencia advierte que el informe está dirigido al mercado equivocado, o cuando un responsable de ingeniería necesita reducir el alcance de un plan de migración en curso. La corrección puede llegar antes de que termine todo el turno.

El trabajo consumido no se recupera. La intervención no reescribe una salida ya entregada, no deshace una acción anterior ni cancela una herramienta que ya comenzó. Los límites de tokens y de llamadas a herramientas se aplican por separado a la respuesta original y a su continuación. Su valor empresarial está en evitar reinicios completos cuando la corrección llega tarde, pero hay que medir si ocurre con la frecuencia suficiente para justificarla.

La intervención solo funciona con Astra y requiere el WebSocket de Responses. Las instrucciones en cola existen únicamente en esa conexión, de modo que la aplicación debe registrar cada actualización aceptada y recuperarse con cuidado tras una desconexión. OpenAI limita cada conexión WebSocket a 60 minutos. En implementaciones por WebSocket con 20 o más llamadas a herramientas, la guía del modo WebSocket señala una ejecución integral hasta aproximadamente 40% más rápida, aunque se trata de un resultado del transporte y no de un ahorro garantizado por la intervención.

Un recorrido de migración listo para ejecutar

Conviene comenzar con un flujo de funciones de bajo riesgo, no con el agente de producción que soporta más carga.

Instala la versión actual del SDK de Python y define la variable de entorno tal como indica la guía de inicio rápido de OpenAI:

pip install openai
export OPENAI_API_KEY="your_api_key_here"

Este es el ejemplo ejecutable de OpenAI para herramientas asíncronas, con datos meteorológicos de demostración. Puede probarse cuando el proyecto de API ya tenga acceso a Astra:

import json
from concurrent.futures import ThreadPoolExecutor

from openai import OpenAI
from openai.types.responses import FunctionToolParam

def get_weather(city):
    # Demo data. Replace this function with your weather service.
    weather = {
        "Paris": {
            "city": "Paris",
            "temperature_c": 22,
            "condition": "Clear",
            "source": "demo weather snapshot",
        }
    }
    return weather[city]

worker = ThreadPoolExecutor()

def main():
    client = OpenAI()
    model = "gpt-6-astra"
    tools: list[FunctionToolParam] = [
        {
            "type": "function",
            "name": "get_weather",
            "description": "Read the demo weather snapshot for a city.",
            "async": True,
            "strict": True,
            "parameters": {
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"],
                "additionalProperties": False,
            },
        },
    ]

    instructions = (
        "Start the weather lookup and answer the independent packing "
        "question without waiting. Use the actual tool result when it "
        "arrives; never invent it. Identify the weather as demo data."
    )
    response = client.responses.create(
        model=model,
        tools=tools,
        instructions=instructions,
        input=(
            "Check the demo weather in Paris. Meanwhile, "
            "list three essentials for any city trip."
        ),
    )

    call = next(item for item in response.output if item.type == "function_call")
    arguments = json.loads(call.arguments)
    if call.name != "get_weather" or arguments != {"city": "Paris"}:
        raise ValueError("Expected a weather lookup for Paris")

    latest_response_id = response.id
    if call.async_:
        job = worker.submit(get_weather, **arguments)
        print(response.output_text)
        # Independent work or conversation turns can happen here.
        # Update latest_response_id after each continuation.
        result = job.result()
    else:
        result = get_weather(**arguments)

    response = client.responses.create(
        model=model,
        tools=tools,
        instructions=instructions,
        previous_response_id=latest_response_id,
        input=[
            {
                "type": "function_call_output",
                "call_id": call.call_id,
                "output": json.dumps(result),
            },
        ],
    )
    print(response.output_text)

if __name__ == "__main__":
    try:
        main()
    finally:
        worker.shutdown(wait=True)

La línea que suele olvidarse es call_id: call.call_id. El resultado posterior corresponde a la llamada de herramienta original, aunque otros turnos de la conversación hayan cambiado el ID de respuesta más reciente.

Qué parte conviene a cada equipo

Un equipo de backend que ya llama funciones

Antes de adoptar Astra en ese flujo, hay que presupuestar la migración a Responses. Una transición controlada permite comparar registros y evaluaciones, en lugar de depurar al mismo tiempo un cambio de endpoint, de parser y de modelo.

Un agente SaaS que espera servicios lentos

El modo asíncrono solo debe usarse para trabajo realmente independiente. Una consulta al CRM, una búsqueda interna o una exportación de documentos pueden comenzar mientras Astra resuelve otra rama. Si una dependencia bloquea la siguiente decisión, debe seguir siendo síncrona o utilizar una herramienta explícita de espera.

Un equipo de operaciones o agencia que supervisa tareas largas

La intervención resulta útil para correcciones que, de otro modo, obligarían a cancelar y reiniciar. Conviene registrar cuántos reinicios evita en la práctica y cuánto trabajo completado conserva cada corrección. Así se construye un caso de negocio, no solo una demostración de producto.

Una empresa regulada que utiliza Zero Data Retention

El modo WebSocket de Responses funciona con store: false y Zero Data Retention, pero la responsabilidad del estado recae en la aplicación. Hay que conservar los Items de razonamiento cifrados cuando corresponda, reproducir todo el contexto cuando un ID de respuesta deje de estar disponible y diseñar esa recuperación antes de ofrecer la intervención a los usuarios.

La parte que no conviene maquillar

El acceso a Astra todavía se está desplegando. La migración puede prepararse desde ahora, pero el cambio completo en producción debe esperar a que el proyecto tenga acceso y a contar con evaluaciones de la carga de trabajo específica.

Las herramientas asíncronas exigen un registro de tareas y resultados que pueden llegar fuera de orden. La intervención añade estado de conexión, gestión de continuaciones y recuperación. Ambas funciones pueden reducir esperas o reinicios desperdiciados, y ambas agregan código que puede fallar.

El argumento económico seguirá abierto hasta disponer de telemetría propia. Con el mismo número de tokens, Astra cuesta 2.5 veces las tarifas promocionales de GPT-5.6 Sol. Un mejor uso de caché, menos tokens de salida y menos reinicios pueden cerrar la brecha en algunas tareas. Conviene proteger el piloto con un límite estricto de gasto y evaluar Astra por costo de tarea terminada y tiempo del operador.

Qué hacer el lunes

• Si una aplicación usa llamadas a herramientas con Chat Completions y quiere adoptar Astra, conviene inventariar un flujo de producción y financiar esta semana una ruta paralela con Responses.
• Si una aplicación solo usa texto, lo razonable es mantenerla estable mientras se despliega el acceso. Esa ruta no está obligada a migrar de endpoint.
• Si las herramientas lentas dominan el tiempo total, hay que probar una función asíncrona y medir el tiempo inactivo, los fallos y el costo por tarea terminada.
• Si las correcciones humanas tardías provocan reinicios, la intervención solo debe prototiparse después de superar las pruebas de reconexión y reproducción del WebSocket.
• Si la tarifa de tokens de Astra, equivalente a 2.5 veces la de Sol, rompe la economía unitaria antes de observar alguna compensación medible, esa carga debe seguir en GPT-5.6 Sol, Terra o Luna.

Para recibir el próximo cambio de plataforma convertido en un flujo de trabajo y una decisión presupuestaria, suscríbete al boletín.