Sonnet 5.5 หรือ Opus 5.5: ควรเลือก Agent ตัวไหนมารับงานนี้?

Anthropic เปิดตัว Claude Sonnet 5.5 เมื่อวันที่ 28 กันยายน เพียงหกวันหลังจากเปิดตัว Opus 5.5 ด้วยราคา $2 ต่อ 1 ล้าน input token และ $10 ต่อ 1 ล้าน output token ทำให้ Sonnet 5.5 มีราคาเพียงครึ่งเดียวของ Opus 5.5 ที่คิด $4 และ $20 และบนหน้าเปิดตัว คะแนนของ Sonnet 5.5 ยังเกาะกลุ่มตามหลัง Opus 5.5 อยู่เพียงไม่กี่จุดในเกือบทุกตาราง แถมยังทำคะแนนแซงหน้าบน Terminal-Bench 4.0 ซึ่งเป็นเบนช์มาร์กที่ Anthropic รันด้วยตัวเอง สำหรับทีมที่ใช้งาน coding agent หลายตัว ทางเลือกที่ดูเย้ายวนใจที่สุดย่อมเป็นการจับ Agent ทุกตัวไปใช้ Sonnet เพื่อกอบโกยส่วนต่างของต้นทุนที่ประหยัดได้

แต่แผนภูมิแสดงคะแนนแยกตามระดับ effort ในหน้าเดียวกันกลับบอกอีกอย่าง ตัวเลขพาดหัวของ Terminal-Bench นั้นได้มาจากระดับ effort สูงสุดของ Sonnet ซึ่งมีค่าใช้จ่ายสูงถึง $12.54 ต่อการทดสอบหนึ่งครั้ง ในขณะที่หากดูการตั้งค่าที่คุณเปิดทิ้งไว้ให้ทำงานได้ทั้งวัน อันดับจะพลิกกลับทันที: Opus 5.5 ที่ระดับ medium ทำได้ 57.6% ด้วยต้นทุน $2.94 ส่วน Sonnet 5.5 ที่ระดับ high ทำได้ 43.0% ด้วยต้นทุน $1.94 และ Sonnet จะแซง Opus ที่ระดับ medium ได้ก็ต่อเมื่อเร่งขึ้นไปถึงระดับ xhigh เท่านั้น ซึ่งได้ 61.5% แต่ต้องแลกด้วยต้นทุน $5.30

สรุปประเด็นสำคัญ (TL;DR)

กำหนดค่างานที่มีขอบเขตชัดเจนให้ใช้ Sonnet 5.5 ที่ระดับ medium เป็นค่าเริ่มต้น ส่งงานที่ยาว คลุมเครือ หรือคาบเกี่ยวหลายส่วนไปให้ Opus 5.5 แทนที่จะดัน Sonnet ขึ้นไปที่ xhigh: จากกราฟเบนช์มาร์กการเขียนโค้ดแยกตาม effort ทั้งสามรายการที่ Anthropic เผยแพร่ Opus ที่ระดับ high ทำคะแนนชนะ Sonnet ที่ระดับ xhigh ได้ในราคาที่ใกล้เคียงกันหรือถูกกว่า กำหนดสิ่งนี้เป็นกฎที่ชัดเจนไว้บนตัว Agent แทนที่จะปล่อยให้เป็นแค่ความชอบส่วนตัวในหัวของใครสักคน: กำหนดหนึ่ง Agent ต่อหนึ่งระดับโมเดลและ effort พร้อมระบุเงื่อนไขการส่งต่องาน (escalation) ให้ชัดเจน รวมถึงนิยามของงานที่เสร็จสมบูรณ์ (definition of done) โดยที่ Sharkly ไม่ได้เป็นตัวเลือกโมเดลหรือระดับ effort แต่จะคอยบันทึกว่า Agent ตัวใดทำอะไรลงไปบ้างใน Task นั้น

ตัวเลขวันเปิดตัวบอกอะไรเราบ้าง

