GPT-6.1 Sol กับ COBOL: 86.6% เทียบกับ 5.4% และมีเพียงหนึ่งในสองการทดสอบเท่านั้นที่สามารถรันซ้ำได้

เมื่อ 19 ตุลาคม 2026 O​penAI ได้เผยแพร่การประเมินการเขียนโค้ดสองชุดสำหรับภาษาที่มีทรัพยากรต่ำ และตัวเลขพาดหัวข่าวเป็นของ GPT-6.1 Sol: งานย้ายระบบ COBOL ผ่านเกณฑ์ถึง 86.6% ที่ความพยายามในการให้เหตุผลระดับต่ำ เทียบกับ 5.4% ของ GPT-5.6 Sol ในการตั้งค่าเดียวกัน และเพิ่มขึ้นเป็น 97.9% เมื่อเพิ่มระดับความพยายาม การประเมินชุดที่สองอย่าง MultiLangBench เป็นเรื่องราวของอีกโมเดลหนึ่ง — GPT-6 Astra ทำค่าเฉลี่ยได้ 87.4% จากยี่สิบภาษาที่ความพยายามสูงสุด — แต่มันเป็นครึ่งที่มีประโยชน์กว่าของการเผยแพร่นี้ เพราะ O​penAI วางฮาร์เนสชุดทดสอบไว้บน GitHub ภายใต้ Apache-2.0 และคุณสามารถรันมันเองได้ในบ่ายนี้ ส่วนการประเมินการย้ายระบบ COBOL ซึ่งเป็นตัวที่ถือตัวเลข 86.6% นั้นเป็นอีกเรื่องหนึ่ง: ชุดทดสอบของมันถูกซ่อนไว้ เกณฑ์ผ่านคือผลลัพธ์ต้องตรงกันทุกไบต์กับเคสที่ไม่มีใครนอก O​penAI เคยเห็น และยังไม่มีบุคคลที่สามรายใดทำซ้ำได้ ความไม่สมมาตรนี้คือเรื่องทั้งหมด และควรกล่าวให้ชัดเจนก่อนที่ตัวเลขใดจำนวนหนึ่งจะถูกอ้างอิงในข้อเสนอทางธุรกิจด้านการย้ายระบบ ความล้มเหลวของ AI และเหตุการณ์เกี่ยวกับเอเจนต์ที่ได้รับการบันทึกไว้ซึ่งอยู่เบื้องหลังการเปิดตัวเช่นนี้ ถูกรวบรวมไว้ใน OrcaRouter AI Incident Archive ซึ่งแต่ละรายการมีแหล่งอ้างอิง ระดับความรุนแรง เกรดความเชื่อมั่น และสถานะการถูกโต้แย้งของตัวเอง

มีวันที่หนึ่งที่ต้องจำให้แม่น ตัว GPT-6.1 Sol เองมาจาก 29 กันยายน 2026 — นี่ไม่ใช่การเปิดตัว และไม่มีสิ่งใดในนี้ที่เปลี่ยนแปลงน้ำหนัก ราคา หรือเรตการ์ดของโมเดล สิ่งที่เกิดขึ้นในวันที่ 19 ตุลาคม คือ OpenAI ได้เผยแพร่หลักฐานเกี่ยวกับสิ่งที่โมเดลทำได้ในหมวดหมู่ที่ก่อนหน้านี้ยังไม่เคยบันทึกไว้ และเผยแพร่เบนช์มาร์กที่ใครก็รันซ้ำได้ นั่นคือเหตุการณ์ที่บทความนี้กล่าวถึง

สิ่งที่เผยแพร่จริงคืออะไร และแต่ละครึ่งมีไว้เพื่ออะไร

