Tutorial de Muse Spark 1.3: guía práctica para desarrolladores

Meta lanzó Muse Spark 1.3 el 2 de septiembre de 2026, y las instrucciones de actualización caben en una línea: cambia el ID del modelo. Usa los mismos endpoints, el mismo SDK y los mismos precios.

Según Meta, ese cambio de una línea te da un modelo que termina la misma tarea con ~20% menos llamadas a herramientas y 25% menos tokens que Muse Spark 1.2. Esas cifras vienen de comparativas realizadas por sus propios ingenieros, en tareas no especificadas y sin publicar la metodología.

Ese es exactamente el tipo de afirmación que quiero comprobar antes de repetirla. 

Así que instalé Muse Code, rompí a propósito un proyecto open source real y ejecuté las mismas tres tareas en ambos modelos.

Para seguir este tutorial de Muse Code, necesitas una cuenta de desarrollador de Meta, un terminal en el que te sientas cómodo y macOS o Linux para el agente de Muse Code. Los usuarios de Windows siguen sin suerte en la beta actual.

En pocas palabras

• Muse Spark 1.3 es el modelo insignia de razonamiento multimodal de Meta, lanzado el 2 de septiembre de 2026, con una ventana de contexto de 1M de tokens.
• Muse Code te inicia por defecto en muse-spark-1.3-contributor, lo que significa que Meta entrena con tu código salvo que cambies la opción. El entrenamiento es por exclusión voluntaria, no por inclusión.
• En 6 ejecuciones sobre 3 tareas de código, 1.3 fue más barato en 2 y un 38% más caro en la tercera, para un aumento neto del 12% en costes sobre el conjunto.
• Las completaciones del modelo cayeron 23% y 32% en las 2 tareas donde ganó 1.3, lo que cuadra con la afirmación de Meta sobre llamadas a herramientas. El input sin caché cayó en las 3, pero nunca un 25%.
• El nivel de razonamiento ultra aparece en la CLI y en el selector de sesión, pero el backend lo rechaza con una puerta de características nombrada.

¿Qué es Muse Spark 1.3?

Muse Spark 1.3 es el modelo insignia de razonamiento multimodal de Meta, lanzado por Meta Superintelligence Labs el 2 de septiembre de 2026 y diseñado para sesiones agenticas largas y programación en repositorios grandes. Mantiene 1.048.576 tokens de contexto y acepta texto, imágenes, vídeo y archivos.

Seis cambios respecto a Muse Spark 1.2:

• Eficiencia. Aproximadamente 20% menos llamadas a herramientas y 25% menos tokens en comparativas internas de Meta.
• Colaboración. Hace preguntas aclaratorias ante prompts vagos y valida antes de acciones con consecuencias.
• Multitarea dentro de un mismo hilo, de modo que un mensaje a mitad de flujo se asocia a la tarea que pretendías.
• Seguimiento de instrucciones largas, con menos restricciones perdidas en trabajos de varios pasos.
• Mejor calibración en acciones irreversibles.
• Estilo de código más limpio. Menos vueltas innecesarias, menos verborrea.

Todo pinta bien, pero la hoja de resultados publicada por Meta ejecuta Muse Spark 1.3 a nivel de razonamiento max frente a Muse Spark 1.2 a xhigh, y max seguía vetado en el lanzamiento. 

Artificial Analysis puntuó la variante xhigh comercial en 61 en su Intelligence Index y max en 62. Un punto de diferencia.

Matt Crabtree ya cubrió las tablas de benchmarks completas, el desglose de precios y cómo se compara con GPT-5.6 Sol y Claude Opus 5 en su análisis del lanzamiento de Muse Spark 1.3. No voy a repetirlo. Lo que sigue es qué pasa cuando lo instalas y te pones a trabajar.

Cómo acceder a Muse Spark 1.3

Hay tres vías y la adecuada depende de lo que estés construyendo. Elige en la tabla y salta a la sección correspondiente.

Muse Code, el agente de terminal

Muse Code es el agente de programación en terminal de Meta, en beta para macOS y Linux. Es el arnés que ejecuta Muse Spark, y versionan de forma independiente, así que muse --version no te dice qué modelo estás usando. Mantén eso separado en tu cabeza.

curl -fsSL https://dev.meta.ai/install.sh | bash

Descarga un binario de 230 MB y lo deja en ~/.local/bin/muse, que no siempre está en el PATH de todos.

Luego comprueba qué has instalado:

muse --version

El 4 de septiembre de 2026 me devolvió Muse Code 1.0.2 (1.0.2-R2040.1). 

