El 24 de julio a las 15:59 UTC, DeepSeek desactivó dos endpoints que llevan meses sosteniendo miles de aplicaciones en producción: deepseek-chat y deepseek-reasoner. No fue un outage ni un bug. Fue una deprecación anunciada tres meses antes. Si tu código todavía apunta a esos nombres de modelo, tus llamadas están fallando ahora mismo.
La buena noticia: migrar toma menos de diez minutos si sabes adónde ir. El problema es que, en muchos equipos, el código que llama a DeepSeek vive en algún microservicio que "funcionaba y nadie tocaba". Este post es para ese equipo, y también para quien quiera entender qué cambió realmente con el V4 Pro —porque hay más que solo el nombre del modelo.
V4 Pro: el modelo que reemplazó a deepseek-chat
El 20 de julio DeepSeek declaró disponibilidad general para su familia V4. Dos modelos en esa familia: DeepSeek-V4-Pro y DeepSeek-V4-Flash. V4 Pro es el flagship: arquitectura MoE con 1.6 billones de parámetros totales y 49B activos en cada forward pass. Ventana de contexto de 1 millón de tokens, salida máxima de 384K tokens.
V4-Flash —que cubrimos en detalle a inicios de julio— es la versión ligera con 284B/13B activos, pensada para alto volumen y latencia baja. Aquí la distinción importa: deepseek-chat mapeaba al modelo de conversación general (ahora reemplazado por V4-Pro), y deepseek-reasoner mapeaba al modo de razonamiento (ahora absorbido por el dual-mode Thinking de V4-Pro). Son el mismo endpoint viejo, dos casos de uso distintos.
Ambos modelos son compatibles con el formato de OpenAI ChatCompletions y con el de Anthropic. Si tienes un cliente configurado con base_url de DeepSeek y usabas el SDK de OpenAI, el cambio es literalmente de una sola línea: el nombre del modelo.
Qué pasó el 24 de julio: la fecha que muchos equipos ignoraron
El preview del V4 abrió el 24 de abril. Tres meses de aviso era suficiente, en teoría. En la práctica, muchos equipos actualizaron sus ambientes de prueba pero nunca propagaron el cambio a producción. El deadline llegó, los logs empezaron a llenarse de errores HTTP 404 y 400, y el equipo de guardia tuvo que diagnosticar a las 3 de la mañana por qué sus agentes dejaron de responder.
El patrón es conocido en la industria: los LLMs se actualizan rápido y los sistemas en producción se mueven despacio. Lo mismo pasó con versiones de GPT-4 Turbo y con actualizaciones de la API de Claude. La diferencia aquí es que DeepSeek no incluyó un fallback automático al nuevo modelo: el corte fue total.
V4 Pro vs V4 Flash: cuándo usar cada uno en tu stack
- ▸V4 Pro: análisis de documentos largos, RAG con contexto extendido, agentes que necesitan mantener estado de sesión larga, razonamiento complejo donde el costo por llamada no es el cuello de botella. Precio: $1.74 input / $3.48 output por millón de tokens.
- ▸V4 Flash: alta frecuencia de llamadas, clasificación rápida, extracción de entidades, herramientas de productividad donde la latencia importa más que la profundidad de razonamiento. Precio: $0.14 input / $0.28 output por millón de tokens.
- ▸Ambos: cuando antes usabas GPT-4o o Claude Sonnet y el costo era el limitante. V4 Flash sigue siendo entre 10x y 20x más barato que los equivalentes de OpenAI en volumen alto.
Cómo migrar en cinco minutos: el checklist completo
Si usas el SDK de OpenAI con el base_url de DeepSeek:
- ▸Cambia model="deepseek-chat" por model="deepseek-v4-pro" (o deepseek-v4-flash si priorizas velocidad). El base_url y la API key no cambian.
- ▸Si usabas deepseek-reasoner, pasa a deepseek-v4-pro y activa el modo Thinking incluyendo thinking_budget en los parameters de tu llamada. El comportamiento es equivalente al razonamiento que ya conocías.
- ▸Revisa el max_tokens de tu llamada. La salida máxima ahora es 384K tokens, mucho más que el límite anterior. Si tu código ponía un techo artificial, ya no hace falta.
- ▸Si tenías lógica de chunking porque el contexto no alcanzaba, evalúa si la necesitas: con 1M tokens puedes meter documentos completos sin partirlos. Pero mide el costo primero —más contexto es más precio.
- ▸Actualiza tus tests de integración. Si verificas el nombre del modelo en la respuesta o mockas el endpoint con el nombre viejo, van a fallar hasta que los ajustes.
Una advertencia sobre el contexto de 1M tokens que no aparece en los blogs de marketing: es real, pero mandar 800K tokens por llamada tiene una latencia que puede sorprenderte y un costo que puede disparar tu factura. La ventana grande no reemplaza a un sistema RAG bien diseñado; lo complementa. Prueba primero con 64-128K y mide antes de rediseñar toda tu arquitectura.
El dual mode Thinking: qué cambia para tus agentes en producción
El cambio más interesante de V4 Pro para quien construye agentes no es el tamaño del contexto: es el dual mode. En modo Thinking, el modelo genera un chain-of-thought interno antes de responder. El resultado es visible en la respuesta (campo reasoning_content), útil para debugging y para auditar el comportamiento de un agente.
Para sistemas multi-agente —donde tienes un orquestador que delega tareas a sub-agentes especializados— el patrón que está funcionando mejor es: orquestador en modo Thinking, workers en Non-Thinking. Obtienes razonamiento profundo donde importa y velocidad donde no. En LangGraph puedes configurar el cliente de DeepSeek por nodo, así que el patrón es directo. En CrewAI puedes asignar el modelo con thinking activado al agente manager y Non-Thinking a los agentes ejecutores.
En benchmark de coding y razonamiento, V4 Pro compite con Claude Sonnet 5 en varias pruebas. En producción, los resultados varían según el dominio y el tipo de tarea. La recomendación práctica: úsalo donde hoy usas Sonnet 5 pero el costo es el freno, no como reemplazo universal sin evaluar. Las diferencias en calidad de seguimiento de instrucciones complejas todavía existen.
El stack de agentes en 2026 ya no es un solo modelo
La migración de esta semana es un recordatorio de algo que los mejores AI Engineers ya tienen claro: el stack no es un modelo, es una orquestación. Claude para razonamiento complejo, DeepSeek para volumen, GPT donde la integración lo requiere, Gemini donde Google Cloud es el proveedor. Encima de todos, un orquestador que decide en tiempo real qué modelo usar en cada paso según costo, latencia y complejidad.
Eso es exactamente lo que cubre la ruta de AI Agentic Engineer de DataPath: desde la arquitectura de agentes multi-LLM hasta el deployment, el monitoreo y la evaluación continua en producción. Si quieres empezar por las herramientas concretas, el curso de LangGraph es el punto de entrada más directo —y cubre la integración con múltiples proveedores, incluyendo DeepSeek.
También puedes ver todos los cursos de agentes IA de DataPath para elegir por dónde empezar según tu nivel actual.
