Mistral Medium 3.5 y Vibe: agentes de coding en la nube con pesos abiertos

El 2 de mayo Mistral publicó dos cosas a la vez: Medium 3.5, su nuevo modelo dense de 128B parámetros con 256k de contexto y pesos abiertos bajo MIT modificada, y los Vibe Remote Agents, agentes de coding que viven en la nube en vez de en tu terminal. La combinación es interesante porque ataca a la vez los dos puntos donde Claude Code y Codex han marcado el ritmo el último año: la calidad del modelo de coding y el formato del agente. Y lo hace desde Europa, con la opción real de que te lleves los pesos a casa.

Vamos a desmontar qué hay debajo del titular y, sobre todo, qué implicaciones tiene si estás evaluando agentes IA de código en una pyme técnica.

Qué es exactamente Medium 3.5

Los datos publicados por Mistral y confirmados en la cobertura de MarkTechPost:

Especificación	Valor
Arquitectura	Dense, 128B parámetros
Contexto	256.000 tokens
Multimodal	Sí, con vision encoder propio
Reasoning	Esfuerzo configurable por request
Licencia	MIT modificada, pesos abiertos en Hugging Face
Auto-hospedable	”Tan poco como 4 GPUs” según Mistral
Precio API	$1,5 / millón input — $7,5 / millón output

El número que está moviendo el debate es el 77,6% en SWE-Bench Verified. Por contexto, SWE-Bench Verified es el benchmark de programación más exigente que tenemos publicado: el modelo recibe un repositorio real, un issue de GitHub y tiene que producir un parche que pase los tests. El 77,6% sitúa a Medium 3.5 por delante de Devstral 2 y de Qwen3.5 397B A17B según la propia comunicación de Mistral. Es una declaración fuerte; lo razonable es esperar a benchmarks independientes antes de dar el dato por canónico, pero el rango ya es competitivo con la frontera.

Lo más interesante para construir, sin embargo, no es el porcentaje. Son tres detalles más sutiles:

Reasoning configurable por request. El mismo modelo responde un mensaje rápido o ejecuta una cadena agentica larga ajustando un parámetro. Adiós a tener dos modelos en producción para los dos modos.
256k de contexto en un dense de 128B. No es enorme comparado con los 1M de Gemini, pero es suficiente para meter un repo mediano entero y operar sobre él sin ingeniería de chunking exótica.
Modificación de licencia MIT con pesos abiertos. Esta es la parte que cambia la conversación, y la tratamos abajo aparte.

Qué son los Vibe Remote Agents

Vibe es la suite de coding de Mistral que ya conocías como CLI local. Lo nuevo es que ahora puedes lanzar el agente al cloud y dejarlo trabajando mientras tú haces otra cosa.

Las capacidades que documentan tanto Mistral como InfoQ:

Lanzar tareas desde la CLI de Vibe o desde Le Chat.
Ejecución asíncrona en sandboxes aislados.
Múltiples sesiones en paralelo.
Integración con GitHub para abrir pull requests.
Visibilidad en directo: ver diffs, llamadas a herramientas, estado de progreso.
“Teletransportar” sesiones locales al cloud — sigues una tarea en tu portátil, decides que va para largo, la subes y se queda corriendo.

Esto no es un truco de presentación. Es un cambio de modelo mental que ya empezamos a ver en Codex Cloud y en los managed agents de Anthropic: el agente de coding deja de ser una herramienta interactiva y pasa a ser un proceso de larga duración que orquestas. El developer deja de ser el cuello de botella en cada paso del agente.

Diferencia con un agente local

Aspecto	Agente local (CLI)	Remote Agent
Sesión	Tu terminal	Sandbox cloud
Paralelismo	Una a la vez por terminal	Varias simultáneas
Modelo de uso	Sincrónico, conversacional	Asíncrono, lanzar y revisar
Bloqueo del developer	En cada paso del agente	Solo en revisión y merge
Coste fijo	Cero infraestructura	Compute en la nube

Los dos modelos son válidos. La pregunta no es cuál es “mejor” sino qué tipo de tarea estás dándole al agente. Refactor pequeño, pair programming, ajuste fino → local. Migración aburrida y larga, batch de bug fixes triviales, generar tests sobre módulos completos → cloud.

La parte que cambia la conversación: open weights bajo MIT

Aquí es donde Mistral diferencia. Open weights bajo licencia MIT modificada significa que puedes descargar el modelo y correrlo en tu propia infraestructura. No es una API que puedan apagarte ni cambiarte el precio mañana. Si tu caso de uso es serio, puedes auditar el modelo, fine-tunearlo con datos propios, y sobre todo: tener una garantía de continuidad que no depende de la salud financiera del proveedor.

Las implicaciones prácticas para una pyme con datos sensibles son grandes:

Datos que no pueden salir del perímetro: legal, salud, finanzas, defensa, cualquier sector con compliance estricto. Self-hosting deja de ser un ejercicio teórico.
Soberanía del proveedor: ya no es una conversación de “qué pasa si OpenAI sube el precio un 40%”. Es “tengo los pesos, puedo seguir aunque el proveedor desaparezca”.
Optionality real entre cloud y on-prem: empiezas con la API mientras validas el caso de uso, y cuando los costes lo justifican migras a self-hosted en tus propias GPUs.