Un poco raro para una beta, ya que herramientas de terceros documentaban Muse Code como 0.2.1 semanas antes. Anota la versión que te toque y la fecha.

Captura de pantalla del autor. Instalando Muse Code con el script de una línea y confirmando la versión 1.0.2 en macOS.

Ahora ejecuta muse. La primera vez, imprimió Not logged in. Run muse again to log in y salió. Así que lo ejecutas dos veces, que es el tipo de detalle que te hace pensar que la instalación falló.

La segunda ejecución inicia un flujo de dispositivo OAuth. Muestra una URL de acceso con un código corto, enseña el mismo código aparte y te pide confirmar que coinciden antes de aprobar en el navegador.

Sign in at this page:
  https://auth.meta.com/oauth/device/?code=XXXX-XXXX
confirm this code matches:
  XXXX-XXXX

Waiting for approval…

Y entonces deberías ver esta vista: 

Captura de pantalla del autor. Flujo de acceso de Meta Model API, confirmando los datos de la cuenta antes de emitir credenciales. 

En el navegador confirmas tu nombre, aceptas los términos y añades una tarjeta. Lee el panel de precios en esa pantalla de pago antes de hacer clic, por razones que se aclararán en treinta segundos.

El nivel por defecto entrena con tu código

De vuelta en el terminal, el encabezado de la sesión te dice qué estás ejecutando:

Muse Code 1.0.2
You are logged in.
Model set to muse-spark-1.3-contributor
└ Discounted tokens: your content, including inter-session messages, may be
  used for product improvement.

Lee de nuevo el nombre del modelo. La variante contributor, puesta por defecto, en una instalación limpia y sin que nadie te lo pregunte.

Meta no lo esconde. El aviso está bajo el nombre del modelo, la pantalla de pago marca contributor como DEFAULT y la barra de estado mantiene muse-spark-1.3-contributor visible mientras trabajas. 

Pero la carga está invertida respecto a lo que la mayoría de desarrolladores esperan.

Si abres Muse Code dentro del repo de un cliente y te pones a trabajar, ya has enviado ese código a un endpoint apto para entrenamiento. Comprueba la barra de estado antes de tu primer prompt, no después.

Captura de pantalla del autor. Primera sesión de Muse Code, con el modelo por defecto muse-spark-1.3-contributor y el aviso de mejora de producto debajo.

La barra de estado también muestra el esfuerzo de razonamiento, que en mi caso estaba en high. No en xhigh, la variante que evaluó Artificial Analysis. Recuerda esto al comparar tus resultados con cualquier cifra publicada.

Elegir y cambiar de nivel

Ejecuta /model y verás un selector interactivo con cuatro opciones y sus tarifas. Estas cifras coinciden con la pantalla de pago de Meta:

Contributor es aproximadamente 12 veces más barato en input y 21 veces más barato en output.

Ese descuento lo compras con tu propiedad intelectual. Meta dice: "tu contenido, incluidos los mensajes entre sesiones, puede utilizarse para mejorar el producto", lo que abarca más que el código que le pasas.

Ambas variantes de Muse Spark 1.2 siguen en el selector con precios idénticos, lo que importa para la comparativa posterior: como las tarifas no cambian entre generaciones, comparar tokens es comparar costes sin normalizar nada.

Captura de pantalla del autor. El selector /model mostrando las cuatro variantes de Muse Spark con tarifas de caché, input y output.

Para excluirte, sube con la flecha hasta muse-spark-1.3 y pulsa intro. La línea de "Discounted tokens" desaparece del encabezado.

Para trabajo con clientes, hay una opción más fuerte que no aparece en el terminal. Meta afirma que ha empezado a aceptar solicitudes de cero retención de datos, gestionadas vía ventas en lugar de un interruptor. 

Retención y entrenamiento son cuestiones distintas, y los contratos de agencia suelen exigir respuesta a ambas.

El rate limiting funciona de forma diferente entre niveles, aunque hay fuentes que discrepan. El blog de desarrolladores de Meta describe el nivel contributor como limitado por tokens en una ventana móvil de 5 horas en lugar de por número de solicitudes. La prensa en el lanzamiento de la 1.2 habló de un límite de 60 solicitudes por minuto, un mecanismo totalmente distinto. Yo no alcancé ningún límite en unas 90 completaciones en una tarde.

La Meta Model API y OpenRouter

La Meta Model API es compatible con el SDK de OpenAI, así que migrar implica cambiar el ID del modelo y conservar tu cliente. Los IDs son muse-spark-1.3 y muse-spark-1.3-contributor.

