Tutorial Muse Spark 1.3: um guia prático para desenvolvedores

A Meta lançou o Muse Spark 1.3 em 2 de setembro de 2026, e as instruções de upgrade cabem em uma linha: troque o ID do modelo. Isso significa que ele usa os mesmos endpoints, o mesmo SDK (software development kit) e a mesma precificação.

Segundo a Meta, esse ajuste de uma linha rende um modelo que conclui a mesma tarefa com cerca de 20% menos chamadas de ferramenta e 25% menos tokens do que o Muse Spark 1.2. Esses números vêm de comparações feitas por engenheiros da própria Meta, em tarefas não especificadas, sem metodologia publicada.

Esse é exatamente o tipo de afirmação que eu prefiro conferir antes de repetir.

Então instalei o Muse Code, quebrei de propósito um projeto open source real e rodei as mesmas três tarefas em ambos os modelos.

Para acompanhar este tutorial do Muse Code, você vai precisar de uma conta de desenvolvedor da Meta, um terminal em que se sinta à vontade e macOS ou Linux para o agente do Muse Code. Usuários Windows seguem sem suporte no beta atual.

Em poucas palavras

• Muse Spark 1.3 é o modelo carro-chefe de raciocínio multimodal da Meta, lançado em 2 de setembro de 2026, com janela de contexto de 1M de tokens.
• O Muse Code começa por padrão em muse-spark-1.3-contributor, o que significa que a Meta treina com o seu código a menos que você troque. Treinamento é opt-out, não opt-in.
• Em 6 execuções com 3 tarefas de código, o 1.3 foi mais barato em 2 e 38% mais caro na terceira, para um aumento líquido de 12% no custo do conjunto.
• As conclusões do modelo caíram 23% e 32% nas 2 tarefas em que o 1.3 venceu, o que bate com a promessa da Meta sobre chamadas de ferramenta. A entrada não em cache caiu em todas as 3, mas nunca 25%.
• O nível de raciocínio ultra existe na CLI e no seletor dentro da sessão, mas o backend recusa com um feature gate nomeado.

O que é o Muse Spark 1.3?

O Muse Spark 1.3 é o modelo de raciocínio multimodal carro-chefe da Meta, lançado pelo Meta Superintelligence Labs em 2 de setembro de 2026 e feito para sessões longas com agentes e coding em repositórios grandes. Ele comporta 1.048.576 tokens de contexto e aceita texto, imagens, vídeo e arquivos.

Seis pontos mudaram em relação ao Muse Spark 1.2:

• Eficiência. Cerca de 20% menos chamadas de ferramenta e 25% menos tokens nas comparações internas da Meta.
• Colaboração. Faz perguntas esclarecedoras em prompts vagos e confirma antes de ações consequentes.
• Multitarefa dentro de uma thread, então uma mensagem enviada no meio do fluxo se associa à tarefa certa.
• Seguimento de instruções longas, com menos restrições perdidas em trabalhos de múltiplas etapas.
• Melhor calibração em ações irreversíveis.
• Estilo de código mais limpo. Menos voltas desnecessárias, menos verbosidade.

Tudo isso parece ótimo, mas o scorecard publicado pela Meta roda o Muse Spark 1.3 em max reasoning contra o Muse Spark 1.2 em xhigh, e o max ainda estava com gate no lançamento. 

Artificial Analysis pontuou a variante xhigh (a disponível) com Intelligence Index 61 e o max com 62. Ou seja, diferença de apenas um ponto.

Matt Crabtree já cobriu as tabelas completas de benchmark, o breakdown de preços e como isso se compara com GPT-5.6 Sol e Claude Opus 5 na sua análise do lançamento do Muse Spark 1.3. Não vou repetir. O que vem a seguir é o que acontece quando você instala a coisa e coloca para rodar.

Como acessar o Muse Spark 1.3

Existem três caminhos, e o certo depende do que você está construindo. Escolha pela tabela e pule para a seção correspondente.

Muse Code, o agente de terminal

O Muse Code é o agente de código em terminal da Meta, em beta para macOS e Linux. É o harness que roda o Muse Spark, e os dois versionam de forma independente, então muse --version não diz qual modelo você está usando. Separe isso mentalmente.

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

