¿Muse Spark 1.3 mejor que Claude 5? La verdad después de usarlo

Hace unos días Meta lanzó Muse Spark 1.3, la nueva versión de su modelo. Y esto no llamaría tanto la atención si no fuera porque se lo está comparando con Fable 5.

Yo ya había probado Muse Spark 1.2 con su propio harness, Muse Code. Así que en este artículo voy a mostrar qué puede hacer realmente el 1.3 y si vale la pena pagar la suscripción. Porque eso es lo que dicen las métricas —que está al nivel de Opus o de Fable 5— pero en la práctica la cosa puede cambiar bastante.

Me quedé con la duda de si del 1.2 al 1.3 ha cambiado tanto. Vamos a averiguarlo.

🔥 Patrocinado por Hostinger

¿Cuántas veces terminaste un proyecto y se quedó en tu localhost porque desplegarlo era caro o complicado? Con un VPS de Hostinger tienes tu propio servidor por pocos dólares al mes: 2 núcleos de CPU, 8 GB de RAM, 100 GB de disco NVMe y hasta 8 TB de transferencia, sobre procesadores AMD EPYC.

Tienes acceso root completo, así que instalas lo que quieras: backend, frontend, cualquier lenguaje, tus propios asistentes de IA o proyectos populares como n8n desde su catálogo. Incluye además un asistente de IA integrado para resolver dudas del VPS en lenguaje natural, backups semanales gratuitos y snapshots manuales por si algo sale mal.

Con el código FAZT obtienes hasta un 10% de descuento:

👉 hostinger.com/fazt

Ya con tu servidor andando, saca ese proyecto del localhost.

Qué es Muse Code

Muse Code es el harness de Meta: su propio Claude Code, su propio Codex. Una herramienta de terminal que planifica tareas, edita código y ejecuta comandos dentro de tu proyecto.

Lo interesante técnicamente es que el modelo y el harness están co-entrenados, y que trae subagentes persistentes en worktrees aislados más un log de eventos a prueba de caídas, pensado para trabajo largo sobre un repositorio.

Instalación

Actualización importante. En el video instalé Muse Code vía WSL, porque al lanzarse en agosto solo había soporte para macOS y Linux. Eso ya cambió: Meta añadió soporte nativo para Windows, así que si estás en Windows ya no necesitas WSL. Si lo instalaste como yo, vale la pena rehacerlo de forma nativa.

La instalación es un comando de una línea que registra el comando muse. Después recargas la configuración con source y ejecutas muse para autenticarte. Se abre el navegador, das aprobar, y listo.

El modelo y la versión "contributor"

Al entrar verás que el modelo dice Muse Spark 1.3, pero fíjate si pone contributor. Con /model puedes elegir entre las dos variantes, y la diferencia importa:

Contributor es entre 12 y 21 veces más barato. Ese descuento lo pagas con tus datos. En mi prueba usé contributor justamente para tener más cuota, pero es una decisión consciente que conviene que tomes tú.

Las suscripciones

Muse Code es gratis de instalar; lo que pagas es el uso. Desde que salió de beta el 31 de agosto de 2026 hay tres planes:

Precisión sobre los multiplicadores. La prensa reportó inicialmente que High era 3x y Power 10x. Una auditoría reciente contra la documentación de developer.meta.com encontró que Meta publica 5x y 20x respectivamente. Revisa la página oficial antes de decidir, porque las fuentes no coinciden.

Es el punto de entrada más barato del mercado: una cuarta parte de lo que cuesta empezar con Claude Code o Codex. Eso no se le puede quitar.

Yo usé el plan de $5, que es el que la mayoría va a querer. Y adelanto una cosa: si vas a generar código todo el tiempo en esfuerzo máximo, esa suscripción no te va a alcanzar.

Los niveles de esfuerzo

Con /effort eliges cuánto razona el modelo. Estos son los niveles documentados:

none · minimal · low · medium · high · xhigh · ultra

El valor por defecto es xhigh, y none no está soportado dentro de Muse Code.

La escala funciona así: en los niveles mínimos responde muy rápido y razona poco. En medium ya razona más y se demora más. Entre medium y high está el punto recomendado. xhigh va más lento pero razona mucho más.

