1. O que é o Muse Ember?
2. Como o Muse Ember funciona dentro de um sistema de agentes
3. Para que serve o Muse Ember na prática
4. Muse Ember nos benchmarks: onde lidera e onde fica atrás
5. Quanto custa o Muse Ember
6. Como acessar o Muse Ember e o que fica em aberto
7. Conclusão
O Muse Ember é o modelo de linguagem mais leve e mais barato da Meta, lançado em 9 de novembro de 2026 para uma parte do trabalho dos agentes de IA que costuma passar despercebida nas comparações entre modelos: as etapas pequenas e repetidas. Um agente que atende clientes ou revisa contratos gasta a maior parte dos seus tokens chamando ferramentas, extraindo campos e lendo documentos, e não planejando. É nessa camada que a conta de uma operação com agentes cresce.
A proposta da Meta é dividir o trabalho. O Muse Wonder, modelo de fronteira da empresa lançado em outubro, decide como resolver um problema, e o Muse Ember aplica essa decisão em escala, a um custo por tarefa que a empresa calcula em cerca de um terço do registrado pelo Claude Haiku 5.5 para a mesma nota. O preço por token, porém, é igual ao do concorrente, e entender essa diferença separa a leitura correta do lançamento da manchete.
Este artigo explica o que é o Muse Ember, como ele funciona dentro de um sistema de agentes e para que serve na prática. Na sequência, detalha os benchmarks, onde o modelo lidera e onde fica atrás, quanto custa, como acessar e o que o anúncio ainda deixa em aberto.
O Muse Ember é um modelo de linguagem de pequeno porte desenvolvido pelo Meta Superintelligence Labs, o laboratório de IA da Meta, e lançado em 9 de novembro de 2026. Ele foi treinado para executar as tarefas que agentes de IA repetem ao longo do dia: chamadas de ferramentas, subtarefas de programação, roteamento de pedidos, extração de dados e leitura de documentos longos. Na API, o identificador do modelo é muse-ember-1.0.
Apesar do tamanho, a ficha técnica é de modelo grande. A janela de contexto chega a 1 milhão de tokens, as unidades de texto que os modelos processam e pelas quais cobram, e cada resposta pode ter até 512 mil tokens de saída. Segundo a Meta, o Ember entende texto, imagem, áudio e vídeo de forma nativa, sem depender de um modelo auxiliar para cada formato. Ele também é o primeiro modelo da empresa treinado a partir do Muse Wonder Full, a versão mais capaz da família.
O Ember é o quarto modelo da marca Muse em 2026 (TechCrunch, 2026). A sequência começou em abril com o Muse Spark, de porte intermediário, seguiu em agosto com o Muse Glimmer, versão de pesos abertos do Spark, e chegou em outubro ao Muse Wonder. Com o lançamento, a Meta fecha uma linha em três degraus: o Wonder para os problemas mais difíceis, o Spark para programação e fluxos agênticos e o Ember para a execução em grande volume.
Os nomes da família se sobrepõem, e vale separá-los. O Muse, agente pessoal de consumo lançado em setembro, é um produto; Spark, Glimmer, Wonder e Ember são modelos; Muse Code é o agente de programação no terminal. Por enquanto, o Ember é um modelo para desenvolvedores, e a Meta não o anunciou no aplicativo Meta AI nem no agente Muse.
A lógica do Muse Ember é a de uma equipe com divisão de funções. Um modelo maior e mais caro define as regras para resolver um problema, e um modelo menor aplica essas regras milhares de vezes. A Meta resume a ideia numa frase do anúncio: o Muse Wonder planeja, e o Muse Ember cuida do volume.
O exemplo usado pela empresa é o de um agente de atendimento. Diante de um tipo novo de reclamação, o Wonder estabelece como o caso deve ser tratado, quais dados consultar e quando escalar para uma pessoa. Depois, o Ember aplica essas orientações a dezenas de milhares de atendimentos. O modelo caro entra em cena uma vez; o barato, a cada chamado.
Nesse desenho, o Ember funciona como subagente: um agente auxiliar que recebe uma tarefa delimitada de outro agente, executa e devolve o resultado. Ele também pode atuar como agente principal em automações mais simples, em que não há planejamento complexo a fazer. A estrutura que coordena essa divisão, com regras de roteamento, ferramentas e memória, é o que o mercado chama de harness.
Dois recursos sustentam esse papel. O primeiro é a entrada multimodal: o agente lê capturas de tela, gráficos e documentos digitalizados ou trabalha a partir de mensagens de voz e gravações de reunião sem trocar de modelo. O segundo é o controle do esforço de raciocínio, que define quanto o modelo pensa antes de responder e, por consequência, quanto ele gasta. A API oferece seis níveis, do mínimo ao máximo.
O público imediato do Muse Ember são desenvolvedores e times de engenharia que já operam agentes e pagam por tokens em escala. Para esses times, o modelo é uma peça de arquitetura, e não um assistente para conversar. As aplicações que a Meta destaca (Olhar Digital, 2026) se agrupam em cinco tipos de tarefa:
Os primeiros clientes reportam ganhos de latência, o tempo até a resposta. A Cloudflare diz que o Ember foi até 30% mais rápido nas requisições mais lentas do teste, e a You.com mediu 2,2 segundos de latência no percentil 95 em tarefas de programação. São depoimentos selecionados pela própria Meta, sem metodologia publicada, mas indicam o espaço que o modelo pretende ocupar.
A aposta em modelos menores para trabalho delimitado não é nova. Operações de alto volume já vinham migrando parte das tarefas para small language models, mais baratos e rápidos. O que diferencia o Ember é combinar preço de modelo pequeno com janela de contexto e entrada multimodal típicas de modelos de fronteira.
A Meta comparou o Muse Ember com os dois concorrentes diretos da mesma faixa de preço: o Claude Haiku 5.5, da Anthropic, lançado em outubro, e o GPT-6 Luna, da OpenAI. Os três modelos rodaram no nível máximo de raciocínio, em dez avaliações publicadas no anúncio do modelo (Meta, 2026).
A vantagem mais clara está na automação de processos de negócio. No AutomationBench-AA, conjunto de 657 fluxos de trabalho em aplicativos simulados como Gmail, Salesforce e Slack, o Ember concluiu 37,8% das tarefas sem erro, contra 13,9% do Haiku 5.5 e 20,2% do Luna. É exatamente o tipo de trabalho para o qual o modelo foi desenhado: buscar um registro, chamar uma ferramenta, atualizar outro sistema e repetir.
O modelo também lidera o Coding Agent Index, com 46 pontos contra 37 do Haiku e 31 do Luna. A comparação é mais justa do que a média, porque cada modelo rodou dentro do agente de programação do próprio fabricante: Muse Code, Claude Code e Codex. Contra o Luna, o Ember vence em todas as linhas, com exceção do GDP.pdf, em que os dois empatam.
O Haiku 5.5 vence no FrontierCode 2.0, avaliação que verifica se uma alteração de código seria aprovada por quem mantém o repositório: 34,9% contra 27,2%. É a métrica mais próxima de perguntar se o código está pronto para produção, e pesa para quem pretende usar o modelo para abrir pull requests, e não apenas corrigir trechos.
A segunda fraqueza fica fora da tabela da Meta e diz respeito ao conhecimento factual. No AA-Omniscience, teste de conhecimento da Artificial Analysis, o Ember acerta 21,1% das perguntas, contra 34,7% do Haiku 5.5, e se recusa a responder 64% delas. Essa cautela explica a baixa taxa de alucinação do modelo, e indica o uso adequado: o Ember rende quando recebe o documento ou o dado de que precisa, e não quando depende da própria memória.
Dois cuidados ajudam a interpretar a tabela. Quatro das dez linhas foram medidas pela própria Meta, que descreve os testes dos concorrentes como esforço de melhor tentativa, sem garantia de configuração ideal. A linha do Terminal-Bench também mistura ambientes: o resultado do Ember veio de um teste da Artificial Analysis, enquanto o do Haiku é o número declarado pela Anthropic. Quando a Artificial Analysis rodou o Haiku 5.5 no mesmo ambiente, ele marcou 32,8%.
O dado independente mais sólido é o índice agregado da Artificial Analysis, em que Ember e Haiku 5.5 empatam em 36 pontos, contra 28 do Luna. Sem arredondamento, o Haiku fica ligeiramente à frente. A leitura justa, portanto, é que o Ember iguala o modelo da Anthropic em capacidade geral, sem superá-lo.
Na Meta Model API, o Muse Ember custa US$ 0,10 por milhão de tokens de entrada (cerca de R$ 0,54) e US$ 0,50 por milhão de tokens de saída. A leitura de cache, o reaproveitamento de um contexto já processado, sai por US$ 0,004 por milhão, 4% do preço normal de entrada. Esse valor pesa para agentes que reenviam as mesmas instruções longas a cada chamada.
Há uma segunda faixa de preço, ausente do texto de lançamento. Prompts acima de 200 mil tokens passam a custar US$ 0,30 na entrada e US$ 1,50 na saída, o triplo da tabela padrão (Neowin, 2026). Como a janela de 1 milhão de tokens é um dos argumentos do modelo para ler bases de código e conjuntos de documentos inteiros, justamente esse uso cai na faixa mais cara.
Na faixa padrão, o preço por token do Ember é idêntico ao do Claude Haiku 5.5 e ao do GPT-6 Luna. A diferença aparece no custo por tarefa concluída, que depende de quantos tokens cada modelo gasta para chegar à resposta. No índice da Artificial Analysis, o Ember resolve uma tarefa por cerca de US$ 0,14, contra US$ 0,41 do Haiku 5.5 e US$ 0,15 do Luna, todos no esforço máximo.
A explicação está no volume de texto gerado. Para completar o mesmo índice, o Ember produziu 115 milhões de tokens de saída e o Haiku 5.5, 298 milhões, cerca de 2,6 vezes mais, pagando o mesmo valor por token. Para quem opera agentes, essa é a métrica que importa: uma tabela de preços igual pode esconder uma fatura três vezes maior.
Dentro da própria família, a distância é ainda maior. O Muse Spark 1.3 marca 37 pontos no mesmo índice, apenas um a mais que o Ember, e custa US$ 2,39 por tarefa, cerca de 17 vezes mais (Canaltech, 2026). Já o Muse Wonder cobra US$ 4 por milhão de tokens de entrada, 40 vezes o preço do Ember, e é essa distância que sustenta a proposta de usar o modelo caro para planejar e o barato para executar.
O Muse Ember está disponível desde o lançamento na Meta Model API, com o identificador muse-ember-1.0, e no Muse Code, o agente de programação da Meta. O modelo também chega pelas nuvens parceiras Google Cloud e Oracle Cloud. A API aceita clientes compatíveis com o SDK da OpenAI, o que reduz o esforço de testar o modelo em aplicações que já existem.
O Ember é um modelo proprietário. A Meta não liberou os pesos, ao contrário do que fez com o Muse Glimmer, e o caminho de acesso passa pela API, pelo Muse Code ou pelas nuvens parceiras, sem versão para download.
Em segurança, a Meta avaliou o modelo pelo Meta Superintelligence Scaling Framework, sua política de gestão de riscos, e afirma que ele ficou abaixo de todos os limites de alto risco em cibersegurança, ameaças químicas e biológicas e perda de controle. O Ember também recebeu proteções para tarefas executadas em nome do usuário, como resistência a injeção de prompt e pedido de confirmação humana antes de ações de alto impacto.
Algumas lacunas pesam numa avaliação corporativa. Os custos por tarefa no gráfico da Meta são estimativas calculadas a partir do preço anunciado, e os ganhos de latência vêm de depoimentos de parceiros escolhidos pela empresa. Há ainda uma divergência sobre modalidades: a Meta fala em áudio e vídeo, enquanto a página do modelo na Artificial Analysis lista apenas texto e imagem. Testar o Ember nas tarefas reais da operação, com os próprios dados, segue sendo o critério mais confiável.
Em síntese, o Muse Ember desloca a disputa entre modelos pequenos do preço por token para o custo por tarefa. Com a mesma tabela do Claude Haiku 5.5 e do GPT-6 Luna, o modelo da Meta alcança a nota do Haiku no índice agregado da Artificial Analysis gastando cerca de um terço por tarefa, e lidera com folga a automação de fluxos de negócio.
Em resumo, três decisões explicam esse perfil. A Meta desenhou o Ember para ser subagente, e não modelo de conversa, por isso priorizou chamadas de ferramenta e extração em vez de conhecimento enciclopédico. Ao treiná-lo a partir do Muse Wonder Full, aproximou sua capacidade da do Spark 1.3 com um custo 17 vezes menor. E, ao separar os três modelos em degraus de preço bem distantes, transformou a escolha de modelo numa decisão de arquitetura.
Para empresas que já operam agentes, a consequência prática é medir custo por resultado entregue, e não por token. Uma operação que manda todas as etapas para o modelo mais capaz, por precaução, tende a pagar pelo raciocínio de fronteira em tarefas que um modelo leve resolveria. As fraquezas do Ember em código pronto para produção e em conhecimento factual mostram, ao mesmo tempo, que o roteamento precisa de critério: o modelo barato rende quando recebe contexto e escopo fechado.
A tendência é que a camada de execução dos agentes fique cada vez mais barata e disputada, com Anthropic, OpenAI e Meta lançando modelos leves com poucas semanas de intervalo. Quem não acompanhar esse movimento corre o risco de seguir pagando preço de fronteira por trabalho repetitivo, enquanto a concorrência reorganiza seus fluxos em torno do custo por tarefa.
Separar o lançamento que muda a conta da operação daquele que só rende manchete exige leitura atenta toda semana. Assine a AI Factory News e receba toda semana a análise do Distrito sobre modelos, agentes e lançamentos de IA.
