Muse Code：誰製作的、費用多少，以及目前是哪個版本

Muse Code是 Meta 專為終端機與 CI 打造的程式編寫代理，並為 Muse Spark 模型系列而生，而對任何來到這裡的人來說，真正重要的兩個版本是Muse Spark 1.3——當前世代，日期為 2026 年 9 月 2 日——以及Muse Spark 1.2，這仍是除非你另行指定，否則 CLI 會選用的版本。Muse Code 以原生muse二進位檔安裝，可以互動方式或無介面模式執行，並有三種販售方式：三種月費方案，分別為 $5.00、$15.00 與 $50.00，以及在 Meta Model API 上按用量計費的 Token 計價，Standard 級別為每百萬輸入 Token $1.25、每百萬輸出 Token $4.25。再往前一個世代，Muse Spark 1.1，仍在同一級別以相同費率提供服務。

請把這一頁當作參考頁面來讀，而不是當作新聞。Muse Code 本身並不是什麼值得報導的新東西：Meta 在 2026 年 8 月 5 日以 beta 版推出，並於 2026 年 8 月 31 日結束 beta，而本頁使用這些日期，是為了把這個模型定位在時間軸上，而不是為了發布它。本頁之所以存在，是因為我們在 2026 年 9 月 28 日第一手測量到的長期搜尋需求：單純的查詢「muse code」在過去 28 天內帶來 4,547 次曝光，點擊數為零，而同一意圖的商業化拼法——「muse code free」、「muse code plan」、「muse code plans」、「muse code free tier」、「muse code 1.3」——另外帶來 124 次曝光，點擊數同樣為零。讀者問的是四個具體問題。本頁依序回答這些問題，資料來自 Meta 自家的文件，並且會明確指出某項數字是出自 Meta，而不是出自獨立評測者。

如果你真正需要的，是對這個代理行為的評測，或是與另一個 coding harness 的正面對決，那這裡不是那樣的頁面。那些文章這個部落格上已經有了，而值得你花時間閱讀的幾篇，連結放在最後。

Muse Code 是什麼，以及是誰製作的

供應商的定義只有一句話：「Muse Code 是 Meta 專為終端機與 CI 打造的編碼代理，並為 Muse Spark 而生。」它不是函式庫，不是聊天介面，也不是模型——它是一個執行框架。你在專案目錄內執行它；它會規劃、編輯檔案並執行命令來完成任務，且從首次執行起便啟用核准機制與作業系統沙箱。

Meta 將 Muse Code 與 Meta Model API 定位為通往同一個底層模型的兩條路徑：當你在打造自己的代理或應用程式時，直接呼叫 API；當你想要一個現成的編碼代理，能在命令列上或管線內使用時，就執行 Muse Code。這項區別對定價很重要，因為訂閱買的是執行框架，而 API 金鑰則是按 token 另行計費。

安裝方式採用單行安裝程式，而兩家廠商的介面對於這個字串並不完全一致：

• macOS 與 Linux —— curl -fsSL https://dev.meta.ai/install.sh | sh（在文件頁面上），以及結尾為 | bash 的相同指令（在行銷頁面與兩篇研究部落格文章上）

• Windows — irm https://dev.meta.ai/install.ps1 | iex，僅發佈於文件頁面上

• 驗證 — muse --version，然後在專案目錄中執行 muse 以啟動互動式工作階段

• 首次執行 — 系統會要求你信任工作區（這會載入其技能、規則與鉤子），並透過瀏覽器登入或使用 API 金鑰進行驗證；在 CI 中，你則設定 META_API_KEY 來代替

• 兩種介面 — muse 用於互動式終端機 UI，muse exec "<prompt>" 用於單次非互動式執行至完成

• 從你自己的程式驅動它 — muse serve 會執行版本化的工作階段通訊協定，muse schema 會印出其 JSON schema，而 npm install @muse-code/sdk 會安裝 TypeScript 包裝器

