Qué cambia al pasar de Assistants API a Responses API

Responses API combina una interfaz más directa con las capacidades de herramientas que anteriormente hacían atractiva a Assistants API. En consecuencia, ya no necesitas reproducir exactamente el ciclo Assistant → Thread → Run → Run Step.

Además, resulta útil separar tres responsabilidades: la configuración del modelo, el estado de la conversación y la ejecución de acciones reales. De ese modo, tu aplicación mantiene el control del negocio mientras OpenAI se ocupa del razonamiento y la generación.

Assistants API vs Responses API: equivalencias principales

Cómo migrar Assistants API a Responses API paso a paso

Ejemplo práctico con Conversations y Responses API

El siguiente patrón crea una Conversation para un usuario. En producción, debes guardar su identificador en una base de datos persistente como PostgreSQL, MySQL o Supabase.

from openai import OpenAI

client = OpenAI()

conversation = client.conversations.create(
    metadata={
        "customer_id": "cliente_123"
    }
)

print(conversation.id)

Una vez que tienes el ID, puedes utilizar esa Conversation en las siguientes Responses. De este modo, mantienes continuidad sin depender de un Thread antiguo.

Crear una Response utilizando GPT-5.6

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.6",
    conversation="conv_xxxxx",
    instructions=(
        "Eres un asistente de soporte. "
        "Responde únicamente con información confirmada."
    ),
    input="¿Cuál es el estado de mi solicitud?"
)

print(response.output_text)

En consecuencia, el cambio reduce parte de la lógica que anteriormente necesitaba crear un Run, esperar su ejecución y recuperar después los Messages correspondientes.

Cómo migrar las herramientas de tu Assistant

Además, una de las ventajas de Responses API es que las herramientas son parte central de la arquitectura. OpenAI mantiene tools integradas y también admite funciones propias y servidores MCP remotos.

Ejemplo de function calling

tools = [
    {
        "type": "function",
        "name": "consultar_pedido",
        "description": "Consulta un pedido por su ID.",
        "parameters": {
            "type": "object",
            "properties": {
                "pedido_id": {
                    "type": "string"
                }
            },
            "required": ["pedido_id"],
            "additionalProperties": False
        },
        "strict": True
    }
]

response = client.responses.create(
    model="gpt-5.6",
    tools=tools,
    input="Consulta el pedido PED-8841"
)

Sin embargo, aunque el modelo decida utilizar una función, tu servidor debe validar si ese usuario realmente puede ejecutar la acción. Nunca uses la IA como sustituto de la autorización de tu backend.

Qué hacer con los Threads antiguos

Por otra parte, una de las preguntas más importantes es qué ocurrirá con todas las conversaciones ya almacenadas. La respuesta depende de si esos historiales todavía tienen valor operativo.

En la práctica, evita migrar millones de conversaciones simplemente porque existen. Un histórico que nunca vuelve a consultarse puede incrementar trabajo, coste y posibilidades de error sin mejorar la experiencia.

Arquitectura recomendada después de la migración

En primer lugar, una aplicación sólida no debería delegar todas sus responsabilidades al modelo. La IA puede razonar y elegir herramientas; sin embargo, tu infraestructura continúa controlando identidad, permisos, datos críticos y operaciones reales.

Cómo migrar sin romper una aplicación en producción

De hecho, que Responses API devuelva una respuesta válida no significa que la migración esté terminada. También debes comprobar que el comportamiento siga siendo correcto para tus usuarios.

Checklist antes de retirar Assistants API

Preguntas frecuentes sobre la migración