De auteur onderzoekt het bestandssysteem en de logs van Meta's Muse en ontdekt dat er, naast het interne Meta-model 'Avocado', ook andere modellen worden aangeroepen.
Belangrijkste bevindingen:
- Er is een model genaamd
azure/muse-special aangetroffen, waarvan de technische kenmerken (zoals tool call ID's en versleutelde payloads) sterk wijzen op een OpenAI-model via Azure.
- De modelcatalogus bevat bovendien referenties naar Claude (Opus, Sonnet, Haiku) en Kimi.
- Er is uitgebreide infrastructuur aanwezig voor de integratie van Anthropic en OpenAI, inclusief specifieke clients en request-afhandeling.
De auteur speculeert dat Meta deze externe modellen gebruikt voor taken waar hun eigen modellen tekortschieten of voor A/B-testen. Wel stelt de auteur dat directe distillatie van de modelgewichten onwaarschijnlijk is, omdat de 'chain of thought' van de externe modellen versleuteld blijft. De auteur prijst uiteindelijk de technische uitvoering van het project en de openheid van het Meta-team.
Draait Meta's Muse stiekem op een OpenAI-model?
Dit is deel 2 van het onderzoek naar het bestandssysteem van Muse, nadat mijn artikel deze week op de voorpagina van Hacker News verscheen. In dit artikel focus ik op een model dat ik in mijn logs vond, genaamd muse-special, en beantwoord ik de vraag: maakt Muse achter de schermen daadwerkelijk gebruik van OpenAI- en Claude-modellen?
Eén vreemde sessie
Muse registreert welk model elke agentsessie gebruikt. Bijna elke sessielog in mijn VM werd gerouteerd naar Meta's interne model, genaamd Avocado. Maar één subagent gebruikte een model met de naam azure/muse-special. Interessant...
Het spoor van de naam volgen
Dit maakte me nieuwsgierig, dus ik heb in de repo via Cursor gezocht en vond het volgende: "GPT Responses model client via MAGI native Azure OpenAI lane."
De modelcatalogus lijkt azure/muse-special te vermelden, gevolgd door azure/gpt-5.6-sol. Toen ik mijn sessietranscripten doorzocht, vielen twee details op:
- De handtekening is getagd als
gptresponsesv1 en bevat een versleutelde payload die begint met gAAAAA (wat OpenAI gebruikt).
- Tool call ID's gebruikten
call gevolgd door 24 tekens met verschillende hoofd- en kleine letters. Dit verschilde van alle andere regels die de Avocado-sessies printten (call gevolgd door 32 hexadecimale tekens).
Deze kleine details wijzen erop dat het muse-special-model mogelijk een OpenAI-model is of de Responses API van OpenAI. Is muse-special dus een alias voor een GPT-model dat via Azure wordt aangeboden?
De bestanden en logs vertellen me niet precies welk GPT-model het is, of waarom het in eerste instantie door de subagent is gekozen, maar laten we een stap terug doen en verder onderzoeken.
De modelcatalogus
De bredere modelcatalogus die wordt meegeleverd met de agent-daemon van Muse bevat ongeveer 15 versies van Avocado, plus:
- Claude: Opus 4.6 / 4.7 / 4.8, Sonnet 4.6 en Haiku 4.5.
- GPT: 5.5 en 5.6 varianten via OpenAI, Azure en Codex.
- Kimi: K3 via Fireworks en Meta-gehoste routes.
De Anthropic-infrastructuur
De ondersteuning voor Claude gaat verder dan alleen het model-ID; het bevat een Anthropic-client met request-afhandeling, prompt-conversie en streaming-parsers:
anthropic/request_flow.rsanthropic/convert_prompt.rsanthropic/parsessestream.rs
Nu we dit weten, rijst de vraag: waarom? Er zijn API-sleutelbestanden aanwezig voor Anthropic, OpenAI, etc., waarbij de toegang beperkt is tot de inference-proxy service. Er is echter ook een proxy kill-switch instelling in de omgeving: JARVISANTHROPICBASEURLREVPROXY_OVERRIDE=0. De commentaar bij deze instelling noemt dit een live kill-switch, geen verouderde configuratie.
Waarom is dit allemaal meegeleverd?
Ik vermoed dat hier een paar redenen voor zijn.
Ten eerste kan het zijn dat een OpenAI- of Anthropic-model simpelweg superieur is in een specifieke taak die Muse momenteel niet kan uitvoeren, waardoor ze daar selectief voor routeren.
Ten tweede zijn al deze VM's uitgerust met de mogelijkheid om model-responsen, tool calls, etc. via A/B-tests te vergelijken voor distillatie en RL (Reinforcement Learning). Distillatie of RL? Misschien. Ik weet het niet.
Dit leidt ons naar de kern: de keuze voor het model achter Muse vindt uiteindelijk plaats aan de serverzijde. De runtime heeft clients voor meerdere providers, wat Meta de mogelijkheid geeft om de routering te wijzigen zonder gebruikers hiervoor te vragen. In mijn geval was er slechts één uitzonderlijke sessie die niet het Avocado-model (Meta) gebruikte, maar de infrastructuur is er dus wel voor.
Is Meta bezig met distillatie?
Is Meta dus bezig met distillatie vanuit andere frontier-labs? Om technisch te worden: nee.
Bij het muse-special-model is de ruwe redenering (reasoning) versleuteld. De daemon bewaart deze om deze in de volgende beurt terug te sturen naar Azure. In het binary staat expliciet dat de versleutelde redenering de RL completion-server override niet kan gebruiken.
Meta kan hier dus alleen de reactie, de tool calls en een korte samenvatting van de redenering zien wanneer OpenAI/Anthropic die teruggeeft. De ruwe chain of thought is versleuteld en de RL-server weigert deze blobs. Er is geen aanwijzing dat Meta de gewichten (weights) van OpenAI of Anthropic kopieert.
Avocado-modellen worden echter anders behandeld. De denkteksten worden direct in het transcript geschreven, met een lege handtekening, en zijn beschikbaar voor RL-gebruik. Volgens de privacy-notitie en de repo geven Avocado-modellen dus aan dat gesprekken kunnen worden gebruikt om AI bij Meta te ontwikkelen, tenzij je hiervoor kiest om je af te melden (opt-out). Dat is logisch.
Slotbeschouwingen
Dit is mijn eigen verkenning van wat een zeer coole release van Meta is geweest. Mijn beste gok is dat muse-special een OpenAI-model is dat via Azure wordt aangeboden.
Wat je ook van Meta vindt, het talent dat aan dit project heeft gewerkt verdient erkenning. Ze hebben een andere aanpak gekozen in een wereld vol chatbots en zoekbalken. Ook de reactie van het executive team op mijn eerste artikel, dat redelijk veel aandacht kreeg, was verbazingwekkend, evenals hun bereidheid om contact op te nemen met een onbekende om hun denkproces uit te leggen.
Het is niet elke dag dat je in het bestandssysteem mag kijken van een product dat honderden miljoenen mensen zou kunnen bereiken. Een blik in een runtime cell geeft ons een vroeg inkijkje in waar dit hele idee van persoonlijke agents naartoe gaat, en het was deze week fascinerend om dit allemaal door te lezen.
Als je aan Muse hebt gewerkt, neem dan gerust contact op. Ik zou graag meer willen weten en misschien een bijdrage leveren. De ontwikkelingen lijken snel te gaan. Ze breken tot nu toe nog niet echt.
Draait Meta's Muse stiekem op een OpenAI-model?
Dit is deel 2 van het onderzoek naar het bestandssysteem van Muse, nadat mijn artikel deze week op de voorpagina van Hacker News verscheen. In dit artikel focus ik op een model dat ik in mijn logs vond, genaamd muse-special, en beantwoord ik de vraag: maakt Muse achter de schermen daadwerkelijk gebruik van OpenAI- en Claude-modellen?
Eén vreemde sessie
Muse registreert welk model elke agentsessie gebruikt. Bijna elke sessielog in mijn VM werd gerouteerd naar Meta's interne model, genaamd Avocado. Maar één subagent gebruikte een model met de naam azure/muse-special. Interessant...
Het spoor van de naam volgen
Dit maakte me nieuwsgierig, dus ik heb in de repo via Cursor gezocht en vond het volgende: "GPT Responses model client via MAGI native Azure OpenAI lane."
De modelcatalogus lijkt azure/muse-special te vermelden, gevolgd door azure/gpt-5.6-sol. Toen ik mijn sessietranscripten doorzocht, vielen twee details op:
- De handtekening is getagd als
gptresponsesv1 en bevat een versleutelde payload die begint met gAAAAA (wat OpenAI gebruikt).
- Tool call ID's gebruikten
call gevolgd door 24 tekens met verschillende hoofd- en kleine letters. Dit verschilde van alle andere regels die de Avocado-sessies printten (call gevolgd door 32 hexadecimale tekens).
Deze kleine details wijzen erop dat het muse-special-model mogelijk een OpenAI-model is of de Responses API van OpenAI. Is muse-special dus een alias voor een GPT-model dat via Azure wordt aangeboden?
De bestanden en logs vertellen me niet precies welk GPT-model het is, of waarom het in eerste instantie door de subagent is gekozen, maar laten we een stap terug doen en verder onderzoeken.
De modelcatalogus
De bredere modelcatalogus die wordt meegeleverd met de agent-daemon van Muse bevat ongeveer 15 versies van Avocado, plus:
- Claude: Opus 4.6 / 4.7 / 4.8, Sonnet 4.6 en Haiku 4.5.
- GPT: 5.5 en 5.6 varianten via OpenAI, Azure en Codex.
- Kimi: K3 via Fireworks en Meta-gehoste routes.
De Anthropic-infrastructuur
De ondersteuning voor Claude gaat verder dan alleen het model-ID; het bevat een Anthropic-client met request-afhandeling, prompt-conversie en streaming-parsers:
anthropic/request_flow.rsanthropic/convert_prompt.rsanthropic/parsessestream.rs
Nu we dit weten, rijst de vraag: waarom? Er zijn API-sleutelbestanden aanwezig voor Anthropic, OpenAI, etc., waarbij de toegang beperkt is tot de inference-proxy service. Er is echter ook een proxy kill-switch instelling in de omgeving: JARVISANTHROPICBASEURLREVPROXY_OVERRIDE=0. De commentaar bij deze instelling noemt dit een live kill-switch, geen verouderde configuratie.
Waarom is dit allemaal meegeleverd?
Ik vermoed dat hier een paar redenen voor zijn.
Ten eerste kan het zijn dat een OpenAI- of Anthropic-model simpelweg superieur is in een specifieke taak die Muse momenteel niet kan uitvoeren, waardoor ze daar selectief voor routeren.
Ten tweede zijn al deze VM's uitgerust met de mogelijkheid om model-responsen, tool calls, etc. via A/B-tests te vergelijken voor distillatie en RL (Reinforcement Learning). Distillatie of RL? Misschien. Ik weet het niet.
Dit leidt ons naar de kern: de keuze voor het model achter Muse vindt uiteindelijk plaats aan de serverzijde. De runtime heeft clients voor meerdere providers, wat Meta de mogelijkheid geeft om de routering te wijzigen zonder gebruikers hiervoor te vragen. In mijn geval was er slechts één uitzonderlijke sessie die niet het Avocado-model (Meta) gebruikte, maar de infrastructuur is er dus wel voor.
Is Meta bezig met distillatie?
Is Meta dus bezig met distillatie vanuit andere frontier-labs? Om technisch te worden: nee.
Bij het muse-special-model is de ruwe redenering (reasoning) versleuteld. De daemon bewaart deze om deze in de volgende beurt terug te sturen naar Azure. In het binary staat expliciet dat de versleutelde redenering de RL completion-server override niet kan gebruiken.
Meta kan hier dus alleen de reactie, de tool calls en een korte samenvatting van de redenering zien wanneer OpenAI/Anthropic die teruggeeft. De ruwe chain of thought is versleuteld en de RL-server weigert deze blobs. Er is geen aanwijzing dat Meta de gewichten (weights) van OpenAI of Anthropic kopieert.
Avocado-modellen worden echter anders behandeld. De denkteksten worden direct in het transcript geschreven, met een lege handtekening, en zijn beschikbaar voor RL-gebruik. Volgens de privacy-notitie en de repo geven Avocado-modellen dus aan dat gesprekken kunnen worden gebruikt om AI bij Meta te ontwikkelen, tenzij je hiervoor kiest om je af te melden (opt-out). Dat is logisch.
Slotbeschouwingen
Dit is mijn eigen verkenning van wat een zeer coole release van Meta is geweest. Mijn beste gok is dat muse-special een OpenAI-model is dat via Azure wordt aangeboden.
Wat je ook van Meta vindt, het talent dat aan dit project heeft gewerkt verdient erkenning. Ze hebben een andere aanpak gekozen in een wereld vol chatbots en zoekbalken. Ook de reactie van het executive team op mijn eerste artikel, dat redelijk veel aandacht kreeg, was verbazingwekkend, evenals hun bereidheid om contact op te nemen met een onbekende om hun denkproces uit te leggen.
Het is niet elke dag dat je in het bestandssysteem mag kijken van een product dat honderden miljoenen mensen zou kunnen bereiken. Een blik in een runtime cell geeft ons een vroeg inkijkje in waar dit hele idee van persoonlijke agents naartoe gaat, en het was deze week fascinerend om dit allemaal door te lezen.
Als je aan Muse hebt gewerkt, neem dan gerust contact op. Ik zou graag meer willen weten en misschien een bijdrage leveren. De ontwikkelingen lijken snel te gaan. Ze breken tot nu toe nog niet echt.
Groetjes,