วิธีรัน GPT-6.1 Sol Agents บน Sharkly

OpenAI เปิดตัว GPT-6.1 Sol ในงาน DevDay เมื่อวันที่ 29 กันยายนที่ผ่านมา โดยตั้งราคาตามเดิมเท่ากับ GPT-6 Sol คือ $2 ต่อหนึ่งล้าน input token และ $10 ต่อหนึ่งล้าน output token พร้อมทั้งปรับลดราคา cached input ลงครึ่งหนึ่งเหลือเพียง $0.10 ทว่ารายละเอียดที่สำคัญที่สุดสำหรับทีมที่ใช้งาน Codex Agent หลายตัวกลับเป็นสิ่งที่ไม่ได้ประกาศอย่างเอิกเกริก หน้าจอเริ่มต้นใน เอกสารประกอบของ Codex CLI ตอนนี้เปลี่ยนเป็น gpt-6.1-sol medium แล้ว ซึ่งหาก Computer เครื่องใดไม่ได้ตรึง (pin) โมเดลที่ต้องการไว้ Agent ของคุณก็จะเปลี่ยนโมเดลทันทีที่มีการอัปเดต Codex บนเครื่องนั้น แทนที่จะเปลี่ยนตามความตั้งใจของทีม

Sharkly จะไม่แสดงการเปลี่ยนแปลงดังกล่าวให้เห็น เพราะ Agent จะทำงานตามโมเดลเริ่มต้นของ Runtime และไม่มีการระบุชื่อโมเดล ทำให้ตั้งแต่สัปดาห์นี้เป็นต้นไป Agent สองตัวที่ได้รับคำสั่งเหมือนกันทุกประการอาจรันคนละโมเดลบน Computer สองเครื่อง ในขณะที่ Task บนบอร์ดดูเหมือนกันไม่มีผิดเพี้ยน การจะรู้ว่า Agent ตัวไหนใช้โมเดลอะไร หรือผลลัพธ์ชิ้นไหนมาจากโมเดลใด จึงกลายเป็นเรื่องที่ต้องมานั่งนึกย้อนความจำกันเอง คู่มือนี้จะครอบคลุมเฉพาะส่วนต่างที่มีการเปลี่ยนแปลงนับตั้งแต่ คู่มือ GPT-6 Sol ของเรา โดยจะอธิบายว่าค่าเริ่มต้นใหม่นี้มาจากไหน ควรตรึงโมเดลไว้เมื่อใด การตั้งค่าสองจุดที่เปลี่ยนไป และ Crew ควรจัดสรรงานอย่างไรเมื่อโมเดลระดับกลางมีขีดความสามารถเข้าใกล้รุ่นท็อปมากยิ่งขึ้น

สรุปประเด็นสำคัญ (TL;DR)

GPT-6.1 Sol เข้ามายัง Sharkly ผ่านทาง Codex Runtime บน Computer และตัว Sharkly เองจะไม่มีการเปลี่ยนแปลงใดๆ ทั้งสิ้นเมื่อมีการอัปเดต ขอให้ตรวจสอบว่า Computer แต่ละเครื่องรัน Codex บิลด์ใดอยู่ และไฟล์ ~/.codex/config.toml ได้ตรึงโมเดลไว้หรือไม่ โดยเครื่องที่ไม่ได้ตรึงโมเดลไว้จะใช้ค่าเริ่มต้นของ CLI ซึ่งปัจจุบันเอกสารระบุเป็น gpt-6.1-sol พร้อมระดับ effort แบบ medium ส่วน Computer ที่ตั้งค่าตามคู่มือก่อนหน้านี้ของเราจะยังคงอยู่ที่ gpt-6-sol จนกว่าจะมีคนเข้าไปแก้ไขไฟล์หนึ่งบรรทัด นอกจากนี้ ให้เปลี่ยนระดับ effort จาก none เป็น low, จำไว้ว่าส่วนลดค่าแคช 50% จะเห็นผลบน Computer ที่เรียกเก็บเงินผ่าน API key ไม่ใช่บัญชีที่ล็อกอินด้วยแพ็กเกจ และควรมองตารางจัดสรรงานด้านล่างเป็นแนวทางสำหรับนำไปทดสอบกับ Task ของคุณเอง ไม่ใช่ข้อสรุปตายตัว

มีอะไรเปลี่ยนแปลงไปบ้างใน Codex Runtime

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