การประเมินทั้งสองตอบคำถามที่แตกต่างกัน และกรอบของ OpenAI เองก็แยกทั้งสองออกจากกัน MultiLangBench ถามว่าโมเดลสามารถ สร้างบางสิ่งในภาษาที่ไม่มีใครใช้ฝึกโมเดลได้หรือไม่: พัฒนา SQLite 3.40.1 จากศูนย์ในภาษาโปรแกรมมิ่งหนึ่งในยี่สิบภาษา แล้วผ่านชุดทดสอบความสอดคล้องของฐานข้อมูล การประเมินการย้ายระบบ COBOL ถามว่าโมเดลสามารถ ย้ายบางสิ่งได้หรือไม่: แปลโปรแกรม COBOL เป็น C++, Java, Kotlin, Python หรือ Rust โดยรักษาพฤติกรรมที่สังเกตได้ไว้ให้ตรงกันทุกประการ

อย่างแรกคือการทดสอบระดับความสามารถขั้นต่ำ ส่วนอย่างที่สองคือสิ่งที่องค์กรธุรกิจให้ความสำคัญจริง ๆ เพราะ COBOL ไม่ใช่เรื่องแปลกในเชิงเบนช์มาร์ก — ประมาณการที่มีมานานของ IBM ระบุว่า COBOL รองรับระบบธนาคารออนไลน์มากกว่า 40% และธุรกรรม ATM ประมาณ 95% และโค้ดเหล่านี้ได้รับการดูแลโดยกำลังแรงงานที่ไม่ได้ถูกทดแทน

• MultiLangBench ความพยายามสูงสุด — GPT-6 Astra 87.4%, GPT-6 Luna 40.3%, GPT-5.6 Sol 26.8% Astra ทำได้เกิน 83% ใน 19 จาก 20 ภาษา โดย COBOL เป็นจุดอ่อนที่สุดที่ 72.1% เทียบกับ 10.9% ของ GPT-5.6 Sol ซึ่งบ่งชี้ว่าภาษาที่ยากที่สุดในชุดนี้ยังคงเป็นภาษาที่มีเครื่องมือเก่าแก่ที่สุด

• การโยกย้าย COBOL แบบใช้ความพยายามต่ำ — GPT-6.1 Sol 86.6%, GPT-5.6 Sol 5.4% โดยมีต้นทุน API สำหรับการรันประเมินอยู่ที่ประมาณ 61% ของโมเดลรุ่นก่อน หรือน้อยกว่า 39%

• การย้ายระบบ COBOL ต้องใช้ความพยายามสูงขึ้น — GPT-6.1 Sol 97.9% ซึ่ง O​penAI อธิบายว่าใกล้ถึงจุดอิ่มตัว

• รายละเอียดรายภาษาที่ OpenAI ได้เผยแพร่ — Fortran 83.5% สำหรับ Astra เทียบกับ 21.4% สำหรับ GPT-5.6 Sol; Visual Basic 89.4% เทียบกับ 27.5%; OCaml 85.8% เทียบกับ 25.6%; GPT-6 Luna อยู่ที่ 17.1% บน COBOL, 31.4% บน Fortran, 34.1% บน OCaml และ 41.6% บน Visual Basic

• ต้นทุนต่อหนึ่งตัวอย่างบน MultiLangBench — อยู่ที่ประมาณ $0.77 สำหรับ GPT-6 Luna เทียบกับ $3.48 สำหรับ GPT-5.6 Sol ต่ำกว่าประมาณ 78% ซึ่งเป็นตัวเลขที่ทำให้โมเดลที่อ่อนที่สุดในตารางกลายเป็นตัวที่น่าสนใจสำหรับไปป์ไลน์การสร้างบิลด์

การประเมินที่คุณรันซ้ำได้: สิ่งที่ MultiLangBench ต้องการจริง ๆ