Isso baixa um binário de 230 MB e o coloca em ~/.local/bin/muse, que nem sempre está no PATH de todo mundo.

Depois, confira o que veio:

muse --version

Em 4 de setembro de 2026, isso retornou Muse Code 1.0.2 (1.0.2-R2040.1).

Um pouco estranho para um beta, já que ferramentas de terceiros documentavam o Muse Code como 0.2.1 semanas antes. Fixe a versão que você recebeu à data em que a recebeu.

Captura de tela do autor. Instalando o Muse Code com o script de uma linha e confirmando a versão 1.0.2 no macOS.

Agora rode muse. Na primeira vez, ele imprimiu Not logged in. Run muse again to log in e saiu. Então você roda duas vezes — o tipo de detalhe que faz parecer que a instalação quebrou.

Na segunda execução, começa um fluxo OAuth por dispositivo. Ele imprime uma URL de login com um código curto, mostra o mesmo código separadamente e pede para confirmar que batem antes de aprovar no navegador.

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

Waiting for approval…

E então você deve ver a seguinte tela: 

Captura de tela do autor. O fluxo de login da Meta Model API, confirmando os dados da conta antes de emitir credenciais.

No navegador, você confirma seu nome, aceita os termos e cadastra um cartão. Leia o painel de preços nessa tela de pagamento antes de clicar em Avançar — os motivos ficam claros em uns trinta segundos.

O tier padrão treina com o seu código

De volta ao terminal, o cabeçalho da sessão diz o que está rodando:

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.

Leia o nome do modelo de novo. A variante contributor, definida como padrão, em uma instalação nova, sem ninguém perguntar.

A Meta não esconde isso. O aviso fica logo abaixo do nome do modelo, a tela de pagamento marca contributor como DEFAULT, e a barra de status mantém muse-spark-1.3-contributor visível enquanto você trabalha.

Mas a responsabilidade está invertida em relação ao que a maioria dos desenvolvedores espera.

Se você abrir o Muse Code dentro de um repositório de cliente e começar a trabalhar, já enviou esse código para um endpoint elegível a treinamento. Confira a barra de status antes do seu primeiro prompt, não depois.

Captura de tela do autor. Uma primeira sessão do Muse Code, com o modelo padrão muse-spark-1.3-contributor e o aviso de melhoria de produto abaixo.

A barra de status também mostra o esforço de raciocínio, que para mim estava em high. Não xhigh, a variante que a Artificial Analysis benchmarkou. Vale lembrar disso ao comparar seus resultados com números publicados.

Escolhendo e trocando de tier

Rode /model e você verá um seletor interativo com quatro opções e suas tarifas. Esses valores batem com a tela de pagamento da própria Meta:

O Contributor é cerca de 12 vezes mais barato na entrada e 21 vezes mais barato na saída.

O que compra esse desconto é a sua propriedade intelectual (PI). A redação da Meta é "seu conteúdo, incluindo mensagens entre sessões, pode ser usado para melhoria de produto", o que cobre mais do que só o código que você envia.

As duas variantes do Muse Spark 1.2 ainda aparecem no seletor com preços idênticos, o que importa para a comparação adiante: como as tarifas não mudam entre gerações, comparar tokens é comparar custo sem precisar normalizar nada.

Captura de tela do autor. O seletor /model mostrando as quatro variantes do Muse Spark com tarifas de cache, entrada e saída.

Para optar por não treinar, suba até muse-spark-1.3 e pressione Enter. A linha "Discounted tokens" some do cabeçalho.

Para trabalho de cliente, há uma opção mais forte que nunca aparece no terminal. A Meta diz que passou a aceitar solicitações de zero data retention, tratadas via time de vendas e não por um toggle.

Retenção e treinamento são questões separadas, e contratos de agência geralmente pedem resposta para ambas.

O rate limiting funciona de forma diferente entre os tiers, embora as fontes discordem do como. O blog de desenvolvedores da Meta descreve o tier contributor como limitado por tokens em uma janela móvel de 5 horas, e não por contagem de requisições. Já matérias na imprensa no lançamento do 1.2 relataram limite de 60 requisições por minuto, que é um mecanismo totalmente diferente. Eu não atingi nenhum dos limites em cerca de 90 conclusões de modelo em uma tarde.

