Muse Spark 1.3 ट्यूटोरियल: एक व्यावहारिक डेवलपर गाइड

Meta ने 2 सितंबर, 2026 को Muse Spark 1.3 जारी किया, और अपग्रेड निर्देश एक ही पंक्ति में समा जाते हैं: मॉडल ID बदलें। इसका मतलब है कि यह वही endpoints, वही software development kit (SDK), और वही मूल्य निर्धारण उपयोग करता है।

Meta के अनुसार वह एक-पंक्ति का बदलाव आपको ऐसा मॉडल देता है जो वही कार्य लगभग 20% कम टूल कॉल्स और 25% कम टोकन के साथ पूरा करता है, Muse Spark 1.2 की तुलना में। ये संख्याएँ Meta के अपने इंजीनियरों की तुलना से आती हैं, ऐसे कार्यों पर जिनका वे नाम नहीं बताते, और बिना किसी कार्यविधि लिखित विवरण के।

यह ठीक वही तरह का दावा है जिसे दोहराने से पहले मैं जाँचना चाहता हूँ। 

इसलिए मैंने Muse Code इंस्टॉल किया, जानबूझकर एक वास्तविक ओपन सोर्स प्रोजेक्ट तोड़ा, और दोनों मॉडलों पर वही तीन कार्य चलाए।

इस Muse Code ट्यूटोरियल को आगे बढ़ाने के लिए, आपको एक Meta डेवलपर खाता, एक टर्मिनल जिसमें आप सहज हों, और Muse Code एजेंट के लिए macOS या Linux चाहिए। Windows उपयोगकर्ता अभी भी वर्तमान बीटा में वंचित हैं।

संक्षेप में

• Muse Spark 1.3 Meta का फ्लैगशिप मल्टीमॉडल रीजनिंग मॉडल है, 2 सितंबर, 2026 को जारी, 1M टोकन के कॉन्टेक्स्ट विंडो के साथ।
• Muse Code डिफ़ॉल्ट रूप से आपको muse-spark-1.3-contributor पर शुरू करता है, जिसका अर्थ है कि जब तक आप स्विच नहीं करते, Meta आपके कोड पर प्रशिक्षण करता है। प्रशिक्षण opt-out है, opt-in नहीं।
• 3 कोडिंग कार्यों पर 6 रन में, 1.3 दो पर सस्ता रहा और तीसरे पर 38% महंगा, कुल सेट पर 12% लागत वृद्धि।
• जिन 2 कार्यों पर 1.3 जीता, वहाँ मॉडल completions 23% और 32% गिरे, जो Meta के टूल-कॉल दावे से मेल खाता है। अनकैश्ड इनपुट तीनों पर घटा, लेकिन कभी 25% नहीं।
• ultra रीजनिंग स्तर कमांड-लाइन इंटरफेस (CLI) और इन-सेशन पिकर में मौजूद है, लेकिन बैकएंड इसे एक नामित फीचर गेट के साथ अस्वीकार करता है।

Muse Spark 1.3 क्या है?

Muse Spark 1.3 Meta Superintelligence Labs द्वारा 2 सितंबर, 2026 को जारी Meta का फ्लैगशिप मल्टीमॉडल रीजनिंग मॉडल है, जिसे लंबे agentic सेशंस और बड़े रिपॉज़िटरीज़ में कोडिंग के लिए बनाया गया है। यह 1,048,576 टोकन का कॉन्टेक्स्ट रखता है और टेक्स्ट, इमेज, वीडियो और फाइलें स्वीकार करता है।

Muse Spark 1.2 से छह चीजें बदलीं:

• दक्षता। Meta की आंतरिक तुलना में लगभग 20% कम टूल कॉल्स और 25% कम टोकन।
• सहयोग। अस्पष्ट प्रॉम्प्ट्स पर स्पष्टीकरण मांगता है और परिणामकारी कार्रवाइयों से पहले जाँचता है।
• मल्टीटास्किंग एक ही थ्रेड के भीतर, ताकि बीच में भेजा गया संदेश उसी कार्य से जुड़ जाए जिसे आप चाहते थे।
• लंबे निर्देशों का पालन, बहु-चरणीय कार्य में कम छूटी हुई बाधाएँ।
• अपरिवर्तनीय कार्रवाइयों पर बेहतर कैलिब्रेशन।
• क्लीनर कोडिंग शैली। अनावश्यक टर्न्स कम, कम शब्दाडंबर।

