Mistral anunció el 28 de octubre de 2026 su Responses API en vista previa pública. Recuperamos este anuncio para explicar su consecuencia práctica: facilita reutilizar el formato de una integración Responses, pero la aplicación sigue siendo responsable del historial y de ejecutar las herramientas. Compatibilidad de formato no garantiza equivalencia de funciones, calidad o costes.
El anuncio oficial de Mistral indica que funciona con todos sus modelos de chat alojados, incluido Large 4. Eso no convierte a todos esos modelos en multimodales ni les concede las mismas capacidades de razonamiento. Tampoco es un anuncio de disponibilidad general: la documentación mantiene la etiqueta de vista previa.
Qué cambia en la respuesta
La guía oficial utiliza el formato OpenAI Responses. La respuesta contiene un array output, una lista donde pueden aparecer por separado mensajes, elementos de razonamiento y llamadas a funciones. El programa puede tratar cada elemento según su tipo, en lugar de asumir que toda la respuesta es una cadena de texto.
La API admite entrada y salida de texto, entrada de imágenes con modelos que soporten visión y entrada de archivos mediante URL HTTPS, datos base64 o identificadores de archivos subidos. También documenta salida estructurada con JSON o JSON Schema, streaming y razonamiento según el modelo. Admitir imágenes de entrada no significa generar imágenes de salida.
El historial no vive en el identificador de respuesta
El endpoint es POST /v1/responses. En esta implementación, sin estado significa que la aplicación conserva los mensajes y vuelve a enviarlos en input en cada solicitud. Debe incluir también los elementos output de las respuestas anteriores, no solo el texto visible al usuario.
La referencia del endpoint concreta varios límites: previous_response_id y conversation deben omitirse o ser nulos; store debe omitirse, ser falso o nulo; y background debe ser falso. Una integración que dependía de recuperar conversaciones almacenadas en el servidor debe resolver esa diferencia antes de migrar.
Esta condición describe el funcionamiento de la API. No equivale por sí sola a una garantía contractual sobre retención de datos.
Una función propuesta todavía necesita autorización
Ejemplo hipotético, no ejecutado por Puntoes: un asistente recibe una consulta sobre un pedido y propone llamar a una función que obtiene su estado. La aplicación comprueba identidad, permisos y argumentos, ejecuta la consulta de solo lectura y devuelve un elemento function_call_output con el call_id correspondiente. Para continuar, conserva la salida completa anterior junto con ese resultado.
Las herramientas documentadas aquí son funciones ejecutadas por el cliente, incluidas agrupaciones mediante namespaces. No debe suponerse que esta interfaz incorpora por compatibilidad un navegador o un buscador alojados por el proveedor. Además, max_tool_calls se acepta por compatibilidad, pero actualmente se ignora: no sirve como límite efectivo de ejecución. El programa debe controlar cuántas acciones permite y con qué permisos.
Qué comprobar antes de cambiar una integración
Conviene repetir casos de varios turnos, argumentos ambiguos, errores de herramientas y reintentos. En streaming hay que atender los eventos de finalización, fallo, respuesta incompleta y error, además de los fragmentos de texto. El presupuesto max_output_tokens incluye razonamiento y respuesta, por lo que no representa exclusivamente texto que verá el usuario.
Una primera respuesta correcta acredita ese recorrido concreto; no demuestra una migración completa ni ahorro. Aquí no hemos realizado llamadas de pago ni medido rendimiento. La descarga y licencia de un modelo son otra decisión: explicamos sus condiciones en la publicación de los pesos de Mistral Large 4.