
O que entendo por análise, e o que não consegui testar
O Muse Spark 1.1 foi lançado em 9 de julho de 2026, então já passou cerca de quatro semanas em uso real, não quatro dias. Isso importa. Agora existem dados independentes, não apenas as impressões do dia do lançamento. O panorama mais amplo da empresa está no meu resumo sobre a Meta AI.
Há menos relatos em primeira mão do que um lançamento de ponta costuma gerar, e o motivo é estrutural. A Meta Model API abriu exclusivamente para os Estados Unidos. Desenvolvedores relataram ter sido bloqueados no primeiro dia a partir do Vietnã, do Canadá e da Argentina, e ela só chegou ao OpenRouter cerca de uma semana depois. Um comentarista resumiu o efeito prático sem rodeios:
"O fato de não estar disponível no Openrouter torna muito difícil testar. Eu ia comparar com o Grok 4.5 e o GPT-5.6 Luna, mas não quero me cadastrar na Meta só para isso a menos que valha a pena."
Ou seja, uma thread de lançamento com 413 pontos produziu apenas um punhado de relatos reais de uso. Tudo o que vem a seguir se apoia em três tipos de fontes: as execuções independentes do Artificial Analysis, o próprio relatório de avaliação da Meta, com 105 páginas, e o pequeno número de engenheiros que de fato conseguiram fazer funcionar. Onde ninguém testou algo, eu digo isso em vez de preencher a lacuna.
O único gráfico que explica todos os outros resultados
Aqui está o ranking do Muse Spark 1.1 nos benchmarks que compõem o Intelligence Index. Mesmo modelo, mesma semana, um único laboratório rodando todos os testes.