यह सब अच्छा लगता है, लेकिन Meta का प्रकाशित स्कोरकार्ड Muse Spark 1.3 को max रीजनिंग पर और Muse Spark 1.2 को xhigh पर चलाता है, और लॉन्च के समय max अभी भी gated था। 

Artificial Analysis ने शिपिंग xhigh वेरिएंट को Intelligence Index 61 और max को 62 अंक दिए। तो केवल एक अंक का अंतर।

Matt Crabtree पहले ही पूरी बेंचमार्क तालिकाएँ, मूल्य-निर्धारण ब्रेकडाउन, और यह GPT-5.6 Sol और Claude Opus 5 के मुकाबले कैसा बैठता है, अपने Muse Spark 1.3 रिलीज़ विश्लेषण में कवर कर चुके हैं। मैं उसमें से कुछ नहीं दोहरा रहा। आगे जो है वह बताता है कि जब आप इसे इंस्टॉल करते हैं और काम में लगाते हैं तो क्या होता है।

Muse Spark 1.3 तक कैसे पहुँचें

तीन रास्ते हैं, और सही वाला इस पर निर्भर करता है कि आप क्या बना रहे हैं। तालिका से चुनें, फिर मिलते-जुलते सेक्शन पर जाएँ।

Muse Code, टर्मिनल एजेंट

Muse Code Meta का टर्मिनल कोडिंग एजेंट है, macOS और Linux के लिए बीटा में। यही Muse Spark चलाने का harness है, और दोनों स्वतंत्र रूप से संस्करणित होते हैं, इसलिए muse --version आपको यह नहीं बताता कि आप किस मॉडल से बात कर रहे हैं। अपने मन में इन्हें अलग रखें।

curl -fsSL https://dev.meta.ai/install.sh | bash

यह 230 MB का एक बाइनरी खींचता है और उसे ~/.local/bin/muse पर डालता है, जो हर किसी के PATH में नहीं होता। 

फिर देखें क्या मिला:

muse --version

4 सितंबर, 2026 को मुझे मिला Muse Code 1.0.2 (1.0.2-R2040.1). 

बीटा के लिए यह कहना थोड़ा अजीब है, क्योंकि तृतीय-पक्ष टूलिंग कुछ हफ्ते पहले तक Muse Code को 0.2.1 के रूप में दस्तावेज़ित कर रही थी। जो भी संस्करण आपको मिले, उसे मिलने की तारीख के साथ पिन करें।

लेखक द्वारा स्क्रीनशॉट। एक-लाइन स्क्रिप्ट से Muse Code इंस्टॉल करना, फिर macOS पर संस्करण 1.0.2 की पुष्टि।

अब muse चलाएँ। पहली बार, इसने प्रिंट किया Not logged in. Run muse again to log in. और बाहर निकल गया। तो आप इसे दो बार चलाते हैं, जो उस तरह की छोटी बात है जो आपको लगता है कि इंस्टॉल टूट गया।

दूसरी बार चलाने पर OAuth डिवाइस फ्लो शुरू होता है। यह एक साइन-इन URL प्रिंट करता है जिसमें एक छोटा कोड होता है, वही कोड अलग से दिखाता है, और ब्राउज़र में अनुमोदन से पहले आपसे पुष्टि करने को कहता है कि दोनों मेल खाते हैं।

Sign in at this page:
  https://auth.meta.com/oauth/device/?code=XXXX-XXXX
confirm this code matches:
  XXXX-XXXX

Waiting for approval…

और फिर आपको निम्न दृश्य दिखना चाहिए: 

लेखक द्वारा स्क्रीनशॉट। Meta Model API साइन-इन फ्लो, क्रेडेंशियल जारी करने से पहले खाता विवरण की पुष्टि करता हुआ। 

