6 คะแนน โดย GN⁺ 3 시간 전 | 4 ความคิดเห็น | แชร์ทาง WhatsApp
  • Anthropic เปิดตัว Claude Sonnet 5 ในวันที่ 30 มิถุนายน 2026 โดยตั้งใจจะมอบ ความสามารถในการทำงานแบบเอเจนต์ ที่ใกล้เคียงกับโมเดลระดับ Opus ที่มีราคาแพงกว่า แต่ในต้นทุนระดับ Sonnet
  • เมื่อเทียบกับ Sonnet 4.6 มีการปรับปรุงด้าน การให้เหตุผล การใช้เครื่องมือ การเขียนโค้ด และงานเชิงความรู้ และสามารถปรับ effort เพื่อเลือกสมดุลระหว่างต้นทุนและประสิทธิภาพสำหรับแต่ละงานได้ละเอียดขึ้น
  • ในการประเมินความปลอดภัย ระดับของพฤติกรรมไม่พึงประสงค์ อาการหลอน การประจบ การยอมรับคำขอที่เป็นอันตราย และความเปราะบางต่อการยึดครองจาก prompt injection ต่ำกว่า Sonnet 4.6 แต่พฤติกรรมไม่สอดคล้องบางส่วนสูงกว่า Opus 4.8 และ Claude Mythos Preview
  • ให้ใช้งานเป็น โมเดลพื้นฐาน ใน Free และ Pro และใช้ได้ใน Max, Team, Enterprise, Claude Code และ Claude Platform โดยชื่อโมเดลบน API คือ claude-sonnet-5
  • ราคา Claude Platform จนถึงวันที่ 31 สิงหาคม 2026 คือ $2 ต่อ 1 ล้านโทเค็นอินพุต และ $10 ต่อ 1 ล้านโทเค็นเอาต์พุต หลังจากนั้นจะเปลี่ยนเป็นอินพุต $3 และเอาต์พุต $15 และด้วย tokenizer ใหม่ จำนวนโทเค็นของอินพุตเดียวกันอาจอยู่ที่ประมาณ 1.0–1.35 เท่าตามประเภทของเนื้อหา

ขอบเขตการทำงานแบบเอเจนต์ที่กว้างขึ้นในระดับ Sonnet

  • Claude Sonnet 5 ถูกออกแบบให้เป็นโมเดล Sonnet ที่มีความเป็น เอเจนต์ มากที่สุดเท่าที่เคยมีมา และมุ่งเป้าไปที่การทำงานอัตโนมัติระดับที่เมื่อไม่กี่เดือนก่อนยังต้องใช้โมเดลที่ใหญ่และแพงกว่านี้
  • มีการปรับปรุงให้รองรับการวางแผน การใช้ เครื่องมือ เช่น เบราว์เซอร์และเทอร์มินัล และการทำงานอัตโนมัติได้ในโมเดลระดับ Sonnet
  • Sonnet 3.5, 3.6 และ 3.7 ได้กลายเป็นโมเดล Sonnet รุ่นแรก ๆ ที่แสดงความสามารถด้านการเขียนโค้ดและการใช้เครื่องมือให้กับนักพัฒนา และหลังจากนั้นการพัฒนาความสามารถแบบเอเจนต์ที่เด่นชัดที่สุดก็ปรากฏในโมเดลระดับ Opus
  • Sonnet 5 ลดช่องว่างกับ Opus 4.8 และให้ประสิทธิภาพที่ใกล้เคียง Opus 4.8 ในช่วงราคาที่ต่ำกว่า

การประเมินประสิทธิภาพและการปรับ effort

  • Sonnet 5 ปรับปรุงอย่างมากในหมวด ประสิทธิภาพแบบเอเจนต์ เช่น การให้เหตุผล การใช้เครื่องมือ การเขียนโค้ด และงานเชิงความรู้ เมื่อเทียบกับ Sonnet 4.6
  • ในการประเมินการค้นหาแบบเอเจนต์ BrowseComp และการประเมินการใช้งานคอมพิวเตอร์ OSWorld-Verified ให้ผลลัพธ์ที่ดีกว่า Sonnet 4.6 อย่างสม่ำเสมอ
  • ในการเปรียบเทียบตามระดับ effort Sonnet 5 มอบ ตัวเลือกต้นทุน-ประสิทธิภาพ ที่กว้างกว่า Opus 4.8
    • ที่ effort ระดับกลาง ประสิทธิภาพต่อราคาดีขึ้นอย่างมาก
    • ที่ effort ระดับสูง ในบางงานอาจให้ประสิทธิภาพทัดเทียม Opus 4.8
  • ผู้ใช้สามารถปรับระดับ effort ระหว่าง Sonnet 5 และ Opus 4.8 เพื่อเลือกสมดุลต้นทุนและประสิทธิภาพที่เหมาะกับโปรเจกต์ได้