A maioria dos modelos é entediante de uma forma útil. Ficam mais ou menos no mesmo percentil onde quer que você teste, então um único número prevê o resto. Este não. A distância entre seu melhor e seu pior ranking é maior do que toda a diferença entre o topo e a base da maioria das faixas de preço.
É por isso que o número de manchete que todos repetem, 50,6 contra 60,7 do Opus 5, quase não diz nada em que você possa agir. Ele faz a média de um resultado excelente com um ruim. O que você precisa saber é qual dos dois está comprando.
Onde ele realmente vence
Três coisas aqui são reais, e eu preferiria que a crítica mais adiante não as enterrasse.
Ele escreve código bem. Não "bem para o preço". Bem, e ponto. No SciCode, supera o Claude Opus 5, o GPT-5.6 Sol e o Grok 4.5. A frase "a Meta está atrás em programação", que circulou após o lançamento, se refere a execuções longas de agente, não à geração de código, e são dois trabalhos diferentes.
| Modelo | SciCode |
|---|---|
| Kimi K3 (max) | 58,7% |
| Muse Spark 1.1 (xhigh) | 58,2% |
| GPT-5.6 Sol (high) | 56,9% |
| Claude Opus 5 (max) | 55,7% |
| Grok 4.5 (high) | 54,1% |
| Gemini 3.6 Flash | 52,7% |
| DeepSeek V4 Flash | 49,9% |
É a coisa mais rápida do painel. 217,4 tokens de saída por segundo contra 55,7 do Claude Opus 5, e um pouco à frente do Gemini 3.6 Flash, com 213,5. Para qualquer aplicação voltada ao usuário, as pessoas sentem uma diferença de 4x no throughput antes mesmo de alguém medir.
A tarifa de cache é a parte mais bem projetada do produto. A 0,15 $ por milhão, isso representa um desconto de 88%, aplicado automaticamente, sem nenhuma chave de cache para você gerenciar. Um engenheiro apontou por que essa proporção importa mais do que o preço de tabela:
"O preço do input em cache tem uma boa proporção. Compare com o Grok 4.5, que saiu a 2 $/6 $ mas depois cobra silenciosamente 0,50 $ por 1M de tokens de input em cache. Isso é tão alto quanto o Opus 4.8!"
Juntando tudo isso, o bom caso de uso ganha uma forma óbvia: prompts curtos, um prompt de sistema estável, volume enorme, uma decisão por chamada. Classificação em lote, etiquetagem, extração, roteamento. A tabela de preços completa está no meu detalhamento sobre o preço do Muse Spark 1.1. Para o restante do mercado, comece pelo preço do Claude. A linha da OpenAI está reunida em uma única tabela em todos os modelos da OpenAI.
Onde ele desmorona
A Meta posicionou isso como um modelo agêntico. Seu anúncio destaca o uso de ferramentas e fluxos de trabalho multi-etapa, a linha que separa agentes de chatbots. Então, o teste justo são as avaliações agênticas independentes. É aqui que a análise vira.
| Benchmark agêntico | Muse Spark 1.1 | Melhor do conjunto | Onde ele fica |
|---|---|---|---|
| AA-Briefcase Elo | 868,9 | Claude Opus 5 com 1718,7 | 18º de 19 |
| GDPval-AA v2 Elo | 1370,6 | Claude Opus 5 com 1852,0 | Último de 7 |
| Tau-3 Banking | 25,2% | Kimi K3 com 34,0% | 9º de 10 |
A contradição é difícil de ignorar. O modelo vendido pelo uso agêntico de ferramentas é o pior desempenho agêntico do painel independente. No GDPval, fica 481 Elo atrás do Opus 5, e os intervalos de confiança não se sobrepõem a nada acima dele. No uso agêntico de ferramentas, fica atrás até do DeepSeek V4 Flash, que custa 0,14 $ de entrada e 0,28 $ de saída.
A Meta não contesta isso totalmente. O próprio relatório de avaliação admite que "para tarefas agênticas de longo horizonte (por exemplo, DeepSWE e DeepSearchQA), melhorias significativas ainda ficam atrás ou empatadas com os modelos concorrentes de melhor desempenho". Essa admissão é medida contra o Opus 4.8 e o GPT-5.5, ambos uma geração atrás do que você compraria hoje.
A leitura da comunidade chegou a um lugar parecido. Um comentarista, ao ver o modelo aparecer perto do topo de um ranking de programação, tomou isso como prova de que o ranking estava quebrado:
"seu benchmark obviamente tem falhas quando os 3 melhores modelos em Typescript (Combined) são Grok 4.5, Muse Spark 1.1 (kkk), Gemini 3.5! Flash"
A formulação mais afiada veio de um confronto entre quatro modelos. Alguém ali ficou confuso porque o Muse Spark produziu o melhor artefato individual do conjunto e ainda assim tirou 2 de 5. O esclarecimento resume o modelo inteiro em uma frase:
"2/5 não é qualidade, é consistência, como está escrito ali. Os links completos estão no final. A maioria das tentativas do Spark são fracassos"
Teto alto. Piso baixo. Tudo o mais nesta análise decorre disso.
A sessão única mais longa já publicada chega ao mesmo ponto. Três horas com o modelo, de um desenvolvedor que o rodou por meio de uma CLI de programação:
"Acabei de testar por 3 horas seguidas, e tenho que dizer que fiquei decepcionado. Não sei o que deu na Meta ultimamente, mas é bom lembrar que eles foram os criadores do Llama, que acendeu o movimento open source de modelos. Mesmo em código fechado (pelo menos agora), eu diria que fica entre o Kimi 2.7 e o GLM 5.2, nem perto do Opus 4.8 medium/Sonnet5"
Vale a pena não levar isso tão a sério. É a tarde de uma única pessoa, e ele não reporta nenhum número medido. Quase ninguém reporta. Ao longo de quatro semanas de Reddit e Hacker News, há apenas cerca de uma dúzia de relatos reais em primeira mão de uso deste modelo, e nenhum deles publica um número que a própria pessoa tenha medido. Também ninguém testou publicamente a janela de 1M de tokens sob estresse. Em parte por causa do bloqueio regional, em parte porque um modelo para o qual você não consegue uma chave de API não é testado por hobbyistas.
Deve confiar este trabalho ao Muse Spark 1.1?
Escolha o trabalho que você realmente tem. A resposta muda mais do que o preço.
Este é o trabalho para o qual ele foi feito. Entrada curta, uma decisão, volume enorme, e a tarifa de cache automática cuida do resto.
Ele roda a 217,4 tokens de saída por segundo, o mais rápido do painel, e com um prompt de sistema estável é cobrado a 0,15 $ por milhão em vez de 1,25 $.
A fraqueza em programação que todos repetem é sobre execuções longas de agente, não sobre escrever código. Pedindo uma única função, ele fica perto do topo do mercado.
No SciCode, fica em 2º de 8 com 58,2%, acima dos 55,7% do Claude Opus 5 e de todas as variantes testadas do GPT-5.6.
É no trabalho de longo horizonte que ele se perde, e as novas tentativas devolvem silenciosamente a economia obtida. Mantenha um modelo mais forte para as execuções de várias horas.
O AA-Briefcase o coloca em 18º de 19 com 868,9 Elo, abaixo do Gemini 3.6 Flash e abaixo do Nemotron 3 Ultra.
A janela de um milhão de tokens é o recurso de destaque e, ao mesmo tempo, um dos resultados medidos mais fracos do modelo. Busque a informação primeiro, depois monte o prompt. Não jogue o arquivo inteiro ali dentro.
O raciocínio de contexto longo fica em 25º de 26, e o próprio relatório da Meta dá 54,1 no MRCR v2, contra 74,0 do GPT-5.5.
A demonstração de uso de computador é real e verificável, não encenada, e o modelo decide a cada etapa se usa um script ou clica. Ainda assim, não lidera o benchmark que mais promove.
O próprio relatório da Meta o coloca em 80,8 no OSWorld-Verified, atrás dos 83,4 do Claude Opus 4.8.
Não inventar fatos não é a mesma coisa que saber a hora de ficar quieto, e essa é a dimensão de alinhamento mais fraca do modelo segundo os próprios testes da Meta.
O teste Petri da Meta pontua a alucinação de entrada em 1,67, pior que o 1,22 do GPT-5.5 e o 1,34 do Claude Opus 4.8.
A falha que a própria Meta documenta
Esta é a parte que eu gostaria de saber antes de conectar isso a qualquer coisa. Está enterrada na documentação, não no post de lançamento.
O Muse Spark 1.1 mantém sua cadeia de raciocínio privada, o que hoje é normal. O incomum é o que acontece no caminho de integração mais comum. A própria documentação de raciocínio da Meta afirma que, no Chat Completions, o campo reasoning_content é redigido e fica vazio antes de chegar a quem fez a chamada, "então não há nada para reproduzir e cada turno raciocina do zero".
O guia de agentes de programação da Meta explica a consequência: o modelo "pode perder o fio do seu próprio raciocínio anterior e se comportar de forma errática: repetindo trabalho que já fez, contradizendo etapas anteriores".
Um modelo vendido por trabalho agêntico multi-etapa esquece seu próprio raciocínio entre turnos no caminho que a maioria das ferramentas usa por padrão. O raciocínio multi-turno só sobrevive na Responses API, onde o servidor mantém o contexto para você por meio de previous_response_id.
Nada disso é teórico. O melhor relato prático desde o lançamento descreve exatamente esse tipo de problema, e vem de um engenheiro que conseguiu rodar o Codex contra a API dentro de um contêiner:
"É algum tipo de erro de parsing ou de integração, devido ao que eu acho ser o codex não antecipando a chamada de ferramentas do lado do servidor e como a meta trata esses ids... nas primeiras vezes que rodei o codex com o muse, ele falhava na primeira chamada que não fosse busca na web."
Ele consertou o problema e continuou positivo em relação ao modelo. O ponto é que duas fontes independentes, a própria documentação da Meta e a primeira pessoa a integrá-lo em um ambiente real, chegam à mesma causa raiz. A engenharia agêntica é sob medida, e ambientes de terceiros tropeçam nela.
O número de alucinação que todo mundo cita é o errado
Aqui preciso corrigir uma leitura lisonjeira que tem circulado, incluindo minha própria cobertura anterior.
O Muse Spark 1.1 de fato tem uma boa taxa de não alucinação, ou seja, recusa-se a responder em vez de inventar coisas com uma frequência razoável. Verdade, e tem seu valor. Mas o índice composto de confiabilidade de conhecimento, que recompensa respostas corretas e penaliza alucinações, o coloca em 18,0. É a mais baixa das doze configurações listadas na própria página do modelo. O Claude Opus 5 marca 31,3.
Os próprios testes de alinhamento da Meta concordam, com uma linguagem mais direta do que qualquer concorrente publicou. Da avaliação Petri 3.0 em seu relatório: "a alucinação de entrada (1,67) é a principal, mais alta que o GPT-5.5 (1,22) e o Claude 4.8 Opus (1,34)". A mesma passagem sinaliza engano elevado em relação aos usuários e recusa excessiva elevada.
Então, duas fontes independentes, uma delas a própria Meta, chegam à mesma conclusão: a alucinação é a dimensão mais fraca deste modelo, não a mais forte.
Ainda assim, esse não é o número no qual eu basearia uma decisão de implantação de suporte. Este é:

Todo benchmark de alucinação mede se um modelo inventa fatos sobre o mundo. Quase nenhuma falha de suporte se parece com isso. Uma equipe de suporte técnico B2B com quem trabalhamos, que processava cerca de 200 tickets por mês no Zendesk e crescia rumo a 2.000, encontrou a versão real do problema. O bot deles dizia aos clientes que dava suporte a veículos que não estavam no banco de dados deles, porque a própria central de ajuda dizia "damos suporte a todos os modelos". O modelo foi fiel à sua fonte. A fonte estava errada.
Nenhuma pontuação em nenhum ranking captura isso. É por isso que treinar IA em uma base de conhecimento é um problema de conteúdo antes de ser um problema de modelo, e por isso limiares de confiança fazem mais pela qualidade das respostas do que qualquer upgrade de raciocínio jamais fará.
A mesma lógica se aplica rio acima. Acertar a triagem de tickets move a taxa de resolução de forma mais confiável do que trocar de modelo. Os padrões de falha são consistentes o suficiente para que os problemas dos chatbots de IA os catalogue melhor do que qualquer ficha de modelo.
A velocidade é real, mas olhe para o relógio certo
O número de throughput é real, e é a melhor estatística individual do modelo. O número de latência precisa de uma correção.
| Medida | Muse Spark 1.1 | Claude Opus 5 (max) |
|---|---|---|
| Velocidade de saída | 217,4 tok/s | 55,7 tok/s |
| Tempo até o primeiro token | 2,89 s | - |
| Tempo de raciocínio antes da primeira resposta | 9,20 s | - |
| Tempo até o primeiro token de resposta | 12,09 s | 51,22 s |
Os 2,89 s brutos da Meta para o tempo até o primeiro token são os melhores do painel. Também não é o que um usuário realmente experimenta. Some 9,2 segundos de raciocínio oculto e o primeiro token realmente útil chega em 12,09 s. Ainda assim, é claramente melhor que o Opus 5, então a conclusão se mantém. Mesmo sendo quatro vezes mais lento do que o número de manchete sugere.
Esse mesmo raciocínio oculto impulsiona a história do custo. 68% dos tokens de saída cobrados são raciocínio que quem faz a chamada nunca vê, com 15.164 tokens de raciocínio contra 7.232 tokens de resposta por tarefa. Na execução completa do índice do Artificial Analysis, 360 $ de um total de cerca de 548 $ foram gastos com raciocínio. Tokens baratos, hábito de pensar caro. É a razão pela qual o custo do atendimento ao cliente com IA nunca acompanha a tabela de preços.
Quatro armadilhas que vale a pena conhecer antes de começar
Nenhuma delas é motivo para desistir. Cada uma custa uma tarde se você encontrá-la sem estar preparado.
tool_choicesó aceita"auto". Você não pode forçar uma ferramenta específica, e não existe"required"nem"none". Qualquer outra coisa retorna um erro 400.- A saída estruturada vem desativada por padrão. Com
strict: false, a referência de chamada de ferramentas da Meta avisa que os argumentos gerados "não têm garantia de validar" contra o seu esquema. Valide antes de executar qualquer coisa. - O Claude Code precisa de três mudanças separadas. Uma URL base sem
/v1, os cinco aliases de modelo redirecionados paramuse-spark-1.1, e depoisANTHROPIC_AUTH_TOKENno lugar deANTHROPIC_API_KEY. - O MCP é anunciado, mas não documentado. O post de lançamento diz que o modelo generaliza para servidores MCP e habilidades personalizadas. A referência de chamada de ferramentas não documenta nenhum dos dois. Ferramentas definidas pelo desenvolvedor são o único caminho de extensibilidade realmente mostrado.
Também não existe um limite do lado do servidor para loops descontrolados de ferramentas personalizadas. max_tool_calls limita apenas as ferramentas integradas da Meta, algo que vale a pena saber se você já viu um loop de agente de IA girar sem parar. A metade da delegação desse assunto está coberta em orquestração de subagentes, e o argumento para testar você mesmo está em avaliações de agentes.
O que a Meta ainda não publicou
Lacunas também são material de análise, e esta lista é mais longa do que deveria ser, quatro semanas após o lançamento.
| Não publicado | Por que importa |
|---|---|
| Máximo de tokens de saída | Você não consegue dimensionar um teto de requisição |
| Data de corte do conhecimento | Você não consegue raciocinar sobre desatualização |
| Número de parâmetros | Nenhum detalhe de arquitetura de qualquer tipo |
| Lista de regiões liberadas | Tudo o que se sabe vem de usuários bloqueados |
| Duração da retenção de dados | Prompts pagos não entram em treinamento, mas a duração da retenção em si não é informada |
| SLA de uptime ou disponibilidade | Nada, absolutamente |
| Prefixo mínimo cacheável | A tarifa de 0,15 $ depende de uma variável não documentada |
A Meta também não aparece no ranking oficial do Terminal-Bench, então a pontuação autodeclarada ali não tem confirmação de terceiros. Meu panorama do Muse Spark 1.1 cobre a disputa metodológica em torno desse número. Ela ainda não foi resolvida.
Quem deve comprar, e quem deve deixar passar

