Claude Sonnet 5.5 vs GPT-6 Sol: เปรียบเทียบ 2 รันไทม์ในราคาเท่ากัน

Anthropic เปิดตัว Claude Sonnet 5.5 เมื่อวันที่ 28 กันยายน ในราคา $2 ต่อ 1 ล้าน input tokens และ $10 ต่อ 1 ล้าน output tokens ส่วน OpenAI ก็เปิดตัว GPT-6 Sol ไปเมื่อวันที่ 22 กันยายน ด้วยราคา $2 และ $10 เท่ากัน ทั้งสองโมเดลเปิดตัวห่างกันเพียง 6 วัน ตั้งราคาเท่ากันเป๊ะ และต่างก็อยู่ในระดับรองท็อปถัดจากโมเดลเรือธงของแต่ละค่าย สำหรับทีมพัฒนาที่กำลังเลือกโมเดลเริ่มต้น (default) มาทำเป็น coding agent ราคาที่เท่ากันนี้แทบไม่ได้ช่วยให้ตัดสินใจได้เลย เพราะโจทย์ที่แท้จริงคือการเลือกระหว่าง Claude Code กับ Codex ในฐานะ Runtime ที่ครอบแต่ละโมเดลอยู่ รวมถึงต้นทุนต่องานที่ทำเสร็จจริง (finished task) ของแต่ละคู่

การทดสอบเปรียบเทียบอย่างตรงไปตรงมาหมายถึงการใช้ Runtime สองตัว, การตั้งค่าสองแบบ, ผลลัพธ์สองชุด และผู้รีวิวหนึ่งคนที่ต้องคอยจำว่า terminal ไหนสร้าง diff ไหนขึ้นมา การเลือกโมเดลอาจตั้งค่าแค่บรรทัดเดียว แต่การนำทั้งสองตัวมาเทียบกันจริงๆ กลับกลายเป็นความโกลาหลย่อมๆ ของโลก agent

สรุปใจความสำคัญ (TL;DR)

Claude Sonnet 5.5 และ GPT-6 Sol มีราคาต่อโทเคนเท่ากัน แต่จุดต่างอยู่ที่ Runtime ที่ทีมงานมักจะเลือกใช้รันโมเดลเหล่านี้ นั่นคือ Claude Code สำหรับ Sonnet 5.5 และ Codex สำหรับ Sol ในตารางเปรียบเทียบตอนเปิดตัวของ Anthropic มีผลการทดสอบอยู่ 4 แถวที่มีคอลัมน์ของ GPT-6 Sol โดย Sonnet 5.5 ชนะอย่างชัดเจนไป 3 รายการ ส่วนรายการที่สี่อย่าง FrontierCode นั้นผลลัพธ์ขึ้นอยู่กับระดับ effort ที่ใช้ ยิ่งไปกว่านั้น ต้นทุนต่องานยังพลิกผันไปตามเบนช์มาร์ก: ใน FrontierCode นั้น Sonnet 5.5 ทำผลงานได้เทียบเท่ากับระดับที่ดีที่สุดของ Sol ด้วยต้นทุนเพียงประมาณ 1 ใน 5 เท่านั้น ทว่าใน AA-Briefcase ผลงานที่ดีที่สุดของ Sol มีต้นทุนอยู่ที่ $2.67 ต่องาน ขณะที่ Sonnet 5.5 อยู่ที่ $29.19 อย่าลืมว่านี่คือตารางจากฝั่งผู้พัฒนาเพียงเจ้าเดียว วิธีตัดสินระหว่าง Sonnet 5.5 กับ GPT-6 Sol ให้เด็ดขาดคือการนำ Task เดียวกันไปรันผ่านทั้งสอง Runtime บนโค้ดเบสของคุณเอง แล้วนับเวลา (นาที) ที่มนุษย์ต้องใช้ในการรีวิวก่อนยอมรับการเปลี่ยนแปลงโค้ดแต่ละครั้ง (accepted change) และการเลือกเก็บไว้ใช้ทั้งสองตัวก็ถือเป็นคำตอบที่เข้าท่า หากคุณใช้ Task เป็นศูนย์กลางในการบันทึกข้อมูล

ตัวเลขที่เผยแพร่ออกมาบอกอะไรเราได้จริงบ้าง