นอกจากนี้ Codex CLI เวอร์ชันปรับปรุงใหม่ยังเพิ่มระบบสั่งการด้วยเสียง, มุมมอง /agents, การแก้ไขพรอมต์, การกู้คืนเซสชัน (resume) และการใช้งาน worktree ในทุกแพ็กเกจ ฟีเจอร์เหล่านี้มีประโยชน์มากเมื่อคุณสั่งการ Codex ด้วยตนเองผ่านเทอร์มินัล แต่เมื่อต้องทำงานร่วมกันในทีม Task จะทำหน้าที่เป็นบันทึกข้อมูลส่วนกลาง โดยในโหมด Temporary นั้น Sharkly จะสร้างไดเรกทอรีแยกเฉพาะสำหรับแต่ละ Task และสำหรับการทำงานกับ repository ก็สามารถเตรียม worktree ใหม่เอี่ยมได้ทันที พร้อมส่งสถานะการทำงาน ล็อก คำถาม และผลลัพธ์กลับมาบันทึกไว้ที่ Task เพื่อให้คนถัดไปสามารถเข้าดูต่อได้ทันที

จะตรึงโมเดลไว้ หรือปล่อยให้ Computer แต่ละเครื่องใช้ค่าเริ่มต้น

เริ่มต้นด้วยการสำรวจระบบของคุณก่อน เพราะแนวทางที่เหมาะสมอาจแตกต่างกันไปใน Computer แต่ละเครื่อง โดยคำสั่ง sharkly computer list จะแสดงรายชื่อ Computer ทั้งหมดที่ลงทะเบียนไว้กับองค์กรของคุณ และ sharkly computer show <computer-id> จะแสดงข้อมูลของ Computer เครื่องนั้นพร้อมทั้ง Runtime ที่มีอยู่ ส่วนบนตัวเครื่อง Computer เอง การเรียกใช้คำสั่ง codex จะแสดงหมายเลขบิลด์และโมเดลที่ใช้งานอยู่ ทั้งนี้ บันทึกการเปลี่ยนแปลงของ Codex ระบุว่าเวอร์ชัน 0.159.1 (29 กันยายน) ได้เปลี่ยนมาใช้ GPT-6.1 Sol เป็นค่าเริ่มต้น และตัวอย่างเซสชันในเอกสารแสดงค่าเป็น model: gpt-6.1-sol medium

สิ่งที่ต้องตรวจสอบมีอยู่สองจุดด้วยกัน จุดแรกคือไบนารีตัวใดกำลังทำงานอยู่ บน macOS เครื่อง Computer ที่ไม่ได้ติดตั้ง Codex แบบแยกต่างหากอาจไปลงทะเบียน Codex CLI ที่แถมมากับแอปเดสก์ท็อป ChatGPT ให้เป็น Runtime แทน ซึ่งเอกสารของ Sharkly แนะนำให้ติดตั้ง Codex แยกเองและกำหนดไว้ใน PATH จะดีกว่า จุดที่สองคือการตั้งค่าในเลเยอร์ใดเป็นตัวกำหนดโมเดล จาก พื้นฐานการกำหนดค่าของ Codex ค่าเริ่มต้นส่วนบุคคลจะอยู่ใน ~/.codex/config.toml แต่ละ repository สามารถเขียนทับค่านั้นได้ด้วยไฟล์ .codex/config.toml ของตัวเอง (ซึ่งจะโหลดเฉพาะในโปรเจกต์ที่เชื่อถือได้เท่านั้น) และหากมีการระบุ -m หรือ --model ผ่าน command line ก็จะมีผลเหนือการตั้งค่าทั้งสองแบบ

หลักในการตัดสินใจแบ่งออกเป็นสองกรณี: ปล่อยให้ Computer ใช้ค่าเริ่มต้นเมื่อเครื่องนั้นมีผู้ใช้งานคนเดียว รัน Task เพียงสัปดาห์ละไม่กี่ครั้ง และต้องการใช้โมเดลแนะนำของ OpenAI โดยไม่อยากคอยดูแลไฟล์คอนฟิก แต่ควรตรึงโมเดลไว้เมื่อมีคนในทีมหลายคนมอบหมายงานให้ Agent บน Computer เครื่องเดียวกัน เมื่อ Crew ทำงานข้าม Computer หลายเครื่อง หรือในระหว่างกลาง Sprint ซึ่งการเปลี่ยนแปลงเงียบๆ โดยไม่รู้ตัวอาจทำให้ผลลัพธ์ของวันอังคารกับวันพฤหัสบดีดูเหมือนทำมาจากโมเดลเดียวกันบน Task ทั้งที่ความจริงแล้วไม่ใช่

หากต้องการตรึงโมเดล ให้แก้ไขไฟล์คอนฟิกของผู้ใช้บน Computer ที่รัน Codex Runtime ดังนี้:

# ~/.codex/config.toml
model = "gpt-6.1-sol"
model_reasoning_effort = "medium"