最後一點是多數摘要都會漏掉的部分。Muse Code 不僅僅是一個 CLI：工作階段協定是一份有文件記載、具版本控制的介面，而變更記錄顯示它正被刻意擴充——工作階段可以透過協定重新命名，用戶端可以讀取每次編輯的結構化差異摘要，而驅動程式則可以設定整個工作階段範圍的推理投入預設值。

Muse Code 的費用是多少，以及免費方案問題的直白解答

目前沒有免費方案。這一點值得直截了當地說清楚，因為它是需求資料中最常被問到的商業問題，而答案毫無疑義：Muse Code 的產品頁、訂閱頁與更新日誌合起來，既沒有免費方案、沒有試用、沒有免費額度配置，也沒有受速率限制的免費取用權限。

關於那項查核，有一點要提醒。Meta 的定價文件確實用過「platform free-tier credits」這個詞一次——就在 Muse Voice Transcribe 的註記中，該註記寫道，零資料保留的轉錄服務定價與 Standard 方案相同，而且平台免費方案額度適用。Muse Voice Transcribe 是 Meta Model API 上的一項獨立產品，有其自己的按小時計費；那句話完全沒有提到 Muse Code。 如果你發現那句話被引用來當作 Muse Code 有免費方案的證據，那就是被斷章取義了。

Meta 實際公布的是三種訂閱等級，全部按月計費，外加隨用隨付的 token 計費，適用於超出方案提示詞額度的任何用量：

• 日常使用 — 每月 $5.00；可使用最新的 Muse 模型；每 5 小時 10–50 個提示，包含圖片與影片上傳；語音模式；網頁搜尋

• High Usage — 每月 $15.00；包含 Everyday 方案中的所有內容；用量是 Everyday 的 5 倍；更多提示詞；更多多模態輸入

• Power Usage — 每月 $50.00；High Usage 方案中的所有內容；20 倍的 Everyday 使用額度；擴充提示詞；搶先體驗新功能；更高的檔案上傳量

• 標準 token 費率 —— 每百萬輸入 token 1.25 美元、每百萬輸出 4.25 美元、每百萬快取輸入 0.15 美元，適用於 muse-spark-1.3、muse-spark-1.2與muse-spark-1.1等版本皆一體適用

• 貢獻者權杖費率 — 每百萬輸入、輸出及快取輸入為 $0.10 / $0.20 / $0.002，適用於 muse-spark-1.3-contributor與muse-spark-1.2-contributor

標準方案與貢獻者方案恰好只有一個實質差異，而 Meta 在模型頁面和費率表上都說明了這一點：在標準方案中，你的提示與生成內容不會用於訓練 Meta 模型；在貢獻者方案中則會。產品頁面將貢獻者方案的列標示為「用於改善我們的產品」，並將標準方案的列標示為「不用於改善我們的產品」。貢獻者方案在輸入上大約便宜十二倍，在輸出上大約便宜二十一倍，這個差距大到足以讓它先是資料治理決策，再才是預算決策。

有三個定價細節很容易被忽略，而且在您評估工作負載規模之前，都很值得了解：

• 沒有長上下文溢價——Meta 的費率表明確說明這一點：無論上下文視窗幾乎是空的還是幾乎全滿，你支付的費率都相同，這很不尋常，且會實質改變長時間代理執行的成本效益

• 網頁搜尋接地會另行按量計費——每 1,000 次搜尋查詢收費 $2.50，另加請求的 token 費用，且適用於 Muse Spark 等文字模型

• 速率限制是以團隊為單位，而非以金鑰為單位——Standard 方案每分鐘 3,000 次請求和 4,000,000 個權杖，Contributor 方案每分鐘 100 次請求和 3,000,000 個權杖；在同一個團隊內使用多個金鑰不會使配額倍增

訂閱機制記載於 Meta 的訂閱頁面，且屬標準做法：升級會按比例計費並立即生效，降級則於下一個帳單週期生效，取消需在帳單日期前至少 24 小時提出，而已取消的訂閱不予退款，法律要求退款者除外。訂閱涵蓋的具體是 Muse Code CLI 憑證；額外的 API 金鑰則採隨用隨付計費。