มีเพียง 4 แถวเท่านั้น ในบทความเปิดตัว Claude Sonnet 5.5 มีการเปรียบเทียบระหว่าง Sonnet 5.5, Sonnet 5, Opus 5.5 และ GPT-6 Sol แต่มีเพียงแถวเหล่านี้เท่านั้นที่มีตัวเลขของ Sol ให้เห็น:

นี่คือตารางจากผู้พัฒนารายเดียว โพสต์เปิดตัว Sol ของ OpenAI เผยแพร่ออกมาก่อนที่ Sonnet 5.5 จะเปิดตัว 6 วัน ดังนั้นตารางเปรียบเทียบจากผู้พัฒนาที่มีข้อมูลของทั้งสองโมเดลจึงมีแค่ของ Anthropic เท่านั้น นอกจากนี้ ข้อมูลของทั้งสองฝั่งยังมีข้อควรระวังเรื่องบั๊กอีกด้วย โดยการทดสอบ Sonnet 5.5 ของ Artificial Analysis นั้นรันบนเวอร์ชันก่อนเปิดตัวจริงซึ่งมีบั๊กเรื่อง structured output (ซึ่งได้รับการแก้ไขแล้วในภายหลัง) และทาง OpenAI เองก็เพิ่งแก้ไขบั๊กด้านความเข้าใจรูปภาพใน Sol ซึ่งคะแนนของ Artificial Analysis และ Surge AI อาจยังไม่สะท้อนถึงการแก้ไขนี้

แถว FrontierCode คือแถวที่ทีมเขียนโค้ดควรอ่านอย่างยิ่ง เพราะนี่เป็นการเปรียบเทียบระดับ Runtime อยู่แล้ว: ตัวเลข 52.1% เทียบกับ 49.3% คือการวัดระหว่าง Claude Code บน Sonnet 5.5 กับ Codex CLI บน Sol ซึ่งเป็นคู่ที่คุณจะนำไปใช้งานจริง ส่วนหมายเหตุใต้ตารางสำหรับคะแนนที่ระดับ max ก็สำคัญไม่แพ้กัน เพราะ FrontierCode มีการหักคะแนนหากมีการแก้ไขโค้ดนอกเหนือขอบเขต (out-of-scope changes) และที่ระดับ max effort นั้น Sonnet 5.5 มักจะเรียกใช้สกิล code-review ของ Claude Code บ่อยกว่า ซึ่งจะกระจายงานออกไปยัง subagent จำนวนมาก จากการตรวจสอบของ Cognition ในสองกรณีพบว่า พฤติกรรมนี้ส่งผลให้เกิด timeout หรือไม่ก็แก้ไขโค้ดเกินขอบเขตของงาน ยิ่งใช้ effort สูง diff ก็ยิ่งกว้าง และยิ่งต้องใช้เวลารีวิวมากขึ้นตามไปด้วย

ข้อมูลอื่นๆ ในหน้านั้นไม่มีตัวเลขของ Sol ปรากฏอยู่อีกเลย โดยกราฟระดับ effort ของ Terminal-Bench 4.0 และ CursorBench 4.0 พล็อตข้อมูลของ GPT-5.6 Sol แทน เนื่องจากยังไม่มีการเปิดเผยตัวเลขของ GPT-6 Sol

อย่างไรก็ตาม ยังมีแหล่งรวบรวมข้อมูลจากบุคคลที่สามอยู่อีกแห่ง โดย Artificial Analysis จัดอันดับให้ endpoint ระดับ max-effort ของ Sonnet 5.5 ได้คะแนน 56 บน Intelligence Index ซึ่งอยู่อันดับที่ 3 จากทั้งหมด 216 โมเดล ณ วันที่ 29 กันยายน ส่วน Sol อยู่ที่ 48 ณ วันที่ 23 กันยายน ซึ่งเป็นวันที่เราบันทึกข้อมูลไว้ล่าสุด ทั้งสองตัวเลขมาจากคนละช่วงเวลา บนดัชนีที่มีการเคลื่อนไหวตลอด และไม่มีตัวเลขไหนที่วัดผลจากการทำงานจริงบน repository ของคุณเลย

ต้นทุนต่องานที่สำเร็จ ไม่ใช่ต้นทุนต่อโทเคน