ब्राउज़र साइड आपका नाम पुष्टि करता है, शर्तें स्वीकार करवाता है, और कार्ड लेता है। भुगतान स्क्रीन पर मौजूद मूल्य निर्धारण पैनल को आगे बढ़ने की बजाय वहीं पढ़ें—उसका कारण लगभग तीस सेकंड में साफ हो जाएगा।

डिफ़ॉल्ट टियर आपके कोड पर प्रशिक्षण करता है

वापस टर्मिनल में, सेशन हैडर बताता है कि आप क्या चला रहे हैं:

Muse Code 1.0.2
You are logged in.
Model set to muse-spark-1.3-contributor
└ Discounted tokens: your content, including inter-session messages, may be
  used for product improvement.

उस मॉडल नाम को फिर पढ़ें। contributor वेरिएंट, डिफ़ॉल्ट के रूप में सेट, एक नई इंस्टॉल पर, बिना किसी के पूछे।

Meta इसे छिपा नहीं रहा। खुलासा मॉडल नाम के नीचे बैठा है, भुगतान स्क्रीन contributor को DEFAULT के रूप में लेबल करती है, और स्टेटस बार काम करते समय muse-spark-1.3-contributor को दृश्य में रखता है। 

लेकिन बोझ उस अपेक्षा से उल्टा है जो अधिकतर डेवलपर रखते हैं।

यदि आप किसी क्लाइंट रिपो के अंदर Muse Code खोलते हैं और काम शुरू करते हैं, तो आपने वह कोड पहले ही एक training-eligible endpoint पर भेज दिया है। अपना पहला प्रॉम्प्ट देने से पहले स्टेटस बार जाँचें, बाद में नहीं।

लेखक द्वारा स्क्रीनशॉट। पहला Muse Code सेशन, जिसमें डिफ़ॉल्ट मॉडल muse-spark-1.3-contributor पर सेट है और नीचे product improvement का खुलासा।

स्टेटस बार रीजनिंग effort भी दिखाता है, जो मेरे लिए high पर था। xhigh नहीं, वह वेरिएंट जिसे Artificial Analysis ने बेंचमार्क किया था। जब आप अपने परिणामों की किसी भी प्रकाशित संख्या से तुलना करते हैं, तो इसे याद रखना उपयोगी है।

टियर चुनना और बदलना

/model चलाएँ और आपको चार विकल्पों और उनकी दरों के साथ एक इंटरैक्टिव पिकर मिलता है। ये आँकड़े Meta की अपनी भुगतान स्क्रीन से मेल खाते हैं:

Contributor इनपुट पर लगभग 12 गुना और आउटपुट पर 21 गुना सस्ता है।

उस छूट की कीमत आपका बौद्धिक संपदा (IP) है। Meta का शब्दांकन है "your content, including inter-session messages, may be used for product improvement," जो केवल आपके सौंपे गए कोड से अधिक को कवर करता है।

Muse Spark 1.2 के दोनों वेरिएंट अभी भी पिकर में समान कीमतों पर मौजूद हैं, जो आगे की तुलना के लिए मायने रखता है: चूँकि दरें पीढ़ियों के बीच नहीं बदलतीं, टोकन तुलना ही लागत तुलना है, कुछ भी सामान्यीकृत करने की जरूरत नहीं।

लेखक द्वारा स्क्रीनशॉट। /model पिकर जो चारों Muse Spark वेरिएंट्स के cached, input और output रेट दिखा रहा है।

Opt-out करने के लिए, muse-spark-1.3 पर ऊपर एरो करें और एंटर दबाएँ। "Discounted tokens" पंक्ति हैडर से गायब हो जाती है।

क्लाइंट कार्य के लिए, एक और सशक्त विकल्प है जो टर्मिनल में कभी दिखता नहीं। Meta कहता है कि उसने zero data retention अनुरोध स्वीकार करना शुरू कर दिया है, जो किसी टॉगल के बजाय सेल्स के माध्यम से संभाले जाते हैं। 

Retention और training अलग सवाल हैं, और एजेंसी कॉन्ट्रैक्ट्स में आमतौर पर दोनों के जवाब चाहिए होते हैं।

