Muse Wonder Full é exclusivo por assinatura: o que isso significa para equipes de agentes

O modelo mais potente da Meta não está na API da Meta. O Muse Wonder Full atinge 56 pontos no Artificial Analysis Intelligence Index, empata com o Claude Code no Sonnet 5.5 com 68 pontos no Coding Agents Index e lidera contra todos os modelos no benchmark histórico de programação da Meta. Você só pode utilizá-lo dentro do Muse Code, o agente de terminal da Meta, nos planos Power (US$ 50) ou Maximum (US$ 200). A API disponibiliza a versão menor, o Muse Wonder, com pontuações de 52 e 63. Não há cobrança por token para o Full, nenhum gateway e nenhuma previsão de lançamento.

Para um desenvolvedor individual, trata-se de uma escolha de preços. Para uma equipe que executa agentes a partir de um quadro compartilhado, é uma questão estrutural: o melhor modelo da Meta fica isolado no terminal de uma única pessoa, sob uma assinatura individual, com as configurações de dados dessa pessoa, e nada a que uma Task seja atribuída consegue acessá-lo. Este artigo analisa os impactos disso em uma Crew e o que fazer a respeito.

Os dois Wonders sob a ótica de uma equipe

A coluna da direita é uma ferramenta individual. A coluna da esquerda é uma lane compartilhada. Tudo o que vem a seguir decorre dessa diferença.

O que uma equipe perde quando o melhor modelo é de uso pessoal

O trabalho sai do quadro. O diferencial do Sharkly é que atribuição, progresso, impedimentos, resultados e revisões ficam visíveis da solicitação ao lançamento. Uma sessão do Muse Code não oferece nada disso. Se o modelo mais avançado roda apenas ali, as Tasks mais complexas acabam recaindo sobre quem possui a assinatura, e o quadro registra uma Task concluída sem histórico de execução, sem logs e sem um caminho passível de revisão.

As preferências de uma pessoa viram a política da equipe. As assinaturas do Muse Code vêm por padrão no modo Contributor, que permite à Meta treinar modelos usando prompts, códigos e respostas em troca de limites maiores de uso. O assinante pode desativá-lo, mas ninguém mais consegue saber se ele realmente fez isso. Já um Runtime em um Computer chama a API no modo Standard, em que o tráfego não é usado para treinamento — e isso vale para todos os Agents nesse Computer, sem que ninguém precise marcar uma opção.

A capacidade é limitada pelo plano, não pela chave. Os planos do Muse Code são renovados em janelas semanais e de cinco horas, e a semana de lançamento evidenciou o que acontece quando há instabilidades: o Wonder e o Full esgotaram as cotas de forma anormalmente rápida no primeiro dia, a Meta precisou reiniciar os limites de todos, e Alexandr Wang afirmou que ainda havia ajustes a fazer. Uma lane na API possui um limite diferente: 3.000 requisições e 4 milhões de tokens por minuto compartilhados pela equipe — algo que um quadro consegue monitorar e controlar, mas uma pessoa não.

O benchmark divulgado não é o que você terá em produção. O material de lançamento da Meta destaca os números do Full. Quem planeja a capacidade com base neles está dimensionando o trabalho para um modelo que a Crew simplesmente não pode executar. Para a equipe, os números relevantes são os do Wonder: 52 no índice, 53,1 no SWE-Marathon e 25 em conhecimento. Ainda assim, é um ótimo modelo para tarefas contínuas; a configuração para executá-lo leva apenas uma tarde.

O que a equipe ainda aproveita

Nada disso torna o Full inútil. Apenas faz dele outro tipo de ferramenta. A resposta honesta é que ele se encaixa onde o Claude Code ou o Codex em um terminal individual já se encaixam: na exploração técnica do engenheiro líder, naquele spike de investigação que ninguém escopou ainda ou em uma sessão pesada de depuração que só virará uma Task quando for compreendida. O Full é quatro pontos superior justamente nesse tipo de trabalho. Use-o ali.