哪個版本是目前版本：1.2.1、Muse Spark 1.3，以及兩者皆非的預設版本？

這是需求資料最強烈指出的問題——「muse code 1.3」這個查詢竟然存在——而這確實令人困惑，因為「版本」可以指三種不同的東西，而 Muse Code 三種全都發布。

• CLI 發行版本——1.2.1 是目前版本。Meta 的更新日誌將其發行版本列為 1.2.1、1.1.1、0.2.1 與 0.1.0，其中最後一個標示為「Launch version」

• 模型世代 —— Muse Spark 1.3，於 2026 年 9 月 2 日發表，Meta 的模型頁面將其描述為「最新版本……推薦用於新專案」

• CLI 的預設模型——muse-spark-1.2，於說明文件的首次執行章節中述明，並在設定頁面的模型選擇下再次提及

所以全新安裝 Muse Code 1.2.1 會執行 Muse Spark 1.2，除非你傳入 --model muse-spark-1.3，或在工作階段中途用 /models 切換。Meta 自家的快速入門頁面使用 muse-spark-1.3於每個 API 範例中，這使得這個分歧比實際上更容易被誤讀：如今 API 範例與 CLI 預設值並不是指向同一個模型。

1.2.1 的更新日誌說明的是測試框架中的變更，而非模型本身的變更，重點項目如下：

• 語音輸入在 macOS 上預設為開啟，繫結至 Option+V，並以 /voice

• 一個 /rewind指令，可將對話返回至較早的輸入，並共用雙擊 Esc 所用的選擇器