रेट लिमिटिंग टियर के बीच अलग तरह से काम करती है, हालांकि स्रोत इस पर असहमत हैं कि कैसे। Meta का डेवलपर ब्लॉग contributor टियर को रिक्वेस्ट काउंट के बजाय rolling 5-घंटे की विंडो में टोकन द्वारा कैप्ड बताता है। 1.2 लॉन्च पर प्रेस कवरेज ने इसके बजाय 60 requests per minute कैप बताया, जो पूरी तरह अलग तंत्र है। मैंने दोपहर में लगभग 90 मॉडल completions में से किसी भी सीमा को नहीं छुआ।

Meta Model API और OpenRouter

Meta Model API OpenAI SDK संगत है, इसलिए माइग्रेट करने का मतलब है मॉडल ID बदलना और अपने क्लाइंट कोड को रखना। मॉडल IDs हैं muse-spark-1.3 और muse-spark-1.3-contributor।

OpenRouter इसे meta/muse-spark-1.3 स्लग के तहत रखता है। इसकी एक कीमत है: OpenRouter ने लगभग 81 tokens per second का थ्रूपुट मापा, जबकि सीधे जाने पर Artificial Analysis ने 182 रिकॉर्ड किया, और पहले तीन दिनों में उपलब्धता करीब 92% रही। Meta एकमात्र प्रदाता है, इसलिए failover के लिए कोई दूसरा प्रदाता नहीं।

आपका पहला Muse Spark 1.3 सेशन

नीचे की हर चीज़ python-humanize/humanize पर चलती है, कमिट 823ad6096 पर पिन की हुई। यह 6 मॉड्यूल्स में 1,676 लाइनों का सोर्स है, टेस्ट सूट एक सेकंड से कम में चलता है, और डोमेन आत्म-व्याख्यात्मक है। यहाँ कुछ भी रिपो में संशोधन नहीं करता। 

ये केवल पढ़ने-भर के प्रश्न हैं ताकि देखा जा सके कि लिखने वाली किसी चीज़ को सौंपने से पहले एजेंट एक कोडबेस का अन्वेषण कैसे करता है।

दो प्रॉम्प्ट ताकि समझ आए कि यह कोड कैसे पढ़ता है, पहले वाले से शुरू करते हैं: 

Map the dependency graph of this project and tell me which module has the most inbound imports.

इसने दो commands चलाए, प्रोजेक्ट स्ट्रक्चर लिस्ट किया, फिर import के लिए grep करने के बजाय एक AST parser लिखा। उत्तर: i18n जिसके 4 inbound imports हैं, ब्रेकडाउन: i18n 4, number 2, और filesize, lists, time तथा _version 1-1।

मैंने अपनी स्क्रिप्ट से जाँचा और अलग संख्या मिली, जो पकड़ जैसी लगी। मेरी स्क्रिप्ट गलत थी। उसने केवल relative imports (from ._version import ...) गिने और absolute रूप (from humanize.i18n import ...) को मिस किया, जो इस पैकेज में अधिकांश इम्पोर्ट्स का तरीका है। मॉडल ने दोनों संभाले।

दूसरा प्रॉम्प्ट वह है जिसे चलाना वाकई काबिल-ए-गौर है, क्योंकि आप इसे ग्रेड कर सकते हैं:

List every public function in src/humanize, grouped by module, with a count per module.

इसने कुल 20 बताए: filesize 1, i18n 5, lists 1, number 8, time 5। सब सही। फिर बिना कहे जोड़ा कि i18n.get_translation नाम से पब्लिक है पर i18n.__all__ में अनुपस्थित है, जो केवल बाकी चार को एक्सपोर्ट करता है। यह भी सही।

उस सेशन की लागत 8 टर्न्स में $0.01 आई।

वह रीजनिंग स्तर जिसके बारे में Meta बात नहीं करता

muse --help यह दस्तावेज़ित करता है:

--reasoning-effort <EFFORT>
    Meta reasoning effort: none|minimal|low|medium|high|xhigh|ultra
    (default: high)

इन-सेशन /effort पिकर उन सात में से छह पेश करता है, none को छोड़कर। 

लेखक द्वारा स्क्रीनशॉट। /effort पिकर छह चयन-योग्य रीजनिंग स्तर सूचीबद्ध करता हुआ, high को current के रूप में चिह्नित।

