Lançado o Muse Spark 1.1

• O Muse Spark 1.1, lançado pela Meta Superintelligence Labs, é um modelo de raciocínio multimodal voltado para tarefas de agentes, com melhorias em uso de ferramentas e do computador, programação e compreensão multimodal em relação à versão anterior
• Seu ponto central é assumir o planejamento e a orquestração em apps e serviços externos diversos, generalizando em zero-shot para native tools, MCP servers e custom skills
• Ele gerencia ativamente uma janela de contexto de 1 milhão de tokens para recuperar informações de trabalhos anteriores e comprimir o contexto essencial necessário para etapas posteriores
• Desenvolvedores podem acessar o modelo pela Meta Model API, lançada em preview público, e também usá-lo no app Meta AI e em meta.ai no modo “Thinking”
• A Meta realizou avaliações de segurança antes da implantação seguindo o Advanced AI Scaling Framework e concluiu que o modelo está dentro da margem de segurança nas categorias Chemical & Biological, Cybersecurity e Loss of Control

---

Posição do Muse Spark 1.1 e forma de disponibilização

• O Muse Spark 1.1 é o modelo mais recente da Meta Superintelligence Labs e é apresentado como um grande upgrade em relação ao Muse Spark anterior
• Trata-se de um modelo de raciocínio multimodal para tarefas de agentes, com ênfase em melhorias nas seguintes áreas
  • uso de ferramentas
  • uso do computador
  • programação
  • compreensão multimodal
• Este lançamento, junto com a apresentação do Muse Image, é ligado a mais um passo em direção à visão de “personal superintelligence” da Meta
• Desenvolvedores podem acessar o Muse Spark 1.1 pela Meta Model API, disponibilizada em preview público
• No app Meta AI e em meta.ai, ele é oferecido no modo “Thinking”

Tarefas de agentes e processamento de contexto longo

• Ele planeja e orquestra o fluxo de execução em tarefas de agentes pessoais que atravessam vários apps e serviços externos
• Generaliza em zero-shot para native tools, MCP servers e custom skills
• Foi treinado para lidar com projetos complexos muito mais rápido do que o Muse Spark
  • o agente principal reúne contexto e faz o planejamento, depois delega a execução a subagentes em paralelo
  • os subagentes seguem as tarefas atribuídas, entendem as ferramentas disponíveis e escalam para o agente principal quando necessário
• Ele gerencia ativamente uma janela de contexto de 1 milhão de tokens
  • lembra das ações executadas
  • recupera informações de trabalhos muito anteriores
  • comprime o histórico para preservar as etapas essenciais para tarefas futuras

Automação do uso do computador

• O Muse Spark 1.1 se destaca em workflows de uso do computador que passam por vários aplicativos e em que as informações mudam em tempo real
• Mesmo em sessões longas, ele mantém o contexto, adapta-se a exigências variáveis e navega por interfaces pouco familiares com mínima intervenção humana
• Em tarefas de desktop, ele não opera sempre apenas clique a clique, escolhendo entre automação e manipulação direta conforme o caso
  • escreve scripts quando a automação é mais rápida
  • usa cliques quando a interação direta é mais simples
  • gera várias ações agrupadas em cada etapa
• No exemplo de preparação de uma festa à noite, ele reconhece quando surge um novo contexto durante o processo de pedido e realiza as atualizações necessárias sem intervenção do usuário

Desempenho em programação e workflow de desenvolvimento

• O desempenho do Muse Spark 1.1 melhora de forma significativa em tarefas reais de programação que envolvem codebases grandes e complexas
• Ele pode executar diagnóstico e correção de bugs complexos, implementação de novos recursos em sistemas de nível empresarial e migrações de código em larga escala
• Em casos de uso como criação de aplicações web e perguntas e respostas end-to-end, mostra um grande salto em relação ao primeiro modelo
• Foi treinado para se adaptar suavemente a diferentes harnesses e lidar com comportamentos multiturno complexos de forma estável
  • planning mode
  • goal conditioning
  • subagent delegation
  • suporte a recursos comuns de programação com agentes, como context compaction