รีโพซิทอรีคือ github.com/openai/MultiLangBench ซึ่งใช้สัญญาอนุญาต Apache-2.0 และการอ่านฮาร์เนสให้ข้อมูลมากกว่าการอ่านลีดเดอร์บอร์ด งานนี้เจาะจงพอที่โมเดลจะต้มตุ๋นไม่ได้: ต้องสร้างไฟล์ปฏิบัติการที่รับพาธฐานข้อมูลเป็นอาร์กิวเมนต์บรรทัดคำสั่ง อ่านคิวรี SQL จาก stdin และมีพฤติกรรมเหมือน SQLite 3.40.1 การทดสอบมาจากชุดทดสอบ TCL ของ SQLite เอง — มีการทดสอบทั้งหมดประมาณ 51,000 รายการ โดยประมาณ 24,000 รายการถูกแปลงเป็นชุดสามส่วนที่ฮาร์เนสใช้ ได้แก่ ฐานข้อมูลเริ่มต้น คิวรีของผู้ใช้ และคิวรีตรวจสอบ ชื่อการทดสอบเป็นแฮช SHA-256 ขององค์ประกอบเหล่านี้ ดังนั้นจึงไม่สามารถจดจำชุดทดสอบด้วยชื่อได้

ความยากอยู่ที่กฎเกณฑ์ และแต่ละข้อก็ปิดทางลัดลง

• ไม่มีอินเทอร์เน็ต และไม่มี SQLite ที่ไหนเลยในสภาพแวดล้อม ฮาร์เนสระบุให้ลบร่องรอยทุกอย่างของ SQLite ออกก่อน โมเดลไม่สามารถเรียกเอนจินจริงผ่านเชลล์ได้ และไม่สามารถดึงตัว implementation มาได้

• การตรวจสอบจะรันกับ SQLite 3.40.1 ของจริง Implementation ของคุณแก้ไขฐานข้อมูล ฮาร์เนสจะดึงมันออกมาและตรวจสอบด้วยของจริง พฤติกรรมแบบประมาณเอาไม่ผ่าน

• หกสิบวินาทีต่อการทดสอบ และคำตอบที่ผิดภาษาจะได้ศูนย์ การผสมภาษาจะล้มเหลว และชุดทดสอบระบุว่าอาจใช้โมเดลอื่นตรวจสอบว่าคุณเขียนด้วยภาษาใดจริง ๆ กฎข้อสุดท้ายนี้มีอยู่เพราะการโกงที่เห็นได้ชัด — เขียนด้วย Python แล้วห่อ — เป็นสิ่งแรกที่โมเดลที่มีความสามารถจะลอง

• การรันแบบเร็วใช้ 272 เทสต์ ไม่ใช่ 24,000 README แนะนำให้รันเฉพาะการทดสอบที่ชื่อขึ้นต้นด้วย00, 01 หรือ 02 เมื่อคุณต้องการตัวเลขที่เทียบกันได้ นี่คือรายละเอียดที่ควรสังเกตก่อนที่คุณจะเปรียบเทียบคะแนนของคุณกับของ OpenAI: การรันชุดเต็มและการรันแบบเร็วไม่ใช่การวัดเดียวกัน และ README ระบุไว้เช่นนั้น

นั่นคือเกณฑ์มาตรฐานที่ตรวจสอบได้จริง และยังบอกอะไรบางอย่างที่สื่อไม่ได้บอกคุณไว้: ตัวเลขพาดหัว 87.4% ถูกวัดบนชุดทดสอบที่คุณนำไปใช้กับโมเดลของคุณเองได้ ซึ่งหาได้ยากพอที่จะคุ้มค่ากับการดาวน์โหลด

eval ที่คุณไม่สามารถรันซ้ำได้ และเหตุใดสิ่งนั้นจึงไม่ใช่เรื่องอื้อฉาวโดยอัตโนมัติ