Y ultra es distinto: no es el modelo razonando a tope, sino que lanza múltiples subagentes para avanzar en paralelo. Hace más trabajo, consume muchos más tokens. Es el mismo concepto que ya existe en Claude Code.

Los skills que trae de fábrica

Muse Code no tiene modo plan con Shift+Tab como Codex o Claude Code. En su lugar trae sus propios skills preconstruidos, que listas con /skills o filtrando por built-in:

• plan — el que sustituye al modo plan
• browser — testing de navegador
• doctor — diagnóstico de configuración
• git — comandos básicos
• grill — hacerte una batería de preguntas

Ese último asumo que está inspirado en grill-me, de Matt Pocock, que es bastante popular ahora mismo.

Un detalle: si ya tienes skills en tu carpeta .agents, Muse Code los lee de ahí también. En mi caso me apareció un montón que ya tenía instalados.

Llamar al skill como Skill use bundled plan es muy verboso. Basta con /plan. Y /clear limpia la pantalla.

Prueba 1: una plataforma de cursos desde cero

Arranqué en una instancia limpia, sin skills ni MCPs, para ver el modelo puro. Le pedí con /plan:

Crear una plataforma de cursos donde múltiples usuarios puedan
inscribirse siendo instructor o estudiante. Subida de archivos,
cursos con secciones y capítulos, pagos por suscripción, paneles
de seguimiento con dashboard de stats y gráficos de barra,
y un rol administrador que puede acceder a todo.

Primer consejo práctico: por defecto pide aprobación en cada cambio, lo cual es agotador. Sal con /exit y relanza con muse --yolo para que ejecute sin preguntar. Con /resume recuperas la sesión anterior.

El plan

Honestamente, el plan no está nada mal. Definió criterios de funcionamiento, evaluó el workspace, puso limitaciones y metas fuera de alcance, y tomó decisiones: monolito con Next.js, backend separado, Stripe, sistema de roles, almacenamiento de archivos.

Es corto pero va al grano. Lo único que le faltó fue especificar versiones.

El resultado

La primera fase tomó 15 minutos. Pensé que serían 15 por fase, pero completó todas las fases en 12 minutos. El modelo no es tan lento como esperaba.

Ahora, lo que generó es el típico AI slop. Me registré, entré al catálogo, y es extremadamente básico. Y ojo que esto fue con xhigh.

Revisando el código:

• ✅ Usó diseño de API, lo cual hay que reconocerlo — muchos modelos se van directo a server actions y código de lado cliente
• ✅ Generación de Prisma correcta
• ✅ Versiones de paquetes actualizadas
• ❌ Pero el proyecto en sí es bastante básico

Subí el esfuerzo a ultra para activar los subagentes y pedí un rediseño del dashboard, un landing con secciones y precios, y datos de ejemplo.

Con /usage revisé el consumo: después de unos 10 minutos ya iba en el 55% de la suscripción de $5.

¿El resultado? El landing parece un modelo antiguo de GPT. Y el dashboard no cambió en nada, solo corrigió los colores.

Prueba 2: ayudarlo con un skill

Los skills son prompts preescritos que el agente carga cuando los necesita. Hay para base de datos, frontend, backend, seguridad, auditoría.

Usé Impeccable, que es el que más uso para diseño porque trae guías y plantillas. Lo encuentras en skills.sh, el directorio de agent skills de Vercel Labs.

Su propuesta es interesante y va justo al problema que estaba viendo: partió de la skill frontend-design de Anthropic y se enfoca en eliminar los tics del diseño generado por IA. Sus propias palabras describen el síntoma con precisión: Inter para todo, gradientes de morado a azul, tarjetas anidadas dentro de tarjetas, texto gris sobre fondos de color, el icono cuadrado redondeado encima de cada título. Trae 23 comandos y 45 reglas deterministas de detección.

Instalación:

npx impeccable install

También funciona con npx skills add pbakaus/impeccable, aunque esa vía instala un build compartido en lugar del compilado para tu harness. Muse Code no aparece en el selector por nombre, pero al leer la carpeta .agents lo carga igual.

Luego llamé al skill:

/impeccable rediseña el landing page

Trabajó unos 10 minutos y... el resultado es casi lo mismo. Algunas mejoras visuales, líneas divisorias, secciones. Nada dramático.