• Na demonstração de depuração com OpenCode, ele cria um app web de chat, encontra falhas visíveis ao usuário por meio de screenshots automáticos, rastreia o código relacionado, corrige o problema e depois valida as mudanças
• Desenvolvedores e pesquisadores internos da Meta já usam o Muse Spark 1.1 diariamente, e no Meta Internal Coding Bench ele mostra grande melhora sobre o Muse Spark e resultados competitivos frente às principais alternativas
• Pesquisadores também estão usando o Muse Spark 1.1 em seus workflows para automatizar tarefas de desenvolvimento e avaliação de modelos
• No exemplo de avaliação DeepSWE, ele autoavalia dentro do OpenCode parte das tarefas do DeepSWE em vários níveis de intensidade de raciocínio e gera um dashboard analítico com base nos resultados

Compreensão multimodal e execução

• O Muse Spark 1.1 também se destaca em tarefas que combinam percepção, raciocínio multimodal e uso de ferramentas
• Ele pode interagir com ambientes reais enquanto produz resultados fundamentados
  • geração de código a partir de material visual
  • geração de legendas extremamente detalhadas para imagens e vídeos
  • execução de workflows com agentes para casos de uso multimodais
• As capacidades multimodais são especialmente úteis em situações que exigem percepção e ação ao mesmo tempo
  • inspeciona visão e áudio
  • preserva detalhes ao longo de workflows longos
  • usa esses detalhes ao operar o computador em nome do usuário
• No exemplo do agente para Facebook Marketplace, ele extrai fotos úteis de um vídeo gravado com smartphone, infere o item anunciado e manipula o navegador do usuário para criar o anúncio no Marketplace

Avaliação de segurança

• Antes da implantação, a Meta realizou uma ampla avaliação de segurança seguindo o Advanced AI Scaling Framework
• Esse framework define avaliações, modelos de ameaça e critérios de implantação para os modelos mais avançados da Meta
• As categorias avaliadas incluem os seguintes frontier risks
  • Chemical & Biological
  • Cybersecurity
  • Loss of Control
• Na avaliação da Meta, o Muse Spark 1.1 opera dentro da margem de segurança em todas as categorias de frontier risk
• O modelo mostra forte resistência a jailbreaks diretos, ataques indiretos vindos de dados não confiáveis, prompt injection e ataques ao developer prompt
• Como resultado, há melhora na robustez adversarial e redução nas taxas de hallucination e sycophancy
• Os detalhes completos sobre segurança estão documentados no Muse Spark 1.1 Evaluation Report

Reação dos primeiros parceiros e próximos planos

• Com o preview público da Meta Model API, desenvolvedores podem começar a criar pela primeira vez com base no Muse Spark 1.1
• Os primeiros parceiros o avaliam como um modelo base capaz de lidar com workloads de agentes em larga escala ao combinar contexto longo, programação e capacidades de raciocínio
• O CEO da Replit, Amjad Masad, destacou o fato de um único modelo reunir contexto de 1 milhão de tokens, suporte multimodal a imagem, vídeo e PDF, busca nativa com citações, saída estruturada, chamadas paralelas de ferramentas e pacote compatível com OpenAI
• O CEO da Cline, Saoud Rizwan, disse que quis oferecer acesso antecipado aos desenvolvedores da Cline por causa da forte capacidade de uso de ferramentas e da faixa de preço adequada para rodar workloads reais de programação em escala
• Yashodha Bhavnani, da Box, avaliou que o Muse Spark mostrou capacidades empresariais competitivas com os principais frontier models atuais no conjunto de avaliação de tarefas corporativas da Box
• Dave Morin, da OpenClaw Foundation, avaliou o Muse Spark 1.1 como um modelo rápido e poderoso para execução de agentes
• A Meta afirma estar treinando modelos com desempenho ainda maior e pretende compartilhá-los no futuro

[GN⁺]

Opiniões no Hacker News