การประเมินการโยกย้าย COBOL ได้รับการออกแบบ ดำเนินการ และให้คะแนนโดย O​penAI และกรณีทดสอบไม่ได้เผยแพร่ เกณฑ์ผ่านระบุไว้อย่างแม่นยำ — การโยกย้ายจะนับก็ต่อเมื่อการทดสอบที่ซ่อนอยู่ทุกกรณีให้ผลลัพธ์ที่สังเกตได้เหมือนกันทุกไบต์ — และความแม่นยำนั้นเองคือสิ่งที่ทำให้ผลลัพธ์ไม่สามารถตรวจสอบได้จากภายนอก: 86.6% คือการวัดของ O​penAI เทียบกับกรณีที่ซ่อนอยู่ของ O​penAI เอง มีเพียงหนึ่งในสองการประเมินในการเผยแพร่นี้เท่านั้นที่ผู้อ่านสามารถทำซ้ำได้

การเก็บชุดทดสอบการย้ายระบบไว้ไม่เปิดเผยไม่ใช่เรื่องที่ไม่มีเหตุผลรองรับ คลังข้อมูลนี้น่าจะรวบรวมมาจากโปรแกรมระบบเก่าจริง และการเผยแพร่อาจทำให้โค้ดของลูกค้ารั่วไหล หรือมอบชุดข้อมูลฝึกให้โมเดลในอนาคต การเท่ากันแบบไบต์ต่อไบต์ก็เป็นเกณฑ์ที่อนุรักษ์นิยมอย่างแท้จริง เข้มงวดกว่าการประเมินของผู้ขายส่วนใหญ่: เกณฑ์นี้ไม่ให้รางวัลกับการแปลที่เพียงใกล้เคียง

แต่เกณฑ์นี้ก็เป็นจุดที่ปัญหาในทางปฏิบัติเริ่มต้นเช่นกัน และข้อควรระวังของ OpenAI เองก็ชี้ไปที่ตรงนี้ ผลลัพธ์จากการย้ายระบบยังต้องผ่านการตรวจทานโดยผู้เชี่ยวชาญและการทดสอบเทียบกับกฎทางธุรกิจและความเชื่อมโยงพึ่งพาของระบบก่อนขึ้นระบบจริง และความเท่าเทียมระดับไบต์เป็นเรื่องยากในจุดเดียวกับที่ COBOL ยาก ภาษา COBOL ตัดทอนและปัดเศษเลขคณิตจุดคงที่ในแบบที่ภาษาปลายทางส่วนใหญ่ไม่ทำ ดังนั้นคำแปลอาจดูถูกต้อง ผ่านชุดทดสอบที่ตรวจว่า "ใกล้พอ" และยังคงทำให้ยอดคงเหลือเคลื่อนไปหนึ่งเซนต์ ชุดทดสอบที่ซ่อนอยู่ซึ่งกำหนดให้ต้องเท่ากันแบบตรงตัวจัดการเรื่องนี้ได้ กระบวนการตรวจทานของคุณเองก็ต้องจัดการเรื่องนี้เช่นกัน เพราะคะแนนของโมเดลไม่ใช่คำยืนยันเกี่ยวกับโปรแกรมของคุณ

ตัวเลขต้นทุนก็ต้องใช้ความระมัดระวังแบบเดียวกัน การประหยัด 39% เป็นเพียงประมาณการสำหรับการรันการประเมิน — โทเคนที่เข้าและออกจาก benchmark — ไม่ใช่ค่าใช้จ่ายในการแทนที่ระบบใช้งานจริง ซึ่งมีองค์ประกอบหลักเป็นการสำรวจและทำความเข้าใจระบบ การตรวจทานโดยผู้เชี่ยวชาญ การทดสอบการรวมระบบ และพฤติกรรมที่ไม่มีเอกสารกำกับตลอดหลายปีซึ่งไม่มีการประเมินใดเก็บตัวอย่างมาครอบคลุม

86.6% และ 97.9% ควรเปลี่ยนอะไรในการตัดสินใจ

