Assistants API se desactivó oficialmente el 26 de agosto de 2026 y ya no está disponible. Las aplicaciones deben trasladar generación, estado, herramientas y datos a Responses API. El camino seguro es inventariar cada Assistant, Thread, Run y herramienta, reconstruir la configuración, importar el historial propio y probar respuestas y efectos secundarios antes de cambiar el tráfico. La fecha y la correspondencia constan en la guía oficial de migración de Assistants de OpenAI.
Qué cambia con la desactivación del 26 de agosto de 2026
Es una migración de endpoints y objetos, no un cambio de nombre del modelo. Después de la desactivación, las llamadas a los recursos antiguos de Assistants no son un aviso temporal. El código que crea o lee /v1/assistants, /v1/threads, /v1/threads/messages o /v1/threads/runs necesita una ruta nueva. No inicies una integración nueva con la API antigua ni construyas un fallback que suponga que los objetos antiguos seguirán disponibles.
La correspondencia actual publicada por OpenAI es:
| Assistants API | Plataforma Responses | Significado práctico |
|---|---|---|
| Assistant | Prompt o configuración de la solicitud | Conserva modelo, instrucciones, declaraciones de herramientas y reglas de salida en una configuración versionada. La guía actual permite crear un Prompt desde un assistant en el panel, pero también advierte que los objetos Prompt reutilizables están en proceso de desuso. |
| Thread | Conversation o historial de la aplicación | Conversation almacena elementos, incluidos mensajes, llamadas a herramientas y resultados. También puedes mantener el estado en tu base de datos y enviar los elementos necesarios. |
| Run | Response | Una solicitud de Responses recibe elementos de entrada y devuelve elementos de salida. El objeto Run separado y su bucle de consulta ya no son la abstracción central. |
| Run step | Item | Procesa elementos tipados como message, function_call, function_call_output y reasoning, sin asumir que cada resultado es un mensaje. |
Lee la guía de migración a Responses API junto con la guía de desactivación. Presenta Responses como la API recomendada para proyectos nuevos y explica las diferencias con Chat Completions y los formatos de entrada y salida.
El nuevo modelo mental
Antes, un Assistant era un conjunto persistente de configuración en el servidor. Un Thread guardaba mensajes y un Run ejecutaba el Assistant sobre ese Thread. Responses separa esas responsabilidades. La solicitud especifica modelo, instrucciones, entrada y herramientas. El resultado es un Response tipado cuyo output es una lista ordenada de elementos.
Este diseño deja la orquestación en la aplicación. Tu código decide la identidad, la cantidad de historia, las llamadas permitidas, la autorización, los reintentos y la aprobación humana. OpenAI ofrece opciones de estado, pero no un ciclo de vida implícito de Assistant.
Hay tres estrategias de estado:
- Envía una solicitud sin estado y una lista acotada de elementos de entrada en cada turno. Así tu base de datos controla la retención y la poda.
- Encadena turnos con previous_response_id. El documento sobre el estado de las conversaciones muestra este patrón. Es práctico para flujos breves, pero los tokens de entrada anteriores siguen contando para la facturación y el almacenamiento debe cumplir tu política.
- Crea un objeto de Conversations API y pasa su ID a Responses. Una Conversation tiene un identificador duradero y puede usarse entre sesiones, dispositivos o trabajos. Sus elementos se conservan hasta que se eliminan, por lo que el ID representa estado retenido, no una opción de privacidad.
Elige una estrategia para cada flujo del producto. No mezcles una transcripción reconstruida localmente, una Conversation y una cadena previous_response_id sin una fuente de verdad clara. Los turnos duplicados pueden cambiar el comportamiento del modelo, elevar el coste y complicar las solicitudes de borrado.
Haz inventario antes de cambiar el código
Crea un registro para cada Assistant ID y recorrido de sesión. Anota modelo, instrucciones, parámetros, esquemas, vector stores, archivos, Code Interpreter, formato, metadatos, retención y código que consulte Runs. Busca también trabajos, scripts, paneles, pruebas y analítica. Una respuesta correcta no demuestra que file search, streaming, salida estructurada o funciones con efectos secundarios sigan iguales.
Separa comportamiento y datos. Las instrucciones y herramientas se recrean desde la configuración. Mensajes de Threads y archivos requieren una copia controlada por la aplicación. La guía posterior al corte indica que recuperar mensajes antiguos de Thread ya no funciona.
Reconstruye la solicitud básica
Para una interacción de texto, sustituye la secuencia beta Thread y Run por una sola llamada a Responses. El campo input acepta una cadena o una lista de elementos parecidos a mensajes. Usa instructions para el comportamiento estable de nivel de sistema y deja el texto del usuario en input. Lee el texto normal con response.output_text, pero inspecciona response.output si puede haber herramientas o elementos que no sean texto.
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-5.6",
instructions="Responde con claridad y cita los registros proporcionados.",
input=[{"role": "user", "content": "Resume el estado del pedido."}],
store=False,
)
print(response.output_text)
El endpoint nuevo es /v1/responses y el método del SDK es client.responses.create. No conserves sin cambios la palabra clave messages, la ruta choices[0].message.content ni un bucle de consulta copiado de Runs. Si necesitas guardar Responses, conviértelo en una decisión explícita. La documentación de controles de datos indica actualmente que el estado de aplicación de Responses se conserva 30 días de forma predeterminada o cuando store es true, con las excepciones indicadas.
Conserva el historial correctamente
Si la transcripción pertenece a tu aplicación, normalízala como elementos de entrada de Responses. Un texto del usuario se convierte en input_text, un texto del asistente en output_text y una imagen en input_image con su URL o referencia de archivo. Conserva el orden cronológico y las parejas de llamada a herramienta y resultado necesarias para entender un turno anterior.
Este ejemplo crea una Conversation duradera a partir del historial de la aplicación y envía un turno nuevo:
from openai import OpenAI
client = OpenAI()
conversation = client.conversations.create(
items=[
{
"role": "user",
"content": [{"type": "input_text", "text": "Mi pedido es el 1842."}],
},
{
"role": "assistant",
"content": [{"type": "output_text", "text": "Puedo consultar el pedido 1842."}],
},
]
)
response = client.responses.create(
model="gpt-5.6",
conversation=conversation.id,
input=[{"role": "user", "content": "¿Está listo para enviarse?"}],
)
print(response.output_text)
Después de la desactivación, no migres con threads.messages.list. Usa los registros que conservó la aplicación, reconcilia identidad, borrado, reglas regionales, adjuntos y marcas de tiempo, y verifica cada Conversation ID.
Traslada herramientas y llamadas de funciones
Las herramientas de Responses se declaran en la solicitud. Las herramientas integradas como web search, file search, computer use, Code Interpreter, generación de imágenes y MCP remoto se describen en Using tools. Las funciones personalizadas aún necesitan una implementación en la aplicación. El modelo puede solicitar una función, pero no puede autorizar ni ejecutar por sí mismo tu operación de negocio.
El bucle de control es explícito. Envía la primera solicitud, inspecciona response.output en busca de elementos function_call, valida y ejecuta cada función permitida, añade los elementos de salida del modelo y los elementos function_call_output, y envía la siguiente solicitud. Con modelos de razonamiento, conserva los elementos reasoning que llegan con una llamada, como explica la guía de function calling.
import json
from openai import OpenAI
client = OpenAI()
tools = [
{
"type": "function",
"name": "lookup_order",
"description": "Devuelve el estado de un pedido del usuario autenticado.",
"parameters": {
"type": "object",
"properties": {
"order_id": {"type": "string"},
},
"required": ["order_id"],
"additionalProperties": False,
},
"strict": True,
}
]
input_items = [{"role": "user", "content": "¿Dónde está mi pedido 1842?"}]
response = client.responses.create(
model="gpt-5.6",
tools=tools,
input=input_items,
)
input_items += response.output
for item in response.output:
if item.type == "function_call" and item.name == "lookup_order":
arguments = json.loads(item.arguments)
result = {"order_id": arguments["order_id"], "status": "packed"}
input_items.append(
{
"type": "function_call_output",
"call_id": item.call_id,
"output": json.dumps(result),
}
)
response = client.responses.create(
model="gpt-5.6",
tools=tools,
input=input_items,
)
print(response.output_text)
El modo estricto ayuda con el esquema, pero no concede permisos. Valida usuario, propiedad, rangos, enum y estado en el código. Usa idempotencia o transacción para cobrar, borrar, publicar o enviar. Devuelve un error estructurado, limita turnos y registra aprobaciones con valores sensibles ocultos.
Conserva las salidas estructuradas
Si el Assistant antiguo usaba JSON mode o un esquema, llévalo a text.format de Responses, no a response_format. La guía de salidas estructuradas documenta la forma actual y los helpers del SDK. Valida el resultado antes de enviarlo a una base, interfaz u otra herramienta.
Mantén el esquema pequeño y versionado junto con el Prompt o la configuración. Declara campos obligatorios, usa additionalProperties=false cuando lo requiera el modo estricto y prueba rechazos, respuestas incompletas y cambios. Un objeto JSON por sí solo nunca demuestra éxito.
Seguridad y datos después de la migración
La migración cambia la frontera del estado y exige una revisión de seguridad. Mantén las claves API en un servidor confiable, autentica sesiones y vincula cada Conversation o transcripción con el usuario. No pongas secretos, tokens ni consultas de base sin restricciones en instrucciones o descripciones.
Usa el mínimo de herramientas, separa lectura y escritura, exige confirmación y autoriza fuera del modelo. Trata como no confiables archivos, páginas y respuestas MCP. MCP tiene retención propia y Code Interpreter puede conservar estado temporal. La guía de controles de datos detalla los límites.
Elige store, una Conversation o una transcripción controlada por la aplicación para cada flujo. Los datos de la API no se usan para entrenar modelos de OpenAI sin consentimiento explícito, pero esto no sustituye revisar retención, acceso, borrado, procesamiento regional y proveedores. store=false no es una política general de borrado ni vuelve efímera una Conversation.
Limita entradas y salidas, aplica moderación cuando corresponda y ofrece revisión humana para decisiones de alto impacto. Las buenas prácticas de seguridad de OpenAI recomiendan pruebas adversarias contra prompt injection, moderación y supervisión humana. Registra IDs de solicitud y tipos de evento, pero oculta contenido del usuario, credenciales, argumentos de funciones y resultados de herramientas conforme a tu política.
Fallos habituales de la migración
El endpoint antiguo devuelve un error
Después del 26 de agosto de 2026, las solicitudes a Assistants indican un defecto de migración. Elimina la ruta antigua del cliente en lugar de reintentarla. Si un worker todavía consulta Run IDs, despliega el worker de Responses y cambia sus campos thread_id y run_id por identificadores de sesión y Response.
La respuesta está vacía o falla el parser
La salida de Responses es una lista heterogénea. output_text sirve para texto normal, pero una llamada de herramienta, un rechazo o una respuesta incompleta requieren revisar el estado y los tipos de elemento. No tomes el primer elemento por índice suponiendo que es un mensaje.
El modelo repite el contexto o sube el coste
Elige una estrategia de estado y una regla de poda. previous_response_id no hace gratuitos los tokens de entrada anteriores, y copiar la misma transcripción tanto en Conversation como en input duplica el contexto. Mide tokens de entrada y salida en staging con conversaciones largas realistas.
Una función se ejecuta dos veces
Los reintentos, las llamadas paralelas, los tiempos de espera de red y las reconexiones pueden repetir una llamada. Da a cada operación con efecto secundario una clave idempotente basada en el call ID y el usuario autenticado, y comprueba la transacción de negocio antes de aplicarla. Un mensaje correcto del modelo no demuestra que la función se ejecutó una sola vez.
Desaparecen archivos o resultados de búsqueda antiguos
Inventaría vector stores, IDs de archivos, expiraciones y permisos por separado del historial de Thread. Recrea la ruta de recuperación compatible, verifica el acceso de cada inquilino y prueba citas y resultados vacíos. Convertir la configuración de un Assistant no copia sus archivos.
Lista de comprobación de migración
Sigue estos pasos en orden para cada flujo de producción:
- Registra dependencias de Assistant, Thread, Run, archivos, vector stores, herramientas, Prompt y metadatos antiguos.
- Coloca las instrucciones visibles y los esquemas de herramientas en una configuración versionada.
- Elige un modelo de Responses y confirma herramientas, entradas multimodales, salidas estructuradas y disponibilidad regional.
- Elige una sola estrategia de estado: elementos sin estado, previous_response_id o Conversations.
- Mapea messages a input, choices a output y la extracción de texto a output_text.
- Reescribe las definiciones de funciones e implementa un bucle de herramientas explícito y limitado.
- Recrea por separado file search, Code Interpreter, web search, MCP, streaming y salidas estructuradas.
- Importa solo el historial controlado por la aplicación y conserva orden, identidades, adjuntos, llamadas y borrado.
- Añade autorización, límites de entrada, moderación, idempotencia, logs ocultos y aprobación para efectos secundarios.
- Ejecuta conversaciones de referencia, prompts adversarios, errores de herramientas, reintentos, rechazos, contextos largos y sesiones concurrentes.
- Compara respuestas, citas, efectos de herramientas, tokens, latencia, errores y retención.
- Publica detrás de un feature flag, drena workers antiguos, vigila errores de Responses y conserva un rollback sin la API desactivada.
- Elimina código y claves de Assistant solo después de verificar exportaciones, auditoría y soporte.
Para el diseño del sistema, consulta la guía de arquitectura de agentes de IA en producción. Para conjuntos de regresión y controles de comportamiento, consulta la guía de evaluaciones de agentes de IA.
Cómo saber que la migración terminó
La migración terminó cuando ningún flujo depende de Assistants, cada sesión tiene dueño de estado, cada herramienta está autorizada y es resistente a repeticiones, y el contrato de Responses tiene pruebas. Conserva versiones, decisiones de retención y fallos. Revisa el registro cuando cambie Responses o el modelo, porque retirar el fallback no elimina la evaluación continua.