दोनों एक स्तर सूचीबद्ध करते हैं जिसे ultra कहा गया है, जो किसी Meta घोषणा में नहीं आता। Meta की सार्वजनिक स्थिति है कि max reasoning "अतिरिक्त सुरक्षा परीक्षण पूरा होने के तुरंत बाद आ रहा है।"

तो मैंने इसे माँगा:

muse exec --model muse-spark-1.3-contributor --reasoning-effort ultra 'Reply with exactly: ok'

tbh: reasoning effort ultra is not available (gate ultra_reasoning_effort is closed); using xhigh

एक नामित फीचर गेट है, ultra_reasoning_effort, और यह बंद है। क्षमता बनी हुई है, और स्विच सर्वर-साइड ऑफ है। यह "pending safety testing" से अधिक विशिष्ट तस्वीर है, और यह एक चेतावनी संदेश में आई जिसमें "tbh" शब्द भी है।

दो व्यावहारिक बिंदु। क्लाइंट एक ऐसा स्तर विज्ञापित करता है जिसे बैकएंड परोसेगा नहीं, CLI और पिकर दोनों में। और यह xhigh पर चुपचाप डाउनग्रेड करता है, केवल एक लाइन stderr के साथ, जो किसी स्क्रिप्ट या continuous integration लॉग में अनदेखी होकर गुजर जाएगी। आप मानेंगे कि आप वह कॉन्फ़िगरेशन चला रहे थे जो आप नहीं चला रहे थे।

फिर मैंने एक मान आजमाया जो कहीं दस्तावेज़ में नहीं आता:

muse exec --model muse-spark-1.3-contributor --reasoning-effort max 'Reply with exactly: ok'

कोई चेतावनी नहीं। यह चला और ok लौटाया। तो एक undocumented मान बिना टिप्पणी के वैलिडेशन पास कर जाता है जबकि एक documented मान gated हो जाता है, और आप आउटपुट से नहीं बता सकते कि किस effort स्तर ने वास्तव में आपकी रिक्वेस्ट सर्व की।

लेखक द्वारा स्क्रीनशॉट। ultra माँगने पर बंद फीचर गेट और xhigh पर चुपचाप डाउनग्रेड, जबकि undocumented max बिना टिप्पणी के पास हो जाता है।

यदि आपको परवाह है कि आप कौन-सा रीजनिंग स्तर चला रहे हैं, तो उसे स्पष्ट रूप से सेट करें और stderr पढ़ें। यह न मानें कि आपने जो फ्लैग पास किया वही इस्तेमाल हुआ।

क्या Muse Spark 1.3 का दक्षता दावा टिकता है?

यह है परीक्षण। एक ओपन सोर्स रिपो लें, एक वास्तविक बगफिक्स कमिट को रिवर्ट करें ताकि टेस्ट सूट सचमुच फेल हो, फिर वही तीन कोडिंग कार्य दोनों मॉडलों पर समान प्रॉम्प्ट्स और समान फ्लैग्स के साथ चलाएँ।

ये ऊपर के exploratory सेशन से अलग हैं। इन में से हर एक कोड लिखता है।

कमिट 823ad6096 के सोर्स आधे को रिवर्ट करना, जबकि उसके टेस्ट्स रखें, 6 फेलिंग टेस्ट्स छोड़ता है, और यही शुरुआती स्थिति है:

git checkout 823ad6096e1e5ba82ea876ce761fc2efebd76157
git show 823ad6096 -- src/humanize/filesize.py | git apply -R -
python -m pytest tests/test_filesize.py -q

हर रन ने वही कमांड संरचना का उपयोग किया, केवल मॉडल ID और प्रॉम्प्ट बदलते हुए:

muse exec \
  --model muse-spark-1.3-contributor \
  --reasoning-effort high \
  --no-parallel-tool-calls \
  --approval-mode never \
  'PROMPT GOES HERE'

कार्य 1, बग फिक्स. 

यहाँ सफलता द्विआधारी है: 6 टेस्ट पास होते हैं, या नहीं। 

The test suite tests/test_filesize.py is failing. 
Fix the source code in src/humanize/ so that all tests pass. 
Do not modify any file in tests/.

कार्य 2, छोटा फीचर.