การตีความอย่างตรงไปตรงมาแคบกว่าพาดหัวข่าวและมีประโยชน์กว่าพาดหัวข่าวเหล่านั้น ฐานอ้างอิงที่ 5.4% ไม่ใช่โมเดลที่ทำงานได้ครึ่งๆ กลางๆ แต่เป็นโมเดลที่แทบไม่เคยสร้างคำแปลที่คงพฤติกรรมเดิมไว้ได้ ดังนั้นโมเดลรุ่นเก่าจึงไม่เคยเป็นตัวเลือกสำหรับงานนี้ GPT-6.1 Sol ที่ 86.6% อยู่ในช่วงที่ความคุ้มค่าเชิงเศรษฐศาสตร์พลิกกลับ: เครื่องมือที่ร่างคำแปลส่วนใหญ่และปล่อยให้ผู้ตรวจทานตรวจทานนั้นเป็นผลิตภัณฑ์ที่แตกต่างจากเครื่องมือที่ไม่ให้ผลลัพธ์ที่ใช้งานได้เลย

97.9% ที่ความพยายามสูงขึ้นคือตัวเลขที่ควรตั้งข้อสงสัย ไม่ใช่เพราะมันผิด แต่เพราะมันอิ่มตัวแล้ว เมื่อเบนช์มาร์กใกล้เพดานของมัน มันจะเลิกแยกความแตกต่างระหว่างโมเดลและเริ่มวัดชุดทดสอบแทน และ O​penAI ก็พูดเช่นนั้น สำหรับการวางแผน ให้ถือว่า 86.6% ที่ความพยายามต่ำเป็นจุดปฏิบัติการราคาถูก และ 97.9% เป็นเพดานของสิ่งที่การประเมินสามารถแสดงให้คุณเห็น ไม่ใช่คำสัญญาความแม่นยำสำหรับโค้ดเบสของคุณ

ยังมีการตรวจสอบไขว้ที่ควรทำอีกอย่างหนึ่ง และผลนี้สวนทางกับกระแสโฆษณาเกินจริง ในการทดสอบบิลด์ COBOL ยังคงเป็นภาษาที่อ่อนที่สุดของ GPT-6 Astra อยู่ที่ 72.1% แม้ว่า Astra จะเป็นโมเดลที่แข็งแกร่งกว่าโดยรวมด้วยค่าเฉลี่ย 87.4% ภาษานี้ยากทั้งสองทิศทาง โมเดลที่ย้ายโค้ด COBOL ได้ดีในการประเมินแบบซ่อนเร้นไม่ได้หมายความว่าจะเก่ง COBOL ด้วยเหตุนั้น แต่เก่งในรูปแบบที่การประเมินนั้นสุ่มตัวอย่างมา

อีกเรื่องที่เกิดขึ้นในสัปดาห์นี้: ข้อกล่าวอ้างเกี่ยวกับร่องรอยการใช้เหตุผล

โพสต์ที่ถูกแชร์กันอย่างกว้างขวางเมื่อวันที่ 21 ตุลาคม ระบุว่า reasoning trace ของ GPT-6.1 Sol "อ่านเข้าใจได้ทั้งหมด ไม่มีอะไรต้องกังวล" ไม่มีสิ่งใดในเอกสารเผยแพร่ของ OpenAI เมื่อวันที่ 19 ตุลาคม และไม่มีสิ่งใดบนหน้าเอกสารของโมเดลเอง ที่สนับสนุนข้อความดังกล่าวในฐานะการเปลี่ยนแปลงในสิ่งที่ API ส่งคืน คู่มือ reasoning ของ OpenAI ระบุไว้ชัดเจนว่าโทเคน reasoning แบบดิบไม่ถูกเปิดเผย — รายการ reasoning ยังคงเป็นข้อมูลทึบ — และสิ่งที่คุณขอได้คือบทสรุปของกระบวนการให้เหตุผลผ่านsummaryซึ่งเป็นพารามิเตอร์ โดยเนื้อหา reasoning ที่เข้ารหัสจะถูกเล่นซ้ำข้ามเทิร์น GPT-6.1 Sol รองรับรูปแบบ all_turnsของการเล่นซ้ำดังกล่าว ช่องทางสรุปไม่ใช่ trace ที่อ่านเข้าใจได้ และการถือว่าสองสิ่งนี้เป็นสิ่งเดียวกันคือวิธีที่ทำให้ข้ออ้างด้านความปลอดภัยถูกสร้างขึ้นมาด้วยภาพหน้าจอ