OpenRouter lo ofrece bajo el slug meta/muse-spark-1.3. Eso tiene un coste: OpenRouter midió un throughput de ~81 tokens por segundo frente a los 182 que Artificial Analysis registró yendo directo, con una disponibilidad cercana al 92% en los tres primeros días. Meta es el único proveedor, así que no hay un segundo proveedor al que hacer failover.

Tu primera sesión con Muse Spark 1.3

Todo lo de abajo se ejecuta contra python-humanize/humanize, fijado al commit 823ad6096. Son 1.676 líneas de código fuente en 6 módulos, el test suite corre en menos de un segundo y el dominio no necesita explicación. Nada aquí modifica el repo. 

Son preguntas de solo lectura para ver cómo explora el agente una base de código antes de darle nada que escriba.

Dos prompts para ver cómo lee código. Empecemos por el primero: 

Map the dependency graph of this project and tell me which module has the most inbound imports.

Ejecutó dos comandos, listó la estructura del proyecto y luego escribió un parser de AST en lugar de buscar import a pelo. Respuesta: i18n con 4 imports entrantes, desglosados como i18n 4, number 2, y filesize, lists, time y _version 1 cada uno.

Lo contrasté con mi propio script y obtuve otros números, que parecían un fallo del modelo. Mi script estaba mal: solo contaba imports relativos (from ._version import ...) y se perdía la forma absoluta (from humanize.i18n import ...), que es cómo importa la mayor parte del paquete. El modelo manejó ambas.

El segundo prompt es el que merece la pena ejecutar, porque puedes corregirlo:

List every public function in src/humanize, grouped by module, with a count per module.

Respondió 20 en total: filesize 1, i18n 5, lists 1, number 8, time 5. Todo correcto. Además añadió, sin que se lo pidiera, que i18n.get_translation es pública por nombre pero no está en i18n.__all__, que solo exporta las otras cuatro. También correcto.

Esa sesión costó $0.01 en 8 turnos.

El nivel de razonamiento del que Meta no habla

muse --help documenta esto:

--reasoning-effort <EFFORT>
    Meta reasoning effort: none|minimal|low|medium|high|xhigh|ultra
    (default: high)

El selector en sesión /effort ofrece seis de esos siete, omitiendo none. 

Captura de pantalla del autor. El selector /effort lista seis niveles seleccionables, con high marcado como actual.

Ambos listan un nivel llamado ultra, que no aparece en ningún anuncio de Meta. La postura pública de Meta es que el razonamiento max "llegará en breve cuando terminemos pruebas de seguridad adicionales".

Así que lo pedí:

muse exec --model muse-spark-1.3-contributor --reasoning-effort ultra 'Reply with exactly: ok'

tbh: reasoning effort ultra is not available (gate ultra_reasoning_effort is closed); using xhigh

Hay una puerta de características con nombre, ultra_reasoning_effort, y está cerrada. La capacidad existe y el interruptor está apagado en el servidor. Es una imagen más específica que "pendiente de pruebas de seguridad", y llega en un aviso que además contiene la expresión "tbh".

Dos apuntes prácticos. El cliente anuncia un nivel que el backend no sirve, tanto en la CLI como en el selector. Y baja silenciosamente a xhigh con una sola línea en stderr, que en un script o en un log de CI puede pasar desapercibida. Podrías creer que ejecutas una configuración que no estás usando.

Luego probé un valor que no aparece en la documentación:

muse exec --model muse-spark-1.3-contributor --reasoning-effort max 'Reply with exactly: ok'

Sin ningún aviso. Se ejecutó y devolvió ok. Así que un valor no documentado pasa la validación sin comentarios mientras que uno documentado está vetado, y no puedes saber por la salida qué nivel de esfuerzo sirvió realmente tu petición.

Captura de pantalla del autor. Pedir ultra devuelve una puerta cerrada y una bajada silenciosa a xhigh, mientras que el no documentado max pasa sin comentarios.

Si te importa el nivel de razonamiento que ejecutas, establécelo explícitamente y lee stderr. No asumas que la flag que pasas es la que se aplica.

¿Se sostiene la promesa de eficiencia de Muse Spark 1.3?

Aquí va la prueba. Toma un repo open source, revierte un commit de corrección de bug real para que el test suite falle de verdad y luego ejecuta tres tareas de código en ambos modelos con los mismos prompts y las mismas flags.

Estas son independientes de la sesión exploratoria anterior. Todas escriben código.

Revertir la mitad de código fuente del commit 823ad6096 manteniendo sus tests deja 6 tests fallando, y ese es el estado inicial:

git checkout 823ad6096e1e5ba82ea876ce761fc2efebd76157
git show 823ad6096 -- src/humanize/filesize.py | git apply -R -
python -m pytest tests/test_filesize.py -q

