MiMo-V2.6: Xiaomi abre el stack RL (entornos, verifiers, MOPD)

TL;DR

La segunda fase de MiMo-V2.6 ya es tangible: el dataset MiMo-V2.6-RL-oss con los entornos RL agénticos que entrenaron al flagship acumula 104.589 descargas y 893 likes a 09-oct-2026 (verificado en la API de Hugging Face). Herramientas MCP, workspaces SQL simulados y verifiers ejecutables, todo con licencia para mirar cómo entrena un vendor un modelo de 1T.
Xiaomi también publicó dos checkpoints nuevos, MiMo-V2.6-Pro-MOPD y MiMo-V2.6-Flash-MOPD, que parchean un fallo sutil de la fase RL: tool-call repetition. El README oficial lo resume así: un modelo que aparenta trabajar sin progresar emitiendo una y otra vez la misma llamada a herramientas, un fallo que nada denuncia porque no falla de forma evidente. El API oficial de Xiaomi lleva sirviendo el modelo parcheado desde el 25 de septiembre con el mismo nombre (claim del blog técnico del vendor).
El paper ahora es citable: arXiv 2610.11959, “MiMo-V2.6: Scaling Reinforcement Learning Towards Self-Improvement” (v1, 08-oct-2026). El método del parche, MOPD2, está en la sección 5.6: destilación on-policy multi-profesor para llevar capacidades a dominios donde no hay reward fiable.
Ya existe evaluación independiente: Artificial Analysis da a MiMo-V2.6-Pro un 46 en su Intelligence Index —por delante de Kimi K3 Max (44) y a dos puntos de GPT-6 Sol Max (48)— a $0,13 por tarea frente a $2,00 de K3. Consultado el 09-oct-2026; cifras de un tercero, no mías.
Lo que sigue sin abrir: los logs del run completo, los pesos de los profesores de MOPD2, los datos de pre-entreno. Lo abierto son los entornos, los verifiers y los forks del framework.

De la receta al stack: qué ha cambiado en una semana

El 2 de octubre publiqué el análisis de la receta RL de MiMo-V2.6: You Only RL Once, el grader que compara soluciones del grupo, el router MoE congelado y los benchmarks vendor. Entonces había dos cosas que no se podían verificar desde fuera: que los entornos agénticos del run llegaran a abrirse algún día, y si el modelo aguantaba el tipo ante un evaluador que no fuera Xiaomi. En una semana han pasado ambas cosas, y además el vendor ha parcheado en caliente un fallo post-lanzamiento que es un caso de estudio por sí mismo.

Esta pieza cubre esa segunda fase: qué hay abierto exactamente, el fallo de tool-call repetition y su parche MOPD, y la primera evaluación independiente seria.

Qué hay abierto exactamente

Todo lo de esta tabla está verificado contra las APIs de Hugging Face y GitHub a 09-oct-2026:

Pieza	Qué es	Estado verificado
`XiaomiMiMo/MiMo-V2.6-RL-oss`	Dataset con los entornos RL agénticos	104.589 descargas, 893 likes, ~41.000 ficheros
`code.parquet`, `cyber.parquet`	Tareas de código y ciberseguridad	En la raíz del dataset
`general/envs/<env>/`	Entornos agénticos completos	`instruction.md`, `manifest.json`, `mcp_bridge.py`, `tools/*.py`
Workspaces simulados	Sistemas con datos falsos pero consultables	`schema.sql` + `state.db` por sistema; p. ej. un escenario contable/fiscal con 4 herramientas (pipeline de disposiciones tipo DealCloud, hub de modelado fiscal tipo KPMG, biblioteca de governance tipo SharePoint, registro de activos tipo Yardi)
Verifiers	Comprobación ejecutable de soluciones	`verify.py`, `run_verify.py`, `verifier_meta.json` por entorno
`XiaomiMiMo/verl`	Fork del framework RL (upstream: 23.805★)	684★ propias, creado el 21-sep
`XiaomiMiMo/uni-agent`	”Framework for training long-horizon agents”	24★
`XiaomiMiMo/mimoagent`	Agente de ~100 líneas	42★; el “>74% en SWE-bench verified” es claim de su descripción en GitHub
`MiMo-V2.6-Pro-MOPD` / `Flash-MOPD`	Checkpoints parcheados, MIT	29★/4.004 descargas y 59★/6.902 descargas