A disciplina está na passagem de bastão. Quando uma sessão no Muse Code transforma uma incerteza em um plano, esse plano se converte em uma Task, e a Task vai para uma lane visível no quadro. O Agent Wonder da Crew, ou seu Agent Opus 5.5, executa o trabalho escopado com registro de logs e um revisor. O assinante cuida da exploração; a equipe mantém a rastreabilidade.

Duas práticas simples ajudam a consolidar isso:

• Registre o modelo na Task. O Sharkly não exibe os nomes dos modelos; por isso, as instruções do Agent devem incluir o ID do modelo no topo do relatório, e quem colar resultados do Muse Code deve informar isso nos comentários da Task. Um revisor que não sabe se um diff veio do Full no terminal ou do Wonder na lane não tem como calibrar sua avaliação.
• Decida sobre o modo Contributor em equipe. Se alguém possui uma assinatura do Muse Code e trabalha com repositórios da equipe, a desativação (opt-out) deve ser uma decisão formalizada da equipe, não uma preferência individual. O artigo Injeção de prompt e barreiras de proteção para agentes explica por que a etapa de revisão, e não o modelo, é o verdadeiro ponto de controle.

Uma semana na prática

Imagine uma equipe de cinco pessoas na primeira semana após o lançamento. O líder técnico assina o plano Muse Code Power no primeiro dia e passa a segunda-feira usando o Full naquela migração que ninguém queria fazer. Na terça-feira, já existe um plano: quatro partes bem escopadas, cada uma com testes que precisam passar. Essas quatro partes viram Tasks no quadro, atribuídas ao Wonder Agent no Codex Runtime, e rodam em paralelo no Computer da equipe enquanto o líder revisa tudo pela Inbox. Duas retornam sem problemas. Uma retorna com uma dúvida sobre uma alteração de esquema fora dos repositórios vinculados, que o líder responde diretamente nos comentários da Task. A última falha na suíte de testes duas vezes, continua tentando e é concluída na terceira abordagem, com um log que detalha as três tentativas.

Nada nessa semana exigiu o Full dentro do quadro. O Full cuidou da etapa que ainda não era uma Task. O Wonder executou as Tasks. O histórico documenta quem fez o quê e com qual modelo, pois as instruções do Agent inserem o ID do modelo no início de cada relatório e o comentário do próprio líder indica que o plano surgiu de uma sessão no Muse Code. Essa é a divisão de trabalho sobre a qual o Sharkly foi construído: ferramentas de execução fazem o trabalho, enquanto o quadro mantém visíveis a atribuição, o contexto, os impedimentos, os resultados e a revisão em todas as etapas.

O cenário de fracasso dessa mesma semana também é fácil de prever. O líder faz as quatro partes no Full simplesmente porque a ferramenta está à mão, envia uma branch na quinta-feira e a equipe precisa revisar um diff de 2.000 linhas sem nenhum log de execução e sem ideia de em quais pontos o modelo teve dúvidas. Mais rápido na segunda-feira, muito mais lento na sexta.

O Full chegará à API?

O blog de desenvolvedores da Meta afirma que o Full está disponível apenas por meio de assinaturas do Muse Code e não traz qualquer cronograma. A lógica comercial é evidente: o Full é o grande atrativo para pagar US$ 50 por mês, e a precificação por token concorreria diretamente com isso. Por outro lado, a Meta lançou três dialetos de API, documentou o suporte ao Claude Code e ao Codex no Wonder e disponibilizou o Wonder na Vercel e na Cloudflare logo na semana de lançamento — sinal de que a API não foi deixada de lado. O caminho mais provável é que o Full chegue à API quando o próximo modelo assumir o topo no Muse Code. Planeje suas lanes com base no Wonder e reavalie quando a página de modelos for atualizada.

A decisão em uma tabela

Um modelo quatro pontos superior àquele que seus Agents podem executar é motivo suficiente para manter uma assinatura, mas não para tirar o trabalho do quadro. No fim das contas, as execuções que realmente importam são aquelas que todos conseguem acompanhar.