1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในตารางประเมินโมเดลเขียนโค้ดของ Cursor, Fable 5 Max คว้าอันดับ 1 ด้วย 72.9% กลายเป็นจุดอ้างอิงของการแข่งขันในกลุ่มบน
  • ตระกูล Fable 5 ครองอันดับ 1 ถึง 4 ทั้งหมด ได้แก่ Max, Extra High, High และ Medium โดยทิ้งห่างจากโมเดลกลุ่มอื่นอย่างชัดเจน
  • ตั้งแต่อันดับ 5 เป็นต้นไปมี Opus 4.7 Max 64.8%, GPT-5.5 Extra High 64.3%, Fable 5 Low 64.2%, Opus 4.8 Max 63.8%, และ Composer 2.5 63.2% ตามมา
  • CursorBench 3.1 เพิ่มงานที่เน้น ความเข้าใจ codebase, การหาบั๊ก, การวางแผน, และ code review พร้อมปรับปรุงเกณฑ์การให้คะแนนของงานแก้ไขบางส่วน
  • ต้นทุนเฉลี่ยต่องานคำนวณจากราคาโทเค็นที่เปิดเผยต่อสาธารณะและจำนวนโทเค็นที่ใช้ในแต่ละงาน โดย ความต่างของคะแนนเพียงเล็กน้อย อาจไม่มีนัยสำคัญทางสถิติ

Fable 5 กวาดอันดับหัวตาราง

  • ตาราง CursorBench 3.1 เปรียบเทียบอันดับ คะแนน ต้นทุนเฉลี่ยต่องาน และตัวเลขที่เกี่ยวข้องกับการใช้งานของแต่ละโมเดลไว้พร้อมกัน
  • อันดับ 1 ถึง 4 เป็นโมเดลในตระกูล Fable 5 ทั้งหมด
    • Fable 5 Max: 72.9%, $18.02, 63,842, 76
    • Fable 5 Extra High: 72.0%, $13.74, 48,754, 63
    • Fable 5 High: 70.6%, $10.81, 37,173, 54
    • Fable 5 Medium: 69.8%, $8.27, 28,507, 47
  • ในช่วงอันดับ 5~10 มีโมเดล Opus, GPT-5.5, Fable และ Composer ปะปนกัน
    • Opus 4.7 Max: 64.8%, $11.02, 62,989, 96
    • GPT-5.5 Extra High: 64.3%, $4.37, 17,905, 46
    • Fable 5 Low: 64.2%, $5.70, 18,882, 36
    • Opus 4.8 Max: 63.8%, $7.59, 77,370, 60
    • Composer 2.5: 63.2%, $0.55, 15,152, 37
    • GPT-5.5 High: 62.6%, $3.59, 13,329, 40

คะแนนของโมเดลกลุ่มกลางถึงล่าง

  • อันดับ 11~20 ส่วนใหญ่เป็นโมเดล Opus, Sonnet และ GPT-5.5
    • Opus 4.8 Extra High: 62.1%, $6.14, 55,622, 54
    • Opus 4.7 Extra High: 61.6%, $7.11, 43,942, 72
    • Sonnet 5 Max: 61.2%, $6.87, 93,485, 93
    • Opus 4.7 High: 59.4%, $5.01, 32,227, 59
    • GPT-5.5 Medium: 59.2%, $2.22, 9,065, 35
    • Opus 4.8 High: 58.4%, $4.41, 36,788, 45
    • Sonnet 5 Extra High: 58.4%, $5.23, 58,228, 86
    • Sonnet 5 High: 57.0%, $3.74, 41,735, 66
    • Opus 4.8 Medium: 56.6%, $3.83, 31,684, 41
    • Sonnet 5 Medium: 54.9%, $2.57, 27,469, 53
  • อันดับ 21~36 มี GLM, Kimi, Gemini, Sonnet, Composer และอื่น ๆ รวมอยู่ด้วย
    • GLM 5.2 Max: 54.6%, $3.11, 51,312, 83
    • Opus 4.8 Low: 54.3%, $2.93, 22,726, 36
    • Opus 4.7 Medium: 52.7%, $2.93, 19,193, 41
    • Kimi K2.7 Code: 52.7%, $1.92, 32,902, 70
    • Composer 2: 52.2%, $0.56, 14,163, 40
    • GLM 5.2 High: 50.7%, $2.46, 30,621, 76
    • Gemini 3.5 Flash: 49.8%, $1.94, 35,105, 79
    • Sonnet 4.6 Max: 49.0%, $3.09, 40,280, 55
    • GPT-5.5 Low: 48.8%, $1.19, 4,923, 24
    • Sonnet 4.6 High: 48.8%, $3.06, 37,352, 57
    • Opus 4.7 Low: 48.3%, $1.87, 13,164, 29
    • Sonnet 5 Low: 47.7%, $1.46, 17,028, 37
    • Kimi 2.6: 47.6%, $1.27, 24,783, 56
    • Sonnet 4.6 Medium: 46.0%, $2.64, 31,360, 50
    • Sonnet 4.6 Low: 41.5%, $1.89, 21,211, 50
    • Kimi 2.5: 31.9%, $0.87, 9,446, 30