El “tan poco como 4 GPUs” hay que leerlo con la letra pequeña. Para inferencia con throughput decente sobre un dense de 128B vas a necesitar GPUs gordas (H100 o equivalentes), batching agresivo y un stack de serving serio (vLLM, TGI, SGLang). No es montar Ollama en tu Mac. Pero es factible para un equipo que ya está corriendo workloads de IA en producción.

Sobre el detalle “MIT modificada”: no hemos podido confirmar todavía las restricciones exactas que Mistral añade a la MIT base. Antes de llevar los pesos a producción comercial, lee la licencia entera. La diferencia entre “MIT” y “MIT modificada” puede ser desde una atribución requerida hasta restricciones de uso competitivo.

Por qué le importa esto a una pyme técnica

Si tienes un equipo pequeño y estás evaluando llevar IA a desarrollo o a operaciones internas, este lanzamiento mueve dos cosas:

1. La barrera de entrada para agentes asíncronos baja

Hasta hace poco, montar un agente que trabaje en background sobre tu repo y abra PRs implicaba una de tres cosas: pagar Codex Cloud, montar Claude Managed Agents, o construirlo tú con un wrapper de tu propio harness. Vibe Remote Agents te da una opción más, alineada con un proveedor europeo y con la posibilidad de migrar a self-hosted si la cosa va en serio.

Para un equipo de 5-15 personas, esto significa que automatizar el trabajo de bajo nivel (actualizaciones de dependencias, migraciones de typescript estricto, generación de tests sobre módulos sin coverage, traducción de strings) deja de ser un proyecto de plataforma y pasa a ser una decisión de “lanzo el agente y reviso PRs el lunes”.

2. Open weights cambia el cálculo de “vendor lock-in”

La pregunta clásica de buy vs build sobre IA — que tratamos a fondo en esta guía sobre software a medida — gana una opción intermedia: adoptar un modelo abierto y construir encima. No estás casado con una API y no tienes que construir el modelo desde cero. Es la zona donde han estado Llama y Qwen, ahora con un actor europeo más en el partido.

Si tu negocio depende del modelo (no es un add-on, es el producto), tener pesos abiertos a tu disposición es la diferencia entre apostar por un proveedor y apostar por una tecnología.

Cuándo este lanzamiento no es para ti

Para mantener honesto el análisis:

Si tu caso de uso ya funciona con la API de Anthropic o OpenAI y el coste no es un problema, cambiar de proveedor por moda es mover sillas. Migra cuando el cambio resuelva un dolor concreto: precio, latencia, datos sensibles, riesgo de proveedor.
Si no tienes equipo para correr inferencia self-hosted, el “open weights” es marketing. Vas a usar la API igual que con cualquier otro proveedor. La pregunta entonces es solo de pricing y benchmarks reales en tu caso.
Si estás eligiendo modelo basándote solo en el SWE-Bench, párate. SWE-Bench mide una capa muy específica. Tu workload real puede comportarse diferente. Haz tus propios evals con tu propio repo antes de mover nada.
Si tu workflow de coding es de pair programming síncrono, los Remote Agents no aportan. Sigue con la CLI local del modelo que ya estés usando.

Cómo lo evaluaríamos nosotros si tuviésemos que decidir esta semana

Sin teoría, lo que haríamos en CortesIA:

Spike de un día con la API sobre 5-10 tareas reales del backlog: bugs cerrados recientemente, refactors pequeños, generación de tests. Comparar el resultado con el modelo que ya estamos usando.
Lanzar 2-3 Remote Agents en paralelo sobre un repo de prueba con un PR template definido. Medir tiempo del developer en revisión vs tiempo ahorrado vs calidad del PR resultante.
Calcular el coste por tarea completada, no por token. El precio por token es engañoso si un modelo necesita el doble de pasos que otro.
Decidir el horizonte de self-hosted. Si el caso de uso escala, hacer una estimación honesta de qué costaría montar inferencia propia con 4-8 GPUs cuando el volumen lo justifique.

Esto es exactamente la rutina que aplicamos cuando evaluamos un nuevo stack para un cliente: no nos fiamos de los benchmarks del proveedor, montamos un experimento reproducible sobre datos reales, y la decisión sale de los números nuestros, no de los suyos.

Resumen accionable

Mistral Medium 3.5 está disponible vía API ($1,5 input / $7,5 output por millón de tokens) y como pesos abiertos en Hugging Face bajo MIT modificada — léete la licencia entera antes de usarlo en producción comercial.
Vibe Remote Agents te dan una alternativa europea para agentes de coding asíncronos en la nube, con integración GitHub y sesiones paralelas. Útiles para tareas largas y aburridas, no para pair programming.
El número de SWE-Bench (77,6%) es competitivo pero espera a benchmarks independientes antes de tomar decisiones grandes basándote solo en ese dato.
Si tu caso de uso requiere self-hosting por datos sensibles o soberanía, este lanzamiento abre una opción real. Necesitas un stack serio de serving (vLLM, TGI, SGLang) y GPUs decentes — no es plug-and-play.
Decide con tus propios evals. Coge 5-10 tareas reales de tu backlog, lanza una semana de pruebas y compara. Lo que funcione para Mistral en SWE-Bench puede no ser lo que funciona en tu repo.

Si estás evaluando montar agentes de IA en tu equipo y no tienes claro por dónde empezar — qué modelo, qué arquitectura, qué guardrails — hablemos. Hacemos exactamente este tipo de spike de evaluación con datos del cliente antes de comprometernos con un stack.