ในโพสต์เปิดตัว Gemini 4 Argon ของ Google มีตารางเบนช์มาร์กทั้งหมด 19 รายการ ซึ่งจากการนับของเรา Argon ชนะขาดลอยไป 13 รายการ และเสมอกัน 1 รายการ ส่วนอีก 5 รายการที่แพ้นั้นไม่ได้เกิดขึ้นแบบสุ่ม เพราะ GPT-6 Astra คว้าชัยใน FrontierSWE v2, Terminal-Bench Science และ OSWorld-2.0 ไปได้ ขณะที่ Claude Opus 5.5 ชนะใน Terminal-bench 4.0 และ PostTrainBench ซึ่งล้วนเป็นรายการในกลุ่ม Terminal-Bench ทั้งสองรายการ, กลุ่ม agentic coding หนึ่งรายการ, กลุ่ม ML engineering หนึ่งรายการ และกลุ่ม computer use อีกหนึ่งในสองรายการ ซึ่งสิ่งเหล่านี้คืองานส่วนใหญ่ที่ทีมเขียนโค้ดต้องใช้รอบการรันจริง ๆ และประเด็นนี้ก็ไม่ใช่แค่เรื่องสมมติอีกต่อไป เพราะตั้งแต่วันที่ 13 ตุลาคม 2026 เป็นต้นมา Argon ได้เปิดให้บริการทั่วไป (General Availability) บน Gemini API แบบชำระเงินในชื่อ gemini-4-argon เรียบร้อยแล้ว
ดังนั้นคำตอบของคำถามที่ว่า “โมเดลไหนชนะ?” จึงมีได้ถึงสามคำตอบขึ้นอยู่กับว่าคุณดูที่รายการใด และสำหรับทีมที่ใช้งาน coding agent หลายตัวพร้อมกัน นี่ไม่ใช่เรื่องเล็กน้อยเลย เพราะถ้า Agent ทุกตัวบนบอร์ดทำงานอยู่บน Runtime เดียวกัน ทีมของคุณก็จะต้องแบกรับจุดด้อยของแล็บนั้นควบคู่ไปกับจุดเด่นด้วย และการเปิดตัวโมเดลใหม่ในแต่ละครั้งก็จะจุดชนวนข้อถกเถียงนี้ขึ้นมาซ้ำ ๆ แต่เรื่องที่ว่า Agent ตัวไหนใช้รันอะไร งานไหนเสร็จแล้ว หรืองานไหนต้องตรวจทาน ไม่ควรต้องขึ้นอยู่กับว่าสัปดาห์นี้ใครเป็นผู้นำบนตารางเบนช์มาร์ก
สรุปประเด็นสำคัญ (TL;DR)
ไม่มีแล็บ AI ชั้นนำแห่งใดครองแชมป์ได้ทุกรายการ แม้แต่บนตารางเปรียบเทียบของตนเอง จงมองการเปิดตัวแต่ละครั้งเป็นข้อมูลอ้างอิงสำหรับการกำหนดเส้นทาง (routing) ไม่ใช่เหตุผลที่ต้องย้ายระบบใหม่ทั้งหมด ให้เชื่อมต่อ Runtime ไว้มากกว่าหนึ่งตัว เขียนกฎการกำหนดเส้นทาง (routing rule) ไว้ให้ชัดเจน (กำหนดค่าเริ่มต้น เงื่อนไขในการส่ง Task ไปยัง Agent ตัวอื่น และระบุผู้ตรวจทาน) จากนั้นทดสอบกฎนี้กับ 3 Task จริงจาก codebase ของคุณเอง ทั้งนี้ Astra จะรันผ่าน Codex, Opus 5.5 รันผ่าน Claude Code และโมเดลตระกูล Gemini รันผ่าน Gemini CLI ด้วย API key แบบชำระเงิน แต่เนื่องจาก Google ยังไม่ได้ยืนยันว่า Gemini CLI รองรับ Argon หรือไม่ จึงควรทำ smoke-test กับ gemini-4-argon ก่อนนำไปรับ Task จริง
ตารางของ Google บ่งบอกอะไรบ้าง เมื่อแยกตามประเภทงาน
รายการที่มีความสำคัญต่อ coding agent โดยจัดกลุ่มตามหมวดหมู่ของ Google เอง:
| ประเภทงาน (หมวดหมู่ของ Google) | รายการทดสอบ | ผู้นำบนตารางของ Google | ข้อสังเกต |
|---|---|---|---|
| Agentic coding | DeepSWE v1.1 | Argon 77.9% (Opus 5.5 74.2%, Astra 74.1%) | ผลของ Argon คำนวณโดย Google เอง |
| Agentic coding | FrontierSWE v2 | Astra 65.5% (Opus 5.5 62.3%, Argon 55.0%) | ข้อมูลจากกระดานผู้นำ Proximal |
| Agentic coding | Terminal-bench 4.0 | Opus 5.5 66.4% (Astra 58.2%, Argon 57.4%) | ผลของ Argon คำนวณโดย Google เอง |
| Agentic coding | Vibe Code Bench | Argon 91.9% (Opus 5.5 90.3%, Astra 89.6%) | คะแนนของทั้ง 4 โมเดลห่างกันเพียง 2.3 จุด |
| ML engineering | PostTrainBench | Opus 5.5 49.3% (Argon 45.3%, Astra 44.3%) | Google คำนวณผลการทดสอบเองสำหรับทุกโมเดล |
| Science and math | Terminal-Bench Science 0.1 | Astra 68.1% (Opus 5.5 63.3%, Argon 57.6%) | Argon ได้รับการรันโดยเพิ่ม verifier timeout ขึ้น 6 เท่า |
| Computer use | OSWorld-2.0, offline subset | Astra 72.6% (Argon 69.2%) | ไม่มีข้อมูลของ Opus 5.5 |
| Computer use | Agent’s Last Exam | Argon 39.5% (Opus 5.5 38.2%, Astra 34.2%) | ผลของ Argon คำนวณโดย Google เอง |
| Long context | GraphWalks 256K to 1M | Argon 84.2% (Astra 71.8%, Opus 5.5 66.8%) | คำนวณผลการทดสอบเองสำหรับทุกโมเดล |
เฉพาะในหมวด agentic coding เพียงหมวดเดียวที่มี 4 รายการ ก็มีผู้ชนะต่างกันถึง 3 โมเดลแล้ว ส่วนรายการที่ Argon กวาดชัยชนะไปได้ทั้งหมดนั้นเป็นงานสายความรู้ (knowledge work), long context และงานแบบมัลติโมดัล ซึ่งมีความสำคัญน้อยกว่าสำหรับทีมพัฒนาที่ปลายทางของแต่ละ Task คือผลลัพธ์ที่เป็น diff
อย่างไรก็ดี ต้องพิจารณาข้อมูลนี้โดยเผื่อข้อจำกัดไว้ด้วย เพราะนี่คือตารางของทาง Google เอง โดย Google ทำการรันผลของ Argon เองในหลายรายการ ขณะที่ตัวเลขของคู่แข่งส่วนใหญ่เป็นผลที่รายงานด้วยตนเองหรือดึงมาจากกระดานผู้นำสาธารณะ อีกทั้งตัวทดสอบ (harness) ก็แตกต่างกัน โดยในเอกสาร ระเบียบวิธีประเมินผล (evaluation methodology) ได้ระบุแหล่งที่มาของข้อมูลไว้ครบทุกช่อง นอกจากนี้ ผลการทดสอบจากองค์กรอิสระนับตั้งแต่เปิดตัวก็ยังมีความเห็นไม่ตรงกันด้วย เช่น Humanity’s Sixth Sense ของ Scale AI ให้ Argon เป็นอันดับหนึ่งที่ 55.4% นำหน้า GPT-6 Astra ที่ได้ 53.6% ขณะที่ Cursor ระบุว่ามีประสิทธิภาพเทียบเท่ากับ Opus 5.5 บน CursorBench และ Artificial Analysis จัดอันดับให้ Argon (High) อยู่ในอันดับที่ 8 จาก 216 โมเดล ณ วันที่ 15 ตุลาคม
ในแง่ของราคาก็ยังไม่ใช่ตัวตัดสินชี้ขาดเช่นกัน โดย Argon คิดค่าบริการที่ 2 ดอลลาร์ต่อ 1 ล้าน input token และ 10 ดอลลาร์ต่อ 1 ล้าน output token ไปจนถึงวันที่ 30 พฤศจิกายน 2026 จากนั้นจะปรับเป็น 4 ดอลลาร์และ 20 ดอลลาร์ตั้งแต่วันที่ 1 ธันวาคม ซึ่งอัตราใหม่นี้เท่ากับราคาของ Opus 5.5 พอดี ส่วนราคาที่ประกาศของ Astra อยู่ที่ 10 ดอลลาร์และ 50 ดอลลาร์
เมื่อไม่มีแล็บใดชนะทุกเบนช์มาร์ก ก็ไม่ควรมีแล็บใดครองบอร์ดไปทั้งหมด
ข้อมูลจากผู้พัฒนาเองเป็นเครื่องยืนยันในจุดนี้ ไม่ใช่ข้อโต้แย้งจากเรา เพราะหากแม้แต่ตารางของ Google ที่สร้างขึ้นมาเพื่อโปรโมตโมเดลของตนเอง ยังต้องยอมยกชัยชนะถึง 5 รายการให้คู่แข่งอีกสองราย ย่อมแสดงว่าไม่มีโมเดลเดี่ยวตัวใดที่ดีที่สุดสำหรับ coding agent ในทุกสถานการณ์ แต่มีเพียงโมเดลที่เหมาะสมที่สุดสำหรับ Task บางประเภท ในช่วงไตรมาสนี้ บนชุดการทดสอบของผู้ทดสอบรายใดรายหนึ่งเท่านั้น
มุมมองดังกล่าวเปลี่ยนแนวทางการรับมือในวันเปิดตัวโมเดลใหม่ สิ่งที่หลายทีมมักอยากทำทันทีคือการย้ายระบบทั้งหมด ไม่ว่าจะเป็นการเปลี่ยน Runtime เริ่มต้นใหม่, รื้อการตั้งค่าใหม่ทั้งหมด และปรับเปลี่ยนความเคยชินของทุกคนในทีม แต่วิธีที่ประหยัดต้นทุนกว่ามากคือการมองโมเดลใหม่เป็นอีกหนึ่งทางเลือกสำหรับ Task ที่โมเดลนั้นทำคะแนนได้โดดเด่น แล้วปล่อยส่วนที่เหลือของบอร์ดไว้ตามเดิม เราเคยนำเสนอไปแล้วว่า coding agent ที่ดีที่สุดสำคัญน้อยกว่าวิธีการจัดการงานของคุณ และตารางที่มีโมเดลถึงสามตัวผลัดกันชนะในแต่ละด้านนี้ ก็คือหลักฐานยืนยันมุมมองดังกล่าวด้วยตัวเลขเชิงประจักษ์
แนวทางการตัดสินใจที่ตรงไปตรงมามีอยู่ 2 รูปแบบ:
- ใช้ Runtime เริ่มต้นเพียงตัวเดียว หาก Task ส่วนใหญ่ของคุณมีลักษณะคล้ายกันและมีผู้ตรวจทานงานเพียงคนเดียว เพราะการเพิ่ม Runtime ตัวที่สองย่อมหมายถึงการต้องดูแลคอนฟิกูเรชันเพิ่มขึ้น มีค่าใช้จ่ายเพิ่มขึ้น และต้องรับมือกับรูปแบบข้อผิดพลาด (failure modes) อีกชุดหนึ่ง
- ใช้ 2 หรือ 3 Runtime ร่วมกัน เมื่องานของคุณแบ่งออกเป็นงานที่เน้นคำสั่ง shell, การตรวจสอบผ่าน UI และการอ่าน codebase ขนาดใหญ่อย่างชัดเจน เพราะนี่คือจุดที่ความสามารถของโมเดลบนตารางเบนช์มาร์กแยกออกจากกันอย่างแท้จริง
เขียนกฎการกำหนดเส้นทาง (Routing Rule) ออกมาเป็นลายลักษณ์อักษร
กฎการกำหนดเส้นทางที่อยู่ในหัวของวิศวกรเพียงคนเดียวเป็นแค่ความเคยชินส่วนตัว และความเคยชินย่อมไม่คงอยู่เมื่อมีพนักงานใหม่เข้ามาหรือในช่วงสัปดาห์ที่มีการเปิดตัวโมเดลใหม่ ดังนั้นจงเขียนระบุไว้ในจุดที่ทุกคนในทีมสามารถอ่านได้:
Routing rule v1 (re-test after every frontier launch)
Default
The Agent on your current default Runtime, until your own
comparison says otherwise.
Send the Task to the Claude Code Agent (Opus 5.5 set in Claude Code) when
- most of the work happens in a terminal: builds, CI repair, setup [Terminal-bench 4.0]
- it is training or evaluation plumbing for a model pipeline [PostTrainBench]
Send the Task to the Codex Agent (GPT-6 Astra set in Codex) when
- the change has to be verified by driving a desktop or browser UI [OSWorld-2.0]
- it is scientific or data work done mostly in a terminal [Terminal-Bench Science]
Send the Task to the Gemini CLI Agent (gemini-4-argon) when
- it needs a very large codebase or log read in one pass [GraphWalks]
- note: the 1M window is shared by input, thinking and output, and
Gemini CLI support is unverified. Smoke-test before this line routes work.
Escalate
If a run fails its acceptance checks twice, reassign the Task to the next
Agent in this rule. The failed runs stay on the Task as evidence.
Review
An Agent on a different Runtime from the author reads the diff and the
evidence. A person accepts the result.
แต่ละเงื่อนไขจะระบุถึงรายการเบนช์มาร์กที่เกี่ยวข้องและรูปแบบของ Task ที่สังเกตได้ชัดเจน แต่ส่วนที่สำคัญที่สุดคือบรรทัดของผู้ตรวจทาน (reviewer) เพราะการให้โมเดลตรวจสอบ diff ที่ตนเองไม่ได้เขียนขึ้นมาถือเป็นความเห็นที่สอง (second opinion) ที่มีต้นทุนต่ำ และการอนุมัติรับงานขั้นสุดท้ายก็ยังคงอยู่ที่มนุษย์
ส่วนกฎนี้ควรอยู่ที่ไหนนั้นขึ้นอยู่กับว่าใครเป็นผู้กำหนดเส้นทาง หากมนุษย์เป็นผู้เลือก Assignee กฎนี้ก็ควรระบุไว้ในข้อตกลงร่วมกันของ Space แต่หากเป็น Crew leader เป็นผู้กำหนดเส้นทาง ก็ควรเขียนไว้ในคำสั่งของ Crew ไม่ว่าจะใช้วิธีใด ผลลัพธ์ก็จะถูกส่งกลับมายัง Task เดียวกันเสมอ ทำให้ประวัติการเปรียบเทียบทั้งหมดถูกบันทึกไว้ในที่เดียว ทั้งนี้ บทความ Which model for which coding task จะเจาะลึกยิ่งขึ้นเกี่ยวกับการจับคู่ลักษณะงานเข้ากับบทบาทของแต่ละโมเดล
ทดสอบกฎกับ Codebase ของคุณเองก่อนที่จะปักใจเชื่อ
ผลคะแนนเบนช์มาร์กช่วยคัดเลือกประเภทของ Task เข้ามาอยู่ในรายชื่อตัวเลือก แต่ repository ของคุณเองต่างหากที่จะเป็นตัวตัดสินค่าเริ่มต้น วิธีการในบทความ how to compare coding agents on your own codebase เข้ากันได้ดีกับตารางนี้ เพราะตารางได้บอกไว้แล้วว่าคุณควรเลือก 3 Task ใดมาทดสอบ:
- Task ที่ต้องใช้งานเทอร์มินัลเป็นหลัก เช่น งานแก้ไขปัญหา CI ทำงานไม่ผ่าน
- Task ที่จำเป็นต้องตรวจสอบการเปลี่ยนแปลงผ่าน UI
- โจทย์หรือคำถามที่ต้องอาศัยบริบทของ repository เป็นบริเวณกว้าง
มอบหมายคำอธิบาย Task และเกณฑ์การตรวจรับงาน (acceptance criteria) เดียวกันให้กับ Agent แต่ละตัว โดยเปิดใช้งานโหมด Create temporary directory เพื่อให้การรันแต่ละครั้งมี worktree แยกเป็นของตัวเอง จากนั้นให้ประเมินผลลัพธ์จริงที่ส่งกลับมายัง Task ไม่ใช่ดูจากสิ่งที่ agent กล่าวอ้าง โดยพิจารณาจาก diff, การตรวจสอบและผลลัพธ์ที่ได้, คำถามที่ถูกถามขึ้นมา ตลอดจนระยะเวลาที่มนุษย์ใช้ในการตรวจสอบและอนุมัติรับงาน
คุณสามารถนำ Argon เข้ามาร่วมการเปรียบเทียบนี้ได้ทันที เมื่อการรันคำสั่ง smoke prompt สั้น ๆ บรรทัดเดียวด้วย gemini-4-argon ผ่านบน Gemini CLI ของคุณ จากนั้นให้รัน 3 Task เดิมเพื่อทดสอบก่อนที่จะปรับเปลี่ยนส่วนอื่น ๆ ทั้งนี้ บทความ Opus 5.5 vs GPT-6 Sol default-runtime comparison จะพาคุณไปดูรายละเอียดด้านต้นทุนต่องานที่ทำสำเร็จ (cost-per-completed-task) สำหรับการตัดสินใจในลักษณะเดียวกันนี้
โมเดลแต่ละตัวรันที่ไหนได้บ้าง ข้อมูล ณ วันที่ 15 ตุลาคม 2026
| โมเดล | Runtime | สิ่งที่ต้องใช้บน Computer | ราคามาตรฐานต่อ 1 ล้านโทเคน (ขาเข้า / ขาออก) |
|---|---|---|---|
| GPT-6 Astra | Codex | Codex ที่กำหนดค่าให้ใช้ Astra พร้อมบัญชีหรือคีย์ที่ได้รับสิทธิ์เข้าถึง | $10 / $50 |
| Claude Opus 5.5 | Claude Code | Claude Code ที่กำหนดค่าให้ใช้ Opus 5.5 พร้อมบัญชีหรือคีย์ที่ได้รับสิทธิ์เข้าถึง | $4 / $20 |
| Gemini 4 Argon | Gemini CLI (ยังไม่ได้รับการยืนยัน) | Gemini API key แบบชำระเงิน, กำหนดโมเดลเป็น gemini-4-argon และผ่านการทดสอบ smoke prompt แล้ว |
$2 / $10 ถึงวันที่ 30 พ.ย. หลังจากนั้น $4 / $20 |
| Other Gemini models | Gemini CLI | Gemini API key แบบชำระเงิน, Gemini Enterprise Agent Platform key หรือสิทธิ์การใช้งาน Code Assist Standard หรือ Enterprise | ขึ้นอยู่กับแต่ละโมเดล |
รายการของ Gemini มีข้อพึงระวังอยู่ เพราะตั้งแต่วันที่ 18 มิถุนายน 2026 เป็นต้นมา Gemini CLI ไม่รองรับบัญชี Google AI Pro, Ultra หรือบัญชี Code Assist ฟรีสำหรับบุคคลทั่วไปอีกต่อไป ตามประกาศการเปลี่ยนแปลงของ Google โดยแม้ว่าแพ็กเกจ Pro และ Ultra จะสามารถใช้งาน Argon ในแอปพลิเคชัน Gemini ได้ แต่แพ็กเกจสมัครสมาชิกรายเดือนไม่ใช่ API key และตัว Argon เองก็ไม่มี API ระดับฟรีให้ใช้งาน
Sharkly ไม่ได้เป็นผู้เลือกโมเดลให้คุณ ซึ่งในเอกสารคู่มือของ Agents ได้ระบุไว้อย่างชัดเจนว่า: “Agent จะทำงานตามโมเดลเริ่มต้นของ Runtime และไม่มีการระบุหรือการันตีชื่อโมเดลเฉพาะเจาะจงใด ๆ” คุณสามารถกำหนดโมเดลได้ผ่าน Custom arguments บนตัว Agent หรือ Runtime หรือกำหนดในคอนฟิกูเรชันของเครื่องมือนั้น ๆ บน Computer ดังนั้น คำว่า “Codex Agent” ในกฎการกำหนดเส้นทาง จึงหมายถึง Agent ที่ทำงานบน Codex Runtime ซึ่งได้รับการกำหนดค่าให้ใช้ Astra นั่นเอง
สำหรับขั้นตอนและวิธีการตั้งค่า สามารถดูได้ที่ GPT-6 Astra in Sharkly, Claude Opus 5.5 in Sharkly และสำหรับการตั้งค่า Gemini CLI เพื่อเปลี่ยนไปใช้ Argon สามารถดูได้ที่ Gemini 4 Argon for coding agents
ตารางเปลี่ยนได้ แต่บอร์ดไม่จำเป็นต้องเปลี่ยนตาม
การเปิดตัวโมเดลรุ่นถัดไปจะเข้ามาเปลี่ยนโฉมตารางนี้อีกครั้งอย่างแน่นอน แต่สิ่งที่ไม่ควรเปลี่ยนคือโครงสร้างรอบตัวโมเดล ไม่ว่าจะเป็นกฎการกำหนดเส้นทาง, บรรดา Task ต่าง ๆ, หลักฐานที่ได้จากการรันแต่ละครั้ง ตลอดจนบุคคลผู้ทำหน้าที่อนุมัติรับงาน โดย Agent มีหน้าที่ค้นคว้า ดำเนินการ ทดสอบ และรายงานผล ส่วนมนุษย์มีหน้าที่กำหนดทิศทาง มอบหมายสิทธิ์ และตรวจรับผลลัพธ์
และหากคุณต้องการใช้งาน coding agent หลากหลายตัวร่วมกันอย่างต่อเนื่อง แทนที่จะผูกขาดอยู่กับระบบนิเวศใดเพียงแห่งเดียว นั่นคือโจทย์ที่ Sharkly ถูกออกแบบมาเพื่อตอบคำถามนี้โดยเฉพาะ
