Muse logs point to an OpenAI model behind one session

Of all the agent sessions logged in one user's Muse VM, exactly one skipped Meta's own model, and its transcript looks a lot like OpenAI output. Pete, writing on Mouse, found that subagent labeled azure/muse-special among sessions that otherwise ran on Avocado, and his best guess is that it is an OpenAI model served through Azure.

At a glance

• A single subagent session on September 21 was routed to azure/muse-special, while nearly every other session in the author's VM ran on Avocado, Meta's internal model.
• The evidence is in the formatting: a gpt_responses_v1 signature with an encrypted payload starting gAAAAA, a prefix OpenAI uses, and tool call IDs of 24 mixed-case characters instead of Avocado's 32 hex characters.
• The logs do not say which GPT model sits behind the label or why the subagent picked it, and a model ID in the catalogue proves only that Muse can call it.

If you have not been following: Pete's first article about digging through the Muse filesystem reached the front page of Hacker News this week, and this is Part 2. He noticed the odd label while Muse was building his website. He then set out to check whether Muse sends work to OpenAI and Claude models behind the scenes.

Every session in the log ran on Avocado except one, dated September 21

Muse records which model each agent session uses. When Pete grouped the sessions in his VM by model, nearly all of them had gone to Avocado, Meta's internal model. The exception was a single subagent session on September 21 that used a model named azure/muse-special. Everything else in his chart of sessions by model is Avocado.

He searched the repo inside Cursor for that name and found a line describing a "GPT Responses model client via MAGI native Azure OpenAI lane." In the model catalogue, azure/muse-special appears just before azure/gpt-5.6-sol. The files and logs do not say which GPT model the alias points to, and they do not say why the subagent chose it.

The muse-special transcript uses OpenAI's signature and call ID formats

After finding the catalogue entry, Pete searched his session transcripts for muse-special, and two details stood out. The reasoning signature is tagged gpt_responses_v1 and holds an encrypted payload that starts with gAAAAA, a prefix OpenAI uses. The tool call IDs follow the pattern call_ plus 24 mixed-case characters. His post shows both lines in a screenshot from the transcript.

The Avocado sessions printed something different: call_ followed by 32 hex characters. From these details, Pete concludes that muse-special is possibly an OpenAI model, or OpenAI's Responses API. The session log never names the model outright, so he presents the identification as a best guess rather than a finding.

The daemon's catalogue lists about 15 Avocado versions alongside Claude, GPT and Kimi

The broader model catalogue shipped with Muse's agent daemon lists about 15 versions of Avocado. Alongside them are Claude Opus 4.6, 4.7 and 4.8, Sonnet 4.6 and Haiku 4.5. It also lists GPT-5.5 and GPT-5.6 variants via OpenAI, Azure and Codex, and Kimi K3 through Fireworks and Meta-hosted routes.

A shipped ID means the runtime can address a model, not that the model was used. The Claude support goes further than an ID, though. There is a full Anthropic client with request handling, prompt conversion and streaming parsers, in anthropic/request_flow.rs, anthropic/convert_prompt.rs and anthropic/parse_sse_stream.rs.

There are API key files for Anthropic, OpenAI and other providers, and only the inference-proxy service can read them. The runtime env also sets JARVIS_ANTHROPIC_BASE_URL_REVPROXY_OVERRIDE=0, and a comment calls it a live kill switch rather than stale config.

Pete offers two explanations for shipping clients for other providers

Pete offers two guesses for why the runtime carries all of this. One is that an OpenAI or Anthropic model may do certain tasks better than Muse can right now, so Muse routes those tasks selectively. The other is that the VMs ship ready to A/B test model responses and tool calls for distillation (training one model on another's outputs) and RL.

His own verdict on the second option is "Maybe. Idk." What he does treat as settled is that the model behind Muse is ultimately a server-side choice. Because the runtime has clients for several providers, Meta can change routing without asking users. In his VM only one outlier session left Avocado, but the infrastructure for more is in place.

Encrypted reasoning from muse-special goes back to Azure and stays out of RL

On distillation, Pete's answer is no. With muse-special, the raw reasoning arrives encrypted. The daemon stores it and sends it back to Azure on the following turn. The binary says explicitly that encrypted reasoning cannot use the RL completion-server override.

Think of a sealed envelope that Meta has to hand back to OpenAI at each meeting but can never open. What Meta does see is the reply, the tool calls, and a short reasoning summary when OpenAI or Anthropic returns one. Pete finds no sign that Meta copies OpenAI or Anthropic weights.

Avocado is handled differently. Its thinking text is written straight into the transcript with an empty signature, and it is available for RL use. That matches the privacy note and the repo, which indicate that conversations can be used to develop AI at Meta unless you opt out.

The whole case rests on one outlier session, and the logs name neither the GPT model nor the reason the subagent picked it. In our view, the routing design is the more telling detail: with clients for several providers and a live kill switch already in the runtime, the choice of model appears to sit entirely on Meta's servers.

Checking other Muse VMs

The obvious next test is other users' logs, and whether their session lists show muse-special, Claude or GPT entries next to Avocado. Pete has asked people who worked on Muse to get in touch and says he would like to contribute. He writes that things seem to be moving fast. It is not stated when, or whether, Meta will explain what the muse-special label stands for.