Corrección metodológica, y es importante. Al revisar la documentación de Impeccable para este artículo me di cuenta de que mi prueba no fue del todo justa con el skill. Impeccable está diseñado para ejecutar primero /impeccable init, que escribe un PRODUCT.md y ofrece un DESIGN.md con la audiencia, el carril de marca, la voz, las anti-referencias, los colores, la tipografía y los componentes. Los comandos posteriores dependen de ese contexto. Yo salté ese paso y fui directo al rediseño, así que el skill trabajó a ciegas.

Esto no cambia mi conclusión sobre el modelo —que es de lo que va este artículo— pero sí quiero dejarlo claro: si vas a usar Impeccable, corre init primero. Probablemente el resultado habría sido mejor, aunque con un modelo con más criterio de diseño de base.

Prueba 3: la tarea de código real

Asumamos que el diseño no es su fuerte y que lo suyo es el código. Le di una tarea que hago con frecuencia:

Crea un plan para migrar a un backend separado usando Bun y Hono.
Implementa todas las rutas de la API y las operaciones que falten,
además de crear un contenedor, documentación y testing.

Aclaro por qué elegí esta: es una tarea que Codex y Claude Code hacen bastante bien, normalmente en unos 10 minutos. Además obliga a instalar Bun, que no estaba en el entorno.

El plan, otra vez bien

Iba a crear una carpeta backend, usar bun test, levantar el contenedor, replicar las 23 rutas detectadas e implementar auth en el backend. Con su plan de trabajo paso a paso.

Sus planificaciones cortas serían bastante buenas si llegara a terminarlas.

La implementación, no tanto

Tomó unos 40 minutos. Y al revisar:

• Los tests existen, pero parece que solo cubren lo que él mismo generó
• Todas las rutas quedaron escritas en un solo archivo

Eso último no está bien. Pudo haber creado módulos, como hacen Claude o GPT. Y esto ya lo he probado con modelos chinos —GLM, DeepSeek— y generan mejor estructura que esto. Parece un modelo antiguo.

Del 1 al 10, a esta migración le pongo un 3 o un 4.

Lo positivo: la aplicación corre. Le pedí que ejecutara el proyecto, creé una cuenta y funciona con los datos de la API. Al menos eso no falla.

Pero el patrón de trabajo es el problema. Todo hay que pedirlo al estilo del vibe coding, de a poquito, diciéndole cada vez qué avanzar. Con un GPT-5.6 o un Opus 5, prácticamente este proyecto se habría creado en un solo prompt.

Los benchmarks contra la práctica

Aquí está el nudo del asunto, y merece mirarse con datos.

Lo que dicen las métricas

En el Artificial Analysis Intelligence Index, al momento de su lanzamiento el 2 de septiembre de 2026:

Efectivamente aparece empatado con Fable 5. Pero hay una letra chica que conviene conocer: ese 62 es de la variante max, que está en preview limitado para socios de Meta y ni siquiera tiene proveedor de API listado. La versión que puedes usar tú puntúa 61.

El giro que refuerza el argumento

En el video mencioné que en DeepSWE v1.1 —otro benchmark que mucha gente considera confiable— Gemini 3.8 Flash encabezaba la generación de código, superando a Opus 5 y a GPT-5.6 Sol. Eso es correcto para la instantánea del 1 de septiembre.

Pero revisando trackers posteriores que ya incluyen Muse Spark 1.3, el modelo aparece en primer lugar con 75,4% de pass@1, por encima de GPT-6 Astra, Gemini 3.8 Flash y Opus 5.

Léelo bien, porque es exactamente mi punto: el modelo que acabo de calificar con un 3 sobre 10 en una migración de backend encabeza el benchmark de ingeniería de software.

Eso tiene nombre y está documentado: benchmaxxing. Optimizar para puntuar alto en los tests públicos en lugar de hacer el modelo realmente útil. Las técnicas conocidas son contaminación de datos de entrenamiento, sobreajuste al formato del test, y selección del checkpoint que mejor puntúa.