• [Image #N] 標籤會標註貼上與拖放的圖片，讓模型能依編號針對特定一張回答，且標籤與來源路徑在 resume、rewind 與 fork 後仍會保留

• 內建的 migrate 技能，可將記憶筆記與 MCP 伺服器定義從 Claude Code 或 Codex 匯入 Muse Code

• /mcp以取得已連線 MCP 伺服器及其工具的即時清單

• 新工作階段會以「自動審查」權限設定檔開啟，此設定檔授予與「詢問我」相同的存取權限，但會將符合條件的核准要求轉送給自動審查者，並在審查者無法使用時改為詢問你

• 安全性修正，其中三項屬於行為變更而非外觀調整：透過 env以及setsid 這類包裝器啟動的命令，現在會以其實際啟動的命令來審查；工作階段中途變更權限模式，會套用至已在執行的工具，並在其下次動作時生效；而「不受限制」權限設定檔現在的行為與 --yolo

在模型方面，9 月 2 日的公告明確表示，Muse Spark 1.3 是在多種不同的測試框架上訓練而成，且 Meta 所宣傳的是推理等級——「具備最大推理能力的 Muse Spark 1.3 現已在 Muse Code 與 Meta Model API 上推出」——而非單獨的基礎模型。8 月 5 日的 Muse Spark 1.2 發布文章補上了這個故事的另一半：Muse Spark 1.2 是與 Muse Code 本身共同訓練而成，採用經拒絕取樣的測試框架軌跡，並在目標、壓縮與子代理上進行配方設計，同時整合 Muse Code 工具集以最大化測試框架相容性。模型與測試框架是針對彼此開發的。

封套：上下文、模態、平台

Muse Spark 1.3、Muse Spark 1.2 與 Muse Spark 1.1 共用同一套規格範圍，而 Meta 只用表格中的一列就交代清楚：1,048,576 個詞元的上下文，輸入支援文字、圖像、影片、音訊與 PDF，輸出則僅限文字，且每個等級、每個版本皆然。

模態對等性附帶一項但書，Meta 以註腳形式發布，而這值得一再提醒，而非將其埋沒：Muse Spark 1.3 的音訊理解未獲完整支援，且包含音訊內容的要求，其回應品質可能會降低；Meta 自身的指引是音訊請使用 Muse Spark 1.2，或使用 Muse Voice Transcribe 進行專門的語音轉文字。在 CLI 中，這可以實際執行 —— --model muse-spark-1.2是已記載的覆寫選項，而預設值已經指向該處。

推理強度是測試框架層級的設定，共有八個等級，而 Meta 的設定頁面依序將它們命名為：none、minimal、low、medium、high（預設）、xhigh、max 和 ultra。該清單中有三個細節至關重要：

• max是最深層的推理等級，被描述為超越xhigh的延伸推理，且 Muse Code 在 Standard 與 Contributor 兩個方案中皆有提供

ultra是一種設定，而非模型層級：它會對應到每個供應商的最高推理努力，可以讓 Muse 進行委派，而在不支援的情況下，請求會以xhigh

• Meta 提供者不接受無，因此最低等級僅能透過在測試框架中設定的其他提供者取得

平台支援正是 Meta 兩個介面說法不一致的地方，而這個不一致雖小卻真實存在。文件頁面表示 Muse Code 以同一套程式碼在 macOS、Linux 和 Windows 上執行，並列出三項 Windows 專屬行為：PowerShell 取代 Bash，因此代理程式執行的指令會採用 PowerShell 語法和 Windows 命令列工具；沙箱可能會要求系統管理員核准，Windows 在沙箱首次初始化時可能顯示使用者帳戶控制提示，不過正常使用並不需要以系統管理員身分執行；另外有兩項功能在 Windows 上無法使用——語音輸入和工作階段訊息傳遞，而這兩項在 macOS 和 Linux 上都能運作。相較之下，產品頁面只寫著「Available for MacOS and Windows.」。這兩種說法目前都出自 Meta 自家的網站；合起來看，意思是 Windows 在支援之列，但有已記錄的落差，而 Linux 同樣受到支援，儘管行銷頁面並未提及。

另一個關於可用性的細微差別來自文件，而非行銷文案：Workflows——平行與分階段的代理協作——只有在已安裝的組建包含工作流程引擎且推出已啟用時，才會協調工作，而 Meta 明確表示它們「並非在每個組建或平台上都可用」。如果你安裝的原因正是某項工作流程功能，請確認你的組建具備該功能，而不是假設它一定會有。

Meta 所聲稱的內容，並註明測試框架與投入程度

Meta 會發布基準測試資料，因此這裡誠實的說法不是「沒有廠商基準測試」——而是「這些是廠商基準測試，且比較條件會在 Meta 有說明的地方載明」。

Meta 在行文中提出的唯一量化說法，出現在 Muse Spark 1.3 發布公告中，且其依據是內部比較，而非第三方評估：「在 Meta 工程師的比較中，它證明明顯更快、更有效率，工具呼叫次數少約 20%，token 用量少約 25%。」基準已說明——相對於 Muse Spark 1.2——而投入等級則見於公告自身的表述框架，因為該發行版本是以 Muse Spark 1.3 搭配最大推理（max reasoning）為題。未說明的是任務集、執行次數，或除了它是 Muse Code 之外的測試框架設定。請將這兩個百分比視為供應商所報告的趨勢方向，而非經測量的基準結果。

另一個已公布的结果是案例研究，而非分數，而且它是兩者中更有趣的那個。Meta 報告測試了 Muse Spark 1.2 在超過 1,000 次工具呼叫、長達 24 小時內反覆最佳化 GPU 核心的能力，並使用 Muse Code 的代理式程式設計環境來撰寫、編譯、分析效能，並對照提供的基準逐步改善核心效能。工作負載有明確名稱——NVIDIA Hopper GPU 上的 KDA 與 MLA 核心——限制條件也是：禁止使用 FLA 等第三方核心函式庫，而基準是 Triton FLA KDA 實作。一場長達 24 小時、上千次工具呼叫的執行，是一種不同於基準測試百分比的證據。它說明了在長時程目標下的持久力，卻幾乎沒有說明相對品質。

Muse Spark 1.2 與 Muse Spark 1.3 的發布圖表，將這兩款模型與一小組具名競爭對手，在代理、程式編寫、指令遵循與長脈絡評估上進行對比——DeepSWE v1.1、SWE-Atlas-QnA、Terminal-Bench 2.1 與 4.0、tau2-bench、GDPval、SciCode、IFBench、MultiChallenge 以及 AA-LCR v1.1 都出現在座標軸之列。這些圖表由廠商製作、由廠商繪製，其上所採用的競爭對手配置是 Meta 的選擇，而非中立的評測組合。基於這個理由，我們不在此重現長條圖的數值：把廠商圖表當成排行榜來解讀，正是本頁面所要避免的失敗模式。

有兩個誠實的缺口值得說明，而非粉飾：

• Meta 並未在具名任務集上，以相同投入程度公布 Muse Code 對上 Muse Spark 1.2 的正面對決比較；約 20%／25% 這個數字是最接近的東西，而它是內部比較，陳述的是效率差異，而非分數

• Meta 並未發布 CLI 的即時延遲評估，且已發布的數字中，沒有任何一項能描述在真實編輯負載下，一次工作階段實際感受如何

Artificial Analysis 獨立衡量什麼

Artificial Analysis 是目前發布涵蓋 Muse Code 的程式編碼代理量測結果的獨立評估機構，而這是與上述任何數字都不同類型的一種數字：其資料列是測試框架與模型的配對，由 AA 而非供應商進行評估。

在 Artificial Analysis Coding Agent Index 上——該頁面在其自身的結構化資料中標示為 v1.5——Muse Code 的資料列顯示：

• Muse Code 以最大推理執行 Muse Spark 1.3 — 54.3

• Muse Code 以 xhigh 推理執行 Muse Spark 1.3 — 48.3

• 同一排行榜的榜首——Claude Code 以 reasoning 模式運行 Claude Opus 5.5，拿下 66.0

關於那些數字，有兩件事比數字本身更重要。首先，max 與 xhigh 兩列之間 5.0 分的差距，是同一模型、同一測試框架下只改變了一項設定，這很有用地提醒我們：除非指明投入等級，否則「Muse Code 分數」其實定義得不夠明確。其次，這個排行榜與我們自家九月對 Muse Spark 1.3 的報導所引用的測量並不相同：較早那篇文章引用的是 Muse Spark 1.3 在 max 下為 68、xhigh 下為 64，以及 Claude Opus 5 在 xhigh 下為 68。那些數字已不再出現在現行排行榜上——目前最高的一列是 Claude Opus 5.5 在 max 下拿到 66.0，而 Muse Code 的各列則顯示 54.3 和 48.3。該指數已經修訂，受測陣容的組成也已改變。如果你還在沿用較舊的數字，它們已被取代；這兩組數字永遠不應並列引用，彷彿它們是同一項測量重複兩次所得的結果。

Muse Spark 1.3 的 AA 模型頁面又自成一獨立介面，而且其數字是由 AA 實測，而非由廠商回報：智慧指數為 48.09、Terminal-Bench 2.1 為 84.3%、GPQA Diamond 為 93.5%、HLE 為 48.7%、SciCode 為 58.8%，長上下文召回率為 83%，發布日期為 2026-09-02，上下文視窗為 1,000,000 個 token，並歸類為專有、封閉權重。請注意，這只是單一模型頁面上的一次指數修訂——AA 會發布各模型專屬的指數，而這些指數會依各自的時程修訂，因此將此頁面的數字與不同模型頁面的數字混用，並不能得到同一快照的比較。

這些都無法提供你一份配對比較。AA 的程式編寫評測列在設計上本就跨越不同測試框架——Muse Code 對上 Codex、對上 Claude Code、對上 Grok Build、對上 Kimi Code CLI——因此逐列解讀是在比較一組「測試框架－模型」配對與另一組「測試框架－模型」配對，而不是在同一個測試框架下比較兩個模型。在 Meta 尚未進行配對比較、且 AA 的排行榜也不是為了回答這個問題而打造的情況下，誠實的立場是：在相同投入程度與測試框架下，並不存在這樣的正面對決，而不是從鄰近數字拼湊出一個。

OrcaRouter 會路由什麼，以及不會路由什麼

OrcaRouter 是一個涵蓋 200 多個模型的單一端點，以各家供應商的定價原價提供、零加成，這表示這個系列是否可供應是可以查證的，而非取決於政策。今天已對照我們即時公開的模型清單查核：

• meta/muse-code — 不在目錄中。Muse Code 是一個測試框架，並非可路由的模型，我們不提供它

• meta/muse-spark-1.3 — 未收錄於目錄中

• meta/muse-spark-1.2——可路由，具備 1,048,576 詞元的上下文視窗，定價為每百萬輸入詞元 $1.25、每百萬輸出詞元 $4.25，以及每百萬快取讀取 $0.15，與 Meta 公布的費率相同

• meta/muse-spark-1.1 — 亦可路由，並採用相同三種費率

所以，在 OrcaRouter 上，實際情況是：你可以透過平常處理所有其他事務所用的同一個端點，取用已正式發布的 Muse Spark 各代模型；但你無法透過它取用 Muse Code 或目前的 1.3 世代。請把這段話單純理解為對今日型錄的描述，僅此而已；可用性會變動，模型清單才是查核的地方。

對這類工作負載而言，路由器之所以有價值，在於訂閱制無法提供给你的兩件事。第一，單一 API 金鑰就是一個路由層，當供應商效能劣化時會自動將請求容錯移轉，這在代理執行已深入數千次工具呼叫時格外重要，你寧可不要因為某個上游服務出狀況而讓它中斷。第二，請求是以描述方式定義，而非硬編碼——你可以把 Muse Spark 1.2 放在與其他任何模型相同的路由 DSL 後面，並在不變更用戶端的情況下改變由什麼來服務它。

常見的提問

CLI 的預設模型是目前的模型嗎？不是。Muse Code 的預設是muse-spark-1.2；目前世代為 Muse Spark 1.3，於 2026 年 9 月 2 日發布，你可以透過--model muse-spark-1.3或/models指令來使用。

哪種寫法才正確——「Muse Code 1.3」還是「Muse Spark 1.3」？Muse Spark 1.3。Muse Code 的版本屬於 harness 發行版，目前是 1.2.1；這兩條版本編號互不相干，而這正是查詢「muse code 1.3」會傳回令人困惑的結果的根本原因。

如果我只需要音訊輸入，應該設定哪個模型？ Muse Spark 1.2。Meta 自家的註腳指出，1.3 的音訊理解尚未完整支援，且可能降低回應品質，並建議將音訊相關工作交由 1.2 或 Muse Voice Transcribe 處理。

Contributor 層級是免費或試用層級嗎？不是，而且它不是你能自動獲得的折扣。它是 Muse Spark 從 1.2 起每個版本都提供的較低價變體，交換條件是允許以你的提示與補全內容進行訓練；1.1 世代沒有 Contributor 變體。

總結來說

Muse Code 是 Meta 的終端機與 CI 編碼代理，由 Meta 為其 Muse Spark 模型打造，以三種月費方案販售，價格為 5.00 美元、15.00 美元與 50.00 美元，沒有免費方案，並以隨用隨付的 Standard 費率為後盾：每百萬個 token 輸入 1.25 美元、輸出 4.25 美元；Contributor 費率則為同樣的 token 0.10 美元與 0.20 美元，前提是你願意讓 Meta 以它們進行訓練。目前的 CLI 發行版本是 1.2.1，目前的模型世代是 Muse Spark 1.3，而 CLI 仍預設為 Muse Spark 1.2——每當你引用分數時，都要註明版本與推理強度，因為 Muse Code 以 max 和以 xhigh 執行 Muse Spark 1.3 並不是同一種測量，而且廠商標榜的效率聲明是內部比較，而非獨立結果。

若想實際動手了解 harness 本身，請參閱我們對 Muse Code 終端機程式設計代理的逐步導覽。