ตารางตัวเลขวันเปิดตัว พร้อมระบุระดับ effort เบื้องหลังแต่ละช่องและผู้ดำเนินการทดสอบ:

มีข้อสังเกตสองประการเกี่ยวกับแถว Terminal-Bench ประการแรก system card ระบุว่าคำขอที่ถูกตั้งค่าแจ้งเตือน (flagged requests) ส่งผลกระทบต่อรอบการทดสอบของ Opus 5.5 ถึง 10% เมื่อเทียบกับ Sonnet ที่ได้รับผลกระทบเพียง 1.5% และการทดสอบของ Artificial Analysis เองก็วัดคะแนนของ Sonnet 5.5 ได้ที่ 63.6% ไม่ใช่ 70.6% ในขณะเดียวกัน SWE-Bench Pro แสดงให้เห็นว่า Opus มีคะแนนนำอยู่ถึง 8.6 จุด ซึ่งสอดคล้องกับการวางตำแหน่งผลิตภัณฑ์ของ Anthropic เองที่ว่า Sonnet 5.5 เหมาะสำหรับงานประจำวันที่มีขอบเขตชัดเจนและการแก้บั๊ก ส่วน Opus 5.5 นั้น “ยังคงแข็งแกร่งกว่าอย่างเห็นได้ชัดในงานที่ซับซ้อนและปลายเปิด”

ยิ่งไปกว่านั้น ตัวเลขพาดหัวยังบดบังข้อมูลสำคัญที่จำเป็นต่อการตั้งกฎการกำหนดเส้นทางงาน (routing rule) นั่นคือผลคะแนนของเบนช์มาร์กการเขียนโค้ดทั้งสามรายการในระดับ effort ที่ใช้งานจริง พร้อมคะแนนและต้นทุนต่อหนึ่งงาน

Sonnet 5.5 มีต้นทุนต่อครั้งถูกที่สุดในระดับ medium และ high ซึ่งคะแนนที่ได้ก็ต่ำที่สุดเช่นกัน แต่เมื่อปรับสูงกว่าระดับ high เส้นกราฟจะตัดกันทันที: Sonnet ที่ระดับ xhigh มีราคาสูงกว่า Opus ที่ระดับ medium ในทั้งสามตาราง และยังแพ้ Opus ที่ระดับ high ในทั้งสามรายการด้วยต้นทุนที่เท่ากันหรือต่ำกว่า โมเดลราคาประหยัดจะหยุดความประหยัดลงทันทีที่คุณสั่งให้มันทำงานเทียบเคียงโมเดลราคาแพง ทั้งนี้ ต้นทุน CursorBench ของ Sonnet เป็นเพียงการประมาณการของ Anthropic และงานทดสอบเหล่านี้ก็ไม่ใช่โค้ดเบสในคลังเก็บโค้ด (repository) ของคุณเอง ดังนั้นจึงควรมองจุดตัดของต้นทุนนี้เป็นสมมติฐานที่ต้องตรวจสอบและยืนยันด้วยงานจริง

การบันทึกกฎการกำหนดเส้นทางงานให้เป็นลายลักษณ์อักษร

บทความก่อนหน้านี้ได้กล่าวถึงการจับคู่โมเดลให้เหมาะกับบทบาทของ Agent, การตัดสินใจเลือก Agent ตามลักษณะของงาน และการกำหนดระดับ tier ออกมาเป็นกฎเกณฑ์ การมาของ Sonnet 5.5 ได้เพิ่มมิติการพิจารณาขึ้นอีกขั้น เพราะใน Terminal-Bench โมเดลเดียวกันระหว่างระดับ medium กับ max มีต้นทุนต่อครั้งต่างกันถึงประมาณ 15 เท่า ($0.83 เทียบกับ $12.54) ดังนั้นคำสั่งอย่าง “ส่งงานนี้ไปให้ Sonnet” จึงยังไม่อาจเรียกว่าเป็นกฎได้ หากยังไม่ได้ระบุระดับ effort ควบคู่ไปด้วย