สิ่งที่วัดได้นั้นอยู่ใกล้เคียงและน่าสนใจกว่าสำหรับใครก็ตามที่ตรวจสอบเอเจนต์ การประเมิน GPT-6.1 Sol ของ Sonar เมื่อวันที่ 9 ตุลาคม ซึ่งรันเทียบกับ GPT-6 Sol ที่ระดับความพยายามปานกลางบนงาน Java 4,444 งาน พบว่าโทเคนการให้เหตุผลลดลง 51.4% — จาก 2.64M เป็น 1.28M — ขณะที่สัดส่วนของการให้เหตุผลในเอาต์พุตลดลงจาก 41.8% เป็น 19.5% เอาต์พุตเพิ่มขึ้น และอัตราการผ่านเชิงฟังก์ชันดีขึ้นจาก 83.09% เป็น 85.29% การรันเดียวกันพบว่าความหนาแน่นของช่องโหว่ลดลง 32.4% แต่ข้อค้นพบด้านความน่าเชื่อถือระดับรุนแรงวิกฤตเพิ่มขึ้นจาก 21 เป็น 46 โดยบั๊กด้านการทำงานพร้อมกันเป็นหมวดหมู่ที่ใหญ่ที่สุดที่ 196 ข้อค้นพบ นั่นคือการแลกเปลี่ยนที่ผู้ตรวจสอบสามารถนำไปใช้ดำเนินการได้ ส่วน “เทรซอ่านออก” ไม่ใช่ เพราะเทรซไม่ใช่สิ่งที่ถูกส่งคืนมา

สำหรับโครงการย้ายระบบ สิ่งนี้สำคัญในทางปฏิบัติอย่างหนึ่ง: ร่องรอยการตรวจสอบของคุณคือ diff และผลลัพธ์การทดสอบ ไม่ใช่คำบรรยายของโมเดล จัดสรรศักยภาพในการตรวจทานให้สอดคล้องกัน — การค้นพบของ Sonar ที่ว่าโค้ดที่สร้างขึ้นเพิ่มขึ้น 39.4% ก่อให้เกิดข้อค้นพบรวม 12,982 รายการ เทียบกับ 9,859 รายการ คือรูปร่างของต้นทุนที่ซ่อนอยู่หลังคะแนน benchmark

ดำเนินการทั้งสองกลุ่มด้วยตัวเอง

ปัญหาที่เกิดขึ้นจริงของการเปรียบเทียบแบบนี้คือ โดยปกติกลุ่มฐานและกลุ่มใหม่เป็นสัญญาสองฉบับ คีย์สองตัว และความสัมพันธ์ด้านการเรียกเก็บเงินสองชุด ซึ่งมีแรงเสียดทานมากพอที่ไม่มีใครรันกลุ่มฐาน โมเดลทั้งสองอยู่ในแคตตาล็อกของเราใต้คีย์เดียว: openai/gpt-6.1-sol และ openai/gpt-5.6-sol ในราคาตามรายการของ OpenAI โดยบวกเพิ่ม 0% ดังนั้นราคาอินพุต $2.00 และเอาต์พุต $10.00 ต่อล้านโทเค็นเดียวกันกับที่คุณจะจ่ายให้ผู้ขาย โดยอินพุตแคชอยู่ที่ $0.10 และการเขียนแคชอยู่ที่ $2.50 และระดับเกิน 272K ส่งผ่านในราคา $4.00, $0.20, $5.00 และ $15.00 การเปลี่ยนแปลงอัตราของผู้ขายจะมีผลที่นี่ในวันที่เผยแพร่ ไม่ใช่รอจนถึงการทบทวนสัญญาครั้งถัดไป