काफ़ी खुला ताकि दोनों मॉडल स्कोप पर असहमत हो सकें, जो मायने रख गया।

Add a function called natural_list_with_limit to src/humanize/lists.py. 
It formats a list but truncates after a given number of items, appending "and N more". 
Export it from the package and add tests.

कार्य 3, रिफैक्टर.

तीनों में सबसे भारी, कई फाइलों को छूता हुआ।

src/humanize/number.py is 571 lines. 
Split it into two modules along a sensible boundary, 
update all imports across the package, and make sure the full test suite still passes.

तीन कार्य बिना रीसेट के क्रम में चले, इसलिए कार्य 2 और 3 ने जो भी मॉडल ने पहले बनाया था, उस पर निर्माण किया। दोनों मॉडलों ने वही रास्ता अपनाया।

टोकन काउंट्स सेशन लॉग्स ~/.local/share/muse/sessions/ से आते हैं, एक बार प्रति मॉडल completion गिने गए। सभी छह रन अपने टेस्ट पास कर गए।

और डेल्टाज़, जहाँ नकारात्मक का अर्थ है 1.3 ने कम उपयोग किया:

परिणाम को ईमानदारी से पढ़ना

तीन में से दो कार्य सस्ते आए, 23% और 32% कम मॉडल completions के साथ। यह Meta के टूल-कॉल दावे के बिल्कुल अनुरूप है। फिर रिफैक्टर उल्टी दिशा में गया: 70% अधिक completions और 38% अधिक लागत।

तीनों में मिलाकर, 1.3 की लागत 1.2 से 12% अधिक रही। तो दक्षता का दावा वास्तविक है लेकिन कार्य-निर्भर, और एकल हेडलाइन प्रतिशत इसे पूरी तरह छिपा देता है।

अनकैश्ड इनपुट हर कार्य पर 19%, 22% और 5% गिरा। कभी 25% नहीं। 

Meta नहीं कहता कि उसने कौन-से टोकन गिने, और उत्तर बहुत बदल जाता है इस पर कि आप इनपुट, आउटपुट, अनकैश्ड, या कुल का मतलब लेते हैं।

कैश हिट दरें 88% से 97% रहीं और कार्य की लंबाई के साथ बढ़ीं। cached और uncached को अलग किए बिना कच्चे इनपुट टोकन रिपोर्ट करना लगभग अर्थहीन होगा, क्योंकि रिफैक्टर के 4.18M इनपुट वास्तव में 109k नए कॉन्टेक्स्ट + 4.07M re-reads हैं जो पचासवें हिस्से की दर पर बिल होते हैं।

क्यों रिफैक्टर सीधी हार नहीं है

उसे अक्षम कहने से पहले देखें कि 1.3 ने वास्तव में उस कार्य पर क्या किया।

इसने हर मूव किए गए ब्लॉक को मूल से byte-identical होने की प्रोग्रामेटिक पुष्टि की। 

इसने दोनों नई फाइलों पर --doctest-modules चलाया। इसने /tmp में एक थ्रोअवे डायरेक्टरी से import resolution का परीक्षण किया। फिर इसने दो बातें फ़्लैग कीं जिनके बारे में किसी ने नहीं पूछा: कि humanize.scientific फ़ंक्शन नए सबमॉड्यूल को शैडो करता है, और कि एक naturaldelta doctest प्रिस्टीन ट्री पर भी समान रूप से फेल होता है, इसलिए विफलता परिवर्तन के कारण नहीं है।

Muse Spark 1.2 ने एक हेल्पर फ़ंक्शन डुप्लिकेट कर एक सर्कुलर इम्पोर्ट से बचा लिया और आगे बढ़ गया। 1.3 ने उसे इम्पोर्ट किया और समझाया कि कोई सायकिल क्यों नहीं है।

आप "अधिक टोकन जले" को इस डिज़ाइन में "ज़्यादा गहन काम हुआ" से अलग नहीं कर सकते। ईमानदार कथन यह है कि 1.3 ने अधिक खर्च किया और अधिक दिया, और यह जीत है या नहीं यह इस पर निर्भर करता है कि क्या आप अतिरिक्त सख्ती चाहते थे।

