MiniMax acaba de lanzar M3 —que mucha gente llama informalmente “MiniMax 3.0”—, y sobre el papel es impresionante. Lo presentan como el primer modelo open-weight con tres capacidades frontera a la vez: código, contexto de un millón de tokens y multimodalidad nativa. Quiero dejar clara mi postura desde el principio: tengo fe en que sea un buen modelo, pero no será mi daily driver.
Qué trae M3 sobre la mesa
Los números que publica MiniMax no son humo. M3 corre sobre una arquitectura propia, MiniMax Sparse Attention (MSA), con ventana de contexto de hasta 1M tokens (mínimo garantizado de 512K). La multimodalidad no es un parche: dicen haber reconstruido todo el pipeline de datos para entrenarla desde el paso cero.
En benchmarks agénticos hay datos llamativos. En BrowseComp marca 83.5, superando a Opus 4.7 (79.3). En su PostTrainBench, donde el modelo entrena otros modelos de forma autónoma, queda tercero (37.1), solo por detrás de Opus 4.7 (42.4) y GPT-5.5 (39.3). Y enseñan demos potentes: reproducir un paper de ICLR en 12 horas de ejecución autónoma, u optimizar un kernel CUDA con 9,4× de speedup tras 147 iteraciones.
Como ingeniero, eso me parece genuinamente bueno. Que un modelo open-weight pelee en esa liga es una noticia excelente para todos.
Dónde está mi reserva
Mi escepticismo no va contra los benchmarks. Va contra una experiencia concreta que se repite con los modelos que no son top absoluto: llega un punto en el que necesito más calidad y el modelo simplemente no puede dármela.
Y aquí está el matiz importante: ese techo no se resuelve con andamiaje. Puedo poner subagentes a revisar el código, capas de verificación, bucles de auto-crítica, todo el orquestado que quieras. Eso mejora la consistencia y reduce errores tontos, pero no eleva el techo de razonamiento del modelo base. Si el modelo no “ve” la solución correcta, mil subagentes revisando no la van a inventar. Solo van a confirmar, con más pasos y más coste, la misma limitación.
El trabajo real expone los límites
Para tareas acotadas —scaffolding, refactors mecánicos, generar boilerplate, recuperación sobre contextos largos— M3 probablemente rinda de sobra. Ahí el contexto de 1M y las capacidades agénticas son una ventaja real.
El problema aparece en el trabajo difícil: el cambio que toca cinco sistemas a la vez, el bug sutil que exige entender una abstracción completa, la decisión de diseño donde el modelo tiene que sostener mucho estado mental y razonar de verdad. Ahí es donde, en mi experiencia, GPT-5.5 y Claude Opus siguen marcando una diferencia que no es de matiz, sino de “lo resuelve o no lo resuelve”.
No espero que cubra mi uso
Seamos justos: no estoy pidiéndole a M3 que sea algo que no pretende ser. Es un modelo open-weight con una propuesta de valor enorme —capacidad frontera abierta, desplegable, con un plan de tokens competitivo—. Para muchísima gente y muchísimos casos, va a ser más que suficiente.
Pero no espero que llegue al uso que le doy a un GPT-5.5 o a un Claude Opus. Mi flujo de trabajo empuja constantemente contra el límite superior de calidad, y ahí no hay arquitectura de agentes que compense un techo de modelo más bajo.
Mi veredicto
M3 me genera fe, y lo digo en serio. Es un paso adelante para el ecosistema abierto y lo voy a tener vigilado. Pero “buen modelo” y “daily driver para mi trabajo más exigente” son dos categorías distintas, y por ahora M3 está en la primera. Lo usaré para lo que hace bien, sin pedirle lo que sé que no me va a dar.
