คุณสั่งรันสามงานก่อนมื้อเที่ยง เก้าสิบวินาทีต่อมา ในสามเทอร์มินัลนั้นมีสองอันที่ไม่พิมพ์อะไรออกมาเลย อันหนึ่งกำลังใช้เหตุผลไล่ดูทั้ง repository อีกอันเจอ 504 ตอนเรียกออกไปแล้วและจะไม่กลับมาอีก จากมุมที่คุณนั่งอยู่ ทั้งสองอันคือสี่เหลี่ยม scrollback เหมือนกันเป๊ะที่มีเคอร์เซอร์กะพริบอยู่
นี่ไม่ใช่ปัญหาใหม่ แต่การเปิดตัวเมื่อ 2026-09-22 ทำให้มันแย่ลงอย่างเฉพาะเจาะจงและวัดผลได้ การตั้งค่า reasoning ระดับสูงสุดบนโมเดลใหม่ ๆ ซื้อความแม่นยำด้วยการคิดนานก่อนจะพูดอะไรออกมา Artificial Analysis วัดเวลาถึงโทเคนแรกของ GPT-6 Sol ตัวเลือก reasoning โหมด “max” ได้ที่ 102.15 วินาที และ GPT-6 Luna ที่ 124.23 วินาที นี่เป็นการวัดโดยบุคคลที่สามบนการตั้งค่าเฉพาะ ไม่ใช่ตัวเลขจากผู้ขายเอง และข้อจำกัดนี้สำคัญ แต่ทิศทางไม่ต้องสงสัยเลย: ความเงียบตอนเริ่มรันตอนนี้นานพอที่จะแยกไม่ออกจากการล้มเหลว
สรุปสั้น ๆ
เวลาถึงโทเคนแรก (time to first token) คือความหน่วงระหว่างการส่งคำขอไปจนถึงอักขระตัวแรกของคำตอบที่มาถึง และบนโมเดล reasoning ที่ใช้ความพยายามสูง ความหน่วงนี้คือช่วงที่การคิดส่วนใหญ่เกิดขึ้น เทอร์มินัลแยกไม่ออกระหว่างการรันที่กำลังคิด การรันที่กำลังรอคน และการรันที่ตายไปเมื่อสองนาทีก่อน เพราะทั้งสามอย่างไม่พิมพ์อะไรออกมาทั้งสิ้น แต่สถานะทำได้ เอเจนต์ค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนเป็นผู้กำหนดทิศทาง มอบอำนาจ และรับผลลัพธ์ สิ่งที่สัญญานี้ต้องมีเพื่อให้ทำงานได้คือสถานะการรันที่มองเห็นได้โดยไม่ต้องมีใครคอยเฝ้า: Sharkly เก็บ context ความคืบหน้า อุปสรรค ผลลัพธ์ และการรีวิวโดยคนไว้บน Task ตั้งแต่คำขอจนถึงการปล่อยงาน ดังนั้นการคิดนาน ๆ กับการรันที่ตายไปจึงเลิกดูเหมือนกัน
รอนานขึ้น และโมเดลถูกไม่ใช่โมเดลเร็ว
นี่คือสิ่งที่การวัดโดยบุคคลที่สามบอกเกี่ยวกับโมเดล GPT-6 ใหม่สองตัวที่การตั้งค่า reasoning สูงสุด
| โมเดล | API id | ความเร็วเอาต์พุต | เวลาถึงโทเคนแรก | อินพุต / เอาต์พุตต่อ 1M โทเคน |
|---|---|---|---|---|
| GPT-6 Sol (max) | gpt-6-sol |
115.2 โทเคน/วินาที | 102.15 วินาที | $2 / $10 |
| GPT-6 Luna (max) | gpt-6-luna |
153.9 โทเคน/วินาที | 124.23 วินาที | $0.10 / $0.50 |
ลองอ่านสองคอลัมน์สุดท้ายควบกัน Luna มีราคาต่อโทเคนเป็นหนึ่งในยี่สิบของ Sol และทำให้คุณรอนานขึ้นก่อนที่มันจะพูด ต้นทุนกับความหน่วงเป็นคนละแกน และสัญชาตญาณที่ว่าโมเดลถูกกว่าคือโมเดลที่ตอบไววกว่านั้นผิดไปเลยในกรณีนี้
ขอพูดข้อจำกัดตรง ๆ สองข้อก่อนใครจะสร้างแดชบอร์ดจากตัวเลขพวกนี้ ข้อแรก ตัวเลขนี้มาจาก Artificial Analysis ไม่ใช่จาก OpenAI และอธิบายเฉพาะตัวเลือก reasoning โหมด “max” เท่านั้น การตั้งค่า effort ที่ต่ำกว่านั้นให้ผลคนละแบบ และตัวเลขของคุณเองจะเปลี่ยนไปตามขนาด prompt ความพร้อมใช้งานของเครื่องมือ และเส้นทางที่ทราฟฟิกของคุณไปลง ข้อสอง เวลาถึงโทเคนแรกไม่ใช่การวัดเดียวกับความเร็วเอาต์พุต Anthropic บอกว่า Claude Opus 5.5 สร้างเอาต์พุตได้เร็วกว่า Opus 5 ราว 30% ซึ่งเป็นข้อความเกี่ยวกับโทเคนหลังตัวแรก โมเดลสามารถสตรีมได้เร็วแต่ก็ยังทิ้งให้คุณจ้องหน้าจอว่างเปล่านานนาทีครึ่งได้
เทอร์มินัลที่เงียบไม่ใช่สถานะ
ความเงียบในเทอร์มินัลมีสาเหตุอย่างน้อยสี่อย่าง และเทอร์มินัลแสดงผลทั้งสี่แบบเหมือนกันหมด:
- Runtime กำลังทำงาน มีการคิดเหตุผลอยู่ แต่ยังไม่มีเอาต์พุต
- การรันจบไปสักพักแล้วและกำลังรอให้คนตอบคำถาม
- คำขอล้มเหลว เอกสารของ Sharkly พูดตรง ๆ ว่าข้อนี้ตีความผิดได้ง่ายแค่ไหน: “Timeout / 408 / 504 หมายความว่าคำขอช้า ถูกยกเลิก หรือถูกเกตเวย์หน่วงไว้ นั่นไม่เหมือนกับกรณีที่ Computer ออฟไลน์”
- Computer หายไปจริง ๆ หรือไดเรกทอรีที่การรันต้องใช้ไม่ว่างเลย
เอเจนต์หนึ่งตัว เทอร์มินัลหนึ่งอัน คุณก็แค่รออีกนาทีแล้วจบ แต่ห้าเอเจนต์ข้ามสาม repository และสอง Computer คุณต้องสลับแท็บไปมาระหว่างหน้าต่างแล้วเดา นั่นคือหน้าตาธรรมดา ๆ ของ agent chaos: ไม่ใช่ความล้มเหลวครั้งใหญ่โต แต่เป็นทีมที่เอาความสนใจไปจมอยู่กับคำถามว่า “ตัวนี้ยังมีชีวิตอยู่ไหม” หลายครั้งต่อชั่วโมง
ปฏิกิริยาตอบสนองแบบอัตโนมัติที่คนมักทำคือฆ่ามันทิ้งแล้วรันใหม่ ที่ effort ระดับสูง ปฏิกิริยาแบบนี้แพงสองต่อ คุณต้องจ่ายเวลารอโทเคนแรกใหม่ทั้งหมด และโยนการคิดที่กำลังจะมาถึงทิ้งไป
สถานะต้องแยกอะไรออกจากกัน
โมเดลของ Sharkly เองน่าลอกเลียนไม่ว่าคุณจะใช้ Sharkly หรือไม่ เพราะมันแยกสองสิ่งที่เทอร์มินัลหลอมรวมเข้าด้วยกัน นี่เป็นการแยกแบบเดียวกับที่ทำให้สถานะการรัน บันทึก และสัญญาณความล้มเหลวอ่านออกจริง ๆ การรัน (run) มี execution state: Queued, Dispatched, Waiting for local directory, Running, Completed, Failed หรือ Canceled ส่วน Task มี lifecycle status และ Agent มี working state ซ้อนอยู่ข้างบนอีกชั้น: Working, Waiting for human reply, Waiting for human review หรือ Error เอกสารระบุเส้นแบ่งไว้ชัดเจนว่า run state เหล่านี้ “ไม่ได้หมายความโดยอัตโนมัติว่า Task มีสถานะเวิร์กโฟลว์เดียวกัน”
การแยกแบบนี้คือคำตอบทั้งหมดของคำถามที่ว่าค้างอยู่หรือกำลังคิด
| สิ่งที่เทอร์มินัลแสดง | สิ่งที่มันอาจเป็นจริง ๆ | อะไรที่แยกสองอย่างนี้ออก | ใครต้องลงมือต่อ |
|---|---|---|---|
| ไม่มีอะไรเลย ผ่านไป 100 วินาที | Running ยังไม่ถึงโทเคนแรก | Run state เป็น Running บันทึกมี timestamp ตอน dispatch | ไม่มีใคร ปล่อยไว้ |
| ไม่มีอะไรเลย ผ่านไป 10 นาที | Waiting for human reply | Working state เปลี่ยนไป Task สร้างรายการที่ต้องให้ความสนใจใน Inbox | ผู้รับผิดชอบตอบในบริบทนั้น |
| ไม่มีอะไรเลย ตลอดไป | Failed | Run state เป็น Failed บันทึกการทำงานมีชื่อเรื่องและคำตอบต้นฉบับจากโมเดลเซอร์วิส | ผู้รับผิดชอบอ่านบันทึกก่อนลองใหม่ |
| ไม่มีอะไรเลย ไม่เคยเริ่ม | Queued หรือ Waiting for local directory | Run state บวกกับว่าพูลไดเรกทอรีไหนไม่ว่าง | ปล่อยไดเรกทอรีให้ว่างหรือเพิ่มความจุแบบขนาน |
ทั้งสี่แถวนี้ไม่มีแถวไหนต้องมีคนคอยมองในจังหวะที่มันเปลี่ยน นั่นคือประเด็น สถานะถูกบันทึกไว้ และคำถามที่ว่า “มันกำลังคิดหรือค้างอยู่” กลายเป็นสิ่งที่คุณเข้าไปดูได้ แทนที่จะเป็นสิ่งที่คุณต้องนั่งรอให้ผ่านไป
timeout ต่อ Task ที่คุณตั้งไว้เมื่อเดือนมีนาคม
Agent ใน Sharkly มีจำนวน Task สูงสุดที่รันขนานได้ และมี timeout ต่อ Task ทีมส่วนใหญ่ตั้ง timeout นั้นครั้งเดียวตอนแรก โดยยึดจากว่านานแค่ไหนที่พวกเขายอมจ้องเทอร์มินัล ถ้าตัวเลขนั้นคือสองนาที และหลังจากนั้นคุณย้าย Agent ไปใช้การตั้งค่า reasoning ระดับ max คุณก็ได้ตั้งนโยบายที่ยกเลิกการรันในช่วงที่กำลังคิด แล้วรายงานว่าล้มเหลว
ไปดูก่อนของคุณภายในสัปดาห์นี้ เพดานขั้นต่ำไม่ใช่ “ฉันยอมรอนานแค่ไหน” แต่เป็น “Runtime นี้ใช้เวลานานแค่ไหนที่ระดับ effort ที่ฉันใช้จริง บวกกับตัวงานเอง” สำหรับการรันที่แค่โทเคนแรกก็กินเวลาเกินร้อยวินาทีได้ timeout ที่ต่ำกว่าห้านาทีคือการโยนเหรียญที่แต่งตัวเป็นนโยบาย
มีการตั้งค่าที่เกี่ยวข้องอีกสองอย่างที่ควรตรวจพร้อมกัน จำนวน Task สูงสุดที่รันขนานได้คือขีดจำกัด concurrency ที่แท้จริงของคุณ และเมื่อไดเรกทอรีที่ตั้งค่าไว้ไม่ว่างทั้งหมด การรันใหม่จะนั่งอยู่ใน Waiting for local directory แทนที่จะล้มเหลว ซึ่งเป็นพฤติกรรมที่ถูกต้องแต่ดูเหมือนค้างถ้าคุณดูแค่เทอร์มินัล
caching แก้ปัญหานี้ได้ไหม
ได้บางส่วน และไม่ใช่ส่วนที่คุณอยากได้ prompt caching ของ OpenAI สำหรับ GPT-6 ให้ส่วนลด 90% สำหรับการอ่านอินพุตที่ cached โดยมีอัตราการ hit สูงขึ้นเป็นค่าเริ่มต้น เพิ่ม breakpoint แบบระบุชัดเจนเพื่อให้คุณเลือกได้ว่า prefix ที่ cached สิ้นสุดตรงไหน และไม่ทำให้ cache แตกอีกต่อไปเมื่อคุณเปลี่ยน reasoning effort หรือความพร้อมใช้งานของเครื่องมือ GitHub รายงานว่าโทเคน prompt ที่ต้องประมวลผลใหม่ลดลงกว่า 50% จากการเรียกใช้หลายพันล้านครั้ง นั่นเป็นชัยชนะด้านต้นทุนและความหน่วงจริง ๆ ในส่วนของ prompt และการแก้เรื่องการเปลี่ยน effort ก็มีประโยชน์จริงสำหรับเอเจนต์ที่ยกระดับงานจากการตั้งค่าถูก ๆ ไปเป็นการตั้งค่าแพง ๆ กลางทาง
แต่มันไม่ได้ลบรอบการคิดเหตุผลออกไป cache ที่ warm หมายความว่า prompt ของคุณถูกประมวลผลใหม่ตั้งแต่ต้นน้อยลง ไม่ได้หมายความว่าโมเดลคิดเรื่องบั๊กของคุณไปแล้ว ยังไงก็ต้องเผื่องบเวลาสำหรับการรอไว้
เมื่อไหร่ควรจ่ายค่าการรอ และเมื่อไหร่ไม่ควร
ใช้การตั้งค่า reasoning ระดับสูงสุดเมื่องานนั้นเป็นงานที่คุณไม่อยากทำสองรอบ: การ migration, refactor ที่กระทบทั้งระบบ, อะไรก็ตามที่คำตอบผิดมีต้นทุนสูงกว่าเก้าสิบวินาที OpenAI รายงานว่า Sol ที่การตั้งค่า xhigh ทำคะแนนได้ 33.2% บน AutomationBench 1.0.6 ด้วยต้นทุน $0.27 ต่องาน ซึ่งคือลักษณะของการแลกเปลี่ยนนี้ ความแม่นยำตอนนี้ถูกในแง่เงินแต่แพงในแง่เวลานาฬิกา
ใช้การตั้งค่า effort ที่ต่ำลงเมื่อมีคนนั่งรอคำตอบอยู่ตรงนั้น งานแบบโต้ตอบ คำถามเร็ว ๆ เกี่ยวกับไฟล์ การแก้ไขเล็ก ๆ ในขอบเขตจำกัด: ปัญหาความเงียบแทบจะหายไปที่ effort ต่ำลง เพราะโทเคนแรกโผล่มาในตอนที่คุณยังจำได้ว่าถามอะไรไป
และเส้นแบ่งที่พูดตรง ๆ: ถ้าคุณรันเอเจนต์ตัวเดียวบน Task เดียว คุณไม่ต้องมีบอร์ดสำหรับเรื่องนี้ แค่ tail log ก็พอ ปัญหาสถานะจะเริ่มตอนที่จำนวนการรันมากกว่าจำนวนเทอร์มินัลที่คุณดูได้อย่างมีความหมาย ซึ่งสำหรับคนส่วนใหญ่คือประมาณสาม
สิ่งที่วิธีนี้แก้ไม่ได้
สถานะบอกคุณได้ว่าการรันกำลัง Working แต่มันไม่ได้บอกว่าการรันนั้นกำลังทำอะไรที่มีประโยชน์ และเอเจนต์ที่ผิดอย่างมั่นใจก็แสดงสถานะสีเขียวแบบเดียวกับเอเจนต์ที่ดีตลอดเวลาที่การรันยังดำเนินอยู่ ซึ่งบน Opus 5.5 อาจยาวถึง 18 ชั่วโมงหรือมากกว่า การแยก “กำลังรัน” ออกจาก “กำลังรันได้ดี” ยังคงเป็นปัญหารีวิว และการรีวิวยังคงเป็นงานของคน ระบบอัตโนมัติหยุดตรงจุดที่ต้องใช้ดุลพินิจของทีม
ถ้าคุณรันเอเจนต์หลายตัวพร้อมกันอยู่แล้ว การเปลี่ยนแปลงที่มีประโยชน์ที่สุดในสัปดาห์นี้ไม่ใช่โมเดลใหม่ แต่คือการทำให้สถานะของการรันทุกครั้งอ่านได้โดยไม่ต้องเปิดเทอร์มินัล เพื่อให้เก้าสิบวินาทีของความเงียบถัดไปเป็นข้อมูล ไม่ใช่คำถาม