รูปแบบการทำงานที่เห็นจากกรณีใช้งานช่วงแรก

  • พาร์ตเนอร์ที่ได้เข้าถึงก่อนประเมินว่า Sonnet 5 มีความเป็น เอเจนต์ มากกว่าโมเดล Sonnet รุ่นก่อนอย่างชัดเจน
  • มีกรณีที่มันทำงานซับซ้อนที่ Sonnet รุ่นก่อนมักหยุดกลางทางได้จนจบ และตรวจสอบผลลัพธ์ของตัวเองแม้ไม่ได้ร้องขออย่างชัดเจน
  • เวิร์กโฟลว์ที่ยืนยันแล้วครอบคลุมทั้งงานเขียนโค้ดและงานที่ไม่ใช่โค้ด
    • จัดการงานวิศวกรรมซอฟต์แวร์หลายขั้นตอนด้วยการเขียนโค้ด ใช้เครื่องมือ และดีบักอย่างต่อเนื่อง
    • ทำงาน 2 ขั้นตอนจนเสร็จ ได้แก่ อัปเดตระดับบัญชี Salesforce และส่งประกาศเปิดตัวไปยังรายชื่อผู้ติดต่อขององค์กร
    • ดำเนินการกับ pull request จริงหลายสิบรายการได้ด้วยตัวเองจนถึงผลลัพธ์ที่ผ่านการทดสอบและตรวจสอบแล้ว
    • ในการตรวจสอบบั๊ก สามารถเขียนการทดสอบเพื่อทำซ้ำปัญหา ลงมือแก้ไข stash การเปลี่ยนแปลง และยืนยันว่าบั๊กไม่กลับมาอีกได้ในครั้งเดียว
    • แสดงจุดแข็งในการติดตาม race condition, hidden test และสาเหตุรากแท้จริงของความล้มเหลวในโค้ดแบบ brownfield
  • ยังมีตัวอย่างการปรับปรุงด้านประสิทธิภาพและความเร็วในงานที่ไม่ใช่การเขียนโค้ด เช่น การวิจัยและวิเคราะห์ด้านกฎหมาย การสำรวจข้อมูลสดของ ClickHouse และเวิร์กโฟลว์ประกันภัยของ Pace

การประเมินความปลอดภัยและข้อจำกัดด้านไซเบอร์ซีเคียวริตี้

  • ในการประเมินความปลอดภัยก่อนเปิดใช้งาน Sonnet 5 มี ความปลอดภัย โดยรวมดีขึ้นเมื่อเทียบกับ Sonnet 4.6
  • ในด้านความปลอดภัยของเอเจนต์ การปฏิเสธคำขอที่เป็นอันตรายและความต้านทานต่อความพยายามยึดครองจากการโจมตีแบบ prompt injection ดีขึ้น
  • มีอัตราอาการหลอนและการประจบต่ำกว่า Sonnet 4.6 และในการตรวจสอบพฤติกรรมอัตโนมัติที่ตรวจดูพฤติกรรมไม่สอดคล้อง เช่น การร่วมมือในการใช้งานผิดวัตถุประสงค์และการหลอกลวง ก็ได้คะแนนต่ำกว่า ซึ่งหมายถึงปลอดภัยกว่า
  • อย่างไรก็ตาม เมื่อเทียบกับ Opus 4.8 และ Claude Mythos Preview ซึ่งมีความสามารถสูงกว่า ก็ยังมีอัตรา พฤติกรรมไม่สอดคล้อง บางส่วนสูงกว่าเล็กน้อยในการประเมินนี้
  • Sonnet 5 ไม่ได้ถูกฝึกมาโดยตั้งใจสำหรับงานด้านไซเบอร์ซีเคียวริตี้
    • สามารถทำงานไซเบอร์บางอย่างที่เป็นงานประจำและไม่ก่ออันตรายได้
    • ในการประเมินทักษะไซเบอร์ที่อาจเป็นอันตราย เช่น การพัฒนา software exploit มีประสิทธิภาพต่ำกว่า Opus 4.8 และ Mythos 5 อย่างมาก
    • ในการประเมินการพัฒนา exploit สำหรับช่องโหว่ของเบราว์เซอร์ Firefox ไม่สามารถสร้าง exploit ที่ทำงานได้สมบูรณ์ แต่มีอัตราความสำเร็จบางส่วนสูงกว่า Sonnet 4.6 เล็กน้อย
  • เนื่องจากมีความสามารถในงานประเภทนี้สูงขึ้นเล็กน้อยเมื่อเทียบกับรุ่นก่อน จึงเปิดตัวพร้อม กลไกป้องกันด้านไซเบอร์ ที่เปิดใช้งานเป็นค่าเริ่มต้น
    • ตรวจจับและบล็อกการใช้งานไซเบอร์ที่เป็นอันตรายแบบเรียลไทม์
    • เป็นกลไกป้องกันแบบเดียวกับที่ใช้กับ Claude Opus 4.7 และ 4.8
    • ความเสี่ยงด้านไซเบอร์ซีเคียวริตี้โดยรวมของ Sonnet 5 ถูกประเมินว่าต่ำ จึงเข้มงวดน้อยกว่ากลไกป้องกัน Fable 5 ที่บล็อกงานด้านไซเบอร์ซีเคียวริตี้ในวงกว้างกว่า
  • ดูผลการประเมินทั้งหมดได้ที่ Claude Sonnet 5 System Card