ราคาต่อโทเคนที่เท่ากันไม่ได้บ่งบอกอะไรมากนักเกี่ยวกับค่าใช้จ่ายจริงที่จะเกิดขึ้น เพราะจำนวนโทเคนที่ใช้ต่อหนึ่งงานนั้นขึ้นอยู่กับตัวโมเดล, ระดับ effort และ Runtime ที่ใช้งาน ในหน้าเปิดตัวของ Anthropic มีการเผยแพร่คะแนนและต้นทุนต่องานแยกตามระดับ effort สำหรับสองแถวที่มีข้อมูลร่วมกัน ดังนี้:

ลองดูที่ FrontierCode ก่อนเป็นอันดับแรก Sonnet 5.5 ที่ระดับ high ทำคะแนนได้ 49.4% ด้วยต้นทุน $0.42 ต่องาน ซึ่งเทียบเท่ากับผลงานที่ดีที่สุดของ Sol ที่ 49.3% ด้วยต้นทุน $2.07 ทาง Anthropic จึงสรุปไว้ว่า “ต้นทุนต่องานถูกกว่าประมาณ 5 เท่า” แต่รายละเอียดสำคัญที่ต้องนำไปพิจารณากลับอยู่ต่ำลงมา: ที่ระดับ medium ตัว Sonnet 5.5 ทำคะแนนได้เพียง 36.5% ซึ่งต่ำกว่า Sol แม้จะอยู่ที่ระดับ low เสียอีก และระดับ medium นี้เองที่เป็นค่า default effort ของ Claude Code สำหรับ Sonnet 5.5 แม้คู่มือ prompting guide ของ Anthropic จะแนะนำให้เริ่มต้นที่ระดับ high หรือใช้ medium สำหรับการเขียนโค้ดด้วย agent ในงานที่มีรายละเอียดชัดเจน แต่การตั้งค่าเริ่มต้นที่ไม่มีใครแตะต้องนี้เอง อาจเป็นตัวตัดสินผลการเปรียบเทียบทั้งหมดได้เลย

แต่ใน AA-Briefcase ซึ่งเป็นเบนช์มาร์กสำหรับงานสายความรู้ (knowledge work) ผลลัพธ์กลับตาลปัตร ผลงานที่ดีที่สุดของ Sol มีต้นทุน $2.67 ต่องาน ในขณะที่ผลงานที่ดีที่สุดของ Sonnet 5.5 ต้นทุนพุ่งไปถึง $29.19 หรือแพงกว่าประมาณ 11 เท่า เพื่อแลกกับคะแนนที่สูงกว่า และหากดูการตั้งค่าของ Sonnet 5.5 ที่มีต้นทุนใกล้เคียงกับระดับ max ของ Sol มากที่สุด นั่นคือระดับ medium ที่ $1.64 ก็ทำคะแนนได้ 1461 เทียบกับ 1483 โมเดลสองตัวเดียวกันแท้ๆ แต่คำตอบว่าตัวไหนคุ้มค่ากว่าเมื่อเทียบกับผลลัพธ์ กลับตรงกันข้ามอย่างสิ้นเชิง

ระบบ Caching ช่วยลดช่องว่างและเปลี่ยนโครงสร้างค่าใช้จ่ายตรงนี้ โดย Sonnet 5.5 คิดค่าอ่าน cached input อยู่ที่ $0.10 ต่อ 1 ล้านโทเคน และค่าเขียน cache อายุ 5 นาทีที่ $2.50 (ราคาของ Anthropic) ส่วน GPT-6 ให้ส่วนลด 90% สำหรับการอ่าน cached input ซึ่งคิดเป็น $0.20 จากอัตราปกติ $2 นั่นหมายความว่าค่าอ่าน cache ของ Sonnet 5.5 ถูกกว่าครึ่งหนึ่ง ทว่าจุดที่ต่างกันจริงๆ คือปัจจัยที่ทำให้ cache หลุด: OpenAI ระบุว่า การเปลี่ยน reasoning effort หรือการเปิด/ปิดเครื่องมือจะไม่ทำให้ cache หลุดอีกต่อไป ในขณะที่คู่มือของ Sonnet 5.5 จาก Anthropic ระบุว่าการเปลี่ยนค่า effort ระดับบนสุดระหว่างแต่ละ request จะทำให้ cache หลุด พร้อมชี้เป้าไปที่การตั้งค่า effort แบบ per-message ที่ยังอยู่ในช่วงเบต้า ดังนั้น agent ที่ปรับเปลี่ยน effort กลางคันระหว่างทำงาน ย่อมเห็นผลกระทบนี้บนบิลค่าบริการอย่างแน่นอน