फ़ीचर कार्य उल्टा पैटर्न दिखाता है और Meta के "कम verbose" दावे का सबसे साफ़ चित्रण है। Muse Spark 1.2 ने max_items, n और max_len जैसे पैरामीटर उपनाम गढ़ दिए जो किसी ने नहीं माँगे थे, और 28 टेस्ट लिखे। 

Muse Spark 1.3 ने एक सेंसिबल डिफ़ॉल्ट के साथ एक ही सिग्नेचर और 20 टेस्ट लिखे, आउटपुट टोकन्स में 54% कमी के साथ।

जो मैं नियंत्रित नहीं कर सका

चार बातें, और इनके बिना लेख ईमानदार नहीं होता।

1. Muse Code ने खुद को बीच में 1.0.2 से 1.0.3 में अपडेट कर लिया, इसलिए harness सभी छह रनों में एक-सा नहीं था। 
2. कार्य 2 और 3 हर मॉडल के अपने पूर्व आउटपुट से शुरू हुए, किसी byte-identical ट्री से नहीं, क्योंकि सीक्वेंस बिना रीसेट के चलता है।
3. हर सेल एक ही ट्रायल है, इसलिए साधारण रन-टू-रन वैरिएंस मापा नहीं गया। 
4. और मैंने सब कुछ contributor टियर पर चलाया, जो वही मॉडल है लेकिन वही डेटा शर्तें नहीं।

इनमें से कोई भी परिणामों की दिशा को अमान्य नहीं करता। इसका मतलब यह जरूर है कि 12% का समग्र अंतर तीन-तीन मैचिंग रनों जितना मजबूत संकेत नहीं देता।

Mose Spark 1.3 सर्वोत्तम अभ्यासी और ट्रबलशूटिंग

पहले दिन मुझे कुछ चीज़ें जानना अच्छा लगता।

सहयोग व्यवहारों के लिए प्रॉम्प्टिंग

Muse Spark 1.3 अस्पष्ट प्रॉम्प्ट्स पर स्पष्टीकरण माँगता है, इसलिए एक अतिनिर्दिष्ट प्रॉम्प्ट उस फीचर को बंद कर देता है जिसके लिए आप भुगतान कर रहे हैं। यह प्रत्यूर्जक है यदि आपने दो साल हर निर्देश को पहले से ही भरकर लिखना सीखा है।

फिर भी, स्कोप मायने रखता है। "number.py को बाँट दें" मॉडल को सीमा, इम्पोर्ट अपडेट्स, और done की परिभाषा का अनुमान लगाने पर छोड़ देता है। वह संस्करण जो मैंने वास्तव में उपयोग किया, तीनों को स्पष्ट करता है:

src/humanize/number.py is 571 lines. Split it into two modules along a sensible boundary, update all imports across the package, and make sure the full test suite still passes.

एक और बात जानने लायक। मेरे रिफैक्टर प्रॉम्प्ट ने कहा number.py is 571 lines। यह 567 है। दोनों मॉडलों ने बिना कहे मुझे सुधारा, और 1.3 ने अपनी ओपनिंग लाइन में ही। मेरी संख्या रिपो tip को मापने से आई, पिन किए कमिट को नहीं।

लागत कम रखना

अपने प्रॉम्प्ट के स्थिर हिस्से को आगे रखें ताकि वह cacheable रहे। 88% से 97% हिट दरों पर, आपकी कैशिंग व्यवहार आपकी बिल को आपके मॉडल चयन से कहीं ज़्यादा प्रभावित करती है।

तीनों कार्यों की कुल लागत contributor पर $0.034 आई। वही काम standard पर $0.91 चलता, यानी 27x अंतर। यह है टियर निर्णय पैसे में: तीन सेंट बनाम नब्बे।

यदि आप OpenRouter से जाते हैं, तो web search अलग से $2.50 प्रति 1,000 कॉल्स पर बिल होता है।

जब Muse Spark 1.3 सही चुनाव नहीं है