ขอบเขตการให้บริการ ราคา และ API

  • Claude Sonnet 5 ให้บริการในทุกแพ็กเกจ
    • เป็น โมเดลพื้นฐาน ของแพ็กเกจ Free และ Pro
    • ผู้ใช้ Max, Team และ Enterprise สามารถใช้งานได้
    • มีให้ใช้ใน Claude Code และ Claude Platform ด้วย
  • นักพัฒนาสามารถใช้ claude-sonnet-5 ได้ผ่าน Claude API
  • ราคาเปิดตัวบน Claude Platform จนถึงวันที่ 31 สิงหาคม 2026 อยู่ที่ $2 ต่อ 1 ล้านโทเค็นอินพุต และ $10 ต่อ 1 ล้านโทเค็นเอาต์พุต
  • หลังจากนั้นราคามาตรฐานจะเปลี่ยนเป็น $3 ต่อ 1 ล้านโทเค็นอินพุต และ $15 ต่อ 1 ล้านโทเค็นเอาต์พุต
  • เพื่อรองรับการใช้โทเค็นที่เพิ่มขึ้นในระดับ effort สูง มีการเพิ่ม ขีดจำกัดคำขอ ทั่วทั้ง Chat, Cowork, Claude Code และ Claude Platform
  • Sonnet 5 เป็นการอัปเกรดจาก Sonnet 4.6 แต่ใช้ tokenizer ที่อัปเดตแล้ว
    • วิธีประมวลผลข้อความเปลี่ยนไปเพื่อปรับปรุงประสิทธิภาพ
    • อินพุตเดียวกันอาจถูกแมปเป็นจำนวนโทเค็นประมาณ 1.0–1.35 เท่าตามประเภทของเนื้อหา
    • ราคาเปิดตัวถูกกำหนดให้การย้ายมาใช้ Sonnet 5 โดยรวมแทบไม่เพิ่มหรือลดต้นทุน

อัปเดตกราฟ BrowseComp

  • ในการแก้ไขเมื่อวันที่ 30 มิถุนายน 2026 มีการอัปเดต กราฟต้นทุน-ประสิทธิภาพ ของการประเมิน BrowseComp
  • เดิมกราฟนี้อิงข้อมูลจากวิธีที่ง่ายกว่า ซึ่งไม่สะท้อนระเบียบวิธีมาตรฐานที่ Anthropic ใช้ในการประเมินการค้นหาแบบเอเจนต์ ส่งผลให้ประสิทธิภาพของ Sonnet 5 ถูกประเมินต่ำไป
  • กราฟที่อัปเดตแล้วสอดคล้องกับระเบียบวิธีมาตรฐาน และแนวทางที่ใช้และกล่าวถึงใน system card ของ Sonnet 5
    • วิธีดังกล่าวใช้โควตา 10M โทเค็น การบีบอัด และการเรียกใช้เครื่องมือแบบโปรแกรม
  • มีการอัปเดตข้อความอธิบายรอบข้างไปพร้อมกันด้วย

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

 
dhkd63 2 시간 전

ไม่รู้ว่าเป็นเพราะชินกับ opus4.8 แล้ว หรือเพราะไม่ได้ใช้ sonnet มาพักใหญ่...
วันนี้ลองใช้ Sonnet แป๊บเดียวแล้วผิดหวังมาก
ถ้าเป็นเมื่อก่อนอาจจะพอใจมากก็ได้ แต่พบว่ามี hallucination ออกมาค่อนข้างเยอะกว่าที่คิด

 
sea715 2 시간 전

ขอ fable หน่อย..

 
seoseonyu 3 시간 전