Cada ejecución usó la misma forma de comando, cambiando solo el ID del modelo y el prompt:

muse exec \
  --model muse-spark-1.3-contributor \
  --reasoning-effort high \
  --no-parallel-tool-calls \
  --approval-mode never \
  'PROMPT GOES HERE'

Tarea 1, corrección de bug. 

El éxito es binario: los 6 tests pasan, o no. 

The test suite tests/test_filesize.py is failing. 
Fix the source code in src/humanize/ so that all tests pass. 
Do not modify any file in tests/.

Tarea 2, pequeña funcionalidad.

Lo bastante abierta como para que los dos modelos discrepen sobre el alcance, cosa que resultó importante.

Add a function called natural_list_with_limit to src/humanize/lists.py. 
It formats a list but truncates after a given number of items, appending "and N more". 
Export it from the package and add tests.

Tarea 3, refactorización.

La más pesada de las tres, tocando varios archivos.

src/humanize/number.py is 571 lines. 
Split it into two modules along a sensible boundary, 
update all imports across the package, and make sure the full test suite still passes.

Las tres tareas se ejecutaron en secuencia sin reinicio entre ellas, de modo que las tareas 2 y 3 se construyeron sobre lo que el modelo produjo antes. Ambos modelos recorrieron el mismo camino.

Los conteos de tokens vienen de los logs de sesión en ~/.local/share/muse/sessions/, contados una vez por completación del modelo. Las seis ejecuciones pasaron sus tests.

Y las diferencias, donde negativo significa que 1.3 usó menos:

Leer el resultado con honestidad

Dos de las tres tareas salieron más baratas, con 23% y 32% menos completaciones del modelo. Eso encaja con la afirmación de Meta sobre llamadas a herramientas. Luego la refactorización fue al revés: 70% más completaciones y 38% más coste.

En el conjunto, 1.3 costó un 12% más que 1.2. Así que la promesa de eficiencia es real pero depende de la tarea, y un único porcentaje en un titular lo oculta por completo.

El input sin caché cayó en todas: 19%, 22% y 5%. Nunca un 25%. 

Meta no dice qué tokens contó, y la respuesta cambia mucho según si hablas de input, output, sin caché o total.

Las tasas de acierto de caché fueron del 88% al 97% y subieron con la longitud de la tarea. Informar de tokens de input brutos sin separar caché de no caché sería casi inútil, ya que los 4,18M de input de la refactorización son en realidad 109k de contexto nuevo más 4,07M de relecturas facturadas a un cincuentavo.

Por qué la refactorización no es una pérdida clara

Mira lo que 1.3 hizo realmente en esa tarea antes de llamarlo ineficiente.

Verificó que cada bloque movido fuera byte a byte idéntico al original, de forma programática. 

Ejecutó --doctest-modules en ambos archivos nuevos. Probó la resolución de imports desde un directorio temporal en /tmp. Luego señaló dos cosas que nadie pidió: que la función humanize.scientific sombrea el nuevo submódulo, y que un doctest de naturaldelta falla de forma idéntica en el árbol prístino, así que el fallo no es atribuible al cambio.

Muse Spark 1.2 duplicó una función auxiliar para esquivar un import circular y siguió. 1.3 la importó y explicó por qué no había ciclo.

No puedes separar "gastó más tokens" de "hizo un trabajo más exhaustivo" con este diseño. La afirmación honesta es que 1.3 gastó más y entregó más, y que si eso es una victoria depende de si querías ese plus de rigor.

La tarea de funcionalidad muestra el patrón contrario y es la ilustración más limpia del "menos verbo" de Meta. Muse Spark 1.2 inventó alias de parámetros max_items, n y max_len que nadie pidió y escribió 28 tests. 

Muse Spark 1.3 escribió una única firma con un valor por defecto sensato y 20 tests, con un 54% menos de tokens de salida.

Lo que no pude controlar

Cuatro cosas, y el artículo sería deshonesto sin mencionarlas.

1. Muse Code se actualizó de 1.0.2 a 1.0.3 a mitad, así que el arnés no fue idéntico en las seis ejecuciones. 
2. Las tareas 2 y 3 partieron del output previo de cada modelo en lugar de un árbol byte a byte idéntico, porque la secuencia corre sin resets.
3. Cada celda es un único intento, así que la variabilidad normal entre ejecuciones no está medida. 
4. Y ejecuté todo en el nivel contributor, que es el mismo modelo pero no las mismas condiciones de datos.

Nada de eso invalida la dirección de los resultados. Sí significa que una diferencia agregada del 12% es una señal más débil de lo que darían tres repeticiones por celda.