A Meta Model API e o OpenRouter

A Meta Model API é compatível com o SDK da OpenAI, então migrar significa trocar o ID do modelo e manter seu client. Os IDs são muse-spark-1.3 e muse-spark-1.3-contributor.

O OpenRouter oferece sob o slug meta/muse-spark-1.3. Isso tem um custo: o OpenRouter mediu throughput em torno de 81 tokens por segundo contra 182 registrados pela Artificial Analysis indo direto, com disponibilidade perto de 92% nos três primeiros dias. A Meta é a única provedora, então não há fallback para outro fornecedor.

Sua primeira sessão com o Muse Spark 1.3

Tudo abaixo roda contra python-humanize/humanize, fixado no commit 823ad6096. São 1.676 linhas de fonte em 6 módulos, a suíte de testes roda em menos de um segundo e o domínio dispensa explicação. Nada aqui modifica o repo.

São perguntas somente de leitura para ver como o agente explora um codebase antes de eu entregar algo que escreva.

Dois prompts para sentir como ele lê código, vamos ao primeiro: 

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

Ele rodou dois comandos, listou a estrutura do projeto e depois escreveu um parser de AST em vez de grepar por import. Resposta: i18n com 4 imports de entrada, detalhando como i18n 4, number 2, e filesize, lists, time e _version 1 cada.

Conferi com meu próprio script e obtive números diferentes, que pareceram um erro do modelo. Meu script é que estava errado. Ele contava só imports relativos (from ._version import ...) e ignorava a forma absoluta (from humanize.i18n import ...), que é como a maior parte do pacote importa. O modelo tratou as duas formas.

O segundo prompt vale a execução porque dá para corrigir:

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

Ele respondeu 20 no total: filesize 1, i18n 5, lists 1, number 8, time 5. Tudo correto. Depois acrescentou, sem eu pedir, que i18n.get_translation é pública pelo nome mas está ausente do i18n.__all__, que exporta só as outras quatro. Também certo.

Essa sessão custou US$ 0,01 em 8 turnos.

O nível de raciocínio que a Meta não comenta

muse --help documenta isto:

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

O seletor /effort dentro da sessão oferece seis desses sete, omitindo none.

Captura de tela do autor. O seletor /effort listando seis níveis de raciocínio selecionáveis, com high marcado como atual.

Ambos listam um nível chamado ultra, que não aparece em nenhum anúncio da Meta. A posição pública da Meta é que o max reasoning virá "em breve, após concluirmos testes adicionais de segurança".

Então pedi por ele:

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

Existe um feature gate nomeado, ultra_reasoning_effort, e ele está fechado. A capacidade está construída, e o interruptor está desligado no servidor. Isso é mais específico do que "pendente de testes de segurança" — e veio numa mensagem de aviso que também contém "tbh".

Dois pontos práticos. O cliente anuncia um nível que o backend não atende, tanto na CLI quanto no seletor. E ele faz downgrade silencioso para xhigh com uma única linha em stderr, que num script ou log de CI passa batido. Você acreditaria estar rodando uma configuração que não foi usada.

Depois tentei um valor que não aparece em lugar nenhum da documentação:

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

Sem nenhum aviso. Rodou e retornou ok. Ou seja, um valor não documentado passa na validação sem comentário enquanto um valor documentado é bloqueado, e você não consegue saber pela saída qual esforço realmente atendeu ao seu pedido.

Captura de tela do autor. Pedir ultra retorna um feature gate fechado e um downgrade silencioso para xhigh, enquanto o max não documentado passa sem comentário.

Se você se importa com o nível de raciocínio, defina explicitamente e leia o stderr. Não assuma que a flag enviada é a flag usada.

A promessa de eficiência do Muse Spark 1.3 se sustenta?

Eis o teste. Pegue um repositório open source, reverta um commit real de correção de bug para a suíte de testes realmente falhar, e rode três tarefas de coding em ambos os modelos com os mesmos prompts e as mesmas flags.

São tarefas separadas da sessão exploratória acima. Todas elas escrevem código.

Reverter a parte de fonte do commit 823ad6096 mantendo os testes deixa 6 testes falhando, e esse é o estado inicial:

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