• O relatório linkado tem muito mais detalhes: https://ai.meta.com/static-resource/muse-spark-1-1-evaluatio...
  Ao olhar os detalhes do Terminal-Bench-2.1, está escrito que “avaliamos 89 tarefas do Terminal-Bench 2.1 do repositório oficial com um harness de agente exclusivo para ferramentas bash, e os recursos foram limitados a CPU de 6 núcleos e 8 GB de RAM”, mas nesse caso o resultado é desclassificado
  Cada tarefa do terminal bench tem seu próprio limite de CPU e de RAM, e exceder qualquer um dos dois leva à desclassificação. No tbench-2.1, entre as 89 tarefas, há 0 que permitem CPU de 6 núcleos, e apenas 8 permitem 8 GB de RAM
  Esse tipo de benchmarking suspeito tira completamente a graça de criar harnesses para melhorar o desempenho do modelo em benchmarks. Porque, faça o que fizer, você nunca vence os números imprecisos da manchete. Provavelmente por isso esse modelo não está no leaderboard oficial https://www.tbench.ai/leaderboard/terminal-bench/2.1
  Como ex-funcionário da Meta, isso me deixa um pouco amargo, mas não muito surpreso. Até o fim do PSC e antes de passar para a próxima coisa, aumentar os números era o principal indicador de avaliação de desempenho

  • Exceto quando o modelo acidentalmente dispara uma fork bomb, não entendo por que seria preciso considerar limites de recursos. Eu achava que esse benchmark media o uso de terminal, especialmente a capacidade de encadear muitas chamadas de ferramentas bash; em que tipo de caso de teste isso passa a importar?
  • Esse é exatamente o problema dos modelos fechados. Não dá para saber ao certo se aquilo pelo qual estamos pagando é um modelo-base superior ou um harness bem projetado para maximizar pontuações de benchmark
  • Curiosidade sincera: com que frequência os limites de recursos viram gargalo? O que o harness ajuda aqui? Algo como limitar o paralelismo ou usar ferramentas mais eficientes?
  • Entendo o ponto, mas não tenho certeza de que seja tão importante assim
    O harbor / tb2.1 limitou o swap disponível para execuções em Docker? Antigamente havia um bug em que a execução da instância Docker podia usar mais memória do que o especificado. Algumas tarefas originais eram, na prática, impossíveis de concluir sem usar swap, e se o Docker fosse impedido de acessar swap, nem a solução oráculo passaria
    Se bem me lembro, crack-7z-hash e filter-js-from-html tinham esse problema, mas faz alguns meses que não vejo isso, então não tenho certeza
  • Não me parece um problema tão grande. Ao avaliar qualquer produto, eu também não aceito automaticamente a palavra de quem o fez. É óbvio que haverá viés. É para isso que existem testes independentes como https://artificialanalysis.ai

• Tive a chance de usá-lo antecipadamente por alguns dias e, nesse período, consegui criar um plugin para LLMs. Dá para testar o modelo no terminal assim
  uv tool install llm
llm install llm-meta-ai
llm keys set meta-ai
# paste API key here
llm -m meta-ai/muse-spark-1.1 "Generate an SVG of a pelican riding a bicycle"
  O resultado está aqui: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...
  Para comparação, o pelicano gerado pelo Muse Spark 1 está aqui: https://simonwillison.net/2026/Apr/8/muse-spark/

  • Fico curioso sobre como você encontra tempo para pré-visualizar tantos modelos. Os lançamentos recentes de modelos têm sido realmente insanos; às vezes não parece trabalho?

• Talvez o Zuck devesse se concentrar menos em competir de frente e mais em exercer o papel de spoiler no mercado de modelos
  Ele não precisa alcançar a receita de modelos da Anthropic ou da OpenAI; basta conseguir derrubar essa receita em 99%. É só continuar gastando bilhões de dólares em desenvolvimento de modelos de fronteira e liberá-los com pesos abertos, transformando modelos de código em commodity. E também precisa haver um bom harness de referência open source
  Quase ninguém está numa posição em que isso seja possível e faça sentido do ponto de vista do negócio. De qualquer forma, é bem provável que o rumo vá nessa direção, e ele pode acelerar muito isso. Assim como aconteceu com compiladores, seria bom ver os modelos passarem de produtos proprietários para commodities
  Pode ser uma das melhores coisas que o Zuck poderia fazer pelo mundo

  • Se eles perderem receita, quem é que vai acabar alugando os recursos computacionais da Meta?
  • Para virar o verdadeiro rei dos spoilers, bastaria abrir em open source os datasets de treinamento. Duvido que vá tão longe
  • Modelos de código não são o destino final. Eles são apenas parte do processo de bootstrap rumo à inteligência geral
  • Eles já não tentaram fazer isso com o llama?
  • Tudo o que ele precisa fazer é provar que já não é tão difícil assim criar modelos desse tipo. O fosso dessas empresas está na percepção de que construir modelos de fronteira é realmente muito difícil

