คู่มือสอน Muse Spark 1.3: แนวทางปฏิบัติสำหรับนักพัฒนา

Meta ปล่อย Muse Spark 1.3 เมื่อวันที่ 2 กันยายน 2026 และคำแนะนำอัปเกรดสรุปได้ในบรรทัดเดียว: เปลี่ยนรหัสโมเดล หมายความว่ายังใช้ปลายทาง (endpoint) เดิม ชุดพัฒนา (SDK) เดิม และราคาเดิม

ตามที่ Meta ระบุ การแก้ไขเพียงบรรทัดเดียวนี้ทำให้โมเดลทำงานจบด้วยจำนวนการเรียกใช้เครื่องมือ (tool call) ลดลงราว 20% และโทเค็นลดลง 25% เมื่อเทียบกับ Muse Spark 1.2 ตัวเลขเหล่านี้มาจากการเปรียบเทียบโดย วิศวกรของ Meta เอง บนงานที่ไม่ได้ระบุชื่อ พร้อมทั้งไม่มีระเบียบวิธีวิจัยประกอบ

ซึ่งเป็นประเภทของคำอ้างที่ควรตรวจสอบก่อนจะนำไปพูดต่อ

จึงติดตั้ง Muse Code ตั้งใจทำให้โปรเจกต์โอเพนซอร์สจริงพัง แล้วรันงาน 3 อย่างเดียวกันบนทั้งสองโมเดล

หากจะทำตามบทสอน Muse Code นี้ ต้องมีบัญชีนักพัฒนา Meta เทอร์มินัลที่ถนัดใช้ และ macOS หรือ Linux สำหรับเอเจนต์ Muse Code ผู้ใช้ Windows ยังใช้ไม่ได้ในรุ่นเบต้านี้

สรุปสั้นๆ

• Muse Spark 1.3 คือโมเดลเหตุผลแบบมัลติโหมดระดับเรือธงของ Meta เปิดตัว 2 กันยายน 2026 พร้อมหน้าต่างบริบท 1M โทเค็น
• Muse Code เริ่มต้นให้ใช้ muse-spark-1.3-contributor ตามค่าเริ่มต้น ซึ่งหมายความว่า Meta จะนำโค้ดของคุณไปฝึกโมเดล เว้นแต่จะสลับเอง เป็นการยกเลิก (opt-out) ไม่ใช่ยินยอม (opt-in)
• จากการรัน 6 ครั้งบน 3 งานเขียนโค้ด รุ่น 1.3 ถูกกว่าใน 2 งาน แต่แพงขึ้น 38% ในงานที่สาม รวมแล้วค่าใช้จ่ายเพิ่มขึ้น 12% เมื่อเทียบทั้งชุด
• จำนวน completion ของโมเดลลดลง 23% และ 32% ใน 2 งานที่ 1.3 ชนะ ซึ่งสอดคล้องกับคำอ้างเรื่อง tool call ของ Meta ส่วนอินพุตที่ไม่แคชลดลงทั้ง 3 งาน แต่ไม่เคยถึง 25%
• ระดับเหตุผล ultra มีอยู่ใน CLI และตัวเลือกในเซสชัน แต่แบ็กเอนด์ปฏิเสธด้วยการปิดฟีเจอร์เกตแบบมีชื่อ

Muse Spark 1.3 คืออะไร?

Muse Spark 1.3 คือโมเดลเหตุผลแบบมัลติโหมดระดับเรือธงของ Meta ที่ Meta Superintelligence Labs เปิดตัวเมื่อ 2 กันยายน 2026 ออกแบบมาสำหรับเซสชันเอเจนต์แบบยาวและการโค้ดในรีโปขนาดใหญ่ รองรับบริบท 1,048,576 โทเค็น และรับอินพุตได้ทั้งข้อความ รูปภาพ วิดีโอ และไฟล์

มี 6 อย่างที่เปลี่ยนไปจาก Muse Spark 1.2:

• ประสิทธิภาพ. tool call น้อยลงราว 20% และโทเค็นน้อยลง 25% จากการเปรียบเทียบภายในของ Meta
• การทำงานร่วมกัน ถามคำถามเพื่อให้เคลียร์เมื่อพรอมต์คลุมเครือ และตรวจสอบก่อนทำงานที่มีผลกระทบ
• มัลติทาสก์ ภายในเธรดเดียว ทำให้ข้อความที่ส่งกลางคันผูกกับงานที่ตั้งใจไว้
• การตามคำสั่งยาวๆ ได้ดีขึ้น ลดการหลุดข้อกำหนดในงานหลายขั้นตอน
• การสอบเทียบการตัดสินใจ ที่ดีขึ้นสำหรับการกระทำที่ย้อนกลับไม่ได้
• สไตล์การโค้ดที่สะอาดขึ้น ลดรอบที่ไม่จำเป็น ลดความเยิ่นเย้อ

ทั้งหมดนี้ดูดี แต่สกอร์การ์ดที่ Meta เผยแพร่รัน Muse Spark 1.3 ที่ระดับเหตุผลmax เทียบกับ Muse Spark 1.2 ที่ระดับxhigh และ max ยังถูกปิดกั้นในวันเปิดตัว 

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

มี 3 ทาง ขึ้นกับสิ่งที่กำลังสร้าง เลือกจากตาราง แล้วข้ามไปยังส่วนที่ตรงกัน

Muse Code เอเจนต์ในเทอร์มินัล

Muse Code คือเอเจนต์โค้ดดิ้งในเทอร์มินัลของ Meta อยู่ในเบต้าสำหรับ macOS และ Linux เป็นฮาร์เนสที่รัน Muse Spark และทั้งสองมีเวอร์ชันแยกกัน ดังนั้น 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 ด้วยสคริปต์บรรทัดเดียว จากนั้นยืนยันเวอร์ชัน 1.0.2 บน macOS

ต่อไปให้รัน muse ครั้งแรกมันพิมพ์ว่า Not logged in. Run muse again to log in แล้วออก ดังนั้นต้องรันซ้ำสองครั้ง เป็นรายละเอียดเล็กๆ ที่ทำให้คิดว่าติดตั้งพัง

ครั้งที่สองจะเริ่มกระบวนการ OAuth แบบ device flow จะพิมพ์ 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 ภายในรีโปของลูกค้าแล้วเริ่มทำงาน แปลว่าได้ส่งโค้ดนั้นไปยังปลายทางที่เข้าเกณฑ์สำหรับการฝึกแล้ว ตรวจสอบแถบสถานะก่อนพิมพ์พรอมต์แรก ไม่ใช่หลังจากนั้น

สกรีนช็อตโดยผู้เขียน เซสชัน Muse Code ครั้งแรก โดยโมเดลเริ่มต้นเป็น muse-spark-1.3-contributor และมีข้อความเปิดเผยเรื่อง product improvement ใต้ส่วนหัว

แถบสถานะยังแสดงระดับความพยายามเชิงเหตุผล ซึ่งของผู้เขียนอยู่ที่ high ไม่ใช่ xhigh อย่างที่ Artificial Analysis ใช้เบนช์มาร์ก จุดนี้ควรจำไว้เมื่อเปรียบเทียบผลกับตัวเลขที่เผยแพร่

การเลือกและสลับระดับ

รัน /model จะมีตัวเลือกแบบอินเทอร์แอกทีฟ 4 ตัวพร้อมอัตราค่าใช้จ่าย ซึ่งตรงกับหน้าชำระเงินของ Meta:

Contributor ถูกกว่าประมาณ 12 เท่าบนอินพุต และ 21 เท่าบนเอาต์พุต

ส่วนลดนั้นแลกมากับทรัพย์สินทางปัญญา (IP) ของคุณ คำของ Meta คือ “เนื้อหาของคุณ รวมถึงข้อความข้ามเซสชัน อาจถูกนำไปใช้เพื่อปรับปรุงผลิตภัณฑ์” ซึ่งครอบคลุมมากกว่าโค้ดที่ให้ไป

