MetaのMuseはOpenAIモデル「muse-special」を使用しているようです

Museが私のウェブサイトを構築している間に、azure/muse-specialというラベルのモデルを見つけました。それで、さらに深く掘り下げました。これは、今週私の記事がHacker Newsのフロントページに掲載された後、Museのファイルシステムを掘り下げるパート2です。この記事では、muse-specialと呼ばれるモデルに焦点を当て、Museは実際に舞台裏でOpenAIとClaudeモデルを使用しているのかという疑問に直面します。Museが記録する奇妙なセッションの1つは、各エージェントセッションがどのモデルを使用するかを記録しています。私のVMのほぼすべてのセッションログは、Metaの内部モデルであるAvocadoにルーティングされていました。しかし、1つのサブエージェントがmuse-specialという名前のモデルを使用しました。興味深い...図1. VM内のセッションをモデル別にグループ化。すべてAvocadoですが、9月21日には1つのazure/muse-specialセッションがあります。画像をクリックして拡大します。名前を追うこれが私に好奇心を抱かせたので、Cursor内のリポジトリ全体を検索したところ、これが見つかりました。「MAGIネイティブAzure OpenAIレーン経由のGPTレスポンスモデルクライアント」。OK。モデルカタログは、azure/muse-special、次にazure/gpt-5.6-solをリストしているようです。それで、セッショントランスクリプトを検索しました...ここで、際立った2つの詳細が見つかりました。署名はgpt_responses_v1としてタグ付けされており、(OpenAIが使用する)gAAAAAで始まる暗号化されたペイロードが含まれています。ツール呼び出しIDは、24文字の英数字が続くcall_を使用しました。これは、Avocadoセッションが印刷した他のすべての行とは異なっていました（32文字の16進数文字が続くcall_）。図2. muse-specialトランスクリプトからの行：OpenAIスタイルのcall_ IDと、暗号化されたgAAAAAペイロードを持つgpt_responses_v1署名。画像をクリックして拡大します。これらの小さな詳細は、muse-specialモデルがOpenAIモデルまたはOpenAIのレスポンスAPIである可能性が高いことを示しています。では、muse-specialはAzure経由で提供されるGPTモデルのエイリアスなのでしょうか？ファイルとログは、それが正確にどのGPTモデルであるか、またはなぜサブエージェントによって最初に選択されたのかを正確には教えてくれませんが、一歩引いてさらに探求してみましょう...モデルカタログMuseのエージェントデーモンにバンドルされているより広範なモデルカタログは、約15バージョンのAvocadoに加えて、以下をリストしています：Claude Opus 4.6 / 4.7 / 4.8 Sonnet 4.6 および Haiku 4.5 GPT-5.5 および GPT-5.6 バリアント（OpenAI、Azure、Codex経由） Kimi K3（FireworksおよびMetaホストルート経由）図3. hatchデーモンに出荷されたモデルIDの要約（ファミリー別にグループ化）。出荷されたIDは、ランタイムがそれにアドレス指定できることを意味し、使用されたことを意味するわけではありません。画像をクリックして拡大します。Anthropicの配線Claudeのサポートは、モデルIDを超えており、Anthropicクライアント（リクエスト処理、プロンプト変換、ストリーミングパーサーを含む）が含まれています：anthropic/request_flow.rs anthropic/convert_prompt.rs anthropic/parse_sse_stream.rs OK、それで、なぜ？と疑問に思っています。Anthropic、OpenAIなどのAPIキーファイルがあり、アクセスは推論プロキシサービスに制限されています。...しかし、envにはプロキシキルスイッチ設定もあります。図4. ランタイムenvのJARVIS_ANTHROPIC_BASE_URL_REVPROXY_OVERRIDE=0。コメントでは、これは古い設定ではなく、ライブキルスイッチと呼んでいます。画像をクリックして拡大します。なぜこれらすべてを出荷するのか？さて、これにはいくつかの理由があると思います。最初の理由は、OpenAIまたはAnthropicモデルが、Museが現在満たせない特定のタスクで優れたパフォーマンスを発揮し、それに対して選択的にルーティングしていることです。2番目の理由は、これらのVMはすべて、蒸留とRLの目的でモデル応答、ツール呼び出しなどのA/Bテスト機能とともに出荷されていることです。蒸留またはRL？たぶん。わかりません。これは、Museの背後にあるモデルは最終的にサーバーサイドの選択であるという真実に私たちを導きます。ランタイムには複数のプロバイダーのクライアントがあるため、Metaはユーザーに尋ねることなくルーティングを変更できます。私の場合は、Avocado（Meta）モデルを使用しなかったのは単一の異常なセッションだけでしたが、インフラストラクチャは存在します。Metaは蒸留していますか？待てよ、Metaは他のフロンティアラボから蒸留しているのか？（技術的になります。tl;dr：いいえ。）muse-specialモデルでは、生の推論は暗号化されています。デーモンはそれを次のターンでAzureに送信するために保存します。バイナリでは、暗号化された推論はRL完了サーバーのオーバーライドを使用できないと明示的に記載されています。したがって、Metaが見ることができるのは、応答、ツール呼び出し、およびOpenAI/Anthropicがそれを返したときの短い推論の要約のみです。生の思考連鎖は暗号化されており、RLサーバーはそれらのブロブを拒否します。MetaがOpenAIまたはAnthropicの重みをコピーしたという兆候はありません。ただし、Avocadoモデルは異なるように扱われます。思考テキストはトランスクリプトに直接書き込まれ、署名は空で、RLで使用できます。したがって、Avocadoモデルは、プライバシーノートとリポジトリによると、オプトアウトしない限り、会話がMetaでAIを開発するために使用できることを示しています。（理にかなっています。）締めくくりこれは、Metaからの非常にクールなリリースであったものについての私の個人的な探求です。私の最良の推測では、muse-specialはAzure経由で提供されるOpenAIモデルです。Metaについてどう思うにしても、このプロジェクトに携わった才能は称賛に値します。彼らはチャットボットと検索バーに満ちた世界で異なるアプローチを取りました。そして、私の最初の記事に対する経営陣の反応は、かなりの注目を集めましたが、彼らがノーネームの私に連絡して考えを説明してくれたことも素晴らしかったです。数百万人もの人々にリーチする可能性のある製品のファイルシステムを覗くことができるのは、日常茶飯事ではありません。ランタイムセルの中を見ることは、このパーソナルエージェントというものがどこに向かっているのかを早期に垣間見ることができ、今週はずっとそれを読むのは非常に興味深かったです。Museに少しでも関わった方は、お気軽にご連絡ください。もっと学び、貢献できれば幸いです。物事は急速に進んでいるようです。まだ本当にブレークスルーではありません。pete at mouse dot dev -Pete @heypeterjames スクリーンショット ← → 閉じる