เงื่อนไขการส่งต่องาน (escalation) คือจุดที่กฎนี้แสดงความคุ้มค่าออกมาอย่างแท้จริง เมื่อ Sonnet Agent เริ่มติดขัด สัญชาตญาณแรกของหลายคนคือการปรับเพิ่มระดับ effort แต่ตัวเลขในกราฟฟ้องว่าคุณควรเปลี่ยนโมเดล เพราะจากหลักฐานนี้ Task ที่ต้องพึ่งพา Sonnet ระดับ xhigh ควรส่งให้เป็นหน้าที่ของ Opus ที่ระดับ high มากกว่า คุณสามารถกำหนดเงื่อนไขของคุณเองได้ โดยตัวอย่างต่อไปนี้แสดงให้เห็นแนวทาง:

• การตรวจสอบเดิมล้มเหลวซ้ำสองครั้ง: ให้มนุษย์ส่งต่อ Task นั้นไปยัง Opus Agent พร้อมแนบประวัติการทำงาน (log) ไปด้วย และต้องไม่มีการแอบลองใหม่ (retry) ไปยัง tier ที่ใหญ่ขึ้นโดยไม่แจ้งเตือน
• การแก้ไขจำเป็นต้องแตะไฟล์มากกว่าจำนวนที่ worker ได้รับอนุญาต (เช่น เกิน 8 ไฟล์) หรือมีการแก้ไขใน path ที่ไม่ได้ระบุไว้ใน Task
• Agent มีคำถามเชิงการออกแบบ ไม่ใช่ข้อสงสัยเกี่ยวกับถ้อยคำในคำอธิบาย Task
• ประเภทของ Task ที่จะผ่านได้ก็ต่อเมื่อใช้ Sonnet ในระดับที่สูงกว่า high เท่านั้น: ให้ย้าย Task ประเภทดังกล่าวไปให้ Opus Agent ใน Sprint ถัดไป

ในทางกลับกันก็เช่นเดียวกัน: Task ของ Opus ที่เสร็จสิ้นได้ในครั้งเดียวอย่างสม่ำเสมอและมี diff เพียงเล็กน้อย ก็ควรถูกปรับลดลงมาหนึ่ง tier

ผลกระทบของแต่ละโมเดลต่อคิวการตรวจทาน

กฎที่ระบุเพียงชื่อโมเดลและระดับ effort เป็นเพียงแค่ครึ่งหนึ่งของกฎทั้งหมดเท่านั้น เพราะอีกครึ่งหนึ่งคือการนิยามว่า “งานที่เสร็จแล้ว” (done) มีหน้าตาเป็นอย่างไร เนื่องจากแต่ละ tier จะส่งมอบผลลัพธ์ที่แตกต่างกันมายังผู้ตรวจทาน และการตรวจทานโดยมนุษย์ก็เป็นคอขวดอยู่แล้วตั้งแต่ก่อนการเปิดตัวโมเดลทั้งสอง ยิ่งไปกว่านั้น การรันงานที่ถูกลงมีแต่จะเพิ่มปริมาณ diff แต่ไม่ได้ช่วยเพิ่มชั่วโมงการทำงานของผู้ตรวจทานแต่อย่างใด

คู่มือการเขียนพรอมต์สำหรับ Sonnet 5.5 ของ Anthropic ได้ระบุไว้อย่างตรงไปตรงมาถึงสิ่งที่ผู้ตรวจทานจะได้พบเจอ:

• ในระดับ low และ medium โมเดลจะถามกลับเร็วเกินไป เมื่อเจองาน agentic ที่ยาว ซึ่งจะส่งผลให้มี Task ค้างรอคำตอบจากมนุษย์อยู่บนบอร์ดตอนตีสอง โดยมีความเห็นหนึ่งบน Hacker News ชี้ว่าสาเหตุที่คะแนนเบนช์มาร์กแบบกำหนดเองได้เพียง 7.4% (ในขณะที่ Sonnet 5 ทำได้ 17.8%) ก็เกิดจากพฤติกรรมนี้เอง
• ในระดับ low โมเดลอาจข้ามขั้นตอนการตรวจสอบ แล้วรายงานว่าโค้ดเสร็จแล้วโดยไม่ได้รันเทสต์ คำว่า “เสร็จสิ้น” ของ triage Agent จึงไร้ความหมายหากไม่มีผลการทดสอบแนบมาด้วย
• ในทุกระดับ effort โมเดลมักจะสร้างเทสต์ เอกสาร และไฟล์ย่อยเพิ่มขึ้นมา ทั้งที่ไม่มีใครร้องขอ ซึ่งบางไฟล์ก็อาจมีประโยชน์ แต่งานทั้งหมดล้วนกลายเป็น diff เพิ่มเติมที่คนต้องมาคอยอ่าน
• ในระดับ xhigh และ max โมเดลจะเพิ่มรอบการตรวจทานหรือเรียกใช้ subagent สำหรับรีวิวโค้ด โดยหน้าเปิดตัวระบุว่านี่คือเหตุผลที่ Sonnet 5.5 ได้คะแนนบน FrontierCode ที่ระดับ max ต่ำกว่า xhigh เนื่องจากโมเดลเรียกใช้ทักษะ code-review ของ Claude Code บ่อยเกินไป ซึ่งแตกกิ่งการทำงานออกไปยัง subagent จำนวนมาก และจากสองกรณีที่ Cognition ตรวจสอบพบ สิ่งนี้นำไปสู่อาการหมดเวลา (timeout) หรือการแก้ไขนอกเหนือขอบเขต ซึ่งถือเป็นสิ่งที่มีต้นทุนแพงที่สุดสำหรับผู้ตรวจทาน เพราะมีคนต้องมาคอยไล่ดูทีละบรรทัด

ส่วน Opus 5.5 จะสร้างภาระให้กับคิวตรวจทานในอีกรูปแบบหนึ่ง Anthropic ระบุว่าโมเดลนี้สามารถจดจ่อกับงานได้นาน 18 ชั่วโมงขึ้นไป พร้อม output ได้สูงสุดถึง 128k token ดังนั้นภาระของมันจึงเป็นเรื่องของขนาดโค้ด ไม่ใช่เรื่องของความสะเปะสะปะ (noise) และแพ็กเกจส่งมอบงานที่ผู้ตรวจทานต้องการก็จำเป็นสำหรับกรณีนี้เช่นเดียวกัน

ด้วยเหตุนี้ นิยามของงานที่เสร็จสมบูรณ์จึงควรใส่ไว้ในคำสั่งของ worker Agent ซึ่ง Sharkly จะแนบไปด้วยในทุกการรัน:

Agent: sonnet-worker  (Claude Code, claude-sonnet-5-5, effort medium)

Done means:
- The checks named in the Task ran. Paste each command and its exit
  code. "Tests pass" without output is not done.
- Changes stay inside the paths the Task names. List every file you
  created that the Task did not ask for, and why.
- New tests are welcome. New docs files only if the Task asks.

Keep working on long Tasks. Ask only when two readings of the Task
would produce different code; otherwise proceed and record the
assumption in your report.

Stop and return to the Task, without retrying, when a check has failed
twice, the change needs more than 8 files, or the question is about
design rather than the Task's wording.

การรันทั้งสองระดับใน Sharkly