คีย์ทั้งสองปรากฏอยู่ในเอกสารการตั้งค่าของ Codex พร้อมค่าดังกล่าว หากคุณตั้งค่าตามคู่มือ GPT-6 Sol ของเรา ไฟล์นี้จะระบุไว้อยู่แล้วว่า model = "gpt-6-sol" ซึ่งทำให้ Computer เครื่องนั้นจะไม่มีการเปลี่ยนโมเดลเมื่ออัปเดต คุณค่อยเปลี่ยนบรรทัดนี้เมื่อพร้อมจริงๆ อย่าเพิ่งรีบเปลี่ยนก่อนหน้านั้น

อัปเดต Codex ด้วยตัวติดตั้งที่เอกสารระบุไว้ ซึ่งใช้ได้ทั้งการติดตั้งใหม่และอัปเดต หรือจะสั่งให้ Sharkly ขออัปเดต CLI สำหรับ Runtime ใด Runtime หนึ่งก็ได้:

curl -fsSL https://chatgpt.com/codex/install.sh | sh
# or, from anywhere with the Sharkly CLI:
sharkly computer update <computer-id> <runtime-id>

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

สองการตั้งค่าที่มีการเปลี่ยนแปลง: ระดับ Effort และระบบแคช

ตัวเลือก none ถูกยกเลิกไปแล้ว โดย GPT-6.1 Sol รองรับเฉพาะ low, medium, high, xhigh และ max และไม่มีทั้ง none หรือ minimal อีกต่อไป ดังนั้น Computer เครื่องใดที่คอนฟิกค่าเป็น none ซึ่งเคยเป็นตัวเลือกยอดนิยมสำหรับการทำงานแบบรวดเร็วใน GPT-6 Sol จะต้องเปลี่ยนมาเป็น low ก่อนที่จะย้ายโมเดล และควรตรวจสอบผลลัพธ์ให้ดีอีกครั้ง เพราะระดับ low ยังคงมีการใช้กระบวนการคิด (reasoning) อยู่ หากการรันล้มเหลวจากการใช้การตั้งค่าเดิม บันทึก execution log จะยังคงเก็บชื่อหัวข้อและการตอบกลับดั้งเดิมของบริการโมเดลเอาไว้ และคำแนะนำในการแก้ปัญหาของ Sharkly สำหรับตัวเลือกที่ไม่รองรับคือให้ตรวจสอบโมเดลและ request options แทนที่จะสั่งรันซ้ำไปเรื่อยๆ โดยไม่หาสาเหตุ

การประหยัดค่าแคชคือข้อได้เปรียบที่เห็นผลคุ้มค่าอย่างเงียบๆ ทาง OpenAI กำหนดราคาสำหรับ cached input ไว้ที่ $0.10 ต่อหนึ่งล้านโทเค็น ซึ่ง “ถูกกว่าราคา input มาตรฐานถึง 95% และถูกกว่าราคา cached input ของ GPT-6 Sol ถึง 50%” จุดนี้จะเห็นความแตกต่างได้ชัดเจนที่สุดกับ Agent ที่รันต่อเนื่องเป็นเวลานาน เช่น งานที่ทำงานกับ repository เดิมต่อเนื่องเป็นชั่วโมงและต้องส่งบริบทเดิมซ้ำๆ รวมถึงสมาชิกใน Crew ที่เริ่มต้นด้วยโครงสร้าง repository เดียวกัน กฎเกณฑ์เดียวกัน และชุดคำสั่งทดสอบเดียวกัน ย่อมสามารถนำ prefix เดิมมาใช้ซ้ำได้ตลอดทั้งวัน

แต่ก็มีข้อพึงระวัง 3 ประการที่ต้องพิจารณาตามจริง ประการแรก การประหยัดค่าโทเค็นนี้จะเห็นผลเฉพาะบน Computer ที่ Codex เรียกเก็บเงินผ่าน API key เท่านั้น สำหรับ Computer ที่เข้าสู่ระบบด้วยแพ็กเกจ ChatGPT จะถูกหักโควตาการใช้งานของแพ็กเกจแทน ซึ่งเราได้เขียนอธิบายไว้ในบทความคู่ขนานเรื่องการรัน GPT-6.1 Sol โดยไม่ใช้ API key ประการที่สอง ราคาตั้งต้น (List price) ไม่ได้ปรับลดลง ดังนั้นงานที่ไม่มีการแคชจึงยังมีค่าใช้จ่ายเท่ากับสัปดาห์ก่อน และประการสุดท้าย บริบทขนาดยาวจะมีค่าบริการเพิ่มเติม โดย OpenAI จะคิดราคาพรอมต์ที่มี input token เกิน 272K ที่อัตรา 2 เท่าสำหรับ input และแคช และ 1.5 เท่าสำหรับ output ตลอดทั้งคำขอนั้น ดังนั้น Agent ที่ต้องดึงบริบทขนาดมหึมาติดไปด้วยในทุกๆ เทิร์น ควรได้รับการปรับลด prefix ให้กระชับและนิ่งเสียก่อน แทนที่จะแก้ปัญหาด้วยการเพิ่มงบประมาณ

