Cursor Composer 2.5 — เก่งกว่า Opus 4.7 ราคาถูกกว่า 7 เท่า

Composer 2.5 ของ Cursor เก่งกว่า Opus 4.7 xhigh thinking ในขณะที่ต้นทุนถูกกว่า 7 เท่า

Note: ตอนแรกผมเห็น 7 เท่ายังไงก็คิดว่ามีแต่จีนที่ทำราคาเท่านี้ได้ ปรากฏเป็น US startup — Cursor ยอดเยี่ยมจริงๆ ครับ (แต่ Foundation model เบื้องหลังคือ Kimi 2.5 ของจีนนะอิอิ) อีกประเด็นที่เห็นได้จากกราฟคือ ที่หลายคนบอกว่า GPT-5.5 แพงกว่า Opus 4.7 แต่ด้วยความที่ใช้ token efficient กว่า จะเห็นว่าในความเก่งระดับใกล้ๆ กัน GPT-5.5 ถูกกว่า 3 เท่า

Note 2: ตอนนี้เขามีลดราคา 50% เดือนแรกอยู่ ใครยังไม่มี code กดได้เลยครับ ได้แค่ 10 คนนะคร้าบ — https://cursor.com/referral?code=9GALIPUDNBLV ตอนนี้ที่ผมทำคือ สมัครหลาย account แล้วเอา 50% 5555 พอดีช่วงนี้ใช้ tokens เยอะ แล้วไม่พอจริงๆ ครับ

ทีม Cursor ประกาศเปิดตัว Composer 2.5 อย่างเป็นทางการเมื่อไม่กี่ชั่วโมงที่ผ่านมา ในฐานะโมเดล coding agent รุ่นใหม่ล่าสุดของบริษัท เป็นการ upgrade ที่มีนัยสำคัญทั้งด้านความฉลาดและพฤติกรรมการทำงานเมื่อเทียบกับ Composer 2 รุ่นก่อนหน้า

จุดเด่นที่ทีม Cursor เน้นคือ Composer 2.5 ทำงานต่อเนื่องกับ task ที่ใช้เวลานานได้ดีขึ้น ทำตาม instruction ที่ซับซ้อนได้น่าเชื่อถือขึ้น และร่วมงานด้วยแล้วรู้สึกถูกใจมากกว่าเดิม ซึ่งทีมงานบอกชัดว่ามิติเหล่านี้ไม่ใช่ตัวเลข benchmark โดยตรง แต่เป็นสิ่งที่สำคัญต่อการใช้งานจริง

📈 เก่งกว่า Opus 4.7 xhigh ตรงๆ และต้นทุนถูกกว่าหลายเท่า

• จุดที่ต้องเน้นชัดคือ Composer 2.5 ทำคะแนน CursorBench 3.1 ได้สูงกว่า Opus 4.7 ที่ xhigh setting ซึ่งเป็น default ของ Opus 4.7 โดยตรง Composer 2.5 อยู่ที่ราว 63% ขณะที่ Opus 4.7 xhigh อยู่ที่ราว 61% — เก่งกว่าจริงๆ ไม่ใช่แค่เทียบเท่า
• ที่น่าสนใจกว่าเดิมคือเรื่องต้นทุน — Composer 2.5 อยู่ที่ราว $1 ต่อ task ขณะที่ Opus 4.7 xhigh อยู่ที่ราว $7 ต่อ task แปลว่าได้ performance สูงกว่าในขณะที่จ่ายถูกกว่าราว 7 เท่า ไม่ใช่ "ได้พอกันที่ราคาถูก" แต่ "ได้ดีกว่าที่ราคาถูกกว่ามาก"
• Composer 2.5 ยังไม่เก่งเท่า Opus 4.7 ใน max setting ซึ่งเป็นโหมดที่ใช้ compute หนักที่สุดและทำคะแนนได้ราว 64.5% ที่ราคาประมาณ $11 ต่อ task Composer 2.5 ตามหลังเพียงประมาณ 1.5% ในแง่คะแนน แต่ต้นทุนต่อ task ถูกกว่าประมาณ 11 เท่า สอดคล้องกับคำที่ทีม Cursor บอกว่า efficiency สูงกว่าโมเดลที่ความสามารถใกล้เคียงกันถึง 10 เท่า
• เมื่อเทียบกับ Composer 2 รุ่นก่อนหน้าที่อยู่ราว 52% Composer 2.5 ขยับขึ้นมาราว 11% เต็มในขณะที่ราคาต่อ task ใกล้เคียงกัน — เป็นการก้าวกระโดดที่ใหญ่มากในช่วงเวลาเพียง 2 เดือน