แต่ตัวเลขทั้งหมดนี้ยังไม่ใช่ต้นทุนต่อการเปลี่ยนแปลงโค้ดที่คุณยอมรับนำไปใช้งานจริง (accepted change) เพราะการรันราคาถูกที่ต้องสั่งรันซ้ำอีกสองรอบและเสียเวลารีวิวยาวนาน สุดท้ายแล้วนั่นแหละคือตัวเลือกที่แพงกว่า

วิธีตัดสินบนโค้ดเบสของคุณเอง

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

Sharkly ไม่ได้ทำหน้าที่เลือกโมเดลให้คุณ โดยในเอกสารคู่มือของ Agents ระบุไว้อย่างชัดเจนว่า: “Agent จะทำงานตามโมเดลเริ่มต้นของ Runtime นั้นๆ โดยไม่มีการให้สัญญาหรือแสดงชื่อโมเดลเฉพาะเจาะจง หากต้องการเปลี่ยนโมเดล ให้ตั้งค่าที่การกำหนดค่าเครื่องมือของ Runtime หรือ Computer ไม่ใช่ที่ตัว Agent” ดังนั้น การจัดการโมเดลจึงเกิดขึ้นที่ฝั่ง Computer:

• Claude Code บน claude-sonnet-5-5: ต้องใช้ Claude Code v2.1.284 ขึ้นไป ทั้งนี้โมเดล default ของ Claude Code คือ Opus 5.5 สำหรับแพ็กเกจ Pro, Max, Team, Enterprise และ Anthropic API ดังนั้นเครื่อง Computer จะรัน Opus จนกว่าจะมีคนไปเปลี่ยน และ alias อย่าง sonnet จะหมายถึง Sonnet 5.5 เฉพาะบน Anthropic API เท่านั้น แนะนำให้ระบุ id แบบเต็มและยืนยันด้วยคำสั่ง claude --model claude-sonnet-5-5 บนโฮสต์นั้น อ่านขั้นตอนทั้งหมดได้ที่บทความการรัน Sonnet 5.5 agent ใน Sharkly
• Codex บน gpt-6-sol: กำหนดโมเดลในการตั้งค่าของ Codex บนเครื่อง Computer เครื่องนั้น โดยดูขั้นตอนได้ที่บทความการรัน GPT-6 Sol agent ใน Sharkly
• ใช้ไดเรกทอรีทำงานชั่วคราวบน Agent ทั้งสองฝั่ง: การรันแต่ละครั้งจะได้ไดเรกทอรีแยกต่างหาก และการรันที่เชื่อมกับ repository สามารถเตรียม worktree ใหม่เอี่ยมได้ ทำให้การทดสอบทั้งสองฝั่งไม่มีการใช้ checkout ร่วมกันเด็ดขาด

จากนั้นให้บันทึกแผนการทดสอบไว้เป็นลายลักษณ์อักษรก่อนเริ่มรันงาน:

Task:    SH-312, one real Task, same description and starting commit for both runs
Run A:   Claude Code Agent, claude-sonnet-5-5, effort: medium (Claude Code default) or high
Run B:   Codex Agent, gpt-6-sol, effort: whatever Codex on that Computer is set to, written here
Accept:  the same acceptance test for both
Record:  accepted y/n, human review minutes, reruns, files touched outside scope,
         provider cost from your own Anthropic and OpenAI bills
Decide:  after several Tasks of each kind you actually assign, not one

มอบหมาย Task ให้กับ Agent ตัวหนึ่ง และสั่งเริ่มทำงาน Agent อีกตัวด้วยการ mention ในคอมเมนต์ โดย Sharkly อนุญาตให้การ mention เริ่มต้นการทำงานของ Agent ที่ไม่ได้เป็น Assignee ได้ ผลลัพธ์จากการรันทั้งสองฝั่งจะส่งกลับมายัง Task เดียวกัน ทำให้ diff ทั้งสองชุด, ผลการทดสอบทั้งสองรอบ และข้อซักถามต่างๆ รวมอยู่ใน timeline เดียว แทนที่จะต้องคอยเลื่อนดูประวัติการทำงานสองหน้าจอแยกกัน หากต้องการดูแนวทางการทดสอบแก้บั๊กเดี่ยวๆ พร้อมเกณฑ์การให้คะแนน สามารถอ่านเพิ่มเติมได้ที่ Claude Code vs Codex on the same bug