Cada execução usou o mesmo formato de comando, trocando apenas o ID do modelo e o prompt:

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

Tarefa 1, bug fix.

O sucesso aqui é binário: os 6 testes passam, ou não.

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/.

Tarefa 2, pequena feature.

Aberta o suficiente para que os dois modelos discordem de escopo — e isso fez diferença.

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.

Tarefa 3, refatoração.

A mais pesada das três, tocando vários arquivos.

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.

As três tarefas rodaram em sequência sem reset entre elas, então as tarefas 2 e 3 se basearam no que o modelo produziu antes. Ambos os modelos caminharam pelo mesmo trajeto.

As contagens de tokens vêm dos logs de sessão em ~/.local/share/muse/sessions/, contadas uma vez por conclusão de modelo. Todas as seis execuções passaram nos testes.

E os deltas, onde negativo significa que o 1.3 usou menos:

Lendo o resultado com honestidade

Duas de três tarefas saíram mais baratas, com 23% e 32% menos conclusões de modelo. Isso bate com a promessa da Meta sobre chamadas de ferramenta. Já a refatoração foi no sentido oposto: 70% mais conclusões e 38% mais custo.

No conjunto, o 1.3 custou 12% a mais do que o 1.2. Então a promessa de eficiência é real, mas depende da tarefa — e um número único de manchete esconde totalmente isso.

A entrada não em cache caiu em todas as tarefas em 19%, 22% e 5%. Nunca 25%.

A Meta não diz quais tokens contou, e a resposta muda muito dependendo se você quer dizer entrada, saída, não em cache ou total.

Taxas de acerto de cache ficaram entre 88% e 97% e subiram com o tamanho da tarefa. Reportar tokens brutos de entrada sem separar cache de não cache seria quase sem sentido, já que os 4,18M de entrada da refatoração são, na prática, 109k de novo contexto mais 4,07M de releituras cobradas a um quinquagésimo do valor.

Por que a refatoração não é prejuízo puro

Veja o que o 1.3 fez de fato nessa tarefa antes de chamá-lo de ineficiente.

Ele verificou programaticamente que cada bloco movido estava byte a byte idêntico ao original.

Rodou --doctest-modules nos dois arquivos novos. Testou resolução de imports a partir de um diretório temporário em /tmp. Depois sinalizou duas coisas que ninguém pediu: que humanize.scientific (a função) sombreia o novo submódulo, e que um doctest de naturaldelta falha idêntico na árvore original, então a falha não é atribuível à mudança.

O Muse Spark 1.2 duplicou uma função helper para driblar um import circular e seguiu em frente. O 1.3 importou e explicou por que não havia ciclo.

Você não consegue separar "gastou mais tokens" de "fez um trabalho mais minucioso" com esse desenho. A afirmação honesta é que o 1.3 gastou mais e entregou mais — e se isso é vitória depende de você querer o rigor extra.

A tarefa de feature mostra o padrão oposto e ilustra melhor a promessa da Meta de "menos verboso". O Muse Spark 1.2 inventou aliases de parâmetros max_items, n e max_len que ninguém pediu e escreveu 28 testes.

O Muse Spark 1.3 escreveu uma assinatura com um default sensato e 20 testes, com 54% menos tokens de saída.

O que eu não consegui controlar

Quatro coisas — e seria desonesto não mencioná-las.

1. O Muse Code se atualizou de 1.0.2 para 1.0.3 no meio, então o harness não foi idêntico nas seis execuções.
2. As tarefas 2 e 3 começaram da saída prévia de cada modelo, e não de uma árvore byte a byte idêntica, porque a sequência roda sem resets.
3. Cada célula é um único ensaio, então a variância run-to-run normal não foi medida.
4. E rodei tudo no tier contributor, que é o mesmo modelo, mas com termos de dados diferentes.

Nada disso invalida a direção dos resultados. Mas significa que uma diferença agregada de 12% é um sinal mais fraco do que três execuções por célula trariam.

Boas práticas e troubleshooting do Muse Spark 1.3

Algumas coisas que eu gostaria de ter sabido no primeiro dia.

Como solicitar os comportamentos de colaboração