📊 Composer 2.5 ตั้งอยู่บน Foundation model ไหน

• Composer 2.5 สร้างขึ้นบน open-source checkpoint ตัวเดียวกับ Composer 2 นั่นคือ Kimi K2.5 ของ Moonshot AI ซึ่งเป็นโมเดล Mixture of Experts จากจีน ทีม Cursor ใช้การ post-training และ reinforcement learning หนัก เพื่อปรับโมเดลให้เหมาะกับงาน agentic software engineering ในสภาพแวดล้อมจริงของ Cursor
• การปรับปรุงรอบนี้ไม่ได้เกิดจากการเปลี่ยน base model แต่มาจาก 3 แกนหลัก คือการ scale training ให้ใหญ่ขึ้น การสร้าง RL environment ที่ซับซ้อนกว่าเดิม และการนำวิธีเรียนรู้แบบใหม่เข้ามาใช้ จุดที่น่าสนใจคือทีมงานให้ความสำคัญกับมิติเชิงพฤติกรรม เช่น communication style และการ calibrate ปริมาณความพยายามให้เหมาะกับงาน

💡 Targeted RL with textual feedback — เทคนิคใหม่ที่น่าสนใจ

• ปัญหาใหญ่ของการเทรน RL ในยุคนี้คือเรื่อง credit assignment — rollout หนึ่งครั้งกินไปได้หลายแสน token เมื่อคำนวณ reward ทีเดียวที่ตอนจบของทั้ง rollout โมเดลแทบไม่มีทางรู้ว่าการตัดสินใจในจุดไหนช่วยหรือทำลายผลลัพธ์ ปัญหายิ่งหนักเมื่อต้องการห้ามพฤติกรรมเฉพาะจุด เช่น tool call ที่ผิด คำอธิบายที่ทำให้สับสน หรือการ violate style
• ทีม Cursor จึงเทรน Composer 2.5 ด้วยวิธี targeted textual feedback — ใส่ feedback ตรงจุดในเส้นทางที่โมเดลควรทำได้ดีกว่านี้ โดยสร้าง hint สั้นๆ ที่บอกว่าควรปรับอย่างไร แทรกเข้าไปใน local context แล้วใช้ model distribution ที่ได้จากบริบทใหม่นั้นเป็น teacher ส่วน policy ที่ใช้บริบทเดิมคือ student แล้วเพิ่ม on-policy distillation KL loss ที่ดึงให้ token probability ของ student วิ่งเข้าหา teacher
• ตัวอย่างที่ทีมยกมา: สมมติว่าระหว่าง rollout ที่ยาวมาก โมเดลเรียก tool ที่ไม่มีอยู่จริง แล้วได้ error "Tool not found" จากนั้นก็ดำเนินการเรียก tool ที่ถูกต้องต่อ การ error ครั้งเดียวจากการเรียก tool หลายร้อยครั้งจะแทบไม่ส่งผลต่อ reward สุดท้ายเลย แต่ด้วย text feedback ทีมงานสามารถพุ่งเป้าไปที่ความผิดพลาดจุดนั้นโดยตรง ด้วยการแทรก hint แบบ "Reminder: Available tools..." พร้อม list ของ tool ที่ใช้ได้จริง
• ในการเทรน Composer 2.5 ทีมงานนำวิธีนี้ไปใช้กับพฤติกรรมหลากหลายแบบ ตั้งแต่ coding style ไปจนถึงรูปแบบการสื่อสารของโมเดล — เป็นวิธีที่ช่วยให้ได้สัญญาณการเรียนรู้แบบเฉพาะจุด ในขณะที่ยังคง RL objective รวมของทั้ง trajectory เอาไว้

