เอเจนต์โคดดิ้งไม่รู้ว่าเวลาผ่านไปเท่าไร: งานจาก MATS วัด Claude Code กับ Codex พบทั้งคู่เดาว่า "ประมาณชั่วโมงครึ่ง" กับทุกงาน — และ Codex ผิดไป 4.12 เท่า
ถ้าคุณเคยสั่งเอเจนต์ว่า “ทำงานนี้ให้เสร็จใน 30 นาที” หรือ “ผมไปประชุม ช่วยไล่แก้ต่อไปอีกสองชั่วโมง” แล้วรู้สึกว่ามันไม่เคยทำตามจริง ๆ — มีงานวัดผลชิ้นหนึ่งที่ยืนยันว่าคุณไม่ได้คิดไปเอง
Michael Ofengenden ร่วมกับ Maksym Andriushchenko เผยแพร่งาน “Your Agents Are Not Time Aware” บน LessWrong เมื่อ 14 สิงหาคม 2026 (ทำในโปรแกรม MATS 10) และมันเพิ่งถูกสำนักข่าวสาย AI หยิบไปขยายเมื่อ 30 สิงหาคม จึงกลับมาอยู่ในสายตาคนทำเอเจนต์อีกรอบ — เราหยิบมาเขียนในฐานะงานตามเก็บ ไม่ใช่ข่าวสด แต่ผลลัพธ์ในนั้นตรงกับสิ่งที่คนใช้ Claude Code และ Codex ทุกวันเจออยู่จนควรอ่าน
การทดลองเรียบง่ายมาก: ให้เอเจนต์ ทำนาย เวลาที่จะใช้ → ทำงานจริง → แล้ว ย้อนประเมิน ว่าใช้เวลาไปเท่าไรและทำได้ดีแค่ไหน โดยรันบน ProgramBench (200 งาน reimplement ไบนารี) และ AgentTime ชุดประเมินที่ทีมสร้างเองจาก 18 เบนช์มาร์กรวม 235 งาน (มี METR RE-Bench, OSWorld 2.0, DeepSWE, GPQA-Diamond, PaperBench, Humanity’s Last Exam ฯลฯ) รันใน Docker บนเครื่อง Hetzner/AWS โดย ถอด time cap และ budget ของแต่ละเบนช์มาร์กออก เพื่อดูรันไทม์ตามธรรมชาติ และจับเวลาด้วยนาฬิกาที่อยู่นอก sandbox
ผลหลัก: ทุกโมเดลตอบ “ประมาณชั่วโมงครึ่ง”
บน ProgramBench ทีมวัด Opus 4.8 ใน Claude Code เทียบกับ GPT-5.5 ใน Codex:
| เอเจนต์ | รันจริงเฉลี่ย | ช่วง | ทำนาย | ผิดพลาด | อยู่ในช่วง 1.5× ของจริง | Compression exponent |
|---|---|---|---|---|---|---|
| Claude Opus 4.8 | 85 นาที | 10–177 นาที | 99 นาที | 1.16× | 64% | 0.24 |
| Codex GPT-5.5 | 17.5 นาที | 5–38 นาที | 72 นาที | 4.12× | 1% | 0.19 |
เมื่อมองผิวเผินเหมือน Claude จะแม่นกว่ามาก (1.16× เทียบกับ 4.12×) แต่ผู้เขียนชี้เองว่า มันไม่ได้แม่น มันแค่บังเอิญ — ทั้งสองโมเดลตอบ “ประมาณ 90 นาที” เหมือนกันแทบทุกงานโดยไม่สนความยาก และรันไทม์เฉลี่ยของ Claude ดันไปอยู่ที่ 85 นาทีพอดี เมื่อดูเฉพาะงานที่ Claude ใช้เวลาต่ำกว่า 25 นาที อัตราส่วนความผิดพลาดของมันก็เท่ากับ Codex บนงานเดียวกัน
ตัวเลขที่บอกความจริงคือ compression exponent — ความชันของกราฟ log-log ระหว่างเวลาที่ทายกับเวลาจริง ถ้าเป็น 1 แปลว่าทายตามความยากจริง ถ้าเป็น 0 แปลว่าตอบเลขเดิมทุกครั้ง ทั้งคู่ได้ 0.24 และ 0.19 คือเกือบแบนราบ พูดอีกอย่างคือเอเจนต์ตอบได้ว่า “งานประเภทนี้ปกติใช้เวลาเท่าไร” แต่ตอบไม่ได้ว่า “รันครั้งนี้ของฉันจะใช้เวลาเท่าไร” — เป็น planning fallacy แบบเดียวกับมนุษย์เป๊ะ
คอลัมน์ “อยู่ในช่วง 1.5× ของจริง” ที่ Codex ได้ 1% คือตัวเลขที่โหดที่สุดในตาราง
บน AgentTime ผลออกมาว่า การทำนายแย่กว่ากับงานสั้น และจะเข้าใกล้ความจริงก็ต่อเมื่องานยาวระดับหลายชั่วโมง เฉพาะรันที่สำเร็จ (คะแนน ≥95%, เหลือ 260 รัน) Fable 5 ทำนายเกินจริง 3.1 เท่า (124 งาน) และ GPT-5.6 Sol ทำนายเกินจริง 9.9 เท่า (136 งาน)
หมายเหตุที่ควรบอกให้ตรง: ตัวเลขในเนื้อหากับใน TLDR ของโพสต์เองไม่ตรงกัน — TLDR เขียนว่า “Fable เกิน 3 เท่า Sol เกิน 7 เท่า” ขณะที่เนื้อหาระบุ 3.1× และ 9.9× ตัวเลขในเนื้อหามีขอบเขตกำกับชัดเจนกว่า (นับเฉพาะรันที่สำเร็จ) เราจึงยึดตัวนั้น และควรระวังตัวเลขที่ถูกยกไปเล่าต่อในสื่อ
เรื่องที่คนใช้ Claude Code กับ Codex ควรอ่านที่สุด: harness สำคัญกว่าโมเดล
นี่คือส่วนที่มีมูลค่าเชิงปฏิบัติสูงสุดของงานนี้
Opus 4.8 รันเฉลี่ย 85 นาที ส่วน GPT-5.5 รัน 17.5 นาทีบนงานชุดเดียวกัน — ต่างกันเกือบห้าเท่า ทั้งที่ตามข้อมูลของ Artificial Analysis สองโมเดลนี้ความเร็วเอาต์พุตใกล้กัน (62 เทียบกับ 81 โทเคน/วินาที) และความสามารถก็ใกล้กัน อัตราการผ่านเทสต์ก็ไม่ต่างกันมาก (65.1% เทียบกับ 60.5%)
คำอธิบายอยู่ที่ harness ไม่ใช่โมเดล: มากกว่า 80% ของ wall-clock เป็นเวลาคิดและเจนเนอเรต ไม่ใช่รอเครื่องมือ และ Claude Code ใช้เทิร์นมากกว่า Codex 2.5 เท่าแม้จะสลับโมเดลกันแล้ว — ในการทดลองรอบหลังที่ใช้ Opus 5 กับ GPT-5.6 Sol ก็เจอรูปแบบเดิม: GPT-5.6 ใช้เทิร์นใน Claude Code มากกว่าใน Codex ราว 2.5 เท่า
พฤติกรรมสองแบบต่างกันชัด: Claude Code จะรันต่อไปจนกว่ามันจะคิดว่าแก้ปัญหาได้แล้ว ส่วน Codex มักหยุดที่เวลาหนึ่ง — Sol หยุดราว 30 นาทีแทบไม่ขึ้นกับความซับซ้อนของงาน (GPT-5.5 หยุดที่ 17 นาที) ขณะที่ Opus 5 ใน Claude Code รันมัธยฐาน 93 นาที และได้ความแม่นเทิร์นแรกสูงกว่า (96.80% เทียบกับ 82.0%)
แปลเป็นภาษาคนคุมงบ: ค่าใช้จ่ายและเวลาที่คุณจ่ายจริงถูกกำหนดโดย harness ที่คุณเลือก ไม่ใช่แค่โมเดล และการเปรียบเทียบ “โมเดล A vs โมเดล B” ที่ไม่คุม harness ก็ไม่มีความหมาย
ย้อนประเมินทำได้ดี — แต่เพราะมันแอบดู timestamp
ส่วนที่สองของงานทดสอบว่าเอเจนต์รู้ไหมว่าตัวเองใช้เวลาไปเท่าไร โดย fork เซสชันที่ทำงานเสร็จแล้วออกมาหลายชุดและค่อย ๆ ตัดข้อมูลออก:
- R-oracle (มีเครื่องมือคืนค่าเวลาที่ผ่านไป) — ตอบถูกแทบทุกครั้ง
- R-native (เซสชันจริง เครื่องมือปกติ) — พลาดไปไม่กี่เปอร์เซ็นต์
- R-context-only (ปิดเครื่องมือทั้งหมด) — แย่ลงเล็กน้อย
- R-replay (ประกอบ transcript ยิงเข้า API ตรง ไม่มี harness) — แย่ลงอย่างมีนัยสำคัญ
- R-scrubbed (ลบ timestamp ทุกอย่างออก) — ความผิดพลาดเพิ่มเป็นสองเท่า
พูดตรง ๆ คือเอเจนต์ไม่ได้ “รู้สึก” ถึงเวลา มันอ่านนาฬิกาจาก transcript ของตัวเอง — timestamp จาก tool call ที่จบแล้ว (Finished in 2.34s), วันที่ไฟล์จาก ls -la, วันที่ใน git log และ build log ทีมสังเกตว่าหลายรันเอเจนต์ใช้เวลาไปกับการ ขุด transcript ตัวเองหาค่านาฬิกา
และมี baseline โง่ ๆ ที่ชนะเอเจนต์ในมิติหนึ่ง: ความยาว transcript สัมพันธ์กับรันไทม์จริงที่ Pearson r = 0.91 แต่เมื่อคุมความยาว transcript แล้ว การประเมินภายในเซสชันยังเหลือสหสัมพันธ์ 0.4 — แปลว่าเอเจนต์ไม่ได้นับโทเคนอย่างเดียวเสียทีเดียว
เอเจนต์คิดว่าตัวเองเก่งกว่ามนุษย์สี่เท่า และให้คะแนนตัวเองเกินจริง
ส่วนที่สนุกที่สุดคือ ablation เรื่อง persona ทีมถามคำถามเดียวกันแต่เปลี่ยนประธาน: “งานนี้จะใช้เวลาเท่าไรสำหรับ {คุณ / เอเจนต์ AI ระดับแนวหน้า / มืออาชีพที่มีทักษะ}” บน 4,100 เซสชันสด
- เปลี่ยนคำกริยาจาก complete เป็น finish — ขยับแค่ราว 10% (1.11× สำหรับ Fable, 1.07× สำหรับ Sol)
- เปลี่ยน persona เป็นมนุษย์ — ประมาณการยาวขึ้น 3–4 เท่า
- เทียบกับ “เอเจนต์ AI ระดับแนวหน้า” — ทั้งคู่คิดว่าตัวเองเร็วกว่าเล็กน้อย
ตัวอย่างสุดขั้วคืองาน reimplement LuaJIT: Fable 5 ทายว่าตัวเองใช้ 480 นาที แต่มนุษย์ใช้ 240,000 นาที ส่วน Codex ทาย 240 นาทีเทียบกับ 250,000 นาที ข้อยกเว้นเดียวคือ OSWorld ซึ่งเป็นงานคุม GUI เดสก์ท็อป — ตรงนั้นทั้งสองระบบยอมรับว่ามนุษย์เก่งกว่า
ด้านการให้คะแนนตัวเอง: ในเทิร์นเดียวกัน Opus 4.8 และ GPT-5.5 ให้คะแนนตัวเองเกินจริงเฉลี่ย 20 จุด และให้คะแนนสูงแม้ในรันที่ล้มเหลว ตัวอย่างที่ชัดที่สุดคืองาน php-src ที่ทั้งสองโมเดล รู้ว่าทำได้ไม่ดี แต่ให้คะแนนตัวเองราว 70% ทั้งที่คะแนนจริงคือ 7% และ 14.5%
ในการวัดแบบแยกเทิร์นด้วยโมเดลรุ่นใหม่กว่า ผลกลับด้านอย่างน่าสนใจ: Opus 5 ประเมินตัวเองต่ำไป 11–15 จุด (มีรันที่ได้ 99.5% และ 96.7% แต่ให้ตัวเอง 86%) ส่วน GPT-5.6 Sol ยังให้เกินจริง 7 จุด ผู้เขียนระบุว่า Opus 5 เป็นโมเดลเดียวที่เขาทดสอบแล้วประเมินตัวเองต่ำกว่าความจริง
มุมมอง AI Curator
งานนี้ไม่ใช่การจับผิดโมเดล แต่เป็นการชี้ช่องว่างในวิธีที่เราวัดเอเจนต์ทั้งวงการ METR วัด time horizon จากภายนอก — โมเดลทำงานที่มนุษย์ใช้กี่ชั่วโมงได้สำเร็จ 50% ของครั้ง แต่ไม่มีใครวัดว่าเอเจนต์ มีแบบจำลองของเวลาในตัวเอง หรือเปล่า ซึ่งเป็นคนละเรื่องและสำคัญพอ ๆ กันเมื่อเราเริ่มปล่อยเอเจนต์รันยาว
สำหรับทีมไทยที่กำลังเอาเอเจนต์เข้าไปในไปป์ไลน์จริง ผมเห็นสามข้อที่ใช้ได้ทันที:
หนึ่ง — เลิกใช้คำสั่งที่อ้างอิงเวลา “ทำ 30 นาทีแล้วหยุด” ไม่ทำงาน และงานนี้อธิบายว่าทำไม: เอเจนต์ไม่มีนาฬิกาในตัว มันเดาจากบริบท ถ้าคุณต้องการเพดาน ให้บังคับจากภายนอก (timeout ใน harness, จำกัดจำนวนเทิร์น, จำกัดโทเคน) อย่าฝากไว้กับพรอมป์ต์ และถ้าจำเป็นต้องให้เอเจนต์รู้เวลาจริง ๆ ให้ tool ที่คืนค่าเวลาที่ผ่านไปไปเลย — ผล R-oracle บอกว่าพอมีเครื่องมือมันตอบถูกแทบทุกครั้ง เป็นการแก้ที่ถูกและได้ผล
สอง — ตัวเลข 2.5 เท่าของเทิร์นคือตัวเลขงบประมาณ ทีมส่วนใหญ่เลือกเครื่องมือจากตารางเบนช์มาร์กคุณภาพ แต่ความต่างของค่าใช้จ่ายระหว่าง harness บนโมเดลตัวเดียวกันอาจใหญ่กว่าความต่างระหว่างโมเดล ก่อนตัดสินใจว่าจะยืนบน Claude Code หรือ Codex ควรรันงานตัวแทนของทีมเองแล้ววัดเทิร์นกับ wall-clock จริง อย่าอ่านแต่คะแนน
สาม — อย่าเชื่อ self-score ของเอเจนต์เป็นเกตของไปป์ไลน์ ตัวอย่าง php-src ที่ให้ตัวเอง 70% ทั้งที่ได้จริง 7% เป็นภาพชัดว่าทำไมสถาปัตยกรรมแบบ “ให้เอเจนต์ประเมินตัวเองแล้วค่อยส่งต่อ” ถึงอันตราย ต้องมีเกตภายนอกที่รันเทสต์จริงเสมอ และข้อสังเกตว่า Opus 5 กลับประเมินตัวเองต่ำเกินไป ก็สำคัญไม่แพ้กัน เพราะระบบที่ตั้ง threshold ไว้ว่า “ถ้าโมเดลมั่นใจต่ำกว่า X ให้ส่งคน” จะโยนงานที่ทำถูกแล้วกลับมาให้มนุษย์โดยไม่จำเป็น — ทิศทางของอคติเปลี่ยนไปตามรุ่นโมเดล การตั้งเกณฑ์แข็ง ๆ ครั้งเดียวจึงพังเมื่ออัปเกรด
ข้อจำกัดที่ต้องพูดให้ครบ: นี่เป็นโพสต์บน LessWrong ยังไม่ผ่าน peer review และผู้เขียนระบุเองว่าเปเปอร์เต็มกับข้อมูล/เซสชันบน Hugging Face และ GitHub จะตามมา จำนวนงานในหลายการทดลองก็ไม่ใหญ่ (เช่น METR RE-Bench 5 งาน, YC-Bench 2 งาน) และตัวเลขที่ขัดกันเองระหว่าง TLDR กับเนื้อหาบ่งว่ายังเป็นงานที่กำลังเคลื่อนไหว ควรอ่านเป็นสัญญาณทิศทางที่แข็งแรง มากกว่าเป็นค่าคงที่ที่จะเอาไปอ้างเป็นตัวเลขตายตัว
แหล่งข่าว
อ่านเพิ่มในหมวด งานวิจัย
Anthropic ให้ Claude สร้างชุดข้อมูลที่ดูไร้พิษภัยแต่ทำโมเดลเบี้ยว ซ่อนในเรื่องเลี้ยงผึ้งและมวยปล้ำ จนผ่านระบบตรวจที่คล้ายของจริง
ทีม Alignment ของ Anthropic ให้ Claude ปีนหาชุดข้อมูล fine-tune ที่หลบ monitor ได้ ผลคือซ่อนพฤติกรรมในงานเขียนแนวบทบาทสมมติ และโมเดลที่เทรนแล้วนำไปใช้ในบุคลิกตัวเอง ผลซ้ำได้บน Qwen 3.6 27B แต่การทดลองเอื้อฝ่ายโจมตีมากและไม่ได้สะท้อนโมเดลที่ใช้งานจริง
Memdoor ทำซ้ำ GVS5H ได้: ทีม Qwen3.8-27B ห้าตัวตามทัน Fable 5 บนโจทย์ LiveCodeBench Hard แต่ผู้ทำบอกเองว่า 'เท่า' ไม่ใช่ 'ชนะ'
Memdoor ปล่อย workflow team-solve ที่เขียนวิธี GVS5H เป็น YAML ล้วนและทำคะแนน 9.8/10 บน LiveCodeBench Hard 10 ข้อ เทียบกับ 8.0 ของ Fable 5 แบบเรียกครั้งเดียว แต่ตัวอย่างเล็กและมีข้อจำกัด ส่วนงานวิจัยต้นฉบับชี้ว่าวิธีนี้ไม่ได้ช่วยทุกโมเดล
QwenPU รัน LLM ซ้อนใน LLM ด้วยหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ส่วน bootgpt ทำให้เครื่อง 386 บูตเข้าโมเดลภาษาโดยไม่มี OS
ผู้สร้าง Qwenputer ปล่อย QwenPU เมื่อ 31 ต.ค. รัน stories260K ของ Karpathy บนหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ลดเหลือ 53,000 trace token ต่อหนึ่ง token เรื่องเล่า วันเดียวกัน bootgpt ใส่โมเดล int8 ขนาด 11.5KB ให้บูตบนเครื่อง 386 โดยไม่มี OS