Si tu aplicación usa /v1/assistants, tienes dos días. OpenAI apaga la Assistants API el 26 de agosto de 2026, y no hay modo degradado: desde ese día, cada llamada a /v1/assistants, /v1/threads o /v1/threads/runs devuelve un error directo. No hay periodo de gracia, no hay extensión. Lo anunciaron en mayo. Aun así, la semana antes del cierre encontré varios equipos todavía sin plan de migración.
El mismo cierre aplica a Azure OpenAI Assistants API. Microsoft ya migró su servicio a Foundry Agents, construido sobre la Responses API. Y el 26 de agosto también sale o3 del selector de modelos en ChatGPT, aunque eso tiene menos impacto en producción porque o3 vía API (o3-2025-04-16) sigue disponible hasta diciembre de 2026. Son dos fechas distintas pero que OpenAI consolidó en el mismo comunicado, lo que generó bastante confusión.
Qué cierra exactamente el 26 de agosto
Tres endpoints dejan de funcionar en ChatGPT y en el API:
- ▸/v1/assistants — crear, listar y editar configuraciones de asistente
- ▸/v1/threads — crear y recuperar hilos de conversación con historial persistente
- ▸/v1/threads/runs — ejecutar pasos dentro de un hilo y recuperar resultados
Lo que NO cierra: el acceso al modelo vía /v1/chat/completions y /v1/responses sigue funcionando. Lo que desaparece es la abstracción de asistente con memoria de hilo gestionada por la plataforma. Si tus apps ya usan la Responses API o la Chat Completions API directamente, hoy no tienes nada que hacer.
Por qué OpenAI tomó esta decisión (y tenía sentido hacerlo)
La Assistants API resolvía un problema real cuando salió en 2023: gestionar manualmente el historial de conversación era tedioso, y los threads ofrecían una forma limpia de no cargar con eso en cada request. El precio era la opacidad. Los runs tenían latencia variable, el control de errores era difícil de predecir, y el estado interno de un asistente no era directamente observable desde tu código.
Cuando llegó la Responses API con historial de conversación integrado, tool use nativo, streaming limpio y control de error más claro, la Assistants API quedó como un workaround que era más complicado de mantener que de reemplazar. Lo que nadie dice abiertamente es que esto también encaja con la estrategia de consolidación de OpenAI: menos endpoints que mantener, más presión hacia los que tienen mejor instrumentación de costos y uso. En 2026, OpenAI ha retirado más modelos y APIs que en todos los años anteriores juntos.
La migración en la práctica: qué cambia en tu código
La Responses API (/v1/responses) es el destino oficial. En lugar de crear un assistant, un thread y disparar un run, ahora el request incluye directamente el historial de mensajes y la lista de tools disponibles. La respuesta incluye el mensaje del modelo, las tool calls, y el historial actualizado listo para el siguiente turno. El patrón es más parecido a cómo construyes con LangChain o LangGraph que a la arquitectura de run/polling de la Assistants API.
Los pasos de migración en la mayoría de casos son:
- ▸Recuperar o crear el historial de mensajes que antes vivía en el thread
- ▸Incluirlo en el campo messages del request a /v1/responses
- ▸Si usas Function Calling, las tool definitions migran directamente al campo tools del nuevo schema
- ▸Si usas File Search (antes llamado Retrieval), el nuevo endpoint tiene file_search como tool nativa
- ▸Guardar el historial actualizado que devuelve la respuesta para persistirlo en tu propia base de datos
Lo que nadie va a migrar por ti: los Threads con conversaciones activas
OpenAI fue explícito al respecto: no van a proveer una herramienta de migración automática de Threads a Conversations. Si tienes conversaciones activas guardadas en /v1/threads, la ruta es manual. Tienes que exportar cada thread con GET /v1/threads/{id}/messages, transformar los mensajes al formato {role, content} de la nueva API, y guardarlos en tu propia base de datos antes del 26. Para apps con volumen bajo, un script tarda horas. Para apps con miles de conversaciones activas de usuarios, esto es una migración de datos real que debería haber empezado hace semanas.
Lo positivo: la mayoría de los casos de uso de la Assistants API no requieren historiales largos. Si tus threads tenían 5-10 turnos de conversación por sesión, la exportación es manejable en unas pocas horas.
El patrón más sólido para agentes con estado en 2026
Si ya tienes que reescribir la capa de agentes, tiene sentido hacerlo con el patrón correcto para los próximos dos años. La Responses API resuelve el chat con tools de forma directa. Pero para flujos multi-paso, agentes con ramas de decisión, ejecuciones paralelas, o agentes que necesitan pausar y esperar aprobación humana, el patrón que más vi estabilizarse en producción en 2026 es LangGraph.
LangGraph te da estado explícito entre pasos, control de errores por nodo, y soporte para agentes que interrumpen y se reanudan. Puedes construir exactamente el mismo flujo que tenías con la Assistants API, con visibilidad total sobre qué pasa en cada nodo del grafo. Eso cambia lo que puedes depurar y qué tan rápido puedes iterar. No porque sea perfecto —el debugging de grafos complejos tiene su propia curva—, sino porque el observability es tratable.
Si quieres dominar este stack, el curso Creación de Agentes con LangGraph cubre desde el primer grafo hasta agentes con checkpoints y human-in-the-loop. Y la ruta AI Agentic Engineer cubre el stack completo —LangGraph, CrewAI, MCP, sistemas multi-agente— para quien quiere construir agentes en producción de forma estructurada.
La lección que deja el cierre de la Assistants API
Muchos equipos adoptaron la Assistants API porque era la forma más rápida de arrancar. Eso no fue un error. El problema es que 'fácil de arrancar' y 'fácil de mantener en producción' rara vez son la misma API. El cierre forzado tiene un lado útil: obliga a revisar la arquitectura de agentes desde las capas que realmente importan.
En 2026, el stack de agentes en producción no se basa en la abstracción que te ofrece el proveedor del modelo. Se basa en orquestar con herramientas que dan observabilidad, control de estado y manejo de errores predecible. La Responses API es la interfaz con el modelo; lo que construyes encima —tu gestión de estado, tu lógica de retry, tu estructura de grafo— define qué tan bien escala.
Si quieres practicar los patrones nuevos —Responses API, LangGraph, agentes con memoria— con gente que está migrando o construyendo lo mismo, cada semana hacemos un taller en vivo en la Comunidad AI Builders. Desde 19 USD/mes.
Cursos para dominar el stack de agentes en producción
- ▸Creación de Agentes con LangGraph — flujos con estado, checkpoints y human-in-the-loop
- ▸Creación de Agentes con LangChain — retrieval, tools y composición de cadenas
- ▸Ruta AI Agentic Engineer — el camino completo desde agente sencillo a sistemas multi-agente en producción