Lo notable no es la cantidad sino la textura. Estos no son prompts sueltos ni una colección de Q&A: son entornos con un estado que se corrompe, herramientas MCP que fallan, y un verifier que decide si el agente resolvió la tarea o la fingió. Un entorno contable con cuatro sistemas y sus bases SQLite es exactamente el tipo de tarea donde un coding agent sin jefe se pierde — y es el material con el que Xiaomi castigó ese comportamiento durante el RL.

Sobre la frase del abstract — “We open-source the training dynamics, RL environments, and RL framework” — el matiz honesto: lo que yo puedo verificar desde fuera son entornos, verifiers y forks. Qué fracción de las “training dynamics” vive dentro de los parquet y qué fracción se quedó en Xiaomi es imposible auditarlo sin descargar el dataset entero. La promesa del abstract es más amplia que lo demostrable.

El fallo que finge trabajar

Tras el lanzamiento, en MiMo Desktop, MiMo Code, OpenCode y otros harnesses agénticos empezó a aparecer un patrón: el modelo emitía la misma llamada a herramientas una y otra vez. El blog técnico de Xiaomi lo describe con precisión — y el README del checkpoint lo resume mejor que ningún análisis externo:

“the model keeps issuing the same or highly similar tool calls, appearing busy while making no progress. Nothing fails outright, so it tends to go unnoticed”

Traducción operativa: el agente no lanza excepción, no devuelve error, no agota el timeout. Finge trabajar: quema contexto, quema tokens, quita tu tiempo. Es el peor tipo de fallo en un sistema agéntico, porque toda la instrumentación basada en “¿ha fallado?” dirá que todo va bien.

Las cifras del blog oficial (vendor-reported, como todo en este apartado): la tasa de repetición a nivel de respuesta por harness llegaba al 1,02% en Flash-RL bajo OpenCode y al 0,54% en Pro-RL:

Harness	Flash-RL	Pro-RL
OpenCode	1,02%	0,54%
Claude Code	0,27%	0,10%
Codex	0,23%	0,07%
MiMo Desktop	0,19%	0,19%
OpenClaw	0,17%	0,08%
DeepSeek Harness	0,17%	0,07%
Hermes	0,16%	0,05%
MiMo Code	0,11%	0,07%
Zcode	0,07%	0,05%

Y el dato que debería incomodar a cualquiera que escale RL agéntico: el propio entrenamiento alimentaba el vicio. En las evaluaciones internas de Xiaomi sobre Flash-RL, la fracción de ejemplos reprocesados (“replayed”) con tool-call flooding (más de diez llamadas en un turno) ya era del 11,1% en el paso 0 del RL y subió al 24,6% en el paso 20. El reward optimizaba corrección de la tarea; nadie puntuaba “no hacer el tonto con las herramientas”. Es un reward blind spot de manual, y lo documentan ellos, lo cual es más de lo que hace la mayoría.

La gestión del parche también merece lectura. El 25 de septiembre a las 06:00 (UTC+8), Xiaomi cambió el modelo que sirve su API — sin cambiar los nombres mimo-v2.6-pro y mimo-v2.6-flash — y reseteó la cuota restante de MiMo Desktop como disculpa. Los pesos parcheados llegaron a Hugging Face el 27 de septiembre. Si consumías la API entre el 21 y el 25, el modelo cambió bajo tus pies sin que el nombre te avisara. En la era de los modelos como servicio, “misma versión, pesos distintos” es el estado normal; conviene diseñar las evaluaciones de regresión en consecuencia.