ทั้งรุ่น Muse Spark 1.2 ยังอยู่ในตัวเลือกด้วยราคาเดียวกัน ซึ่งสำคัญต่อการเปรียบเทียบภายหลัง: เนื่องจากอัตราไม่เปลี่ยนระหว่างเจนเนอเรชัน การเปรียบเทียบโทเค็นจึงเท่ากับการเปรียบเทียบค่าใช้จ่ายโดยไม่ต้องปรับอะไร

สกรีนช็อตโดยผู้เขียน ตัวเลือก /model แสดง Muse Spark ทั้งสี่รุ่นพร้อมอัตรา cached, input และ output

หากต้องการยกเลิกการเข้าร่วม เลื่อนขึ้นไปที่ muse-spark-1.3 แล้วกด enter บรรทัด “Discounted tokens” จะหายไปจากส่วนหัว

สำหรับงานลูกค้า มีตัวเลือกที่เข้มงวดกว่านี้ซึ่งไม่ปรากฏในเทอร์มินัล Meta ระบุว่าได้ เริ่มรับคำขอไม่เก็บข้อมูล (zero data retention) ซึ่งจัดการผ่านฝ่ายขาย ไม่ใช่ผ่านสวิตช์

การเก็บรักษาข้อมูล (retention) และการฝึก (training) เป็นคนละประเด็น และสัญญากับเอเจนซีมักต้องตอบทั้งคู่

การจำกัดอัตราการใช้งานทำงานต่างกันระหว่างระดับ แม้ว่าแหล่งข้อมูลจะให้ข้อมูลไม่ตรงกัน บล็อกนักพัฒนา Meta อธิบายว่า contributor จำกัดตามจำนวนโทเค็นในหน้าต่างกลิ้ง 5 ชั่วโมง ไม่ใช่ตามจำนวนคำขอ ขณะที่สื่อที่รายงานตอนเปิดตัว 1.2 ระบุว่าจำกัด 60 คำขอต่อนาที ซึ่งเป็นกลไกที่ต่างกันโดยสิ้นเชิง ผู้เขียนไม่เคยชนข้อจำกัดใดๆ แม้ทำ completion ราว 90 ครั้งในช่วงบ่ายวันเดียว

Meta Model API และ OpenRouter

Meta Model API เข้ากันได้กับ OpenAI SDK ดังนั้นการย้ายคือเปลี่ยนเพียงรหัสโมเดลแล้วคงโค้ดไคลเอนต์ไว้เดิม รหัสโมเดลคือ muse-spark-1.3 และ muse-spark-1.3-contributor

OpenRouter ให้บริการภายใต้สลัก meta/muse-spark-1.3 ซึ่งมีต้นทุนเพิ่ม: OpenRouter วัดอัตราการไหลที่ ~81 โทเค็นต่อวินาที เทียบกับ 182 ที่ Artificial Analysis บันทึกเมื่อเรียกตรง และความพร้อมใช้งานราว 92% ในสามวันแรก Meta เป็นผู้ให้บริการรายเดียว จึงไม่มีผู้ให้บริการสำรองสำหรับสลับเมื่อมีปัญหา

เซสชันแรกกับ Muse Spark 1.3

ทุกอย่างด้านล่างนี้รันกับ python-humanize/humanize ปักหมุดที่คอมมิต 823ad6096 มีซอร์ส 1,676 บรรทัด กระจาย 6 โมดูล ชุดทดสอบรันไม่ถึงวินาที และโดเมนไม่ต้องอธิบายเพิ่มเติม ไม่มีอะไรในนี้แก้ไขรีโป

คำถามแบบอ่านอย่างเดียวเพื่อดูว่าเอเจนต์สำรวจฐานโค้ดอย่างไร ก่อนจะให้ทำอะไรที่เขียนทับได้

มีสองพรอมต์เพื่อจับจังหวะการอ่านโค้ด เริ่มจากอันแรก:

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