• कोई exposed reasoning ट्रेसेज़ नहीं। आप देखते हैं कि उसने क्या तय किया, क्यों नहीं, जो किसी खराब रिफैक्टर को डिबग करना कठिन बनाता है।
• Max reasoning gated है, इसलिए हर हेडलाइन बेंचमार्क संख्या के पीछे की कॉन्फ़िगरेशन उपलब्ध नहीं।
• Closed weights। न self-hosting, न fine-tuning। Meta के रोडमैप में "Muse Spark open weights release" का उल्लेख है, बिना संस्करण, तारीख या लाइसेंस के।
• एक ही प्रदाता। जब Meta का endpoint degrade होता है, रूट करने को कहीं नहीं।

आम समस्याएँ और समाधान

• muse: command not found एक क्लीन इंस्टॉल के बाद। स्क्रिप्ट ~/.local/bin/muse पर इंस्टॉल करती है, जो हर शेल में PATH में नहीं होता।
• Not logged in. Run muse again to log in. जैसा कहा गया है वैसा ही। पहला muse बाहर निकलता है, दूसरा साइन-इन शुरू करता है।
• आप contributor टियर पर हैं और आपने इसे चुना नहीं। यह डिफ़ॉल्ट है। स्टेटस बार जाँचें और /model चलाएँ किसी भी proprietary चीज़ को खोलने से पहले।
• ultra रीजनिंग चुपचाप xhigh बन जाता है। गेट बंद है। आपने जो फ्लैग पास किया उस पर भरोसा करने के बजाय stderr पढ़ें।
• Muse Code सेशन के बीच खुद को अपडेट कर देता है। मेरे यहाँ 1.0.2 से 1.0.3 हो गया रनों के बीच। यदि आप कुछ माप रहे हैं, संस्करण पिन और रिकॉर्ड करें।

एक चीज़ जो पुनरुत्पादित नहीं हुई

रिपोर्ट्स आईं कि EU उपयोगकर्ताओं को 1.3 के शिप होने के बाद भी Muse Spark 1.1 सर्व किया जा रहा था। मैंने यह सब नीदरलैंड्स से चलाया और मुझे हर जगह 1.3 मिला। वे रिपोर्ट्स Meta.ai, कंज्यूमर असिस्टेंट, से संबंधित थीं, और लगता नहीं कि Muse Code या Model API पर लागू होती हैं। दो अलग-अलग रोलआउट्स।

अंतिम विचार

Meta का दक्षता दावा मेरे तीन में से दो कार्यों पर ठहरा और तीसरे पर उलट गया, पूरे सेट पर 12% लागत वृद्धि के साथ। जहाँ 1.3 जीता, वहाँ टूल-कॉल पक्ष 23% और 32% की कमी पर मजबूत लगता है। टोकन पक्ष पूरी तरह इस पर निर्भर करता है कि आप कौन-से टोकन गिनते हैं।

यदि आप पहले से Meta Model API या Muse Code पर हैं, तो मॉडल ID बदलना एक मिनट का काम है, और रोज़मर्रा के काम पर आप शायद आगे निकलेंगे। यदि आप प्रोडक्शन एजेंट्स के लिए नए सिरे से चुन रहे हैं, तो gated max वेरिएंट और अनुपस्थित reasoning ट्रेसेज़ कुछ हफ्ते प्रतीक्षा करने के ठोस कारण हैं।

जिस चीज़ पर मैं वास्तव में कार्रवाई करूँगा, वह दक्षता संख्या नहीं है। यह कि Muse Code आपको डिफ़ॉल्ट रूप से training-eligible टियर पर रखता है, और कि दस्तावेज़ित रीजनिंग स्तर पर माँगने पर चुपचाप डाउनग्रेड हो जाता है। दोनों एक-लाइन चेक हैं और आसानी से छूट जाते हैं।

तुलना अपने स्वयं के वर्कलोड पर चलाएँ। मेरे तीन कार्य आपके तीन कार्य नहीं हैं, और उनके बीच का फैलाव मॉडलों के बीच के अंतर से बड़ा था।

पूरी बेंचमार्क तस्वीर के लिए, Matt का Muse Spark 1.3 रिलीज़ विश्लेषण तालिकाएँ लिए हुए है। ऐसे मॉडलों का स्वयं मूल्यांकन करने की कौशल विकसित करने के लिए, हमारे AI Agent Fundamentals स्किल ट्रैक से शुरू करें।