Muse da Meta usa OpenAI escondido? O que achei

O log que não era para aparecer

Muse da Meta deveria ser a prova de que o Avocado aguenta o tranco sozinho, mas foi só colocar a ferramenta para montar um site de verdade e olhar o log com calma para achar um ponto fora da curva. Quase todas as sessões de agente estavam marcadas como Avocado, o modelo interno, e então um subagente isolado aparece roteado para algo chamado azure/muse-special. Quando você opera agente de código todo dia, esse tipo de exceção importa mais que o fluxo normal, porque exceção em roteamento quase sempre revela arquitetura real, fallback ou teste que ninguém documentou.

Fui seguir o nome, como qualquer pessoa faria ao depurar um sistema opaco, e o rastro leva para uma frase bem específica dentro do repositório: cliente de respostas GPT via trilha nativa MAGI do Azure OpenAI. Logo ao lado, no catálogo, aparecem azure/muse-special e azure/gpt-5.6-sol lado a lado. Não é prova definitiva sozinha, mas já muda o cheiro da investigação. Não parece nome interno aleatório, parece alias operacional para servir um modelo da família GPT através do Azure, com toda a parafernália de autenticação, proxy e controle de tráfego que isso exige.

O fato sem maquiagem

O que aconteceu é simples e incômodo ao mesmo tempo. Durante uma construção normal de site no Muse, uma sessão filha não usou o modelo da Meta. Ela chamou o tal muse-special pelo Azure. O resto continuou no Avocado. O catálogo que acompanha o daemon do agente lista cerca de 15 variações de Avocado, e junto delas traz Claude Opus 4.6, 4.7 e 4.8, Sonnet 4.6 e Haiku 4.5, variantes de GPT-5.5 e GPT-5.6 via OpenAI, Azure e Codex, além de Kimi K3 via Fireworks e rotas hospedadas pela própria Meta. Ou seja, o binário já sai de fábrica com clientes para múltiplos provedores, mesmo que o discurso público seja de modelo próprio de ponta a ponta.

O detalhe que convence não está no nome, está nos rastros de protocolo. Nas transcrições, a sessão suspeita carrega assinatura marcada como gpt_responses_v1 com um blob criptografado que começa com gAAAAA, padrão que a API Responses da OpenAI usa para reasoning criptografado. Os IDs de tool call também mudam: call_ mais 24 caracteres mistos, contra call_ mais 32 hexadecimais nas sessões Avocado. São duas impressões digitais pequenas, mas difíceis de falsificar por acidente. Tudo aponta para a mesma conclusão plausível: aquele subagente falou com um endpoint compatível com OpenAI, servido pelo Azure, e devolveu resposta e chamadas de ferramenta naquele formato.

Como funciona na visão de quem opera

Roteamento decidido no servidor

Na prática, o Muse parece operar como um orquestrador multi-modelo com decisão server-side. O daemon local carrega um catálogo amplo, mantém clientes separados para Anthropic com fluxo de requisição, conversão de prompt e parser de SSE, e mantém uma trilha Azure OpenAI via MAGI. As chaves de API para Anthropic, OpenAI e outros ficam restritas ao serviço de inference-proxy, e ainda existe uma chave de kill-switch no ambiente. Esse desenho é clássico de quem quer trocar o modelo por trás sem atualizar o cliente e sem pedir permissão ao usuário. Você acha que está falando com Avocado, mas o proxy pode ter roteado aquele passo para outro fornecedor porque a política mandou.

Por que fariam isso? A hipótese mais direta é capacidade. Tem tarefa onde um GPT ou um Claude ainda resolve melhor, principalmente em uso de ferramenta complexo, planejamento de arquivo grande ou reparo de erro encadeado, e aí vale rotear o subagente crítico para o modelo mais confiável enquanto o resto roda no modelo barato da casa. A segunda hipótese é experimentação e destilação de comportamento: rodar A e B de respostas, comparar tool calls, medir taxa de sucesso por tarefa para depois treinar o Avocado. Pelos arquivos, o raciocínio bruto do muse-special vem criptografado e o próprio binário diz que esse reasoning criptografado não pode usar o override do servidor de RL por completion. A Meta enxerga a resposta final, as chamadas de ferramenta e um resumo curto quando existe, mas não o chain of thought cru. Já o Avocado grava o pensamento direto na transcrição, com assinatura vazia, pronto para uso em RL. Tecnicamente, isso não é cópia de pesos, é aprendizado com saída observável, que é bem diferente.