• O preço é absurdamente bom. US$ 1,25 por 1 milhão de tokens de entrada, US$ 4,5 de saída, e a entrada em cache custa US$ 0,15
  https://dev.meta.ai/docs/getting-started/pricing-rate-limits

  • Isso dá para comparar de forma mais direta com o xAI Grok 4.5. Os dois seguem mais ou menos a direção de “inteligência de nível Opus por preço de Haiku”, e isso é algo enorme para desenvolvedores de aplicações que querem colocar um modelo desses dentro de apps
    Eu estava testando trocar Haiku e Sonnet pelo Grok 4.5, e pretendo testar este também. Principalmente porque o preço de cache é bem mais barato
  • A proporção de preço da entrada em cache é boa
    O Grok 4.5 saiu por US$ 2/US$ 6, mas discretamente cobra US$ 0,50 por 1 milhão de tokens de entrada em cache. Isso é caro no nível do Opus 4.8
  • A Meta não está no radar da maioria das pessoas que escolhem modelos hoje. Se ela tiver um modelo realmente bom, faz sentido subsidiar para conquistar usuários antes de igualar o preço da concorrência
  • Mais barato que o Qwen 3.7 Max. Depois dos US$ 2 de entrada / US$ 6 de saída do Grok 4.5, este é o segundo sinal de que os grandes laboratórios estão sentindo a pressão do GLM 5.2
  • Ainda assim continua ridiculamente caro. Se você pensar em pagar US$ 10 por 100 resultados de busca do Google, é basicamente isso
    Eu realmente não entendo por que alguém gostaria de gastar mais de US$ 1,50 por 1 milhão de tokens de saída, quanto mais US$ 15~50. Será que existe consumidor realmente pagando por uso assim?

• Até ontem parecia haver um clima forte de que OpenAI e Anthropic estavam irreversivelmente à frente, mas agora xAI e Meta pelo menos lançaram coisas competitivas para modelos práticos e mais baratas
  Claro, olhando para Fable e provavelmente o GPT-6 que deve sair em breve, a ideia de que os dois laboratórios líderes ainda estão na frente continua valendo, mas não é um jogo totalmente encerrado como a turma que pauta a opinião vinha dizendo

  • Os modelos agora, no geral, já ficaram bons o suficiente. Sem um grande avanço, daqui para frente o que importa é só o custo
  • As pessoas interpretaram o atraso do Google como se Anthropic e OpenAI estivessem muito à frente. Na prática, é mais parecido com o Google ficando para trás como aconteceu com Tensorflow, Angular e GCP
  • A nuance é um pouco diferente
    A expectativa em torno do GLM 5.2 já era alta antes disso. Não é que xAI ou Meta tenham criado uma grande diferença de outra forma; elas estão mais próximas de resultados e preços parecidos com os do GLM 5.2

• Pessoalmente eu não gosto da Meta, mas reconheço isso. Quanto mais concorrência, melhor para o consumidor comum e também para as empresas
  Ver modelos chineses, Grok, Meta, Google, OpenAI e Anthropic todos competindo é uma vitória. Estou construindo feito louco para aproveitar ao máximo enquanto ainda dá para usar esses tokens subsidiados

  • Os modelos locais da llama da Meta já foram a cara da IA open source. O cenário realmente mudou muito
  • Com certeza vejo isso como algo bom. Só que, por causa desse avanço, ainda fico em dúvida se a era da IA vai aumentar ou reduzir a quantidade de engenheiros de software necessários
    Por um lado, ficou mais fácil criar produtos, então mais gente vai criar, e vai haver mais produtos e mais funcionalidades. Muita gente sem perfil técnico também vai tentar criar, mas vai travar, e no fim engenheiros serão necessários. O volume total de produtos produzidos por empresas de tecnologia experientes, fundadores sem perfil técnico e aspirantes a fundadores será enorme. O cenário de alta em que mais engenheiros de software serão necessários no futuro próximo está aqui
    Por outro lado, em cerca de um ano as pessoas terão criado um monte desses produtos, mas a maioria não vai conseguir fazer marketing, vender ou ganhar dinheiro com eles. No fim, talvez nem sejam necessários tantos engenheiros de software assim. Ainda assim, no geral, acho que o cenário de alta tem mais chance de vencer em efeito líquido
  • Abrindo mais os modelos chineses, há DeepSeek, GLM (Z.ai), Minimax, Kimi (Moonshot), Hy3 (Tencent) e Qwen (Alibaba)
    Cada um deles pode ter os pesos baixados para execução local
  • Ele postou essa notícia no X, não no próprio Meta Threads. Isso mostra até que ponto existe interesse em impulsionar isso. Claro, enquanto essas empresas continuarem queimando caixa, para nós os custos podem continuar em um nível suportável
  • Esta é a maior competição tecnológica que já vi. As empresas mais ricas, as pessoas mais inteligentes e os países mais ricos entraram nisso
    Não sei se competição é algo bom; veremos em alguns anos. Estou ansioso pelo dia em que voltarei a ter um trabalho braçal