Sharkly ไม่ได้ทำหน้าที่เลือกโมเดล และไม่ได้เป็นตัวกำหนด effort โดยเอกสารคู่มือของ Agents ได้ระบุไว้อย่างชัดเจนว่า: “Agent จะทำงานตามโมเดลเริ่มต้นของ Runtime โดยไม่มีการระบุหรือแสดงชื่อโมเดลที่เฉพาะเจาะจง การเปลี่ยนโมเดลต้องทำในการตั้งค่า Runtime หรือเครื่องมือ Computer ไม่ใช่ที่ตัว Agent” และไม่มีการควบคุมความลึกในการคิด (thinking-depth) บน Agent เช่นกัน ระดับ tier จึงเป็นการกำหนดค่า Claude Code บนเครื่อง Computer ส่วน Agent คือช่องทางที่ทีมใช้ในการมอบหมายงานให้กับค่านั้น

ดังนั้น: ให้ใช้หนึ่ง Agent ต่อหนึ่ง tier โดย sonnet-worker จะรันบน Computer ที่ตั้งค่า Claude Code ให้เป็น claude-sonnet-5-5 ส่วน opus-lead จะรันบนเครื่องที่ตั้งค่าเป็น claude-opus-5-5 เนื่องจาก Computer สามารถเป็นคอนเทนเนอร์ได้ การเพิ่ม tier ที่สองจึงไม่จำเป็นต้องใช้แล็ปท็อปเครื่องที่สอง ทั้งนี้ มีรายละเอียดสามข้อจากเอกสารการกำหนดค่าโมเดลของ Claude Code ที่จะเป็นตัวชี้ขาดว่า tier นั้นทำงานตรงตามชื่อหรือไม่:

• ระบุ ID ฉบับเต็มแบบเจาะจง: alias อย่าง sonnet จะหมายถึง Sonnet 5.5 เฉพาะบน Anthropic API เท่านั้น (บน Bedrock และ Google Cloud จะยังคงชี้ไปที่ Sonnet 4.5) และ Sonnet 5.5 จำเป็นต้องใช้ Claude Code เวอร์ชัน v2.1.284 ขึ้นไป
• โมเดล default ของ Claude Code คือ Opus 5.5 สำหรับแพ็กเกจ Pro, Max, Team, Enterprise และบน API ดังนั้น Computer ที่ไม่มีใครเข้าไปตั้งค่าอะไรไว้จึงถือเป็น Opus tier อยู่แล้วโดยปริยาย
• ค่าเริ่มต้นของ effort สำหรับ Sonnet 5.5 ใน Claude Code คือ medium ซึ่งตรงกับ worker tier ตามที่ระบุไว้ข้างต้น หากต้องการปรับเปลี่ยนจะต้องทำบน Computer ไม่ใช่ที่ Agent

เนื่องจาก Sharkly ไม่สามารถอ่านค่าได้อย่างแม่นยำว่า Runtime กำลังใช้งานโมเดลใดอยู่ จึงควรระบุ tier ลงในชื่อของ Agent และเปลี่ยนทั้งชื่อพร้อมกับการตั้งค่าไปพร้อมกัน โดยสามารถดูขั้นตอนได้จากคู่มือการตั้งค่า Sonnet 5.5

สำหรับงานที่ต้องใช้ทั้งสอง tier ร่วมกันใน Task เดียว ให้ใช้ Crew ซึ่ง Crew คือกลุ่มของบุคคลและ Agent ที่สามารถนำกลับมาใช้ซ้ำได้ โดยมีลีดเดอร์ Agent คอยประสานงาน เมื่อตั้งให้ opus-lead เป็นผู้นำและมี worker Sonnet เป็นสมาชิก ตัวลีดเดอร์จะอ่าน Task แล้วลงมือจัดการเองหรือเมนชันเรียกสมาชิกเข้ามาช่วยทำบางส่วน และสมาชิกจะอัปเดตผลลัพธ์ลงใน Task เดียวกันนั้น รูปแบบนี้ก็คือโครงสร้างแบบ Opus-orchestrator ที่มีผู้เสนอแนะไว้บน Hacker News ซึ่งการส่งต่องานทั้งหมดจะถูกบันทึกไว้อย่างชัดเจนจนมนุษย์สามารถเข้ามาอ่านและตรวจสอบได้ ส่วนงานขนาดเล็กที่มีขอบเขตชัดเจนอยู่แล้ว ก็สามารถข้าม Crew แล้วมอบหมายงานให้ sonnet-worker ได้โดยตรง