ขอบเขตการประเมินของ CursorBench 3.1

  • CursorBench 3.1 นำโจทย์ที่เน้นความเข้าใจ codebase, การหาบั๊ก, การวางแผน และ code review เข้ามาใช้
  • เกณฑ์การให้คะแนนของ งานแก้ไข บางส่วนก็ได้รับการปรับปรุงด้วย
  • CursorBench 3.0 เป็นชุดงานเริ่มต้นที่เน้นโจทย์ด้านการแก้ไข, refactoring และการแก้บั๊ก

การคำนวณต้นทุนและข้อจำกัดในการตีความ

  • ต้นทุนเฉลี่ยต่องานคำนวณโดยใช้ per-million-token pricing ที่เปิดเผยต่อสาธารณะของแต่ละโมเดล
  • รวมราคาของ input, cache read, cache write และ output ทั้งหมด
  • จากนั้นนำราคาไปคูณกับจำนวนโทเค็นที่แต่ละโมเดลใช้ในงาน CursorBench 3.1 แล้วหาค่าเฉลี่ยทั้งชุดงาน
  • ผลลัพธ์ยังคงมี ความผันผวน อยู่ และความต่างของคะแนนเพียงเล็กน้อยอาจไม่มีนัยสำคัญทางสถิติ

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News
  • ค่อนข้างสงสัยอยู่เล็กน้อย
    ในเบนช์มาร์กของ Cursor ระบุว่าโมเดลของ Cursor อย่าง Composer 2.5 ดีพอๆ กับ Opus 4.8 max และ GPT-5.5 xhigh แต่ราคาถูกกว่ามาก
    แต่ในการทดสอบของ Artificial Analysis นั้น Composer 2.5 ตามหลังอยู่พอสมควร: https://artificialanalysis.ai/agents/coding-agents
    ถ้าดูเบนช์มาร์ก DeepSWE จะเห็นว่า GPT-5.5 xhigh ได้ 64, Opus 4.8 max ได้ 56, ส่วน Cursor 2.5 ได้ 16
    ไม่ได้สงสัยว่า Cursor อาจเหมาะกับบางคน แต่ข้ออ้างที่ว่ามันเป็นคู่แข่งของ Opus 4.8 หรือ GPT-5.5 ยังดูน่ากังขาอยู่ มันดูสะดวกเกินไปที่ในเบนช์มาร์กของตัวเองทำได้ดี แต่ในเบนช์มาร์กของบุคคลที่สามกลับตามหลังมาก

    • ผมทำงานอยู่ที่ Cursor ตอนที่เปิดตัว Composer 2.5 มันทำผลงานได้ค่อนข้างแข่งขันได้ในเบนช์มาร์กรวมของ AA และถ้าจำไม่ผิดน่าจะอยู่อันดับ 3 โดยรวม
      ช่วงหลัง AA เปลี่ยนไปใช้ DeepSWE ซึ่งเป็นเบนช์มาร์กที่โฟกัสงานระยะยาวมากขึ้นมาก Composer ยังไม่เก่งกับงานแบบนั้นนัก เลยกำลังพัฒนาให้ดีขึ้นในโมเดลถัดไป
      โดยรวมแล้ว Composer ทำได้ดีในบางเบนช์มาร์ก และไม่ดีในบางที่ ถึงอย่างนั้นผมก็ยังมองว่ามันเป็นโมเดลที่มีความสามารถมากเมื่อเทียบกับช่วงราคาปัจจุบัน ถ้าเห็นพฤติกรรมเฉพาะหรือจุดอ่อนอะไร แจ้งที่นี่หรืออีเมลหา lrobinson at cursor.com ได้
    • ไม่ได้เข้าใจยากเลยว่าเกิดอะไรขึ้น มีการทำ reinforcement learning ให้เข้ากับแพตเทิร์นในข้อมูลของตัวเองและความสามารถบางอย่างอยู่แล้ว ก็ย่อมสร้างเบนช์มาร์กที่สอดคล้องกับชุดฝึกขึ้นมาโดยธรรมชาติ
      ที่น่าขำคือ ในขอบเขตแคบๆ ที่ “ลูกค้าหลัก” ของ Cursor สนใจจริงๆ เบนช์มาร์กนั้นอาจแม่นกว่า Artificial Analysis ก็ได้ นอกเหนือจากนั้นก็มองว่าเป็นเพียงอีกหนึ่ง data point
    • DeepSWE มีข้อบกพร่องอยู่บ้างตรงที่ใช้ execution harness ของตัวเองเท่านั้น และถ้าเป็นโมเดลที่ฮาร์เนสนี้ไม่รองรับดีพอ ก็จะมีปัญหา
      มีหลักฐานมากพอว่าฮาร์เนสมีผลอย่างมากต่อวิธีที่โมเดลเหล่านี้ทำงาน แต่ DeepSWE ตัดปัจจัยนี้ทิ้งไปทั้งหมด เป็นไปได้มากว่าพวกเขาแค่ตรวจสอบว่ามันทำงานได้ดีกับโมเดลไม่กี่ตัวที่ตัวเองชอบ
      อย่างที่มีรายงานใน GitHub issue ฮาร์เนสนี้ไม่ใช้แคช จึงมีปัญหาเรื่อง การคำนวณต้นทุน ด้วย ไม่มีเบนช์มาร์กไหนสมบูรณ์แบบ แต่เรื่องนี้อธิบายความต่างระหว่างเบนช์มาร์กได้พอสมควร
    • เซสชันของ Cursor แทบจะเหมือนกับสิ่งที่ใช้ฝึก reinforcement learning ให้โมเดล Composer เลย เบนช์นี้กับข้อมูลฝึกจึงควรอยู่ใน distribution เดียวกันแทบทั้งหมด
    • ไม่ค่อยรู้เรื่องเบนช์มาร์กนัก แต่ผมใช้ Composer 2.5 มาเยอะ และในการใช้งานจริงมันทำงานได้ดีทีเดียว
  • การเลือกวางแกนแบบนี้ค่อนข้างทำให้งง คิดว่าด้านซ้ายน่าจะเป็นฝั่งที่ถูกที่สุด แต่กลับกลายเป็นแพงที่สุด
    เข้าใจได้ว่าต้องการจัดวางให้มุมขวาบนเป็นตำแหน่งที่ดีที่สุด แต่การกลับทิศของ แกนต้นทุน ก็ยังไม่ค่อยตรงสัญชาตญาณอยู่ดี
    พักเรื่องนั้นไว้ก่อน ผมทำงานอิมพลีเมนต์ที่ยากมากจนเอเจนต์แทบทำไม่ไหวทั้งวันทุกวัน และสำหรับงานที่ต้องการ “การตรวจสอบจริงจัง” ผมต้องคง Opus แบบ max ไว้มาได้สักพักแล้ว รู้สึกว่านี่แทบเป็นวิธีเดียวที่จะทำให้ Opus ทำงานได้ใกล้เคียง GPT-5.5 xhigh
    ถ้าใช้ GPT-5.5 แบบสมาชิก หน้าต่างบริบทจะเล็ก คือ 400k แต่ใช้ได้จริงประมาณ 258k ผมเลยใช้งาน Opus อยู่
    ความต่างคือ GPT-5.5 xhigh เร็วมากในกรณีใช้งานจริงส่วนใหญ่ ทั้งอิมพลีเมนต์ภาพรวมก็มีประสิทธิภาพ และกับคำถามที่ไม่ต้องคิดลึกก็ปรับตัวมาตอบได้เร็ว
    ในทางกลับกัน Opus 4.8 Max จะใช้เวลาครุ่นคิดทุกอย่างนานเกินจำเป็น แม้แต่อิมพลีเมนต์ง่ายๆ ก็อาจกินเวลาหลายชั่วโมง เลยใช้มันกับงานวางแผนและรีวิวเป็นหลัก
    Fable ดีกว่ามากในเรื่องการคิดแบบปรับตัวและการตอบสนองเร็ว แต่ก็น่าจะยังสู้ GPT-5.5 xhigh ไม่ได้อยู่ดี ทุกคนน่าจะพูดเรื่องข้อดีข้อเสียกันมาพอแล้ว และน่าเสียดายที่ในงานยากของผมมันยังไม่ใช่ผู้ลงมืออิมพลีเมนต์ที่ไว้ใจได้ มันยังเป็นพื้นที่ของ GPT และ Fable ยังมีแนวโน้มจะทิ้งช่องโหว่ขนาดใหญ่และอันตรายไว้ในตัวอิมพลีเมนต์ หากไม่คอยดูแลอย่างใกล้ชิด

    • ในประโยคที่ว่า “ทำงานอิมพลีเมนต์ที่ยากมากจนเอเจนต์แทบทำไม่ไหวทั้งวันทุกวัน” มีอะไรที่พิสูจน์ได้สักอย่างไหม หรือแค่ต้องเชื่อกันไปเอง? ฟังดู อัตวิสัย จนน่าขำทั้งหมด
    • ถ้า Fable ทิ้งช่องโหว่อันตรายไว้ในอิมพลีเมนต์ ก็ทำให้นึกว่าน่าจะเอา GLM หรือ DeepSeek มาผสมเพื่อใช้เป็น code red team ได้
      Fable ดูจะมองไม่เห็นเรื่องความปลอดภัยตั้งแต่ระดับการออกแบบ[0] ขณะที่โมเดลเปิดกลับทำด้านนี้ได้ค่อนข้างดี
      [0] ยังไม่ชัดว่า GPT-5.6 จะเป็นอย่างไร แต่ดูจากบล็อกก็น่าจะมี safety filter ที่ระวังเกินเหตุคล้ายๆ กัน
      ที่น่าสนใจคือโพสต์เปิดตัว Opus ช่วงหลังๆ กลับคุยว่าตั้งใจลดความสามารถด้านความปลอดภัยลงบางส่วน “during its [Opus 4.7] training we experimented with efforts to differentially reduce these ["cyber"] capabilities”
    • เป็นสไตล์ Gartner น่ะ มุมขวาบนคือจุดที่ทุกคนอยากไปอยู่
    • เห็นด้วยว่าทำไมถึงกลับแกน x ก็ดูน่างง กราฟนี้ทำให้คนดูทั่วไปเข้าใจได้ยากมาก
    • สงสัยว่าเรื่อง “ถ้าใช้ GPT-5.5 แบบสมาชิก หน้าต่างบริบทจะเล็ก” นี่ คุณรู้สึกว่ามันสร้างความต่างในการทำงานจริงไหม
      ผมใช้ 5.5 high/xhigh เพื่อปรับแต่งและทำเบนช์มาร์กกับโค้ดเบส C อยู่ และแค่อ่านโค้ดเริ่มต้นก็แทบจะกิน หน้าต่างบริบท แรกไปเกือบหมดแล้ว
      เซสชันมีการบีบอัดอัตโนมัติราว 5~15 ครั้ง แต่เพราะงานแต่ละครั้งส่วนใหญ่ยังโฟกัสอยู่กับหน้าต่างล่าสุด มันเลยยังพอทำงานได้ดี
      สำหรับงานเขียนโปรแกรม จุดแข็งของ GPT ดูเหนือกว่า Opus มากพอที่จะชดเชยความต่างของหน้าต่างบริบทได้
  • ยากจะเชื่อว่า Composer 2.5 จะดีขนาดนั้น ลองเทียบกับ GLM 5.2 กับ Opus 4.6 แล้วรู้สึกว่ามันขาดความลึกในการคิดปัญหาและ การให้เหตุผลเชิงวิพากษ์
    มันเหมาะกับการนำแผนที่โมเดลอื่นวางไว้ไปลงมือทำ แต่ถึงอย่างนั้นก็มักมีการแก้โค้ดแปลก ๆ ที่ต่างจากวิธีการทำงานจริงของไฟล์รอบข้างอยู่มาก

    • ตอนนี้ไม่ได้ใช้ Cursor แล้ว แต่ตอนที่เคยใช้เมื่อไม่นานมานี้ประสบการณ์ก็คล้ายกัน วางแผนด้วย Opus, ลงมือทำด้วย Composer, แล้วเก็บงานด้วย Opus
      Composer จะเก่งเมื่อมีแผนที่ดี แต่ไม่ได้อยู่ในระดับน่าทึ่ง สิ่งที่ชอบมากจริง ๆ คือ ความเร็ว
      งานที่ Opus ใช้เวลา 30 นาที Composer ทำเสร็จใน 5~10 นาที แน่นอนว่าผลลัพธ์ไม่ได้สมบูรณ์แบบ จึงต้องมีขั้นตอนเก็บงานด้วย Opus หรือ Codex
      ท้ายที่สุดมันเป็นเรื่องของสมดุล เปลี่ยนแปลงตลอด และขึ้นอยู่กับปัญหาที่กำลังแก้ทั้งหมด ผมพยายามยืดหยุ่นและปรับตามกระบวนการที่เวิร์กที่สุดในช่วงนั้น
    • พอเห็นแบบนี้ก็รู้สึกว่าเป็นแค่ เส้นแบ่งที่แกว่งไปมา ไม่ได้สงสัยประสบการณ์ส่วนตัวของใครนะ เดือนก่อนผมลองใช้ Composer 2.5 ผ่าน Grok กับเครดิตของบัญชี X Premium
      ไม่ได้สร้างจรวดอะไร แต่ก็น่าประทับใจทีเดียว ทุกโมเดลมีจังหวะทำอะไรโง่ ๆ บ้าง แต่สิ่งที่ผมขอให้ทำมันก็ทำได้ค่อนข้างดี และมีผลลัพธ์ที่น่าทึ่งอยู่เหมือนกัน
      บน Grok มันเร็ว และเมื่อเทียบกับโมเดลอื่นที่ผมใช้เยอะ ผมว่ามันดีกว่า gemini 3.1 สำหรับผม 3.5 กับ antigravity แย่กว่า gemini cli รุ่นก่อนหน้า ส่วน Opus 4.6 นั้นใกล้เคียงกัน ผมยังไม่ได้ลองโมเดลใหม่กว่านี้ของ Claude Code
  • ถ้าผมอ่านกราฟถูกต้อง Fable ใช้ โทเค็นน้อยกว่า sonet กับ opus ในการทำงานเดียวกันให้สำเร็จ ถ้าอย่างนั้นก็เป็นเรื่องดี
    ช่วงหลังรู้สึกเหมือนพยายามได้ผลลัพธ์ที่ดีขึ้นด้วยการพ่นโทเค็นออกมามหาศาล แต่ถ้าโมเดลดีขึ้นได้โดยที่ตัวมันเองไม่ได้สร้างโทเค็นเพิ่ม แบบนั้นรู้สึกว่าเป็นความก้าวหน้าจริง
    คำถาม 1: ทำไม จำนวนขั้นตอน ถึงสำคัญในกราฟนี้? มันบอกอะไร?
    คำถาม 2: ทำไมถึงกลับแกนแนวนอนให้ 0 ไม่ได้อยู่ที่จุดกำเนิดแต่อยู่ทางขวา? นี่เป็นวิธีฉลาดแบบใหม่หรือ? เหมือนไม่เคยเห็นมาก่อน

  • น่าสนใจที่ Opus 4.7 ออกมาดีกว่า 4.8 น่าเสียดายที่ไม่ได้ทดสอบ 4.6 ด้วย เมื่อวานผมเห็นคนหนึ่งโดนล้อเพราะยืนกรานที่นี่ว่า 4.6 ดีกว่ารุ่นถัดมา
    แต่ เบนช์มาร์ก มักมีความพลิกแพลงเสมอ ใน DeepSWE นั้น GPT-5.5 ชนะ Opus-4.8 แบบทิ้งห่างพอสมควร แต่ใน FrontierCode กลับตรงกันข้าม
    เบนช์มาร์กเดียวที่เชื่อถือได้คือเวิร์กโหลดจริงของตัวเอง

  • ทุกครั้งที่มีเบนช์มาร์กใหม่ออกมา โมเดลจีนมักได้ผลต่ำกว่าที่คาดมากเมื่ออิงจากเบนช์มาร์กเดิม แล้วพอเวลาผ่านไปก็กลับขึ้นมาใหม่

    • เวทมนตร์ของการ distillation
  • อยากให้เว็บพวกนี้ทุกแห่งแสดงกราฟ Pareto frontier ด้านต้นทุน/ประสิทธิภาพ สิ่งสำคัญหลัก ๆ ก็มีแค่สองอย่างนั้น อาจใส่พารามิเตอร์ความเร็วเพิ่มแล้วทำเป็นสามมิติก็ได้
    https://paraplouis.github.io/llm-pareto-frontier/ เป็นกราฟที่ดีที่สุดเท่าที่ผมเคยเห็น แต่ไม่ได้อัปเดตบ่อยเท่าที่อยากได้

    • เว็บนั้นไม่ค่อยมีประโยชน์ เพราะไม่ได้สะท้อนโทเค็นสำหรับการคิดกับแคช รวมถึงประสิทธิภาพของมัน
      GLM5.2 มี กองเชียร์อู่เหมา ทุกคนที่ PLA ระดมมาบนอินเทอร์เน็ตช่วยโหมโปรโมต แต่กระบวนการคิดมันเยิ่นเย้อเกินไปจนเห็นข้อด้อย
      โมเดลของ Anthropic ก็มีปัญหาเดียวกัน แต่เริ่มต้นจากฐานความฉลาดจริงที่สูงกว่ามาก
      นั่นแหละว่าทำไมการเปรียบเทียบที่พอเชื่อถือได้ตอนนี้จึงดูที่ ต้นทุนรวม ในการทำงานให้เสร็จ แทนที่จะดูจากต้นทุนโทเค็นอินพุต/เอาต์พุตแบบลอย ๆ
  • ผมใช้ Composer 2.5 กับ GPT 5.5 มาเยอะทั้งใน Cursor และ Codex และคำกล่าวที่ว่า Composer 2.5 มีประสิทธิภาพใกล้ GPT 5.5 นั้น เหลวไหลสิ้นดี
    มันเร็วกว่า แต่คุณภาพไม่อยู่ในระดับนั้นเลย
    แถม Composer ยังใช้ได้เฉพาะเมื่อมีสมาชิก Cursor แบบรายเดือน ดังนั้นการเทียบค่าใช้จ่ายก็ไม่มีความหมาย ถ้าเป็นสมาชิก OpenAI ราคาใกล้กัน คุณใช้โมเดลที่ดีกว่าได้มากพอ ๆ กัน

  • ส่วนที่น่าสนใจที่สุดคือต้นทุน GPT 5.5 กับ sonnet 5 มีต้นทุนเท่ากับ GLM 5.2 แต่เป็นโมเดลที่มีความสามารถมากกว่า

  • โมเดลของ Cursor ทำผลงานได้ยอดเยี่ยมในเบนช์มาร์กของ Cursor นี่มันข่าวด่วน 11 โมงชัด ๆ
    แต่โมเดลอื่นทั้งหมดก็อยู่ในตำแหน่งที่ดูสมเหตุสมผลพอควรจากประสบการณ์ใช้งานตรงของผม
    Fable มีต้นทุนสูงกว่า 10 เท่า แต่ในหลายกรณีก็กดโมเดลอื่นมิด อย่างไรก็ตาม บางครั้งมันไม่ใช่การเลือกระหว่างของถูกกับของแพง แต่เป็นการเลือกระหว่างของแพงที่ทำได้กับของที่ทำไม่ได้เลย เหมือนโมเดลอื่น ๆ คุณต้องเรียนรู้ว่าเส้นแบ่งนั้นอยู่ตรงไหน