O Muse Spark 1.3 faz perguntas de esclarecimento em prompts ambíguos, então um prompt superespecificado desliga um recurso pelo qual você está pagando. Contraintuitivo para quem passou dois anos aprendendo a colocar tudo na frente.

O escopo ainda importa. "Separe o number.py" deixa o modelo chutando a fronteira, as atualizações de import e o que conta como feito. A versão que usei de fato deixa os três claros:

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.

Mais uma coisa útil. Meu prompt de refatoração dizia number.py is 571 lines. São 567. Ambos os modelos me corrigiram sem eu pedir, e o 1.3 fez isso na primeira frase. Meu número veio de medir a ponta do repo em vez do commit fixado.

Como manter os custos baixos

Coloque a parte estável do seu prompt na frente para que fique cacheável. Com taxas de acerto de 88% a 97%, o seu padrão de cache pesa muito mais na conta do que a escolha do modelo.

As três tarefas custaram US$ 0,034 no tier contributor. O mesmo trabalho no standard sairia por US$ 0,91 — uma diferença de 27x. Essa é a decisão de tier em dinheiro: três centavos contra noventa.

Se você for pelo OpenRouter, a busca web é cobrada separadamente a US$ 2,50 por 1.000 chamadas.

Quando o Muse Spark 1.3 não é a melhor escolha

• Sem traços de raciocínio expostos. Você vê o que ele decidiu, não o porquê — o que dificulta depurar uma refatoração ruim.
• O max reasoning está com gate, então a configuração por trás de números de benchmark de manchete está fora de alcance.
• Pesos fechados. Sem self-hosting, sem fine-tuning. O roadmap da Meta menciona um "Muse Spark open weights release" sem versão, data ou licença.
• Um único provedor. Quando o endpoint da Meta degrada, não há para onde rotear.

Problemas comuns e correções

• muse: command not found após uma instalação limpa. O script instala em ~/.local/bin/muse, que nem todo shell inclui no PATH.
• Not logged in. Run muse again to log in. É isso mesmo: a primeira execução sai, a segunda inicia o login.
• Você está no tier contributor e não escolheu isso. É o padrão. Confira a barra de status e rode /model antes de abrir algo proprietário.
• ultra vira silenciosamente xhigh. O gate está fechado. Leia o stderr em vez de confiar na flag.
• O Muse Code se atualiza no meio da sessão. O meu foi de 1.0.2 para 1.0.3 entre execuções. Se for medir algo, fixe e registre a versão.

Uma coisa que não reproduziu

Circularam relatos de que usuários da UE ainda recebiam o Muse Spark 1.1 depois do 1.3 lançado. Rodei tudo isso a partir da Holanda e recebi 1.3 o tempo todo. Esses relatos diziam respeito ao Meta.ai, o assistente para consumidores, e não parecem se aplicar ao Muse Code ou à Model API. Rollouts diferentes.

Considerações finais

A promessa de eficiência da Meta se confirmou em duas das minhas três tarefas e se inverteu na terceira, para um aumento líquido de 12% no custo do conjunto. O lado das chamadas de ferramenta parece sólido com reduções de 23% e 32% onde o 1.3 venceu. O lado dos tokens depende totalmente de quais tokens você conta.

Se você já está na Meta Model API ou no Muse Code, trocar o ID do modelo leva um minuto e provavelmente você sai ganhando no trabalho do dia a dia. Se está escolhendo do zero para agentes em produção, o max com gate e a ausência de traços de raciocínio são motivos concretos para esperar algumas semanas.

O ponto em que eu de fato agiria não é o número de eficiência. É que o Muse Code te coloca num tier elegível a treinamento por padrão e que um nível de raciocínio documentado faz downgrade silencioso quando você pede. Ambos são checagens de uma linha e fáceis de passar batido.

Rode a comparação no seu próprio workload. Minhas três tarefas não são as suas três tarefas, e a variação entre elas foi maior do que a diferença entre os modelos.

Para a visão completa de benchmark, a análise do lançamento do Muse Spark 1.3 do Matt tem as tabelas. Para desenvolver as competências para avaliar modelos como este por conta própria, comece pela nossa trilha de habilidades AI Agent Fundamentals.