Buenas prácticas y solución de problemas de Muse Spark 1.3

Algunas cosas que me habría gustado saber el primer día.

Prompts para los comportamientos de colaboración

Muse Spark 1.3 hace preguntas aclaratorias ante prompts ambiguos, así que un prompt sobreespecificado apaga una función por la que estás pagando. Contraintuitivo si llevas dos años aprendiendo a adelantar todas las instrucciones.

Aun así, el alcance importa. "Divide number.py" deja al modelo adivinando el límite, las actualizaciones de imports y qué se considera hecho. La versión que usé concreta las tres cosas:

src/humanize/number.py is 571 lines. Split it into two modules along a sensible boundary, update all imports across the package, and make sure the full test suite still passes.

Una cosa más útil. Mi prompt de refactorización decía number.py is 571 lines. Son 567. Ambos modelos me corrigieron sin que se lo pidiera, y 1.3 lo hizo en su primera frase. Mi número venía de medir la punta del repo en lugar del commit fijado.

Cómo mantener los costes a raya

Pon la parte estable de tu prompt al principio para que sea cacheable. Con tasas de acierto del 88% al 97%, tu comportamiento de caché mueve la factura mucho más que la elección de modelo.

Las tres tareas costaron $0.034 en contributor. El mismo trabajo en standard habría sido $0.91, una diferencia de 27x. Esa es la decisión de nivel en dinero: tres céntimos frente a noventa.

Si pasas por OpenRouter, las búsquedas web se facturan aparte a $2.50 por 1.000 llamadas.

Cuándo Muse Spark 1.3 no es la mejor elección

• Sin trazas de razonamiento expuestas. Ves qué decidió, no por qué, lo que complica depurar una mala refactorización.
• El razonamiento max está vetado, así que la configuración detrás de los números de muchos titulares no está disponible.
• Pesos cerrados. Sin autoservicio ni fine-tuning. La hoja de ruta de Meta menciona un "Muse Spark open weights release" sin versión, fecha ni licencia.
• Un solo proveedor. Si el endpoint de Meta se degrada, no hay a dónde enrutar.

Problemas habituales y soluciones

• muse: command not found tras una instalación limpia. El script instala en ~/.local/bin/muse, que no está en el PATH de todos los shells.
• Not logged in. Run muse again to log in. Exactamente lo que dice. El primer muse sale, el segundo inicia el acceso.
• Estás en el nivel contributor y no lo elegiste. Es el valor por defecto. Comprueba la barra de estado y ejecuta /model antes de abrir nada propietario.
• ultra se convierte silenciosamente en xhigh. La puerta está cerrada. Lee stderr en lugar de fiarte de la flag que pasaste.
• Muse Code se actualiza en mitad de la sesión. En mi caso pasó de 1.0.2 a 1.0.3 entre ejecuciones. Si vas a medir algo, fija y registra la versión.

Una cosa que no pude reproducir

Circularon informes de que a usuarios de la UE se les seguía sirviendo Muse Spark 1.1 tras el lanzamiento de 1.3. Yo ejecuté todo esto desde Países Bajos y recibí 1.3 en todo momento. Esos informes se referían a Meta.ai, el asistente para consumidores, y no parecen aplicar a Muse Code ni a la Model API. Son dos despliegues distintos.

Conclusiones

La promesa de eficiencia de Meta se sostuvo en dos de mis tres tareas y se invirtió en la tercera, para un aumento neto del 12% en costes en el conjunto. La parte de llamadas a herramientas parece sólida con reducciones del 23% y 32% donde ganó 1.3. La parte de tokens depende totalmente de qué tokens cuentes.

Si ya usas la Meta Model API o Muse Code, cambiar el ID del modelo te lleva un minuto y probablemente saldrás ganando en trabajo rutinario. Si eliges desde cero para agentes en producción, el max vetado y la ausencia de trazas de razonamiento son motivos concretos para esperar unas semanas.

Lo que sí tendría en cuenta no es el número de eficiencia. Es que Muse Code te pone por defecto en un nivel apto para entrenamiento, y que un nivel de razonamiento documentado baja en silencio cuando lo pides. Ambas son cosas de una línea que es fácil pasar por alto.

Haz la comparativa en tu propia carga de trabajo. Mis tres tareas no son tus tres tareas, y la variación entre ellas fue mayor que la diferencia entre modelos.

Para la foto completa de benchmarks, el análisis del lanzamiento de Muse Spark 1.3 de Matt tiene las tablas. Para desarrollar las habilidades con las que evaluar modelos como este por tu cuenta, empieza por nuestro itinerario AI Agent Fundamentals.