Em termos de custo e latência, dá para inferir o trade-off mesmo sem tabela oficial. Servir via Azure OpenAI em lane nativa costuma significar throughput reservado, autenticação gerenciada e custo por token bem acima de inferência interna. Faz sentido usar esse caminho só em gargalos: um subagente que decide estrutura do projeto, ou que precisa acertar uma chamada de ferramenta delicada de primeira. Latência também conta. A API Responses com reasoning criptografado exige round-trip com estado, o daemon precisa devolver o blob no turno seguinte, o que aumenta payload e tempo de contexto. Para quem opera, isso cheira a fallback seletivo, não a dependência total. Se fosse tudo no GPT, a conta não fecharia e o marketing de modelo próprio ruiria rápido.

O que isso muda na prática

Para quem constrói agentes, a lição é direta: não confie no nome do modelo no banner. O que vale é o comportamento observado em log, formato de tool call, latência por tipo de tarefa e taxa de erro em edição multi-arquivo. Se você está avaliando o Muse para adotar no time, precisa testar como se fosse um sistema roteado, porque é isso que ele parece ser. Quem ganha aqui é o usuário que pega o melhor de cada modelo sem precisar gerenciar chaves. Quem perde é quem precisa de garantias duras de proveniência, residência de dados e reprodutibilidade, porque fica impossível afirmar que tal geração veio 100 por cento de tal peso, em tal região, com tal política.

• Ative logging verboso das suas sessões e grave modelo por subagente, IDs de tool call e tempo por passo para detectar quando o comportamento muda de Avocado para um formato tipo Responses.
• Separe seu benchmark em tarefas de scaffold simples e tarefas de debug encadeado, porque é no segundo grupo que o roteamento para um modelo de fronteira faz diferença e mascara a capacidade real do modelo padrão.
• Revise contrato e trilha de dados se você lida com código proprietário, já que uma rota via Azure implica outro processador e outra cadeia de retenção, mesmo com proxy no meio.

O ajuste imediato não é trocar de ferramenta, é instrumentar. Crie um roteiro de avaliação de uma tarde: mesmo prompt, mesmo repo, três rodadas, compare diff final, número de passos e retrabalho. Se em uma rodada aparece latência e estilo diferentes com tool calls mais estáveis, anote. Você provavelmente pegou a rota alternativa em ação. Para times que pagam por assento, isso vira conversa de custo-benefício: vale pagar pelo Muse se parte do valor vem de um modelo que você já assina direto? Ou vale justamente porque ele orquestra e escolhe por você sem fricção?

Isso escala ou só move o gargalo?

Aqui fica a tensão real. Manter clientes para Anthropic, OpenAI, Codex, Fireworks e rotas Meta dá flexibilidade, mas cobra preço em complexidade operacional. Cada provedor tem formato de streaming, limite de contexto, semântica de ferramenta e modo de falha diferentes. O código mostra parsers dedicados para SSE da Anthropic, conversão de prompt e lane nativa Azure, o que significa mais superfície para bug, mais retry, mais observabilidade para manter. Resolve o problema de qualidade no curto prazo, mas cria um sistema distribuído onde o comportamento final depende de política de roteamento que o usuário não vê e não controla. Isso escala tecnicamente, só que cobra em previsibilidade.

E tem a pergunta incômoda sobre transparência e destilação. Mesmo que o reasoning criptografado impeça o uso direto em RL, respostas e tool calls ainda são sinal riquíssimo para treino. Nada nos arquivos indica cópia de pesos, e o cuidado com o blob criptografado até sugere limite consciente, mas a linha entre aprender com saída e depender do concorrente é fina. Se o Avocado precisa de ajuda do GPT-5.6 ou do Claude Opus em tarefas críticas hoje, quanto tempo até ele sustentar sozinho o mesmo nível sem a muleta? E se a resposta for que a muleta é permanente, por que vender como modelo único? No fim, a arquitetura multi-modelo é boa engenharia, mas comunicação opaca cobra juros em confiança.

Conclusão

O Muse não parece ser só Avocado o tempo todo, ele parece ser um roteador esperto que usa Avocado como padrão e chama reforço via Azure quando precisa. Resta saber se a Meta vai assumir esse modo híbrido abertamente ou continuar deixando para os logs contarem a história.