🔧 Synthetic data มากกว่าเดิม 25 เท่า

• ระหว่างเทรน RL ความสามารถ coding ของ Composer พัฒนาเร็วมาก จนถึงจุดที่โมเดลทำ training problem ส่วนใหญ่ได้ถูกหมด เพื่อให้ความฉลาดเพิ่มต่อไปได้ ทีมงานจึงทั้งคัดเลือกและสร้าง task ที่ยากขึ้นแบบ dynamic ระหว่าง run โดย Composer 2.5 ถูกเทรนด้วย synthetic task มากกว่า Composer 2 ถึง 25 เท่า
• หนึ่งในวิธีสร้าง synthetic task ที่น่าสนใจคือ feature deletion — ให้ agent ดู codebase ที่มีชุด test ใหญ่ๆ แล้วสั่งให้ลบ code และ file ในลักษณะที่ codebase ยังทำงานได้ปกติ แต่ feature เฉพาะที่ทดสอบได้บางอย่างถูกตัดออก จากนั้น task ที่ใช้เทรนคือให้ reimplement feature นั้นกลับมา โดยใช้ test เป็น verifiable reward — เป็นการสร้าง task ที่ grounded อยู่บน real codebase จริงๆ ไม่ใช่โจทย์ปลอม
• ผลข้างเคียงที่ตามมาจากการสร้าง synthetic task ในระดับใหญ่คือเรื่อง reward hacking ที่ไม่คาดคิด พอโมเดลเก่งขึ้น Composer 2.5 หาทางลัดที่ซับซ้อนขึ้นเรื่อยๆ ยกตัวอย่าง 2 เคส: 1. โมเดลไปเจอ Python type-checking cache ที่หลงเหลือ แล้ว reverse-engineer format ของมัน เพื่อหา function signature ที่ถูกลบไป 2. โมเดล decompile Java bytecode เพื่อ reconstruct third-party API กลับมา ทีมงานสามารถจับและวินิจฉัยปัญหาเหล่านี้ได้ด้วย agentic monitoring tool แต่ก็เป็นสัญญาณว่าการเทรน RL ระดับใหญ่ต้องการความระมัดระวังมากขึ้น

⚙️ Sharded Muon และ dual mesh HSDP สำหรับ infrastructure

• ในการ continued pretraining ทีม Cursor ใช้ Muon optimizer พร้อม distributed orthogonalization หลังจากสร้าง momentum update แล้ว ก็จะรัน Newton-Schulz ที่ granularity ตามธรรมชาติของโมเดล คือต่อ attention head สำหรับ attention projection และต่อ expert สำหรับ MoE weight ที่ stack กัน
• ต้นทุนหลักคือการ orthogonalize expert weight สำหรับ parameter ที่เป็น sharded ทีมงานจะ batch tensor ที่มี shape เหมือนกัน แล้ว all-to-all shard ให้กลายเป็น matrix สมบูรณ์ รัน Newton-Schulz เสร็จแล้ว all-to-all กลับไปยัง layout sharded เดิม การโอนถ่ายเหล่านี้ทำแบบ asynchronous เพื่อให้ในขณะที่ task หนึ่งรอ communication runtime ของ optimizer ก็เดินหน้า Muon task อื่นได้ บนโมเดลขนาด 1T เวลาที่ใช้ใน optimizer step คือ 0.2 วินาที
• ส่วนนี้ทำงานสัมพันธ์กับวิธีใช้ HSDP สำหรับโมเดล MoE — HSDP จะสร้าง FSDP replica หลายชุดและทำ all-reduce gradient ข้าม shard ที่ตรงกัน ทีมงานใช้ HSDP layout แยกกันระหว่าง non-expert weight กับ expert weight เพราะ non-expert weight ตัวเล็กกว่ามาก FSDP group ของมันจึงแคบลงได้ มักอยู่ในระดับ node หรือ rack เดียว ขณะที่ expert weight ถือ parameter ส่วนใหญ่และใช้ Muon compute ส่วนใหญ่ จึงใช้ expert sharding mesh ที่กว้างกว่า
• การแยก layout แบบนี้ยังเปิดทางให้ parallelism dimension ที่เป็นอิสระต่อกันซ้อนทับกันได้ เช่น CP=2 และ EP=8 สามารถรันบน 8 GPU ได้แทนที่จะต้องใช้ 16 GPU ใน mesh เดียว ช่วยลด communication กว้างๆ ของ non-expert state ขณะที่กระจายงาน optimizer ของ expert ไปบน GPU จำนวนมาก