ให้น้ำหนักกับเวลาในการรีวิวมากที่สุด คู่มือ prompting guide ของ Anthropic ระบุว่า Sonnet 5.5 จะเพิ่มชุดทดสอบ เอกสาร และไฟล์เล็กๆ ในทุกระดับ effort รวมถึงจะส่งงานมารายงานความคืบหน้าตั้งแต่เนิ่นๆ ในงานที่ใช้เวลานานเมื่อตั้งระดับไว้ที่ low และ medium อีกทั้งยังเริ่มรอบการรีวิวเพิ่มเติมหรือส่ง reviewer subagent มาช่วยตรวจเมื่อใช้ระดับ xhigh และ max ไม่ว่าฝั่ง Codex บน Sol จะทำอะไรในจุดเดียวกัน การทดสอบจริงจะเผยให้เห็นทั้งหมด สิ่งเหล่านี้ล้วนส่งผลกระทบต่อเวลาในการรีวิวทั้งสิ้น และไม่มีทางปรากฏให้เห็นในคะแนนเบนช์มาร์กเลย

ทำไมคำตอบว่า “ใช้ทั้งคู่” จึงเป็นทางเลือกที่เข้าท่า

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

เลือกใช้ Runtime เพียงตัวเดียว เมื่อผลการทดสอบแสดงให้เห็นว่าไม่มีความแตกต่างที่ส่งผลต่อเวลาในการรีวิวอย่างชัดเจน หรือเมื่อทีมขนาดเล็กต้องการลดภาระในการจัดการเหลือเพียง subscription เดียวและการตั้งค่าชุดเดียว หากคุณใช้แค่ Claude Code และชอบการทำงานแบบ terminal-first อยู่แล้ว คุณอาจไม่จำเป็นต้องมีระบบจัดการ (management layer) เข้ามาช่วยเลย แต่ให้เลือกเก็บไว้ใช้ทั้งคู่ หากผลการทดสอบแยกตามประเภทของงานอย่างเห็นได้ชัด หรือเมื่อคุณต้องการความยืดหยุ่นในการเปลี่ยนค่าเริ่มต้นในเดือนถัดไปโดยไม่ต้องรื้อเวิร์กโฟลว์ใหม่ทั้งหมด ซึ่งคำว่า "เดือนหน้า" ไม่ใช่เรื่องสมมติ เพราะ Opus 5.5, Sol และ Luna เปิดตัวพร้อมกันในวันเดียว และ Sonnet 5.5 ก็ตามมาในอีก 6 วันให้หลัง

การจะใช้งานร่วมกันทั้งสองตัวได้อย่างราบรื่นจะเกิดขึ้นได้ก็ต่อเมื่อคุณใช้ Task เป็นศูนย์กลางการบันทึกข้อมูล ไม่ใช่ตัว Runtime เพราะไม่มีโมเดลอื่นใดที่จะอ่าน thinking block ของ Sonnet 5.5 ได้ ดังนั้นเมื่อ Task ถูกย้ายจาก Claude Code Agent ไปยัง Codex Agent กระบวนการคิด (reasoning) ภายในจะไม่ได้ติดไปด้วย และจะมีเพียงข้อมูลที่เขียนลงใน Task เท่านั้นที่ถูกส่งต่อ การตัดสินใจ ข้อสันนิษฐาน และคำถามที่ยังค้างคา จึงควรเขียนไว้ในคำอธิบายของงานหรือในคอมเมนต์ สามารถอ่านแนวทางใช้งานประจำวันได้ที่ Running Claude Code and Codex together on one codebase และอ่านแนวทางการกระจายงานฝั่ง Claude ได้ที่ Sonnet 5.5 or Opus 5.5

Agent มีหน้าที่ค้นคว้า ลงมือทำ ทดสอบ และรายงานผล ส่วนมนุษย์มีหน้าที่กำหนดทิศทาง มอบหมายสิทธิ์ และตรวจรับผลงาน ตัว Runtime อาจเปลี่ยนไปได้ทุกไตรมาส แต่บริบท ความคืบหน้า อุปสรรค ผลลัพธ์ และการรีวิวโดยมนุษย์ ควรถูกรวมไว้ในที่เดียวให้มองเห็นได้ชัดเจน ตั้งแต่เริ่มเปิดคำขอไปจนถึงการปล่อยงาน (release)

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