Muse logs point to an OpenAI model behind one session

Pete, who posts as @heypeterjames, found that one subagent in his Muse virtual machine ran on a model labeled azure/muse-special instead of Meta’s own Avocado. In a September 25 post on Mouse he explains why he thinks that label hides an OpenAI model served through Azure.

Muse gives each user an agent with its own computer, file system and terminal, and it records which model handled each agent session. In Pete’s VM nearly every session went to Avocado, the internal name for Meta’s Muse model. The one exception was a single subagent session on September 21. This is his second post going through the Muse filesystem.

The fingerprints

The label is just a name. The evidence comes from what sits around it. Pete searched the repo inside Cursor and found a client described as a “GPT Responses model client via MAGI native Azure OpenAI lane.” In the model catalogue, azure/muse-special is listed right before azure/gpt-5.6-sol.

He found two more details in the session transcripts. The muse-special turn carries a signature tagged gpt_responses_v1 with an encrypted payload starting with gAAAAA, a prefix OpenAI uses. Its tool call IDs are call_ plus 24 mixed-case characters, while every Avocado session in the logs prints call_ plus 32 hex characters. From these he concludes that muse-special is possibly an OpenAI model or OpenAI’s Responses API. The files don’t show which GPT model it is or why the subagent picked it.

What the runtime can call

The catalogue that ships with Muse’s agent daemon, called hatch, lists about 15 versions of Avocado. Next to them sit Claude Opus 4.6, 4.7 and 4.8, Sonnet 4.6 and Haiku 4.5, GPT-5.5 and GPT-5.6 variants via OpenAI, Azure and Codex, and Kimi K3 through Fireworks and Meta-hosted routes. Pete notes that a shipped ID means the runtime can address the model. It doesn’t mean the model was ever used.

Claude support goes further than model IDs. The daemon includes a full Anthropic client with request handling, prompt conversion and streaming parsers, in files such as anthropic/request_flow.rs, anthropic/convert_prompt.rs and anthropic/parse_sse_stream.rs. There are API key files for Anthropic, OpenAI and others, and only the inference-proxy service can read them. The runtime env also sets JARVIS_ANTHROPIC_BASE_URL_REVPROXY_OVERRIDE=0, and the comment next to it calls this a live kill switch, not stale config.

Pete offers two guesses about why all of this ships. One is that an OpenAI or Anthropic model does a better job at certain tasks Muse can’t handle yet, so Meta routes those tasks selectively. The other is that the VMs are built to A/B test model responses and tool calls for distillation and RL. Meta’s own launch post for Muse Spark admitted performance gaps in long-horizon agentic systems and coding workflows, which would fit the first guess. His firmer point is that the model behind Muse is a server-side choice, and Meta can change routing without asking users. Still, in his VM that capability was used only once.

Is Meta distilling?

Pete’s short answer is no, and the reason is in how OpenAI handles reasoning. With muse-special, the raw chain of thought comes back encrypted. The daemon stores that blob and sends it back to Azure on the next turn, so the model can pick up its own reasoning without the client ever reading it. The binary says explicitly that encrypted reasoning cannot use the RL completion-server override.

So Meta sees only the reply, the tool calls, and a short reasoning summary when OpenAI or Anthropic returns one. The RL server refuses the encrypted blobs. Pete found no sign that Meta copies OpenAI or Anthropic weights.

Avocado sessions work differently. Their thinking text goes straight into the transcript with an empty signature and is available for RL use. Muse’s privacy note and the repo both indicate that conversations can be used to develop AI at Meta unless the user opts out.