Hay un matiz honesto que conviene añadir: muchas de las cifras de DeepSWE que circulan son auto-reportadas por los propios laboratorios en sus lanzamientos, no verificadas de forma independiente, y los intervalos de incertidumbre de los primeros puestos se solapan. Eso no invalida el benchmark, pero sí explica por qué la tabla y la experiencia real pueden divergir tanto.

Mi veredicto: dónde lo ubicaría

Seré directo. Este modelo no está para tanto. No me veo usándolo en el día a día.

Si lo pongo en un ranking personal, lo ubicaría por detrás de Kimi K3 y de GLM-5.3, probablemente cerca de Gemini 3.8 Flash — y con 3.8 Flash mi experiencia ha sido notablemente mejor.

Lo que más me recuerda es a versiones anteriores de GPT. Se le parece bastante, y hasta el harness tiene cierta similitud.

Da más trabajo del que ahorra. Unas modificaciones que deberían tomar minutos se llevan 30 o 40. Para trabajo real no me fiaría de él.

Cuándo sí podría servirte

Siendo justos, hay escenarios donde tiene sentido:

• Tareas pequeñas y acotadas, donde no necesitas arquitectura
• Si tu presupuesto es de $5 y quieres lo más barato que puedas conseguir ahora mismo
• Dentro de un loop o con un goal definido, donde quizás le encuentres un uso más útil

La suscripción barata es real y eso no se le puede quitar.

Y una nota de perspectiva

Esto puede cambiar. Le pasó exactamente a Grok: la 4.1 no era buena generando código, prácticamente no la usaba, y hoy la 4.6 desde Cursor es un modelo bastante decente. No impresionante al nivel de Fable o GPT, pero útil para generación de código barato.

Muse Spark va en esa misma línea. Dale unos meses.

Precisiones sobre el video

Tres cosas que revisé después de grabar:

1. Muse Code ya tiene soporte nativo para Windows. Yo lo instalé por WSL porque al lanzarse solo había macOS y Linux. Meta añadió el soporte nativo hace muy poco, así que ya no hace falta WSL.
2. Mi prueba con Impeccable no fue del todo justa. El skill espera que corras /impeccable init primero, que escribe el contexto de producto y diseño del que dependen los demás comandos. Yo salté ese paso.
3. Muse Spark 1.3 encabeza DeepSWE en los trackers más recientes, con 75,4% de pass@1. Cuando grabé, la instantánea que revisé tenía a Gemini 3.8 Flash arriba. El dato nuevo refuerza el argumento del benchmaxxing en lugar de contradecirlo.

Preguntas frecuentes

¿Vale la pena la suscripción de $5? Para tareas pequeñas y acotadas, puede ser. Es el punto de entrada más barato que hay. Para desarrollo serio, el tiempo que pierdes cuesta más que la diferencia con una suscripción de $20.

¿Qué es la versión contributor? Una variante del modelo mucho más barata —hasta 21 veces— a cambio de que Meta pueda usar tus sesiones para mejorar sus productos. Solo está disponible en países seleccionados.

¿Se puede usar en Windows? Sí, y ahora de forma nativa. Ya no hace falta WSL.

¿Qué hace el modo ultra? No es el modelo razonando más, sino lanzando múltiples subagentes en paralelo. Avanza más rápido en tareas divisibles, pero consume muchos más tokens.

¿Por qué el modelo puntúa tan alto y rinde así? Es el patrón del benchmaxxing. Los benchmarks miden tareas acotadas y verificables; un proyecto real con arquitectura, módulos y despliegue mide otra cosa.

¿Los skills mejoran mucho el resultado? Ayudan, pero no obran milagros: el modelo sigue siendo el techo. Y hay que usarlos como están diseñados —en el caso de Impeccable, corriendo init primero.

Conclusión

Esperaba que este modelo fuera más sorprendente. Pensé que estaría cerca de un GPT. No está del todo mal, pero tampoco creo que esté al nivel de los modelos con los que lo están comparando.

Si lo has usado en proyectos reales, déjame tu experiencia en los comentarios. Y si tienes dudas, también.

Recursos

• Muse Code, de Meta
• skills.sh, el directorio de agent skills
• Impeccable, el skill de diseño
• grill-me, de Matt Pocock
• Artificial Analysis Intelligence Index

¿Tienes dudas sobre tu stack o quieres una asesoría personalizada? Encuéntrame en fazt.dev.