Compre se você lida com trabalho de alto volume e horizonte curto: classificação, etiquetagem, extração, roteamento, geração de código em arquivo único, qualquer coisa em que uma chamada produz uma resposta e você faz milhões dessas chamadas. A velocidade é real e a tarifa de cache é excelente, e a cerca de 0,29 $ por tarefa, a economia em relação ao preço do Opus 5 é grande o suficiente para importar.
Deixe passar se sua carga de trabalho envolve agentes de longa duração, execuções de pesquisa profunda, ou qualquer coisa que precise raciocinar sobre um grande conjunto de documentos. Os números agênticos independentes não chegam nem perto. Este é um dos poucos casos em que pagar pelo GPT-5.6 ou pelo Opus 5 sai mais barato assim que você conta as novas tentativas. Para ambientes de programação especificamente, o Codex é hoje o caminho mais bem documentado.
Espere se você está fora dos Estados Unidos, ou precisa de uma política de retenção publicada, ou precisa de pesos abertos. Nesse último ponto, o Kimi K3 é a opção mais próxima da fronteira tecnológica com pesos que você realmente pode ter em mãos. A virada para pesos fechados é a parte deste lançamento que a comunidade menos perdoou.
A leitura moderada, de alguém que acompanha o ranking, é justa o suficiente para eu assinar embaixo:
"Novo respeito pelo Meta Muse Spark. Ele parece se encaixar em muitos pontos ideais do ranking. Não é o melhor em nada em particular, mas equilibra custo e desempenho muito bem."
O que isso muda para uma fila de suporte
Quase nada. Digo isso como alguém cujo trabalho é, em parte, perceber quando um novo modelo de fato muda alguma coisa.
A cada poucas semanas, sai um modelo mais barato e mais rápido, e alguém pergunta se isso reescreve o plano da mesa de ajuda. A resposta honesta é que o modelo nunca foi a restrição. Nos próprios testes cruzados da eesel, quando agentes reescreviam um rascunho de IA, cerca de 65% das edições eram de tamanho e tom. Cerca de 20% precisavam de dados que a IA não conseguia acessar em um ERP ou sistema logístico. Apenas cerca de 5% eram a IA errando os fatos. Um modelo melhor resolve exatamente esses últimos 5%. O resto é engenharia de prompt, busca de informações, coaching de agentes sobre as respostas realmente enviadas pela sua equipe, e profundidade de integração.
É também por isso que a redação estilo copiloto é onde a maioria das equipes deveria começar, o padrão por trás das ferramentas de assistência ao agente, e por que um caminho de escalonamento limpo importa mais do que uma posição no ranking. Se você está construindo o caso de negócio em vez da pilha técnica, IA vs custo humano é o enquadramento mais útil.
A falha que mais observo em produção é a que nenhum benchmark na página de lançamento da Meta mede. Um agente narrando uma busca que nunca fez. Reportando arquivos que nunca salvou. Um agente que afirma ter feito o trabalho é um problema mais difícil do que um agente que faz o trabalho mal, e um modelo que esquece seu próprio raciocínio entre turnos não é aquele em que eu confiaria para se autorreportar.
Experimente a eesel para suporte, não apenas uma chave de modelo bruta
Se o que você realmente quer é uma IA respondendo tickets de clientes, a pergunta útil tem pouco a ver com qual modelo lidera o índice neste mês. É se você consegue provar que a coisa é segura antes que ela responda a qualquer pessoa.
É nisso que a eesel é construída. Você pode rodar um agente de IA em simulação sobre seus próprios tickets históricos, e ler suas respostas em conversas passadas reais antes que um único cliente veja uma delas. Se as respostas ainda não estão prontas, você começa no modo copiloto, onde ele redige e sua equipe continua enviando.
A configuração é uma conexão com a mesa de ajuda, não um projeto. Ela se conecta ao Zendesk em poucos minutos, lê a central de ajuda que você já escreveu, e cobra por ticket resolvido em vez de por milhão de tokens, então a fatura acompanha o trabalho feito em vez de o quanto o modelo estava falante naquele dia. Grátis para experimentar, e o preço é público.
O veredito
O Muse Spark 1.1 é um bom modelo com o rótulo errado. A Meta vendeu um agente, e os benchmarks agênticos são seus piores resultados. Pelas evidências, é o melhor modelo rápido e barato de resposta única disponível agora, com uma pontuação forte em geração de código e uma tarifa de cache que ninguém mais alcança.
Julgue-o pelo trabalho que você tem, não pela categoria em que a Meta o arquivou, e fica fácil posicioná-lo. Compre para os milhões de chamadas curtas. Mantenha algo mais forte para as execuções longas. E não deixe uma janela de 1M de tokens te convencer a abrir mão da busca de informações. A cerca de um oitavo do custo por tarefa do Opus 5, ser o segundo melhor nos trabalhos certos já é um ótimo negócio.
Perguntas frequentes
O Meta Muse Spark 1.1 é realmente bom?
Como o Muse Spark 1.1 se compara ao Claude Opus 5?
O Muse Spark 1.1 é rápido?
O Muse Spark 1.1 alucina?
Posso usar o Muse Spark 1.1 com Claude Code ou Codex?
/v1, dos cinco aliases de modelo redirecionados e do ANTHROPIC_AUTH_TOKEN em vez de uma chave de API. A armadilha maior é que o caminho do Chat Completions descarta o raciocínio do modelo entre turnos, então ele se repete e se contradiz em execuções longas. Use a Responses API em vez disso.O Muse Spark 1.1 vale a pena para atendimento ao cliente?
Onde posso usar a Meta Model API?

Article by
Kurnia Kharisma Agung Samiadjie
Kurnia is a software engineer and writer at eesel AI with two years of SEO experience, writing about AI tools, helpdesk software, and customer support. He pairs a developer's understanding of how these products are built with search-driven research into what actually ranks and resonates with the people searching for them.








