Meta 的 Muse 似乎使用了名为 muse-special 的 OpenAI 模型。
Meta's Muse appears to use an OpenAI model labeled muse-special

原始链接: https://mouse.dev/blog/muse-special/

继此前对 Meta“Muse”项目的调查之后,作者分析了 Muse 文件系统,以确定该平台是否使用了 OpenAI 或 Claude 等外部模型。 在日志中发现一个标记为 `azure/muse-special` 的会话(这不同于 Meta 标准的“Avocado”模型)后,作者发现了一份已发布模型 ID 的目录,其中包含各种版本的 GPT 和 Claude。加密载荷和特定工具调用格式等技术指标表明,`muse-special` 很可能是通过 Azure 路由的 OpenAI 模型。 这些外部客户端和终止开关配置的存在表明,Meta 维护着一套基础设施,用于进行 A/B 测试或将任务选择性地路由至前沿模型。然而,作者得出的结论是,Meta 并没有利用这些外部会话进行模型蒸馏;来自外部提供商的原始思维链(chain-of-thought)保持加密状态,Meta 的强化学习服务器无法访问,而 Meta 专有的 Avocado 模型则被明确用于训练。 最终,这项调查揭示了一个灵活的服务器端架构,允许 Meta 动态切换模型。作者称赞了该项目的技术执行力,以及 Meta 就这种复杂的代理驱动架构与社区进行的透明沟通。

一位开发者在探索 Meta “Muse” 的文件系统时发现,该工具可能通过 Azure 使用了 OpenAI 的模型。 这名开发者在 Hacker News 上发帖指出,后台运行着一个标记为 `azure/muse-special` 的模型。进一步调查发现,包括特定响应 ID、加密推理数据块以及会话时间戳在内的元数据,都与 OpenAI 的基础设施高度吻合。此外,其运行库中还包含了 Claude、GPT 和 Kimi 模型的目录,这引发了外界的质疑:为什么 Meta 在执行任务时会调用第三方提供商,而不是仅依赖自研模型。 尽管一些评论者认为这可能只是一个与 OpenAI API 兼容的自定义模型,但作者认为 Meta 内部模型通常有不同的标识方式,而该特定进程表现出了 OpenAI 后端服务的典型行为模式。另有人推测,Muse 可能是利用“路由”机制,通过外部模型来弥补自身性能的不足。Meta 尚未对此置评,但此次讨论突显了社区对于 AI 编码工具“黑箱”架构透明度的持续关注。
相关文章

原文

I found a model labeled azure/muse-special while Muse was building my website. So I dug deeper.

This is Part 2 of digging through the Muse filesystem after my article hit the front page of Hacker News this week.

In this article I focus on a model I found in my logs called muse-special, and confront the question: does Muse actually use OpenAI and Claude models behind the scenes?

A fuzzy mascot holding a sign that reads azure/muse-special

One odd session

Muse records which model each agent session uses.

Nearly every session log in my VM was routed to Meta’s internal model, called Avocado.

But one subagent used a model named azure/muse-special.

Interesting...

Figure 1. Sessions in my VM grouped by model. Everything is Avocado except a single azure/muse-special session on September 21. Click image to enlarge.

Following the name

This made me curious, so I searched across the repo inside Cursor and found this:

“GPT Responses model client via MAGI native Azure OpenAI lane.”

OK.

The model catalogue seems to list azure/muse-special then azure/gpt-5.6-sol.

So I searched my session transcripts...

Here I found two details that stood out:

  1. The signature is tagged gpt_responses_v1 and contains an encrypted payload starting with gAAAAA (which OpenAI uses).
  2. Tool call IDs used call_ followed by 24 mixed-case characters.

This was different from all the other lines that the Avocado sessions printed (call_ followed by 32 hex characters).

Figure 2. Lines from the muse-special transcript: a call_ ID in the OpenAI style and a gpt_responses_v1 signature with an encrypted gAAAAA payload. Click image to enlarge.

These little details tell me that the muse-special model is possibly an OpenAI model or OpenAI’s Responses API.

So is muse-special an alias for a GPT model served through Azure?

The files and logs don’t tell me exactly which GPT model, or why it was selected by the subagent in the first place, but let’s take a step back and explore further...

The model catalogue

The broader model catalogue that is shipped with Muse’s agent daemon lists about 15 versions of Avocado, plus:

  • Claude Opus 4.6 / 4.7 / 4.8
  • Sonnet 4.6 and Haiku 4.5
  • GPT-5.5 and GPT-5.6 variants via OpenAI, Azure and Codex
  • Kimi K3 through Fireworks and Meta-hosted routes
Figure 3. My summary of the model IDs shipped in the hatch daemon, grouped by family. A shipped ID means the runtime can address it, not that it was used. Click image to enlarge.

The Anthropic plumbing

The Claude support goes beyond just the model ID and includes an Anthropic client with request handling, prompt conversion and streaming parsers:

  • anthropic/request_flow.rs
  • anthropic/convert_prompt.rs
  • anthropic/parse_sse_stream.rs

OK, so now we’re kind of wondering... why?

There are API key files present for Anthropic, OpenAI, etc., with access restricted to the inference-proxy service.

...But there’s also a proxy kill-switch setting in the env.

Figure 4. JARVIS_ANTHROPIC_BASE_URL_REVPROXY_OVERRIDE=0 in the runtime env. The comment calls it a live kill switch, not stale config. Click image to enlarge.

Why ship all of this?

Now, there are a few reasons for this, I guess.

  1. The first would be that an OpenAI or Anthropic model just does a superior job at a certain task that Muse can’t fulfill right now, and they selectively route for that.
  2. The second is that all these VMs are shipped with the ability to A/B test model responses, tool calls, etc. for the purpose of distillation and RL.

Distillation or RL? Maybe. Idk.

This leads us to the truth, which is that the model behind Muse is ultimately a server-side choice.

The runtime has clients for multiple providers, which gives Meta the ability to change routing without asking users.

In my case there was only a single outlier session that didn’t use the Avocado (Meta) model, but the infra is there to.

Wait, so is Meta distilling from the other frontier labs?

(Getting technical. tl;dr: No.)

With the muse-special model the raw reasoning is encrypted. The daemon stores it to send back to Azure on the following turn. In the binary it explicitly says that the encrypted reasoning cannot use the RL completion-server override.

So what Meta can see here is only the reply, the tool calls, and a short reasoning summary when OpenAI/Anthropic returns one. The raw chain of thought is encrypted and the RL server refuses those blobs. There is no indication that Meta copies OpenAI or Anthropic weights.

Avocado models are treated differently, however. The thinking text is written directly into the transcript, with an empty signature, and available for RL use.

So Avocado models, according to the privacy note and repo, do indicate that conversations can be used to develop AI at Meta unless you opt out. (Makes sense.)

Closing thoughts

This is my own exploration of what has been a very cool release from Meta.

My best guess is that muse-special is an OpenAI model served through Azure.

Whatever you think of Meta, the talent they brought onto this project deserves credit. They took a different approach in a world full of chatbots and search bars, and the exec team’s response to my first article, which got some eyeballs, has been pretty amazing too, as has their willingness to reach out to a nobody and explain their thinking.

It’s not every day you get to look inside the filesystem of a product that could reach hundreds of millions of people.

Seeing inside a runtime cell gives us an early look at where this whole personal agent thing might be going, and it’s been really fascinating to read through all of it this week.

If you worked on Muse at all, please feel free to reach out. I’d love to learn more and perhaps contribute.

Things seem to be moving fast. Not really breaking, yet.

pete at mouse dot dev

-Pete

@heypeterjames
联系我们 contact @ memedata.com