• Como todas as empresas conseguem fazer parecer que são número 1 em todos os benchmarks?

  • Primeiro, elas pegam um conjunto de benchmarks escolhido a dedo e veem em quais modelos os outros vão pior
    Depois comparam com a versão anterior do modelo da concorrência. Se ainda não parecer bom, comparam com o próprio modelo anterior
  • Porque o fosso competitivo não é tão grande, as melhorias são graduais e dá para escolher quais modelos entram na comparação
    Sendo justo, se o principal ponto forte for preço, parece mais certo comparar com modelos de desempenho semelhante
  • Agora comparar com Gemini já parece uma casa grátis do bingo
  • Para quem conhece IA a fundo, qual seria o benchmark padrão para coding?
  • Basta esperar o momento exato em que o seu modelo passa na frente em pelo menos N benchmarks e anunciar

• Eu não tinha percebido que a Meta estava desenvolvendo e lançando um modelo de pesos fechados. Que pena. Eu gostaria de ver mais progresso em modelos americanos de pesos abertos

• Fiz ele funcionar junto com o codex dentro de um contêiner. Aliás, parece haver um bug que muita gente vai encontrar na interface Codex:Muse
  Pelo que entendi, o codex não esperava chamadas de ferramentas do lado do servidor, e por causa da forma como a Meta lida com esses IDs acontece algum tipo de erro de parsing ou de integração. Nas primeiras vezes em que rodei o codex com o muse, ele falhou na primeira chamada que não era de busca na web
  Corrigi isso, e pessoalmente ainda não estou totalmente convencido sobre chamadas de ferramentas do lado do servidor customizadas e armazenamento indefinido de arquivos, mas até aqui parece um modelo bem legal e estou gostando de usar
  https://github.com/accretional/awesome-muse-spark/blob/main/...

• Pelos benchmarks divulgados, codificação e multimodal também parecem bem bons, mas a taxa de sucesso em chamadas de ferramentas parece ser muito boa
  Qual seria o caso de uso que melhor combina com esse perfil de desempenho?

  • Debugging e diagnóstico envolvem muitas chamadas de ferramentas. Isso inclui fazer grep nos logs ou transformá-los, chamar profiler ou tracer, e até escrever relatórios de incidentes
    Diagnóstico de bugs é uma área em que é preciso programar até certo ponto, mas em que o uso de ferramentas precisa ser ainda melhor. Se houver um bom relatório de diagnóstico, a correção pode ser passada para o Opus
    O Opus também escreve relatórios até certo ponto, mas em documentos typst ele ainda erra com frequência a largura das tabelas, então a última coluna acaba cheia de texto enquanto a largura fica com espaço para só alguns caracteres
  • O Gemini 3.5 Flash é melhor em chamadas de ferramentas do que o Fable. Chamadas de ferramentas provavelmente são uma das áreas que podem ser melhoradas com relativa facilidade por meio de pós-treinamento
  • Fico curioso para saber se veremos esse padrão a cada novo release no futuro. O uso de ferramentas tem grande chance de mudar rapidamente, então o modelo mais recente pode sempre ter vantagem sobre o modelo mais inteligente
  • Isso soa meio inútil. É interessante ter um desempenho excelente em decodificadores restritos como JSON, mas em um decoder geral, quase sempre dá para fazer a ferramenta funcionar na segunda tentativa em um loop de passar pelo validador de ferramentas, receber boas mensagens de erro e tentar de novo. Como a entrada fica em cache, o custo também não é alto