MOPD2: destilación on-policy multi-profesor (§5.6 del report)

El parche no es un fine-tune con penalización de repetición: es la sección 5.6 del technical report ya citable en arXiv. MOPD2 (Multi-Prefix Multi-Teacher On-Policy Distillation) fusiona varios profesores especializados por dominio en el modelo alumno, extendiéndolo a dominios donde la verificación en entrenamiento es poco fiable — los ejemplos del README: desarrollo de juegos long-horizon, investigación científica e inteligencia embodied.

Los profesores son de dos familias: mixRL teachers, entrenados en tareas verificables, y SFT teachers, entrenados sobre demostraciones sintéticas para dominios abiertos donde no se puede diseñar un reward fiable. Tres flujos contribuyen a una única update:

Standard MOPD: los profesores RL supervisan rollouts autónomos completos del alumno.
Teacher-Prefix OPD: de cada trayectoria de profesor con k turnos se derivan k prefijos de historia; el alumno genera un turno nuevo desde cada uno y el profesor lo puntúa contra la misma historia.
SFT-Prefix OPD: las demostraciones SFT aportan la historia y el alumno escribe su propia continuación.

Si el mecanismo te suena es porque es la misma família que la destilación on-policy que ya analizamos: el alumno genera, el profesor puntúa en la distribución del alumno, no en la del profesor. Lo interesante aquí es el uso: MOPD2 como puente del RL hacia los dominios que el RL no puede tocar por falta de verifier. La estrategia “no puedo puntuar esto → destilo un profesor que sí lo hace bien” es probablemente la parte más replicable de todo el report para quien monte su propio pipeline.

Sobre la eficacia del parche: el README muestra una figura de tasa de repetición antes/después por longitud de contexto y harness, sin valores numéricos publicados, y el blog oficial remite a ella. Vendor-reported, sin cifra concreta que citar. El propio README describe el fix como barato de entrenar: “a short specialized-teacher run that converges quickly”.

La evaluación independiente que faltaba

El 2 de octubre el veredicto tenía una pega de tamaño: toda la tabla de benchmarks era del README del vendor. Ahora Artificial Analysis ha medido los modelos vía API, y los números cambian el panorama:

Métrica (AA, 09-oct-2026)	MiMo-V2.6-Pro	Kimi K3 (Max)	GPT-6 Sol (Max)	GLM-5.3 (Max)
Intelligence Index	46	44	48	45
GDPval-AA v2.1	1685	1533	1508	1651
AutomationBench-AA	59%	58%	62%	62%
Terminal-Bench 4.0	35%	13%	44%	42%
Humanity’s Last Exam	49%	47%	48%	42%
Coste por tarea	$0,13	$2,00	$1,04	$2,01
Velocidad de salida (tokens/s)	43	41	96	83

Lecturas, todas sobre cifras de AA (un tercero que evalúa vía API; consulta 09-oct-2026):

En su índice, Pro queda por delante de Kimi K3 Max (46 vs 44) — el abierto frontera de julio que analizamos en su día — costando un 7% de su precio por tarea ($0,13 vs $2,00). El “los abiertos compiten en método, no solo en precio” de la pieza anterior gana aquí su mejor evidencia hasta la fecha.
Sigue por detrás de los cerrados de referencia en lo que la pieza del 02-oct ya señalaba: Terminal-Bench 4.0 (35% vs 44% de GPT-6 Sol Max) y AutomationBench-AA (59% vs 62%). El perfil “orquestación sí, coding exigente de larga cola no” se sostiene con un evaluador neutral.
El precio barato tiene letra pequeña medida: 43 tokens/s (el doble de lento que GPT-6 Sol o GLM-5.3 Max) y 64k tokens de salida por tarea en el índice de AA. Verbosidad + velocidad lenta = la latencia real por tarea es brutal: 1.447 segundos de media según AA. El $/tarea es imbatible; el tiempo/tarea, no.
Flash queda en 38 en el índice a $0,06 por tarea, con 240M de tokens generados para completar la evaluación — “muy verboso” en palabras de AA.

