Muse Spark 1.3 API pricingでまず目に入るのは、入力100万トークンあたり$1.25、出力100万トークンあたり$4.25という数字です。予算策定の出発点としては使えますが、公開情報のすべてに1.3専用の料金表が明記されているわけではありません。Metaは1.2と同じ料金だと説明している一方、一部のカタログには先行バージョンの行が残っています。より安価なContributorについては1.3での扱いがさらに不確かで、データ利用面のトレードオフも伴います。
現時点で予算に使える料金
Muse Spark 1.3は2026年9月2日にリリースされ、Muse CodeとMeta Model APIから利用可能になりました。Metaのローンチ資料では、新バージョンの料金は前世代と同一とされています。Model Price Watchの9月5日付料金記録によると、Meta自身の料金ページを確認した結果、Standard tierの料金は以下のとおりです。
| トークン種別 | 現行の見積もり料金 | 確度と対象範囲 |
|---|---|---|
| 入力 | 100万トークンあたり$1.25 | Meta Model APIのStandard料金として報告 |
| 出力 | 100万トークンあたり$4.25 | Meta Model APIのStandard料金として報告 |
| キャッシュ済み入力 | 100万トークンあたり$0.15 | キャッシュ読み出し料金として報告 |
単価の基準は100万トークンであり、1,000トークンではありません。トラッカーのブレンド単価は入力:出力を3:1として約100万トークンあたり$2.00ですが、以下の試算では5:1のワークロード構成を採用しています。なお、トラッカーはStandard tierに長文コンテキスト向けの追加料金はないと報告しています。
ただし、重要な留保があります。AI on Macの技術レビューでは、公開開発者カタログに完全な1.3料金行ではなく、Muse Spark 1.2が依然として表示されていることを確認しています。同レビューは、Metaが料金据え置きと説明していることから$1.25/$4.25が1.3でも妥当な想定だと結論づけていますが、数値の裏付けは間接的でした。
実務上の答え:初期見積もりでは入力$1.25、出力$4.25を使い、本番トラフィックを移す前にMetaの最新料金表を確認してください。第三者サイトに掲載されているからといって、恒久的に保証された1.3料金として扱うべきではありません。
3つのワークロードで料金を試算
計算式はシンプルです。
input millions × input rate + output millions × output rate
| ワークロード | 入力 | 出力 | Standardの見積もり | Contributorの参考値* |
|---|---|---|---|---|
| 軽量 | 1M | 0.2M | $2.10 | $0.14 |
| 中規模 | 10M | 2M | $21.00 | $1.40 |
| 高負荷 | 100M | 20M | $210.00 | $14.00 |
\*Contributor列は、Model Price Watchが報告するMuse Spark 1.2の参考料金、入力100万トークンあたり$0.10、出力100万トークンあたり$0.20で算出しています。1.3のContributor料金が確認されたわけではありません。
これらの例は入力:出力を固定の5:1で計算しています。キャッシュヒット、リトライ、推論出力、ツール呼び出しループによって、実際の請求額は大きく変わり得ます。同じリポジトリや指示プレフィックスを繰り返し読むエージェントでは、表面的な入力単価よりキャッシュ挙動のほうが重要になる場合もあります。
Contributorは単なる割引ではなく、データポリシーの選択
Contributor tierは、数字だけ見れば魅力的です。Model Price WatchはMuse Spark 1.2について、入力100万トークンあたり約$0.10、出力100万トークンあたり約$0.20と報告しています。また、低価格tierのレート制限はStandardの毎分3,000リクエストに対し毎分100リクエストと大幅に低く、データ利用規約も異なると説明しています。
そのため、Contributorを無条件に本番の標準選択肢にするのは適切ではありません。データポリシーが独自コード、顧客記録、規制対象ワークロードと衝突するなら、トークン料金が安くても意味を失います。
本記事で確認した証拠からは、1.3 Contributor SKUの存在、最終料金、現時点の制限はいずれも確定できません。評価するなら、別個の調達オプションとして扱うのが安全です。
- モデルカタログに1.3 Contributorの識別子が実際に表示されているか確認する。
- 非公開データを送る前に、現行のデータ利用・学習に関する文言を読む。
- エージェントの並行実行数に対し、毎分リクエスト数と毎分トークン数の制限を確認する。
- 同一のプロンプトとツールで、StandardとContributorに同じワークロードを実行する。
- トークン単価だけでなく、成功したタスク全体のコストを比較する。
r/opencodeのユーザー投稿を見ると、ポリシーの問題が机上の話ではなく運用上の問題である理由がわかります。u/MorpheusN_は公開データを対象にモデルを使った経験を述べ、速度を評価する一方、Metaのデータ取り扱いと厳しいガードレールへの懸念も挙げています。このスレッドには正式なプライバシー分析は含まれないため、特定の保持ポリシーの証明ではなく、ユーザーが抱いている懸念の証拠として読むべきです。
「最近のClaude codeより約50倍速い」 — 同じRedditスレッドのu/Routine-Gas-8264。管理されたベンチマークではなく、検証されていないユーザーの主張です。
APIリリースで実際に利用できること
Metaの公式Muse Spark 1.3発表は、長期にわたるエージェント作業、コーディング、ツール利用、マルチタスク向けにこのモデルを位置付けています。リリースはMuse CodeとMeta Model APIで利用できます。
確認できる実用上の特性は4つあります。
- エージェント実行:Metaによると、1.3は長く続く目標を維持し、計画の欠落から回復し、必要なら確認を求め、影響の大きい操作を実行前に確認するよう訓練されています。
- コーディング:Metaは、リポジトリ規模の開発やツール駆動のコーディングワークフローで1.2から改善したと報告しています。
- マルチモーダル入力:対応フォーマットやエンドポイントが有効だと決めつけず、現行APIドキュメントで確認してください。
- 長いコンテキスト:ローンチ時の評価は100万トークン帯に達していますが、評価の範囲と、本番APIで保証される上限は同じではありません。
モデル識別子はMetaの最新開発者カタログからコピーしてください。プロバイダーのカタログ、直接API、アグリゲーターでは識別子が異なることがあります。
AI on Macのレビューは、ローンチ時点でmax reasoningが追加の安全性テスト待ちだったと指摘しています。アプリケーションがこれに依存するなら、発表時の予定が現在も有効だと仮定せず、ライブエンドポイントをテストしてください。
ワークロード選定で根拠にできること
まずMuse Spark 1.3を試すべきなのは、洗練された一発回答よりも、ツール利用、継続的なコンテキスト、コーディングの信頼性が重要なワークフローです。Meta自身の比較では、Muse Spark 1.2よりツール呼び出しが約20%少なく、トークン使用量が25%少ないとされています。ただしこれはベンダー側の比較なので、独立したコスト保証ではなく、本番で検証すべき仮説として扱うべきです。
ユーザーからの情報も大筋では同じ方向を示しますが、内容にはばらつきがあります。Redditスレッドでu/MorpheusN_は、Muse Spark 1.3の「大規模Webリサーチ」、レビュー、分類、ツール利用の生の速度を評価しました。一方で、厳格すぎる拒否、ネイティブのLinuxツールではなくPythonを使いすぎること、ニュアンスの弱さを批判しています。こうした所見は逸話的であり、ハーネス、プラン、タスクに大きく左右される可能性があります。
| ワークロード | 初期判断 | 理由 |
|---|---|---|
| 長時間稼働するコーディングエージェント | 1.3を試験導入 | リリースの重点と、Metaによるツール・トークン比較がこの用途に合う |
| 公開データを対象とする大量リサーチ | 非機密データに限りContributorをテスト | 低い参考料金は重要になり得るが、データ規約と制限も重要 |
| 非公開リポジトリ | Standardまたは承認済みエンタープライズ経路から開始 | 未確認の割引と引き換えにガバナンスの確実性を手放さない |
| ニュアンスが求められる文章作成・説明 | 自動的な改善と見なさない | 初期ユーザー評価は割れており、1.3は実行とエージェントを中心に最適化されている |
| 既存の1.2本番エージェント | 切り替え前に回帰テスト | 確認動作、ツール呼び出し頻度、拒否パターンが変わる可能性がある |
ベンチマークは購入判断ではなく、検証材料として読む
ローンチ時のベンチマークは幅広いものですが、行数の多さよりも証拠の状態が重要です。AI on Macのレビューは、Metaによる実行結果、ローンチ報告、公開リーダーボードの確認結果を分けて扱っています。9月2日に確認した時点で、複数の1.3の結果は該当する独立リーダーボードにまだ明確に反映されていませんでした。
| 能力 | 報告された1.3の結果 | 引用した確認時点での証拠状況 |
|---|---|---|
| エージェントと業務成果物のタスク | GDPval-AA v2 1,754 Elo、JobBench 64.9、OSWorld 2.0 66.9 | ローンチ報告。再確認した公開ページには1.3のGDPval行が見当たらなかった |
| コーディングとツール利用 | DeepSWE v1.1 75.4%、SWE Atlas 59.4、Terminal-Bench 2.1 88.8% | Metaまたはローンチ時の報告。公開リーダーボードはまだ同期されていなかった |
| 長文コンテキストの検索・取得 | MRCR v2は256K–512Kで98.5、512K–1Mで98.1 | ローンチ時に報告された検索・取得評価であり、一般的な推論テストではない |
これらのベンチマークは異なる能力を測定しており、平均化や横断比較をすべきではありません。検索・取得スコア98.1は、任意の100万トークン規模の統合処理でも同等の信頼性があることを示すものではありません。
エージェントのベンチマーク結果はハーネスに依存します。自分のリポジトリでテストし、完了率、介入回数、ツール呼び出し、トークン数、レイテンシ、実効コストを追跡してください。
移行判断:1.3、1.2、それとも見送るか
すでに1.2を運用している場合、1.3への移行は自動的に決まるものではありません。まずは次の条件でカナリアテストを実施してください。
- 失敗からの復旧ケースを少なくとも2件含む、代表的なリポジトリタスクを10件用意する。
- ツール定義、システムプロンプト、コンテキスト予算、タイムアウトを同じにする。
- Contributorの割引で品質低下が見えなくならないよう、最初はStandard tierの料金で比較する。
- 成功率、ツール呼び出し、出力トークン、介入回数、レイテンシ、コストを測定する。
- 拒否、確認要求、コンパイルは通るものの無関係な挙動まで変える編集を確認する。
選ぶべきなのはトークン単価が低いtierではなく、成功タスクあたりのコストが低いtierです。Contributorが最も適するのは、公開データを使う高ボリュームかつ低機密性のワークロードです。逆に、現在のtierのデータ規約のもとで共有する準備ができていない情報をプロンプトや出力に含むワークフローでは、Contributorを避ける理由が強くなります。
Muse Spark 1.3 API料金のFAQ
$1.25/$4.25は1.3で確認済みの料金ですか?
これは現時点で最も有力なStandard tierの予算用数値です。入力100万トークンあたり$1.25、出力100万トークンあたり$4.25で、キャッシュ済み入力は$0.15と報告されています。一部の公開カタログは完全な1.3エントリーではなく1.2の行を表示しているため、Metaの最新料金表を確認してください。
1.3 Contributorの料金は確認されていますか?
本記事で確認した証拠からは、確認されていません。広く引用される入力$0.10、出力$0.20は、Model Price Watchが報告するMuse Spark 1.2 Contributorの参考料金であり、1.3の確定料金ではありません。現行プロバイダーカタログに表示され、データ利用規約が明確になるまでは、1.3 Contributorの掲載情報を暫定的なものとして扱ってください。
キャッシュ済み入力は安くなりますか?
はい。現行のStandard参考料金では、キャッシュ済み入力は100万トークンあたり$0.15とされています。ただし、キャッシュの対象条件、保持期間、実際のヒット率も請求額に影響します。繰り返し使うプレフィックスがすべてキャッシュされると想定せず、リクエストログから見積もってください。
100万トークンのコンテキスト上限はAPIで保証されていますか?
Metaのローンチ評価は100万トークン帯に達していますが、この結果は本番APIの上限を保証するものではありません。この前提で設計する前に、ライブエンドポイントの仕様を確認してください。
Muse Spark 1.3は1.2より優れていますか?
新規の長期コーディングまたはエージェントワークフローでは、最初に試す候補としてより合理的です。ただし既存の1.2システムでは、プロンプトを変えなくてもツール呼び出し頻度、確認動作、拒否パターン、出力スタイルが変わる可能性があるため、回帰テストが必要です。
Contributor tierを非公開のソースコードに使えますか?
低価格だからといって適切だと考えるべきではありません。現行のデータ利用、学習、保持、セキュリティ、レート制限に関する規約をMetaに確認してください。規約が要件を満たさないなら、リポジトリで承認されたtierを使うか、非機密データのワークロードに限定してください。
1.3はStandard料金で見積もり、ライブのMetaカタログでSKUとデータ規約が確認できるまでは、Contributorによる節約分を上振れ要因として扱うのが妥当です。