การจัดสรรงานใน Crew: จะเลือกใช้ Astra, 6.1 Sol, Luna หรือ Claude Runtime

จุดขายหลักของ 6.1 Sol ที่ OpenAI ชูโรงคือ ประสิทธิภาพที่ใกล้เคียงกับ Astra ในราคาเพียงเศษเสี้ยวเดียว โดยตัวเลขทั้งหมดอ้างอิงจากการทดสอบภายในของ OpenAI เอง ในเบนช์มาร์ก DeepSWE v1.1 ทาง OpenAI ระบุว่า 6.1 Sol ทำคะแนนเทียบเท่า Astra ด้วยต้นทุนเพียงราว 1 ใน 5 เท่านั้น และทำคะแนนชนะสถิติที่ดีที่สุดของ GPT-6 Sol ไปได้ 6.4 คะแนน แม้จะใช้ระดับ effort ที่ต่ำกว่าก็ตาม ส่วนใน OSWorld 2.0 ซึ่งเป็นเบนช์มาร์กด้านการควบคุมคอมพิวเตอร์ (computer-use) ตัว 6.1 Sol ที่ระดับ max effort ทำคะแนนตามหลัง Astra ไม่เกิน 2.1 คะแนน แต่มีค่าใช้จ่ายต่อทาสก์เพียงประมาณ 1 ใน 7 อย่างไรก็ดี OpenAI ได้ระบุข้อจำกัดไว้อย่างชัดเจนว่า Astra ยังคงทำคะแนนได้สูงสุดใน Terminal-Bench Science ที่ 68.1% และ OpenAI ก็แนะนำให้ใช้ Astra สำหรับงานด้านวิทยาศาสตร์ที่มีความซับซ้อนสูงสุด

OpenAI’s คู่มือการเลือกโมเดล ได้จำแนกโมเดลตระกูลนี้ไว้ในทิศทางเดียวกัน ได้แก่ ใช้ Astra สำหรับโจทย์ที่มีความคลุมเครือ, ใช้ 6.1 Sol สำหรับงานที่มีความซับซ้อนแต่มีข้อจำกัดเรื่องเวลาและต้นทุน และใช้ Luna สำหรับงานที่กำหนดขอบเขตชัดเจนและงานคัดแยก (triage) พร้อมทั้งย้ำว่าแนวทางนี้เป็นเพียงจุดเริ่มต้นในการพิจารณาเท่านั้น และเนื่องจากโมเดลถูกกำหนดไว้ในการกำหนดค่าของ Runtime กฎการจัดสรรงาน (routing rule) ใน Sharkly จึงเป็นกฎที่ผูกกับตัว Computer นั่นคือ Agent ตัวใดที่ผูกกับ Computer ที่ตั้งค่า Codex ให้เป็น Astra ก็จะรันด้วย Astra เสมอ โดยนี่คือแนวทางเริ่มต้นที่คุณสามารถนำไปทดสอบได้:

แถวสุดท้ายในตารางคือจุดยืนที่เป็นกลางต่อผู้ให้บริการทุกราย ไม่ใช่การอ้างอิงคะแนนเบนช์มาร์ก เพราะ Claude Sonnet 5.5 เปิดตัวเพียงหนึ่งวันก่อน 6.1 Sol ด้วยราคา $2 และ $10 เท่ากัน และบทความของ OpenAI ก็นำ 6.1 Sol ไปเทียบกับ Opus 5.5 และ Fable 5.1 โดยไม่เคยเทียบกับ Sonnet 5.5 เลย อีกทั้งยังไม่มีผู้ให้บริการรายใดเผยแพร่ผลการทดสอบชนกันแบบตรงๆ ดังนั้นการเปรียบเทียบที่น่าเชื่อถือที่สุดจึงมีเพียงการทดสอบกับ Task ของคุณเองเท่านั้น คุณสามารถอ่านเหตุผลโดยละเอียดเกี่ยวกับการกำหนดกฎเกณฑ์ที่ชัดเจนร่วมกับกระบวนการส่งต่องานด้วยมนุษย์ได้ในบทความ การจัดสรรโมเดลสำหรับ Crews

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

คุณสามารถสร้างระบบนี้ขึ้นมาเองด้วย worktree หรือจะเลือกใช้ Sharkly เพื่อช่วยจัดการเวิร์กโฟลว์ทั้งหมดให้เป็นระบบก็ได้