Dos matices antes de abrazar estas cifras. Primero: AA evalúa el API de Xiaomi, que desde el 25 de septiembre sirve el checkpoint MOPD con el mismo nombre; lo que mide AA ya no es, técnicamente, el Pro-RL del README del 21 de septiembre (mi lectura, no una afirmación de AA). Segundo: el ranking de un índice compuesto depende de su mezcla de benchmarks; AA-Omniscience deja a Pro en 8 frente al 20 de K3 y el 27 de GPT-6 Sol. Ningún índice es la verdad; este al menos es de alguien que no vende el modelo.

Qué sigue sin estar abierto

Los logs del run completo. Entornos y verifiers sí; las dinámicas de entrenamiento como series temporales (reward por paso, colapsos, restarts) no aparecen como artefacto descargable. El abstract promete “training dynamics”; lo demostrable hoy es más estrecho.
Los profesores de MOPD2. El alumno fusionado es MIT; los profesores especializados por dominio no están publicados como pesos independientes.
La escala del fix de repetición. Cuánto costó el run del profesor especializado: ni una cifra.
Los datos de pre-entreno. Pesos abiertos, datos no; sin cambios.
Que el grader sea fiable. Sigue siendo un hermano de pesos del alumno y el <2% de hacks confirmados sigue siendo auto-reportado. Que la evaluación independiente de AA dé resultados coherentes con los del vendor es una señal indirecta, no una réplica del pipeline.

Qué haría yo

Si entrenas o vas a entrenar agentes con RL: descarga MiMo-V2.6-RL-oss y estudia la estructura antes que los pesos del modelo. El patrón instruction.md + manifest.json + herramientas MCP + workspace SQLite + verify.py con su verifier_meta.json es un estándar de facto nuevo para entornos agénticos auditables; es más valioso como plantilla para tus propios entornos que como dato de entrenamiento. Los forks (verl, uni-agent, mimoagent) te ahorran montar infra; ojo con atribuirle a verl las 23.805 estrellas del upstream: las suyas son 684.
Si consumías el API de Xiaomi: ya has estado sirviendo el checkpoint MOPD desde el 25 de septiembre sin saberlo. Si viste bucles de tool calls antes, re-ejecuta tus evaluaciones de regresión; si no las tienes, este incidente es el argumento para montarlas.
Si vas por OpenRouter: a 09-oct-2026 no hay variante MOPD listada — solo mimo-v2.6-pro, mimo-v2.6-flash y UltraSpeed, a los mismos precios que ya documentamos ($0,435/$0,87 y $0,14/$0,28 por millón, verificados de nuevo hoy). Lo que sirvan detrás de esos nombres es cuestión del provider, no del catálogo.
Si auto-hosteas el checkpoint -RL: el README ya trae comandos de V2.6 (SGLang con --tp 16 --dp 2, vLLM con --tensor-parallel-size 8), pero las recetas detalladas enlazadas siguen siendo las de V2.5 — el cookbook de SGLang de MiMo-V2.5 y la imagen vllm/vllm-openai:mimov25-cu129. Y si ves el patrón de llamadas repetidas, la vía oficial es migrar a MOPD, no tocar parámetros de sampling a ciegas.

Fuentes: README de MiMo-V2.6-Pro-MOPD · Blog oficial: Diagnosing and Mitigating Tool-Call Repetition in MiMo-V2.6 · Dataset MiMo-V2.6-RL-oss · arXiv 2610.11959 (v1, 08-oct-2026) · Forks XiaomiMiMo en GitHub: verl, uni-agent, mimoagent · Artificial Analysis: MiMo-V2.6-Pro y comparativas (consulta 09-oct-2026) · API de modelos de OpenRouter (consulta 09-oct-2026) · Pieza hermana: análisis de la receta RL del 02-oct