มันรันสองคำสั่ง แสดงโครงสร้างโปรเจกต์ แล้วเขียนตัวพาร์ส AST แทนการ grep หา import คำตอบ: i18n มี inbound import 4 ครั้ง แยกเป็น i18n 4, number 2 และ filesize, lists, time กับ _version อย่างละ 1

ตรวจด้วยสคริปต์ของตัวเองแล้วได้ตัวเลขต่างออกไป ซึ่งเหมือนจะเจอจุดผิด สคริปต์ของผู้เขียนผิดเอง มันนับเฉพาะ import แบบสัมพัทธ์ (from ._version import ...) และพลาดแบบสัมบูรณ์ (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 เป็น public ตามชื่อ แต่ไม่มีใน i18n.__all__ ซึ่งส่งออกแค่สี่ตัวอื่น ถูกต้องเช่นกัน

เซสชันนั้นมีค่าใช้จ่าย $0.01 ตลอด 8 เทิร์น

ระดับเหตุผลที่ Meta ไม่พูดถึง

muse --help มีเอกสารดังนี้:

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

ตัวเลือกในเซสชัน /effort เสนอหกระดับจากเจ็ดระดับ โดยตัด none ออก

สกรีนช็อตโดยผู้เขียน ตัวเลือก /effort แสดงระดับเหตุผลที่เลือกได้หกระดับ โดย high ถูกทำเครื่องหมายว่าเป็นค่าปัจจุบัน

ทั้งสองที่มีระดับชื่อว่า 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 และปิดอยู่ ความสามารถถูกสร้างแล้ว แต่สวิตช์ฝั่งเซิร์ฟเวอร์ปิด นี่ให้ภาพที่เฉพาะเจาะจงกว่าคำว่า “รอทดสอบความปลอดภัย” และยังมากับข้อความเตือนที่มีคำว่า “tbh” ด้วย

สองประเด็นเชิงปฏิบัติ: ไคลเอนต์โฆษณาระดับที่แบ็กเอนด์ไม่ให้บริการ ทั้งใน CLI และตัวเลือก และมันลดระดับลงเป็น xhigh แบบเงียบๆ โดยพิมพ์เพียงหนึ่งบรรทัดลง stderr ซึ่งในสคริปต์หรือบันทึก CI อาจไหลผ่านตาไป คุณจะเชื่อว่ากำลังรันการตั้งค่าที่ไม่ได้ใช้จริง

จากนั้นลองค่าที่ไม่มีในเอกสาร:

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

ไม่มีคำเตือนเลย มันรันและตอบ ok ดังนั้นค่าที่ไม่อยู่ในเอกสารผ่านการตรวจสอบโดยไม่แสดงอะไร ขณะที่ค่าที่อยู่ในเอกสารถูกกั้น และคุณแยกไม่ออกจากเอาต์พุตว่าระดับความพยายามใดถูกใช้จริง

สกรีนช็อตโดยผู้เขียน ขอ ultra แล้วได้ข้อความฟีเจอร์เกตปิดและลดระดับเป็น xhigh แบบเงียบ ขณะที่ขอ max ซึ่งไม่มีในเอกสารผ่านได้โดยไม่แสดงข้อความ

หากสนใจว่ากำลังรันระดับเหตุผลใด ให้ตั้งค่าอย่างชัดเจนและอ่าน stderr อย่าคิดเอาเองว่าธงที่ส่งไปคือธงที่ถูกใช้

คำอ้างเรื่องประสิทธิภาพของ Muse Spark 1.3 ยืนอยู่ได้ไหม?

การทดสอบคือ: ใช้รีโปโอเพนซอร์สหนึ่งตัว ถอยคอมมิตที่แก้บั๊กจริงเพื่อให้ชุดทดสอบล้มเหลวจริง แล้วรันงานโค้ด 3 อย่างบนทั้งสองโมเดลด้วยพรอมต์และแฟลกเดียวกัน

สิ่งเหล่านี้แยกจากเซสชันสำรวจด้านบน และทุกงานเขียนโค้ดจริง

การถอยส่วนซอร์สของคอมมิต 823ad6096 โดยคงไฟล์ทดสอบไว้ จะเหลือเทสต์ล้ม 6 รายการ ซึ่งเป็นสถานะตั้งต้น:

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

ทุกครั้งใช้รูปคำสั่งเดียวกัน เปลี่ยนเฉพาะรหัสโมเดลและพรอมต์:

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 ของโมเดล ทั้งหกรันผ่านเทสต์ทั้งหมด

และค่าต่าง (delta) โดยค่าติดลบหมายถึง 1.3 ใช้น้อยกว่า:

อ่านผลอย่างตรงไปตรงมา

สองงานจากสามมีค่าใช้จ่ายลดลง โดยจำนวน completion ลดลง 23% และ 32% ซึ่งตรงกับคำอ้างเรื่อง tool call ของ Meta แต่รีแฟกเตอร์เป็นฝั่งตรงข้าม: completion มากขึ้น 70% และค่าใช้จ่ายมากขึ้น 38%

เมื่อรวมทั้งสามงาน รุ่น 1.3 มีค่าใช้จ่ายมากกว่า 1.2 อยู่ 12% ดังนั้นคำอ้างเรื่องประสิทธิภาพเป็นจริงแต่ขึ้นอยู่กับงาน และตัวเลขพาดหัวเดียวซ่อนความจริงนี้ทั้งหมด

อินพุตที่ไม่แคชลดลงในทุกงานที่ 19%, 22% และ 5% ไม่เคยถึง 25%

Meta ไม่ระบุว่านับโทเค็นชนิดใด และคำตอบต่างกันมากหากหมายถึง input, output, uncached หรือรวมทั้งหมด

อัตราการโดนแคชอยู่ที่ 88% ถึง 97% และสูงขึ้นตามความยาวของงาน การรายงานอินพุตโทเค็นดิบโดยไม่แยก cached กับ uncached แทบจะไร้ความหมาย เพราะอินพุต 4.18M ของรีแฟกเตอร์จริงๆ คือบริบทใหม่ 109k บวกกับการอ่านซ้ำ 4.07M ที่คิดราคา 1 ใน 50

เหตุใดรีแฟกเตอร์จึงไม่ใช่การขาดทุนตรงๆ

ดูว่าสิ่งที่ 1.3 ทำในงานนั้นจริงๆ คืออะไร ก่อนจะเรียกว่าขาดประสิทธิภาพ

มันตรวจยืนยันเชิงโปรแกรมว่าบล็อกที่ย้ายทุกบล็อกเหมือนเดิมทุกไบต์

มันรัน --doctest-modules บนไฟล์ใหม่ทั้งสอง ทดสอบการแก้ import จากไดเรกทอรีชั่วคราวใน /tmp แล้วชี้สองประเด็นที่ไม่มีใครขอ: humanize.scientific ฟังก์ชันบังชื่อซับโมดูลใหม่ และ doctest ของ naturaldelta ล้มเหมือนกันบนต้นไม้โค้ดที่ยังไม่แก้ แปลว่าความล้มเหลวไม่ใช่เพราะการเปลี่ยนแปลง

Muse Spark 1.2 ก็อปปี้ฟังก์ชันช่วยเพื่อหลบ import วน และเดินหน้าต่อ ส่วน 1.3 import มันมาและอธิบายว่าทำไมจึงไม่มีวนนั้น

คุณแยก “ใช้โทเค็นมากขึ้น” ออกจาก “ทำงานละเอียดรอบคอบขึ้น” ไม่ได้ด้วยดีไซน์นี้ ข้อเท็จจริงที่ซื่อสัตย์คือ 1.3 ใช้จ่ายมากขึ้นและส่งมอบมากขึ้น และจะถือว่าเป็นชัยชนะหรือไม่ขึ้นกับว่าต้องการความพิถีพิถันเพิ่มหรือเปล่า

งานฟีเจอร์แสดงรูปแบบตรงข้าม และเป็นตัวอย่างที่ชัดเจนของคำอ้าง “พูดน้อยลง” ของ Meta 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 กลางทาง ดังนั้นฮาร์เนสไม่เหมือนกันในทั้งหกรัน
2. งานที่ 2 และ 3 เริ่มจากผลลัพธ์ก่อนหน้าของแต่ละโมเดลเอง ไม่ใช่ต้นไม้โค้ดที่เหมือนกันทุกไบต์ เพราะรันต่อเนื่องโดยไม่รีเซ็ต
3. แต่ละช่องเป็นการทดลองครั้งเดียว จึงไม่มีการวัดความแปรปรวนระหว่างการรันปกติ
4. และทั้งหมดรันบนระดับ contributor ซึ่งเป็นโมเดลเดียวกันแต่เงื่อนไขข้อมูลต่างกัน

สิ่งเหล่านี้ไม่ทำให้ทิศทางของผลลัพธ์เป็นโมฆะ แต่หมายความว่า ความต่างรวม 12% ให้สัญญาณอ่อนกว่าเมื่อมีการรันซ้ำสามครั้งต่อช่อง

แนวปฏิบัติและการแก้ปัญหาที่พบบ่อยสำหรับ Muse Spark 1.3

มีบางอย่างที่น่ารู้ตั้งแต่วันแรก

การพรอมต์เพื่อให้ได้พฤติกรรมการร่วมมือ

Muse Spark 1.3 จะถามเพื่อให้ชัดเมื่อพรอมต์กำกวม ดังนั้นการกำหนดรายละเอียดมากเกินไปจะปิดฟีเจอร์ที่จ่ายเงินซื้อมา ซึ่งขัดกับสัญชาตญาณหากใช้เวลาสองปีที่ผ่านมาไปกับการยัดคำสั่งทั้งหมดไว้ต้นพรอมต์

แต่ขอบเขตยังสำคัญ “แบ่ง number.py” ปล่อยให้โมเดลเดาเส้นแบ่ง การอัปเดต import และเกณฑ์ว่าเสร็จเมื่อไร เวอร์ชันที่ใช้จริงจะสะกดทั้งสามเรื่องให้ชัด:

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 มี 571 บรรทัด แต่จริงๆ คือ 567 ทั้งสองโมเดลแก้ให้เองโดยไม่ต้องขอ และ 1.3 ทำตั้งแต่ประโยคแรก ตัวเลขของผู้เขียนมาจากการวัดที่ปลายรีโป ไม่ใช่คอมมิตที่ปักหมุด

ลดค่าใช้จ่าย

วางส่วนที่คงที่ของพรอมต์ไว้ด้านหน้าเพื่อให้แคชได้ ด้วยอัตราโดนแคช 88% ถึง 97% พฤติกรรมแคชของคุณมีผลต่อบิลมากกว่าการเลือกโมเดลเสียอีก

สามงานมีค่าใช้จ่ายรวม $0.034 บนระดับ contributor งานเดียวกันบน standard จะอยู่ที่ $0.91 ต่างกัน 27 เท่า นี่คือการตัดสินใจเรื่องระดับที่อธิบายเป็นเงิน: สามเซ็นต์เทียบกับเก้าสิบ

หากผ่าน OpenRouter การค้นเว็บคิดค่าบริการแยกที่ $2.50 ต่อ 1,000 ครั้ง

เมื่อใดที่ Muse Spark 1.3 ไม่ใช่ตัวเลือกที่เหมาะ

• ไม่มีร่องรอยการให้เหตุผลที่เปิดเผย เห็นแต่สิ่งที่ตัดสินใจ ไม่เห็นเหตุผล ทำให้การดีบักรีแฟกเตอร์ที่แย่ยากขึ้น
• max reasoning ถูกกั้น ดังนั้นการตั้งค่าที่อยู่เบื้องหลังตัวเลขเบนช์มาร์กพาดหัวทั้งหมดจึงใช้ไม่ได้
• น้ำหนักโมเดลปิด ไม่สามารถโฮสต์เองหรือไฟน์จูนได้ โรดแมปของ Meta พูดถึง “ปล่อยน้ำหนักเปิดของ Muse Spark” โดยไม่มีเวอร์ชัน วันที่ หรือไลเซนส์
• ผู้ให้บริการรายเดียว เมื่อปลายทางของ Meta เสื่อม ไม่มีที่ให้สลับ

ปัญหาที่พบบ่อยและวิธีแก้

• muse: command not found หลังติดตั้งใหม่ สคริปต์ติดตั้งไปที่ ~/.local/bin/muse ซึ่งไม่อยู่บน PATH ของทุกเชลล์
• Not logged in. Run muse again to log in ตรงตามที่เขียน ครั้งแรก muse ออกจากโปรแกรม ครั้งที่สองเริ่มลงชื่อเข้าใช้
• คุณอยู่บนระดับ contributor ทั้งที่ไม่ได้เลือก นั่นคือค่าเริ่มต้น ตรวจแถบสถานะและรัน /model ก่อนเปิดสิ่งที่เป็นทรัพย์สิน
• ultra ถูกลดเหลือ xhigh แบบเงียบ เกตปิดอยู่ อ่าน stderr แทนที่จะเชื่อธงที่ส่งไป
• Muse Code อัปเดตตัวเองกลางเซสชัน ของผู้เขียนขึ้นจาก 1.0.2 เป็น 1.0.3 ระหว่างรัน หากกำลังวัดอะไรอยู่ ให้ปักหมุดและบันทึกเวอร์ชัน

เรื่องหนึ่งที่ทำซ้ำไม่ติด

มีรายงานว่าผู้ใช้สหภาพยุโรปยังถูกเสิร์ฟ Muse Spark 1.1 หลัง 1.3 ปล่อย ผู้เขียนรันทั้งหมดนี้จากเนเธอร์แลนด์และได้ 1.3 ตลอด รายงานเหล่านั้นเกี่ยวข้องกับ Meta.ai ผู้ช่วยสำหรับผู้ใช้ทั่วไป และดูเหมือนจะไม่ใช้กับ Muse Code หรือ Model API เป็นการปล่อยสองแบบต่างกัน

ข้อสรุป

คำอ้างเรื่องประสิทธิภาพของ Meta เป็นจริงในสองจากสามงานของผู้เขียน และกลับด้านในงานที่สาม รวมแล้วค่าใช้จ่ายเพิ่มขึ้น 12% ด้าน tool call ดูมั่นคงที่ลดลง 23% และ 32% ในงานที่ 1.3 ชนะ ส่วนด้านโทเค็นขึ้นอยู่กับว่าคุณนับโทเค็นแบบใด

หากใช้อยู่แล้วบน Meta Model API หรือใน Muse Code การสลับรหัสโมเดลใช้เวลาไม่ถึงนาที และน่าจะได้เปรียบในงานประจำ หากกำลังเลือกใหม่สำหรับเอเจนต์ผลิตจริง รุ่น max ที่ถูกกั้นและการไม่มีร่องรอยการให้เหตุผลเป็นเหตุผลเชิงรูปธรรมให้รอสักไม่กี่สัปดาห์

สิ่งที่ควรกระทำจริงๆ ไม่ใช่ตัวเลขประสิทธิภาพ แต่คือการที่ Muse Code ตั้งคุณไว้บนระดับที่ฝึกจากข้อมูลตามค่าเริ่มต้น และระดับเหตุผลที่อยู่ในเอกสารถูกลดระดับแบบเงียบเมื่อร้องขอ ทั้งสองอย่างตรวจได้ด้วยหนึ่งบรรทัดและพลาดได้ง่าย

รันการเปรียบเทียบบนเวิร์กโหลดของคุณเอง งานสามอย่างของผู้เขียนไม่ใช่งานสามอย่างของคุณ และความแปรกระหว่างงานใหญ่กว่าความต่างระหว่างโมเดล

สำหรับภาพเบนช์มาร์กเต็มๆ ดูบทวิเคราะห์ของ Matt เรื่อง Muse Spark 1.3 ส่วนทักษะเพื่อประเมินโมเดลแบบนี้ด้วยตัวเอง เริ่มจาก AI Agent Fundamentals ของเรา