การส่งผ่านนั้นคือสิ่งที่ทำให้ benchmark ที่ทำได้ภายในวันเดียวมีต้นทุนการรันต่ำ: เพียงชี้ MultiLangBench quick suite ไปที่โมเดลทั้งสอง จ่ายตามราคาป้ายของแต่ละโมเดล แล้วคุณก็ได้ตัวเลขเกี่ยวกับ toolchain ของคุณเอง ไม่ใช่ของ O​penAI การ failover อัตโนมัติเป็นอีกครึ่งหนึ่งของข้อโต้แย้ง — หากโมเดลใหม่มีประสิทธิภาพลดลงระหว่างการรัน หรือเส้นทางใดเส้นทางหนึ่งถูกจำกัดอัตรา คำขอจะไม่ล้มเหลวตามไปด้วย ซึ่งเป็นสิ่งที่ทำให้คุณสามารถวางโมเดลที่ยังไม่ผ่านการพิสูจน์ไว้หน้าไปป์ไลน์การย้ายระบบได้ก่อนที่คุณจะมีหลักฐานของคุณเอง

ชุดทดสอบ MultiLangBench เป็นสาธารณะ แต่กรณีการย้ายระบบ COBOL ไม่ได้เปิดเผย ดังนั้นการทดสอบ 86.6% อย่างซื่อตรงเพียงอย่างเดียวคือสิ่งที่คุณสร้างขึ้นเอง: สุ่มตัวอย่างโปรแกรม COBOL ของคุณเองสักสองสามร้อยโปรแกรม แปลงโปรแกรมเหล่านั้น และ diff เอาต์พุตแบบไบต์ต่อไบต์กับพฤติกรรมเดิม นั่นคืองานหนึ่งสัปดาห์และมีค่ามากกว่าตารางของผู้ขาย

สิ่งที่ควรดูต่อไป

มีสามสิ่งที่จะเปลี่ยนภาพนี้ได้ และยังไม่มีสิ่งใดเกิดขึ้นเลย การที่ OpenAI เผยแพร่กรณีการย้ายระบบ COBOL หรือให้ห้องปฏิบัติการอิสระรันกรณีเหล่านั้นซ้ำ จะเปลี่ยนตัวเลขจากผู้ขายให้กลายเป็นผลการวัด การที่บุคคลที่สามทำตาราง MultiLangBench แยกตามภาษาขึ้นมาใหม่จะบอกเราได้ว่า 72.1% ของ COBOL เป็นคุณสมบัติของภาษานั้นหรือของชุดทดสอบ และบันทึกผลการทดสอบมาตรฐานอิสระของโมเดล — ปัจจุบัน Artificial Analysis จัดให้ GPT-6.1 Sol อยู่ที่ Intelligence Index 52 เป็นอันดับที่ 12 จาก 214 โมเดล ด้วยอัตรา 55.2 โทเค็นเอาต์พุตต่อวินาที และ $0.72 ต่องานดัชนี — คือจุดตรวจสอบที่ไม่ dépend กับการประเมินของ OpenAI เองเลย

จนถึงตอนนั้น สรุปที่มีประโยชน์ก็สั้นเท่านั้น GPT-6.1 Sol เป็นโมเดลจากวันที่ 29 กันยายน ซึ่งความสามารถด้านโค้ดเดิม (legacy code) ได้รับการบันทึกไว้เมื่อวันที่ 19 ตุลาคม ในการประเมินหนึ่งที่คุณรันได้ และอีกหนึ่งที่คุณรันไม่ได้ ตัวที่รันได้บอกว่ารุ่นใหม่อยู่ในระดับที่แตกต่างออกไปสำหรับภาษาที่มีทรัพยากรต่ำ ตัวที่รันไม่ได้บอกว่าการย้ายระบบ COBOL ตอนนี้คุ้มค่าที่จะนำร่องแล้ว มีเพียงฐานโค้ดของคุณเองเท่านั้นที่เปลี่ยนอย่างใดอย่างหนึ่งให้เป็นการตัดสินใจได้