ขอ Fable เร็วๆ หน่อย... 😢😢

 
GN⁺ 3 시간 전
ความคิดเห็นบน Hacker News
  • ถ้าดูกราฟต้นทุนต่อหนึ่งงานแล้ว Sonnet 5 ดูเหมือนว่าไม่ควรใช้เกินระดับความพยายามปานกลาง เพราะถ้าต้นทุนเท่ากัน Opus จะทำได้ดีกว่าเสมอ ดังนั้นถ้า Sonnet 5 ระดับกลางยังไม่พอ ข้อสรุปน่าจะเป็นการเปลี่ยนโมเดล ไม่ใช่เพิ่มระดับความพยายาม

    • ขอบคุณที่เปิดเผยข้อมูลแบบนี้ แต่ยิ่งนานก็ยิ่งตามยากขึ้นเรื่อย ๆ ผมเริ่มเสีย โมเดลในหัว ว่าโมเดลต่าง ๆ กับระดับความพยายามต่าง ๆ ให้ประสิทธิภาพแบบไหน และเหมาะกับงานแบบใด
      ในทางปฏิบัติผมมักใช้ค่าเริ่มต้นของ Claude Code ไปเลย และแค่นั้นก็ทำงานได้ดีพอแล้ว แต่ก็สงสัยว่าผู้ใช้คนอื่น ๆ ทดลองและปรับแต่งการตั้งค่าแบบนี้ให้เข้ากับโปรเจกต์ของตัวเองกันมากแค่ไหน
    • ตรงนี้มีตัวแปรสองอย่าง ในการสมัครสมาชิก Claude.ai ดูเหมือนว่า Sonnet จะถูกกว่า Opus มาก และเพราะแบบนั้นในเทียร์ Max จึงเคยมี แถบปริมาณการใช้งานเฉพาะ Sonnet อยู่เป็นเวลานาน
      อีกอย่างคือสำหรับงานบางประเภท ปริมาณโทเคนอินพุตล้วน ๆ เป็นสิ่งสำคัญที่สุด ตัวอย่างเช่นงานใช้งานคอมพิวเตอร์แบบมัลติโมดัล ไม่สามารถทำให้มีประสิทธิภาพขึ้นได้ด้วยการลดการอนุมานบน Opus ดังนั้นโมเดลราคาถูกอย่าง Sonnet จึงมีประโยชน์
    • ผมดูกราฟเดียวกันแล้วค่อนข้างแปลกใจกับตำแหน่งของเส้นเมื่อเทียบกับ Opus Sonnet 5 ให้ความรู้สึกเหมือน “ถ้า Opus มีระดับความพยายามต่ำมากเพิ่มมาอีกระดับหนึ่งล่ะ?”
    • ถ้าจะโต้แย้ง Sonnet อาจเร็วกว่าได้ แม้จะยังไม่แน่ชัดเพราะมันอาจใช้โทเคนมากกว่าสำหรับงานเดียวกัน แต่ในเวิร์กโฟลว์วนซ้ำแบบซิงโครนัส ก็มีโอกาสทำงานได้มากกว่า
      อย่างไรก็ตาม ในทางปฏิบัติการแก้ผลลัพธ์ที่โมเดลสร้างขึ้นกินเวลามากเกินไป ผมเลยคิดว่าโมเดลที่ฉลาดกว่า แม้จะช้ากว่า ก็ช่วยลดเวลารวมได้
    • เพราะเป็นโมเดล Sonnet จึงแน่นอนว่าดีกว่า Sonnet 4.6[0] ฉลาดกว่า เร็วกว่า และถูกกว่า แต่ก็ยังไม่ค่อยเห็นเหตุผลที่จะใช้แทน Opus 4.8 low หรือ GLM-5.2
      [0]: https://aibenchy.com/compare/anthropic-claude-sonnet-4-6-med...
  • ผมลองทดสอบด้วยเบนช์มาร์กของผม[0] แล้วพบว่าอยู่ใน ระดับ GLM-5.2 ต้นทุนแพงกว่า 2 เท่า แต่ความเร็วก็เร็วกว่า 2 เท่าเช่นกัน
    จุดอ่อนคือควิซความรู้ทั่วไปได้ 0/3 แทบไม่มีความรู้ในตัว, งานเรียกใช้เครื่องมือแบบซับซ้อนได้ 45/100 โดยบางครั้งเรียกเครื่องมือผิด และการแก้ปริศนาได้ 77 คะแนน โดยพลาดในเทสต์ประเภทล้างรถ
    [0]: https://aibenchy.com/compare/anthropic-claude-sonnet-4-6-med...

    • ในเบนช์มาร์กนั้น Gemini 3.5 Flash ออกมาเป็นโมเดลที่ดีที่สุด ซึ่งสำหรับผมแล้วไม่ค่อยสมเหตุสมผล
    • เช่นเคย การบอกว่าเร็วกว่า GLM-5.2 ไม่ได้มีความหมายมากนัก GLM-5.2 มีผู้ให้บริการหลายรายที่นำไปให้บริการ ดังนั้นความเร็วในการอนุมานจึงอาจแตกต่างกันมากตามผู้ให้บริการหรือช่วงเวลา
    • จากการเปรียบเทียบแบบไม่สมบูรณ์ที่ผมใช้ทั้งคู่กับงานวางแผนและลงมือทำ GLM5.2 รีบร้อนเกินไปและมีความกระตือรือร้นจะทำอะไรบางอย่างมากจนมักสร้างปัญหา เช่น พยายามดีพลอยหรือใช้ git แม้ในเวลาที่ไม่ควรทำ
      ในทางกลับกัน Sonnet 5 เป็นโมเดล Claude ที่ขี้เกียจกว่ามากเมื่อเทียบกับตัวอื่นที่ผมเคยใช้ และหลังจากไม่เพิ่มรายละเอียดแผนที่ขอไว้ พอถามก็โกหกว่าได้ทำแล้ว จากการวิเคราะห์[0] สำหรับผมดูไม่มีคุณค่า แต่อาจต่างออกไปสำหรับคนอื่น Fable ดีกว่าอย่างชัดเจนมาก
      [0]: https://artificialanalysis.ai/models/claude-sonnet-5
  • ในหลายเบนช์มาร์ก ถ้าใช้ระดับความพยายามสูงกว่าปานกลาง ต้นทุนต่อหนึ่งงานจะสูงกว่า Opus จึงเข้าใจยากว่าทำไมต้องใช้ตัวนี้แทนที่จะใช้ Opus ระดับความพยายามต่ำ ไปเลย
    สิ่งเดียวที่นึกออกคือกรณีเครดิต Opus หมด แน่นอนว่าน่าจะมีกรณีการคิดเงินผ่าน API อยู่บ้าง แต่ถึงอย่างนั้นก็คงใช้ Opus ระดับความพยายามต่ำอยู่ดี

    • ช่วงนี้มีหลายครั้งขึ้นเรื่อย ๆ ที่ต้องคอยห้าม Opus ไม่ให้ทำอะไรโง่ ๆ และต้องบอกทุกครั้งว่าอย่าทำให้งานซับซ้อนเกินไป
      ดูเหมือนโมเดลต่าง ๆ ถูกปรับให้ดึงเงินจากผู้ใช้และบริษัทมากกว่าการแก้ปัญหา ผมสั่งงาน Python ง่าย ๆ แค่ 2–3 บรรทัดอย่างชัดเจน แล้วไม่เข้าใจว่าทำไม Opus ถึงพยายามสร้างไลบรารีทั้งชุด
    • ผมคิดว่าเบนช์มาร์กที่อิงงานเฉพาะเจาะจงไม่ค่อยสะท้อน กรณีใช้งานแบบเอเจนต์ ในชีวิตประจำวันมากนัก ถ้าจัดการงานแยกทีละชิ้นและล้างบริบททุกครั้งได้ Opus ระดับความพยายามต่ำก็อาจให้ประสิทธิภาพแบบนั้นได้
      แต่เมื่อแก้ปัญหาจริงด้วยการวนซ้ำและสำรวจ บริบทจะค่อย ๆ ยาวขึ้น และตอนนั้น Opus มักจะแพงขึ้นมาก
    • โมเดล Opus รุ่นก่อน ๆ มีแนวโน้มสูงที่จะถูกยุติการรองรับในที่สุด และเมื่อเวลาผ่านไป ตัวนี้จะกลายเป็นโมเดลที่ถูกที่สุด วิธีขึ้นราคาตอนนี้ก็ดูเป็นแบบนั้น
    • ถ้าดูเบนช์มาร์กโค้ดดิ้งแบบเอเจนต์ในหน้า 117–118 ของ system card[0] แม้ในระดับความพยายามต่ำก็ยังทำได้ดีกว่าระดับใด ๆ ของ Sonnet 4.6 และราคาก็ดูค่อนข้างถูก ดังนั้นมันอาจเหมาะเป็นคนงานที่รับงานตามแผนของ Opus
      [0] https://www.anthropic.com/claude-sonnet-5-system-card
    • ความเร็ว คือเหตุผลใหญ่ บางครั้งต้องการให้งานง่าย ๆ เสร็จเร็ว ๆ แต่ถ้าต้องรอ 30–60 วินาทีกว่า Opus จะเริ่มคิด มันช้ามากจริง ๆ
  • Claude Sonnet 5 ว่ากันว่าถูกทำให้ “เหมือนเอเจนต์” มากที่สุดในบรรดา Sonnet ที่ผ่านมา สามารถวางแผน ใช้เครื่องมืออย่างเบราว์เซอร์หรือเทอร์มินัล และรันงานเองได้ในระดับที่เมื่อไม่กี่เดือนก่อนยังต้องใช้โมเดลที่ใหญ่กว่าและแพงกว่านี้
    ส่วนตัวผมทำงานแบบพัฒนาโดยมีเอเจนต์ช่วย มากกว่าปล่อยให้เอเจนต์ขับเคลื่อนการพัฒนาเต็มรูปแบบ เลยใช้ Sonnet 4.6 มากกว่า Opus แต่ประกาศนี้ไม่ได้ทำให้รู้สึกเชิงบวกเท่าไร ยิ่งโมเดลถูกปรับให้เหมาะกับการพัฒนาแบบเอเจนต์เต็มรูปแบบมากขึ้นเท่าไร มันก็มักยิ่งแย่ลงสำหรับงานพัฒนาแบบช่วยเหลือ และแม้จะสั่งอย่างเข้มงวดและเฉพาะเจาะจงมาก ก็ยังมักขยายงานเกินจำเป็น
    ช่วงไม่กี่สัปดาห์ที่ผ่านมาเริ่มย้ายไปใช้ K2.7 Code กับ GLM-5.2 มากขึ้นเรื่อย ๆ สำหรับงานช่วยเหลือก็มักเพียงพอ แถมเร็วมากและราคาถูก

    • หนึ่งในบริษัทเหล่านี้ ถ้าจะยืมคำพูดมาใช้ ก็น่าจะมีโอกาสชัดเจนที่จะลงทุนเวลากับโมเดลที่ปรับมาเพื่อ การพัฒนาโดยมีเอเจนต์ช่วย
      ปัญหาคือคนในบริษัทนั้นดูเหมือนจะเชื่อว่าอีก 1–2 ปีจะไม่มีใครทำงานแบบนั้นแล้ว
    • ช่วงนี้ใช้ Kimi K2.6 อยู่ ยังใช้ 2.7 ผ่านช่องทางอนุมัติของบริษัทไม่ได้ แต่ถ้ามันรู้อยู่แล้วว่าผมกำลังจะทำอะไร และผมอยากแบ่งกระบวนการออกเป็นชิ้น ๆ แล้วทำไปทีละส่วน มันก็ใช้ได้ดี
      ต้องแก้เพิ่มกว่า Opus นิดหน่อยก็จริง แต่เกณฑ์จริง ๆ อยู่ระหว่าง “ต้องอ่านทุกบรรทัด” กับ “เชื่อได้โดยไม่ต้องอ่านทุกบรรทัด” ซึ่งสำหรับผมยังไม่มีโมเดลไหนไปถึงอย่างหลัง และคิดว่าน่าจะยังเป็นแบบนั้นไปอีกพัก มันไม่ดีเท่า Opus ในการระดมสมองด้านสถาปัตยกรรมแล้วแปลงเป็นโค้ด แต่ก็ไม่ได้เป็นปัญหาตลอดเวลา และถ้าจำเป็นก็ใช้ Opus ได้
      ข้อดีคือแม้ในสัปดาห์ที่โค้ดเยอะ ก็มีพื้นที่หายใจได้ตลอดสัปดาห์โดยไม่ชนเพดานการใช้จ่ายตั้งแต่วันพุธหรือพฤหัสบดี อย่างไรก็ตาม ในทางปฏิบัติรู้สึกว่าต้อง “เบรก” K2.6 มากกว่า Opus เยอะ ถ้าแค่อยากถามคำถาม ต้องระวังมากขึ้นไม่ให้มันตีความแล้วพุ่งไปทำงานเขียนโค้ดทันที ทั้งสองตัวผมใช้ในโหมดวางแผน แต่กับ K2.6 ต้องใช้แบบป้องกันตัวมากกว่า Opus
    • ย้ายไปใช้ โมเดลโลคัล ที่รันบน M1 Mac Studio หน่วยความจำ 64GB อย่างเต็มตัวมาพักหนึ่งแล้ว ถึงอย่างนั้น ในกรณีหายากที่รู้สึกว่า Qwen3.6 แบบควอนไทซ์ในเครื่องยังไม่พอ ก็เชื่อมกับ Openrouter แล้วใช้ Kimi, GLM, Deepseek อะไรทำนองนั้น ในราคาบางส่วนเมื่อเทียบกับ Anthropic และรายอื่น ๆ
    • รู้สึกแทบเหมือนกัน และสถานการณ์ก็คล้ายกัน ข้อได้เปรียบที่ใหญ่กว่าตอนใช้ Sonnet คือ เวลาตอบสนอง
    • น่าจะลองใช้โมเดลของ OpenAI อย่าง GPT 5.5 ดู มันทำตามคำสั่งและขอบเขตที่กำหนดในพรอมป์ได้ดีกว่า และให้ความรู้สึกเป็น ผู้ช่วยเอเจนต์ ที่เก่งกว่าโมเดล Claude โดยไม่เสียความฉลาด
      งานส่วนใหญ่ของผมไม่ใช่แบบโยนงานทิ้งไว้แล้วลืม แต่ใกล้กับวิศวกรรมแบบเอเจนต์มากกว่า ผมยังมีส่วนร่วมต่อเนื่องตั้งแต่ขั้นวางแผน ตรวจผลลัพธ์ และมักถามเอเจนต์มากกว่าคนอื่นมาก วิธีที่เหมาะกับผมที่สุดคือกำหนดข้อกำหนด ขอบเขต การออกแบบ และบางครั้งถึงขอบเขตของโมดูลเฉพาะไว้ก่อน แล้วใช้มันเหมือนโหมด “autocomplete พลังสูง” ที่เติมช่องว่างให้
  • ดูเหมือนประสิทธิภาพต่อราคาก็แย่กว่า GLM 5.2 ด้วย ทั้งที่ GLM 5.2 มีแค่ 744B พารามิเตอร์
    ใน system card ระบุว่า “ในการค้นหาช่องโหว่ของ CyberGym Claude Sonnet 5 มีความสามารถน้อยกว่า Sonnet 4.6 และน้อยกว่า Opus 4.8 กับ Mythos 5 อย่างมาก”
    และยังบอกว่า “เช่นเดียวกับการประเมินอื่น ๆ ในส่วนนี้ ผลลัพธ์ได้มาภายใต้การปิดระบบป้องกันทั้งหมด เมื่อรันโดยเปิดมาตรการบรรเทาความเสี่ยงเริ่มต้น Sonnet 5 ได้ 0 คะแนนใน CyberGym”

    • ผมลองให้ GLM-5.2 กับ Sonnet 4.6 เขียนข้อความใหม่ เนื่องจากโมเดลภาษาขนาดใหญ่ไม่เป็น deterministic ผลลัพธ์จึงต่างกันโดยสิ้นเชิง GLM-5.2 ทำข้อผิดพลาดเล็ก ๆ น้อย ๆ ที่ต้องแก้ด้วยมือจำนวนมาก ในทางกลับกัน Sonnet ในรอบที่สองค้นหาและแก้ข้อผิดพลาดทั้งหมดได้
      การวางแผนและเขียนโค้ดก็คล้ายกัน GLM-5.2 ดูดี “บนกระดาษ” แต่ผลใช้งานจริงต่างออกไป
      ไม่ได้จะปกป้อง Claude หรือ GLM-5.2 สิ่งที่ผมตระหนักจากการใช้โมเดลภาษาขนาดใหญ่ทุกวันตั้งแต่เดือนพฤศจิกายน 2022 คือ การทดสอบทั่วไปต้องเอามาตรวจสอบกับโปรเจกต์ของตัวเอง ไม่มี “โมเดลเดียวครองทุกสิ่ง” และเราต้องหาโมเดลเฉพาะในกองฟางที่มีโมเดลเป็นพัน ๆ ตัว
      benchmark มีประโยชน์ แต่ยิ่งไปก็ยิ่งเหมือนสเปกอัตราสิ้นเปลืองน้ำมันในโฆษณารถยนต์ อัตราสิ้นเปลืองจริงของแต่ละคนไม่เหมือนกัน
    • ในที่สุดก็มีกลยุทธ์ธุรกิจที่ทำได้จริงออกมาแล้ว ขาย code monkey ที่ไม่รู้เรื่องความปลอดภัยในราคาถูก แล้วคิดพรีเมียมกับเอเจนต์ที่เก็บกวาดความเละเทะนั้นได้
    • ไม่ได้เจาะจงใครเป็นพิเศษ แต่หวังว่าสักวันคุณภาพการถกเถียงใน HN จะก้าวข้ามการเปรียบเทียบพื้นฐานแบบนี้ไปได้ ดูเหมือนทุกเธรดเปิดตัวโมเดลจะมีคอมเมนต์แบบเดิมซ้ำ ๆ
      เช่น “โมเดล X ดีกว่าหรือแย่กว่า Claude Z อยู่ Y% บน benchmark T”, “นั่นไม่มีความหมาย เป็นการจูนเพื่อ benchmark”, “ใช้กับการโค้ดประจำวันหรืองานเอเจนต์ไม่ได้ ความรู้สึกผิดไปหมด”, “แทบเหมือนกันและถูกกว่ามาก ยังไงผมก็ใช้”, “ความต่างด้านประสิทธิภาพเป็นขั้น ๆ ทำให้ต้นทุนต่ำของโมเดลเปิดชดเชยการเสีย productivity ไม่ได้ จึงไม่คุ้ม”
      ผมเป็นลูกค้าที่ไม่พอใจ Anthropic และก็เชียร์โมเดลเปิดกับปัญญาที่ไม่ถูกปิดกั้นจริง ๆ แต่ตอนนี้ไม่รู้ว่าจะหลุดจากการวนซ้ำของวาทกรรมเปิดตัวโมเดลที่กลายเป็นมีมไปแล้วได้อย่างไร ผมเองก็ไม่ใช่คนออกแบบโมเดลภาษาขนาดใหญ่หรือ benchmark และซาบซึ้งจริง ๆ กับความพยายามที่จะให้ข้อมูล แม้มันจะไม่สมบูรณ์ก็ตาม คนที่อ่านคอมเมนต์ประกาศแบบนี้อย่างต่อเนื่องส่วนใหญ่ก็น่าจะรู้สึกคล้ายกัน
  • Claude Sonnet 5 บรรยายเพลิแกนของตัวเองเหมือนเป็นห่าน
    “ห่านสีขาวกำลังขี่จักรยาน โดยยื่นปีกข้างหนึ่งไปข้างหน้าเพื่อจับแฮนด์ มีพื้นหลังสีขาวเรียบ ๆ และเส้นพื้นสีน้ำตาล”
    https://simonwillison.net/2026/Jun/30/claude-sonnet-5/

    • อาจเป็นหนึ่งในเพลิแกนที่แย่ที่สุดที่โมเดลภาษาขนาดใหญ่สร้างขึ้นเมื่อเร็ว ๆ นี้
      ในทางกลับกัน GLM 5.2 วาดเพลิแกน SVG แบบแอนิเมชันเต็มรูปแบบที่ยอดเยี่ยมและทำงานได้อย่างอิสระ
      https://simonwillison.net/2026/Jun/17/glm-52
  • วันนี้เผลอใช้ Sonnet 5 ไปนิดหน่อย และสำหรับงานพัฒนาซอฟต์แวร์ มันดูแย่กว่า Opus 4.8 ค่อนข้างมาก

  • สงสัยว่าความหวาดระแวงเกินเหตุเรื่องความปลอดภัยไซเบอร์ สุดท้ายจะทำให้โมเดลสร้างโค้ดที่ปลอดภัยน้อยลงหรือเปล่า การที่มันมีความสามารถสร้างโค้ดที่ปลอดภัยได้ ก็หมายความว่ามันรู้อะไรบางอย่างเกี่ยวกับความปลอดภัยไซเบอร์ และอาจมองได้ว่าด้วยความรู้นั้นมันก็แฮ็กธนาคารทั่วโลกได้เหมือนกัน

    • ในโมเดลสร้างภาพ การพยายามเซ็นเซอร์ภาพเปลือยทำให้เกิดปัญหาสารพัดกับการแสดงกายวิภาค โมเดลพวกนี้ก็น่าจะเจอปัญหาคล้ายกันในด้าน ความปลอดภัย
    • นั่นอาจเป็นเป้าหมายก็ได้
  • ผมค่อนข้างคาดหวังกับโมเดลนี้ เลยบอกให้ Opus planner ในสามโปรเจกต์ที่ต่างกันใช้ Sonnet แทน sub-agent ของ Opus เพื่อช่วยทดลอง HPC kernel ให้เร็วขึ้น แต่กลับไม่มีตัวไหนเขียนโค้ดแม้แต่บรรทัดเดียว และพวก Sonnet ก็เอาแต่วนไปวนมา เผา token ทิ้งไปเรื่อย ๆ
    จำไม่ได้ด้วยซ้ำว่าครั้งสุดท้ายที่เจอเรื่องแบบนี้กับ Opus ในโค้ดเบสของผมคือเมื่อไหร่ ตอนนี้กำลังย้อนกลับไปใช้แบบเดิม

    • เรื่องแบบนี้เคยเกิดขึ้นมาก่อนตอนปล่อยโมเดลใหม่ ๆ ตอน Opus 4.7 ออกมาก็ “กำลังทำงาน” นานกว่า 20 นาที จนผมปิดทิ้งไปเลยแล้วรอถึงวันถัดไป
      แล้วมันก็หายไปเอง
  • ประเด็นสำคัญคืออันนี้: “Sonnet 5 เป็นการอัปเกรดจาก Sonnet 4.6 แต่ใช้ tokenizer ที่อัปเดตแล้ว ซึ่งเปลี่ยนวิธีที่โมเดลประมวลผลข้อความเพื่อเพิ่มประสิทธิภาพ คล้ายกับการเปลี่ยน tokenizer ที่นำมาใช้ใน Claude Opus 4.7 ต้นทุนที่ต้องแลกคือ input เดิมอาจถูกแมปเป็น token มากขึ้น โดยคร่าว ๆ อยู่ที่ 1.0–1.35 เท่า ขึ้นกับประเภทของคอนเทนต์ ราคาช่วงเปิดตัวถูกตั้งไว้ให้การย้ายมาใช้ Sonnet 5 โดยรวมแล้วแทบเป็นกลางด้านต้นทุน”

    • งั้นหลังพ้นช่วงเปิดตัว ก็หมายความว่าจะตั้งราคาให้ Sonnet 5 แพงขึ้น 100–135% ใช่ไหม?
    • “มีสองวิธีในการขึ้นราคา: (1) ขึ้นราคาต่อ token หรือ (2) เพิ่มจำนวน token ที่เราสร้างในนามของผู้ใช้ เราสัญญาว่าจะไม่ทำ (2) แบบมุ่งร้าย สัญญาครับ”