สรุปใน 5 วินาที: แม้ใช้โมเดลเดียวกัน ปริมาณการใช้ก็อาจต่างกันมากตามสิ่งที่ใส่ใน context ทุกครั้ง จำนวนครั้งที่เรียกโมเดล ปริมาณผลจากเครื่องมือที่พกต่อ และจุดที่บีบอัด context ถ้าโมเดลคือเครื่องยนต์ Harness อย่าง Codex หรือ OpenCode ก็คือระบบที่รวมเกียร์ ระบบจ่ายเชื้อเพลิง ระบบนำทาง และทีมช่าง เครื่องยนต์เดียวกันไม่ได้แปลว่าจะมีอัตราการใช้เท่ากัน
1. “กรอบ 5 ชั่วโมงเท่ากัน แต่ทำงานได้มากกว่าสองเท่า” — นี่คือประสบการณ์ ไม่ใช่ benchmark
นักพัฒนารายหนึ่งโพสต์ว่า หลังเปลี่ยนจาก Codex ไปใช้ OpenCode แต่ยังใช้ GPT-5.6 Sol ตัวเดียวกันผ่านการยืนยันตัวตนของ ChatGPT เขารู้สึกว่าสามารถทำงานได้มากกว่าสองเท่าภายในกรอบ 5 ชั่วโมงและกรอบรายสัปดาห์เท่าเดิม
มีผู้ตอบแนะนำ pi เป็น Harness อีกแบบ บางคนสงสัยเรื่องขีดจำกัด context และบางคนอยากดูการใช้จริงผ่าน telemetry
สิ่งสำคัญที่สุดคือ ยังไม่มีการพิสูจน์ว่า “OpenCode ให้ใช้ได้สองเท่าอย่างเป็นทางการ” นี่เป็นข้อสังเกตที่น่าสนใจ แต่ไม่ใช่การทดลองเปรียบเทียบแบบควบคุม
OpenAI อธิบายว่าการใช้ Codex ไม่ได้ถูกกำหนดด้วยจำนวนข้อความตายตัว แต่เปลี่ยนตามโมเดล ตำแหน่งที่งานทำงาน ความซับซ้อน context การให้เหตุผล ความเร็ว เครื่องมือ และปัจจัยอื่น ๆ บางแผนอาจมีทั้งกรอบ 5 ชั่วโมงและกรอบรายสัปดาห์
ดังนั้นการเปลี่ยน Harness แล้วอัตราการใช้เปลี่ยนเป็นสิ่งที่สมเหตุสมผลในเชิงระบบ
2. Harness คืออะไร — ทุกอย่างที่อยู่รอบตัว AI
ถ้ามองเฉพาะโมเดล เรื่องดูง่าย:
Sol = สมอง
แต่ coding agent จริงมีองค์ประกอบรอบโมเดลจำนวนมาก เช่น
- วิธีประกอบ system instruction
- ไฟล์ที่จะอ่าน
- จำนวน token ของบทสนทนาเก่าที่เก็บไว้
- จำนวนเครื่องมืออย่าง shell และ GitHub
- ปริมาณ tool output ที่นำไปรอบถัดไป
- จำนวน retry หลังล้มเหลว
- จำนวนรอบของ plan, implementation และ review
- การบีบอัดก่อน context overflow
- การแบ่งงานให้ subagent
- เกณฑ์ว่าเมื่อไรถือว่า “เสร็จ”
ทั้งหมดนี้คือ Harness ในความหมายกว้าง
OpenAI เองก็ใช้คำว่า “harness” ตอนอธิบาย Codex และกล่าวถึง App Server ที่เชื่อมโมเดล client เครื่องมือ และสถานะการสนทนา
ดังนั้น:
โมเดลเดียวกัน ≠ ระบบทั้งหมดเหมือนกัน
เหมือนเครื่องยนต์ V8 ตัวเดียวกันใน SUV หนัก 2 ตันกับตัวถังเบา อัตราสิ้นเปลืองย่อมไม่จำเป็นต้องเท่ากัน
3. ตัวกินทรัพยากรมักเป็น “สัมภาระที่ต้องพกทุก turn”
ใน session ยาว การให้เหตุผลแต่ละรอบอาจต้องพกประวัติการสนทนา system prompt กฎอย่าง AGENTS.md, MCP tool schema, ไฟล์จาก GitHub, log จาก shell, ผล test, ความล้มเหลวก่อนหน้า และข้อมูลสำหรับ retry
ทำครั้งเดียวอาจไม่หนัก แต่ถ้าส่งและตีความซ้ำ 10, 20 หรือ 30 ครั้ง ผลก็สะสม
บางครั้งการอ่าน log 100KB หนึ่งครั้งยังมีผลน้อยกว่า การเรียกโมเดลซ้ำหลายครั้งโดยพก context ระดับประมาณ 100KB ไปทุกครั้ง
ถ้า Harness A จบงานใน 15 turn แต่ Harness B ใช้ 30 turn เพราะมี plan, การยืนยัน, การสำรวจซ้ำ และ review ซ้ำ ต่อให้ใช้โมเดลเดียวกัน การใช้ก็ย่อมต่างกัน
แนวคิดง่าย ๆ คือ:
สัมภาระ × จำนวนรอบไปกลับ × จำนวน retry
4. ทำไม OpenCode น่าสนใจ — ChatGPT auth, MCP และ compaction
เอกสาร OpenCode ระบุว่าสามารถเชื่อม OpenAI ด้วย ChatGPT Plus/Pro ผ่าน browser ได้ และยังรองรับ MCP ทั้งแบบ local และ remote
ตัวอย่างโครงสร้างคือ:
OpenCode
→ GitHub MCP
→ database MCP
→ API ของตัวเอง
→ เครื่องมืออื่น
OpenCode มี automatic compaction ด้วย โดยเอกสารปัจจุบันระบุว่าเปิดเป็นค่าเริ่มต้น และยกตัวอย่างการเก็บสรุปที่สร้างขึ้นพร้อมกับประมาณ 15,000 token ล่าสุด
แนวคิดคือ:
เก็บประวัติไว้ในคลัง แต่ขนไปเฉพาะสิ่งที่จำเป็นสำหรับรอบถัดไป
อย่างไรก็ตาม OpenCode เตือนว่า MCP server และ tool schema จำนวนมากกิน context โดยเฉพาะ MCP ขนาดใหญ่อย่าง GitHub MCP
ต่อ MCP 20 ตัวไม่ได้แปลว่าจะมีประสิทธิภาพดีขึ้นเสมอ
5. การใช้ ChatGPT + MCP เชื่อมหลายบริการก็เป็นแนวคิดเดียวกัน
ถ้า ChatGPT อยู่ตรงกลาง แล้ว MCP หรือ connector เชื่อมไปยัง GitHub, server, cloud และ storage โครงสร้างโดยพื้นฐานยังเป็น “model + Harness + tools”
ChatGPT
→ MCP / connector
→ GitHub / server / cloud / storage
OpenCode ก็คล้ายกัน:
OpenCode
→ MCP / shell / API
→ repository / server / cloud
ความต่างคือ conversation state อยู่ที่ไหน tool loop อยู่ที่ไหน และ context ถูก compact ตรงไหน
ดังนั้นคำถามว่า “เหมือนใช้ ChatGPT ผ่าน MCP เชื่อมทุกอย่างหรือไม่?” คำตอบคือค่อนข้าง YES
แนวคิดสถาปัตยกรรมเหมือนกัน ต่างกันที่ผลิตภัณฑ์ซึ่งทำหน้าที่เป็นศูนย์กลาง
6. แล้ว ChatGPT จะส่งงานต่อให้ OpenCode ได้ไหม
OpenCode รองรับการเป็น MCP client และมีอินเทอร์เฟซทางการสำหรับเชื่อมระบบภายนอก รวมถึง HTTP/OpenAPI, SDK และ ACP
เพราะฉะนั้น ในเชิงสถาปัตยกรรมสามารถวาง ChatGPT ไว้ด้านหน้า มีชั้นเชื่อมต่อขนาดเล็ก แล้วให้ OpenCode รับช่วงงานยาวต่อได้
ประโยชน์สำคัญคือ ChatGPT ไม่ต้องพก tool schema และ log ขนาดใหญ่ทุก turn งานที่ต้องวนหลายรอบสามารถอยู่ฝั่ง OpenCode แล้วส่งกลับเฉพาะสถานะและผลลัพธ์สุดท้าย
ตรงนี้เองที่ “ประหยัดขึ้น” กลายเป็นการออกแบบระบบ
7. ถ้าอยากลดการใช้จริง ให้ลดจำนวนครั้งที่ต้องกลับไปหา AI
แนวทางที่มีประสิทธิภาพคือ:
- ส่งขั้นตอน deterministic ไป script
- เก็บ state และ receipt ไว้ฝั่งเครื่อง
- เปิดเฉพาะ tools ที่จำเป็น
- สรุปหรือดึงเฉพาะส่วนสำคัญจาก log ก่อนส่ง
- ไม่อ่านไฟล์เดิมซ้ำโดยไม่จำเป็น
- บันทึกสาเหตุล้มเหลวและ next action
- เรียกโมเดลประสิทธิภาพสูงเฉพาะเรื่องที่คลุมเครือ
- ส่งกลับ final production readback
แบ่งหน้าที่ได้ว่า:
AI = จัดการความคลุมเครือ
script / workflow = ทำขั้นตอนที่แน่นอน
GitHub / DB / state = ความจำ
ถ้าทุก cycle ต้องให้ AI คิดใหม่ว่า “ต่อไปทำอะไร” ก็เท่ากับตรวจสต็อกทั้งคลังซ้ำทุกครั้ง
8. แต่ยังพูดไม่ได้ว่า “OpenCode คุ้มกว่าเสมอในโควตาเท่าเดิม”
OpenAI ยืนยันว่า Codex และ Work แชร์ขีดจำกัดการใช้ บางแผนมีกรอบ 5 ชั่วโมงและรายสัปดาห์ และปริมาณการใช้เปลี่ยนตาม context เครื่องมือ และปัจจัยอื่น
OpenCode ยืนยันว่ารองรับ ChatGPT Plus/Pro authentication
แต่เอกสารทางการที่อ้างถึงไม่ได้บอกว่าการใช้ ChatGPT OAuth ผ่าน OpenCode ถูกคิดด้วยสูตรและค่าสัมประสิทธิ์ภายในเดียวกับ Codex ทุกประการ หรือ OpenCode จะประหยัดกว่าเป็นจำนวนเท่าคงที่
ดังนั้น:
“ได้ผลสองเท่า” เป็นรายงานการวัดที่น่าสนใจ
“จะได้สองเท่าเสมอ” ยังไม่ได้รับการยืนยัน
ถ้าจะเทียบจริง ควรใช้ repo, model, task และ completion criteria เดียวกัน แล้ววัด model calls, input/output token, compaction, tool calls, wall-clock time, จำนวนการเปลี่ยนแปลงที่เสร็จ, retry และผล test สุดท้าย
หน่วยที่สำคัญกว่าคือ การใช้ต่อหนึ่งงานที่สำเร็จ
9. สรุป — ในยุค agent “การเดินสาย” สำคัญมากหลังจากเลือกโมเดล
เมื่อก่อนคำถามหลักคือ “โมเดลไหนฉลาดที่สุด”
ในยุค agent แค่นั้นยังไม่พอ เพราะแม้ใช้โมเดลเดียวกัน ผลงานก็เปลี่ยนตามวิธีจัด context จำนวน tools การจัดการ state, compaction, retry, เกณฑ์จบงาน และการแบ่งงานกับ workflow ภายนอก
โมเดลคือเครื่องยนต์
Harness คือระบบรอบตัวทั้งหมด ตั้งแต่ระบบจ่ายเชื้อเพลิง เกียร์ ระบบนำทาง ทีมช่าง ไปจนถึงพื้นที่เก็บสัมภาระ
ดังนั้นคำถามว่า “Sol ตัวเดียวกัน ทำไมต่างกันขนาดนี้?” จึงเป็นคำถามที่เป็นธรรมชาติ
และเมื่อเริ่มเชื่อมหลายบริการด้วย MCP สิ่งที่ทำก็เปลี่ยนจาก “ใช้ AI” ไปเป็น:
ออกแบบสถานที่ทำงานรอบ AI
ข้อสรุปที่ตรงที่สุดคือ กลยุทธ์ MCP ที่แข็งแรงที่สุดไม่ใช่ “ถาม AI ทุกอย่าง”
แต่คือ เพิ่มจำนวนขั้นตอนที่ไม่จำเป็นต้องถาม AI
แหล่งข้อมูล
- [1] OpenAI, Unlocking the Codex harness: how we built the App Server
https://openai.com/index/unlocking-the-codex-harness/ - [2] OpenAI Help Center, การใช้ Codex กับแผน ChatGPT
https://help.openai.com/ja-jp/articles/11369540 - [3] OpenAI Help Center, การจัดการการใช้งาน GPT-6 Astra ใน Work และ Codex
https://help.openai.com/ja-jp/articles/20001516-managing-usage-with-gpt-6-astra-in-work-and-codex - [4] OpenCode Docs, Providers
https://opencode.ai/docs/providers - [5] OpenCode Docs, MCP servers
https://opencode.ai/v2/docs/mcp-servers - [6] OpenCode Docs, Compaction
https://opencode.ai/v2/docs/compaction - [7] OpenCode Docs, Server / SDK
https://dev.opencode.ai/docs/server/
https://dev.opencode.ai/docs/ja/sdk/ - [8] OpenCode Docs, ACP
https://opencode.ai/v2/docs/cli/acp/
แหล่งข้อมูล
- OpenAI, Unlocking the Codex harness: how we built the App Server openai.com
- OpenAI Help Center, การใช้ Codex กับแผน ChatGPT help.openai.com
- OpenAI Help Center, การจัดการการใช้งาน GPT-6 Astra ใน Work และ Codex help.openai.com
- OpenCode Docs, Providers opencode.ai
- OpenCode Docs, MCP servers opencode.ai
- OpenCode Docs, Compaction opencode.ai
- OpenCode Docs, Server / SDK https://dev.opencode.ai/docs/ja/sdk/ dev.opencode.ai
- OpenCode Docs, ACP opencode.ai