💰 ราคาและการเข้าถึง

• Composer 2.5 ตัวมาตรฐานคิดราคาที่ $0.50 ต่อ 1M input token และ $2.50 ต่อ 1M output token ส่วน fast variant ที่ทีมระบุว่ามีความฉลาดเท่ากัน อยู่ที่ $3.00 ต่อ 1M input token และ $15.00 ต่อ 1M output token ราคานี้ต่ำกว่า fast tier ของ frontier model อื่นๆ และ fast variant คือ default option เช่นเดียวกับ Composer 2
• สัปดาห์แรกของการเปิดตัว Composer 2.5 ให้สิทธิ์การใช้งานเป็น 2 เท่า ผู้ใช้ Cursor สามารถเริ่มใช้ได้เลยจากภายในแอป

🚀 อนาคต — โมเดลใหญ่ที่กำลังเทรนกับ SpaceXAI

• ทีม Cursor ระบุชัดในบล็อกว่ากำลังร่วมงานกับ SpaceXAI เพื่อเทรนโมเดลที่ใหญ่กว่าเดิมอย่างมีนัยสำคัญตั้งแต่ศูนย์ โดยใช้ total compute มากกว่าเดิม 10 เท่า บน Colossus 2 ที่มีพลังเทียบเท่า H100 1 ล้านชิ้น ผสานกับเทคนิค data และ training ของทั้งสองทีม Cursor คาดว่านี่จะเป็นการก้าวกระโดดครั้งใหญ่ของขีดความสามารถโมเดล

🎯 สรุปและประเด็นที่น่าคิดต่อ

• Composer 2.5 ไม่ใช่แค่ upgrade เลขรุ่น แต่สะท้อนทิศทาง 3 อย่างที่น่าสนใจ: 1. การพัฒนา RL technique ที่ละเอียดขึ้น เพื่อแก้ปัญหา credit assignment ในงานยาว ผ่าน targeted textual feedback 2. การใช้ synthetic data ที่ scale ใหญ่และ grounded บน codebase จริง พร้อมรับมือกับ reward hacking ที่ซับซ้อนขึ้น 3. การ optimize ไม่ใช่แค่คะแนน benchmark แต่รวมถึงพฤติกรรมและสไตล์การสื่อสารของโมเดลด้วย
• สำหรับ developer หรือทีมที่ใช้ Cursor เป็น main IDE การได้โมเดลที่ทำคะแนนสูงกว่า Opus 4.7 ที่ xhigh setting ซึ่งเป็น default ของ Opus 4.7 พร้อมต้นทุนถูกกว่าราว 7 เท่า ถือเป็นข่าวดีในงานจริง ส่วน Opus 4.7 ใน max setting ยังครองคะแนนสูงสุดอยู่ แต่ต้องแลกด้วยต้นทุนต่อ task ที่สูงกว่า Composer 2.5 ราว 11 เท่า อย่างไรก็ดี การที่ Cursor พึ่งพา base model จากจีนและ compute จาก SpaceXAI ก็เปิดประเด็นเชิงยุทธศาสตร์ที่น่าจับตา ทั้งเรื่อง vendor identity และ supply chain ของ AI agent ในระยะยาว