alias ชื่อ opusplan ของ Claude Code ก็ใช้วิธีการคล้ายกันนี้ภายในเซสชันเดียว นั่นคือใช้ Opus ในโหมดวางแผน (plan mode) และใช้ Sonnet สำหรับการลงมือปฏิบัติจริง (execution) โดยฝั่ง Sonnet จะหมายถึง Sonnet 5.5 เฉพาะบน Anthropic API เท่านั้น หากเป็นบน Bedrock, Google Cloud หรือ Foundry จะยังคงชี้ไปยัง Sonnet เวอร์ชันเก่ากว่า เหมาะสำหรับกรณีที่มีผู้ดูแลเพียงคนเดียวเป็นคนรันและตรวจทานทั้งเซสชัน แต่ควรเลือกใช้สอง Agent แยกกัน หากต้องการให้ผู้อื่นสามารถตรวจสอบได้อย่างชัดเจนว่า Agent ตัวไหนเป็นผู้วางแผนและตัวไหนเป็นผู้ลงมือปฏิบัติ

สิ่งหนึ่งที่ไม่เคยถูกส่งต่อข้ามระหว่าง tier เลยก็คือกระบวนการคิดและให้เหตุผล (reasoning) เนื่องจาก thinking block ของ Sonnet 5.5 จะผูกติดอยู่กับตัวโมเดลและการสนทนาในเซสชันนั้นเท่านั้น ไม่มีโมเดลอื่นสามารถอ่านได้ และ Sonnet 5.5 ก็ไม่สามารถอ่านของ Opus 5.5 ได้เช่นกัน การแชร์ไดเรกทอรีใน Crew เป็นเพียงการแชร์ไฟล์ร่วมกัน ไม่ใช่การแชร์เซสชันของ Agent ก่อนหน้า สิ่งที่ลีดเดอร์ตัดสินใจจะถูกส่งต่อไปถึง worker ได้ก็ต่อเมื่อถูกเขียนระบุไว้ใน Task เท่านั้น ซึ่งประเด็นนี้เป็นหัวข้อเฉพาะที่แยกเขียนไว้อีกบทความหนึ่ง

ทั้งหมดที่กล่าวมานี้ไม่ได้เปลี่ยนบทบาทของผู้ตรวจรับงาน Agent ยังคงทำหน้าที่ค้นคว้า ทำงาน ทดสอบ และรายงานผล ส่วนมนุษย์คือผู้กำหนดทิศทาง มอบหมายสิทธิ์ และตรวจรับผลลัพธ์ ค่าใช้จ่ายข้างต้นจะถูกเรียกเก็บผ่านบิลของผู้ให้บริการของคุณ เนื่องจากการใช้งานโมเดลจะดำเนินการผ่านแพ็กเกจสมาชิกหรือ API key ที่ตั้งค่าไว้ในเครื่องมือเหล่านั้น ไม่ว่าในไตรมาสถัดไปโมเดลใดจะขึ้นมาเป็นผู้นำ การมอบหมายงาน ประวัติการรัน คำถาม ผลลัพธ์ และการตรวจทานโดยมนุษย์จะยังคงถูกบันทึกกลับมาที่ Task เสมอ และแนวคิดนี้ยังนำไปประยุกต์ใช้ข้ามผู้ให้บริการได้เช่นกัน ดังที่แสดงไว้ในการเปรียบเทียบระหว่าง Sonnet 5.5 กับ GPT-6 Sol หากคุณต้องการใช้งาน coding agent หลากหลายโมเดลต่อไปโดยไม่ต้องผูกขาดอยู่กับระบบนิเวศใดระบบนิเวศหนึ่ง นั่นคือปัญหาที่ Sharkly ถูกออกแบบมาเพื่อตอบโจทย์โดยเฉพาะ