การรั่วไหลของ Bug-Scope จาก Anthropic: โมเดลที่แก้บั๊กหนึ่งตัวและถามถึงคลาส

ประโยคที่น่าสนใจที่สุดในข้อมูลรั่วไหลของ Anthropic ชุดปัจจุบันไม่ได้เกี่ยวกับความสามารถทางปัญญา แต่เกี่ยวกับขอบเขตการทำงาน ตามรายงานที่ถูกส่งต่อบน X เมื่อวันที่ 19 ตุลาคม 2026 Anthropic กำลังเตรียมโมเดลที่เมื่อถูกขอให้แก้บั๊กเพียงจุดเดียว จะสามารถระบุกลุ่มปัญหาที่กว้างกว่าซึ่งอยู่เบื้องหลังได้ และจากนั้นถามว่าควรจัดการกับสิ่งเหล่านั้นด้วยหรือไม่ นั่นเป็นข้อกล่าวอ้างเกี่ยวกับจุดที่โมเดลหยุด ไม่ใช่เกี่ยวกับว่ามันให้เหตุผลได้ดีเพียงใด — และมันตกอยู่ตรงแนวรอยเลื่อนของเอเจนต์เขียนโค้ดทุกตัวที่ใช้งานจริงโดยตรง รวมถึงตัวที่สร้างบน Claude Opus 5.5 ในปัจจุบัน และตัวที่ผู้คนกำลังสันนิษฐานอยู่แล้วว่าจะรันบน Claude Fable 5.5 ซึ่งเป็นแคนดิเดตที่ยังไม่ได้รับการยืนยันสำหรับโมเดลที่กำลังถูกอธิบาย Anthropic ยังไม่ได้ประกาศ ตั้งชื่อ หรือกำหนดวันที่สำหรับโมเดลลักษณะนี้ใด ๆ ไม่มีตัวระบุ ไม่มีตารางราคา ไม่มีการ์ดโมเดล และไม่มีการประเมิน ทุกสิ่งด้านล่างเกี่ยวกับพฤติกรรมที่ถูกรายงานนั้นเป็นการรายงานที่ไม่ได้รับการยืนยันและมาจากแหล่งเดียว และทุกสิ่งด้านล่างเกี่ยวกับไลน์อัปปัจจุบันมาจากเอกสารของ Anthropic เอง ความล้มเหลวของ AI และเหตุการณ์ของเอเจนต์เขียนโค้ดที่มีการบันทึกไว้ ซึ่งอยู่เบื้องหลังรายงานเช่นนี้ ถูกรวบรวมไว้ใน OrcaRouter AI Incident Archive โดยแต่ละรายการมีแหล่งที่มาของตัวเอง ระดับความรุนแรง ระดับความมั่นใจ และแฟล็กข้อโต้แย้ง

ถ้อยคำสำคัญกว่าปกติในกรณีนี้ เพราะบทสรุปสองฉบับของรายงานเดียวกันอธิบายพฤติกรรมที่ต่างกันสองแบบ ฉบับที่อ่านแล้วเหมือนข้อกำหนด — บั๊กหนึ่งตัว ประเภทของบั๊กที่อยู่เบื้องหลัง และคำถามว่าควรขยายขอบเขตงานหรือไม่ — ปรากฏอยู่ในข้อความที่ส่งต่อมาถึงเรา ส่วนฉบับรวบรวมรายงานที่เผยแพร่ต่อสาธารณะ ซึ่งอ่านเมื่อวันที่ 19 ตุลาคม มีถ้อยคำอีกแบบหนึ่ง: โมเดลที่ “มีสัญชาตญาณและการให้เหตุผลที่ดีกว่า ซึ่งสามารถมองเห็นเจตนาที่อยู่เบื้องหลัง และเก่งกว่าในการคิดนอกกรอบ” สองข้อนี้ไม่ใช่ข้อกล่าวอ้างเดียวกัน ข้อหนึ่งพูดถึงโมเดลที่เสนอให้ทำงานเพิ่ม ส่วนอีกข้อพูดถึงโมเดลที่อ่านสิ่งที่คุณหมายถึงออก ทั้งสองอย่างอาจเป็นจริงกับโมเดลเดียวกันได้ แต่มีเพียงอย่างเดียวที่เปลี่ยนหน้าตาของ diff ในเช้าวันจันทร์ และนั่นคือสิ่งที่ควรค่าแก่การแยกออกมาพิจารณา

สิ่งที่ข้อกล่าวอ้างนั้นกล่าวจริง ๆ และสิ่งที่มันไม่ได้กล่าว

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

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

สิ่งที่รายงานไม่ได้ระบุก็มีความสำคัญไม่แพ้กัน ไม่มีชื่อโมเดล ไม่มีตัวระบุ API ไม่มีราคา ไม่มีหน้าต่างบริบทหรือขีดจำกัดเอาต์พุต ไม่มีข้อบ่งชี้ว่าพฤติกรรมดังกล่าวเป็นค่าเริ่มต้น เป็นโหมด หรือเป็นสิ่งที่ผู้เรียกใช้ต้องร้องขอเอง และไม่มีการยืนยันจากผู้จำหน่ายใด ๆ — ห้องข่าวของ Anthropic ไม่ได้เผยแพร่สิ่งใดเกี่ยวกับโมเดลใหม่นับตั้งแต่ Claude Haiku 5.5 เมื่อวันที่ 7 ตุลาคม 2026 และภาพรวมโมเดลของ Claude Platform ยังคงระบุโมเดลไว้ทั้งหมดสี่โมเดล ได้แก่ Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5 และ Claude Haiku 5.5

ทำไม “กลุ่มที่กว้างกว่า” จึงเป็นข้อกล่าวอ้างที่แตกต่างจาก “การใช้เหตุผลที่ดีกว่า”

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

ตัวอย่างแบบฉบับคืออินเจกชัน คุณรายงานคิวรีที่ไม่ได้ผ่านการ sanitize หนึ่งรายการใน handler หนึ่งตัว ประเภทที่อยู่เบื้องหลังก็คือ handler อื่นทุกตัวที่สร้างคิวรีด้วยวิธีเดียวกัน ผู้ตรวจทานที่เป็นมนุษย์ซึ่งเคยเห็นสิ่งนี้มาก่อนจะไม่แก้ handler ตัวเดียวแล้วไปต่อ แต่จะ grep หารูปแบบนี้ แล้วถามว่าการแก้ไขควรอยู่ในตั๋วนี้หรือไม่ โมเดลที่ทำแบบเดียวกันกำลังทำการรีวิว ไม่ใช่การซ่อมแซม ผลลัพธ์ไม่ใช่แพตช์ แต่เป็นข้อค้นพบ — และข้อค้นพบจะมีประโยชน์ก็ต่อเมื่อมีผู้มีอำนาจขยายขอบเขตตั๋วอยู่ในวง

• สิ่งที่ข้อกล่าวอ้างระบุ — เมื่อได้รับข้อบกพร่องมาเพียงหนึ่งจุด ให้ระบุรูปแบบที่เกิดขึ้นและยกขึ้นมาก่อนดำเนินการ

• สิ่งที่การแก้ไขแบบธรรมดาทำ — เปลี่ยนโค้ดที่คุณชี้ไป และหยุดแค่นั้น

• สิ่งที่เอเจนต์ที่ไม่รอบคอบทำ — เปลี่ยนโค้ดที่คุณชี้ไว้ แล้วทำต่อไปเรื่อย ๆ และ diff คือสิ่งแรกที่คุณได้รู้เรื่องนี้

• สิ่งที่รายงานยังคงเปิดประเด็นไว้ — ว่า “asks” หมายถึงคำถามที่หยุดการดำเนินการในเซสชันแบบโต้ตอบ หรือบันทึกที่แนบท้ายการเปลี่ยนแปลงที่เสร็จสิ้นแล้ว

บรรทัดสุดท้ายนั้นคือจุดที่การรั่วไหลไม่อาจถูกประเมินให้คะแนนได้อีกต่อไป ความแตกต่างระหว่างการตีความสองแบบนั้น คือความแตกต่างระหว่างเครื่องมือที่เคารพการควบคุมการเปลี่ยนแปลง กับเครื่องมือที่บันทึกการขยายขอบเขตงานของตนเองเกินเลยไปแล้วในภายหลัง

แนวทางของ Anthropic เองก็อยู่ทั้งสองด้านของเรื่องนี้แล้ว

นี่คือสิ่งที่ทำให้ข้อกล่าวอ้างนี้น่าเชื่อถือมากกว่าเป็นเรื่องสุ่ม คำแนะนำที่ Anthropic เผยแพร่สำหรับ Claude Code ได้ระบุให้ใช้สัญชาตญาณแบบนี้เป๊ะ ๆ ในที่หนึ่ง และเตือนไม่ให้ทำเช่นนั้นในอีกที่หนึ่ง โดยคำแนะนำทั้งสองส่วนถูกคั่นด้วยย่อหน้าหนึ่ง

“จัดการที่ต้นเหตุ ไม่ใช่ที่อาการ” เป็นหนึ่งในกลยุทธ์ที่ระบุไว้ในคู่มือแนวปฏิบัติที่ดีที่สุดของ Claude Code ซึ่งยกตัวอย่างด้วยความล้มเหลวในการ build: แก้ไขข้อผิดพลาดและตรวจสอบว่า build สำเร็จ และอย่าปิดบังข้อผิดพลาด นั่นคือคำแนะนำตรง ๆ ให้มองข้ามกรณีที่ถูกรายงานไป ก่อนหน้านี้ไม่กี่หัวข้อ คู่มือเดียวกันบอกให้ “กำหนดขอบเขตงาน ระบุไฟล์ สถานการณ์ และความต้องการในการทดสอบ” พร้อมตัวอย่างการขอให้ทดสอบที่ครอบคลุม edge case หนึ่งกรณี แทนที่จะขอทดสอบทั่ว ๆ ไป เหตุผลที่ให้ไว้คือ Claude สามารถอนุมานเจตนาได้ แต่อ่านใจคุณไม่ได้

คู่มือนี้ยังลากเส้นแบ่งตามขนาดของ diff ด้วย: โหมดวางแผนคุ้มค่ากับภาระที่เพิ่มขึ้นเมื่อการเปลี่ยนแปลงแตะหลายไฟล์หรือแนวทางยังไม่แน่นอน และ “ถ้าคุณอธิบาย diff ได้ในประโยคเดียว ก็ข้ามการวางแผนไปเลย” โมเดลที่ขยายบั๊กหนึ่งตัวให้กลายเป็นทั้งคลาส โดยโครงสร้างแล้วกำลังเปลี่ยน diff หนึ่งประโยคให้กลายเป็นแผน ดังนั้นพฤติกรรมที่การรั่วไหลอธิบายไว้จึงไม่ใช่เรื่องแปลกจากปรัชญาผลิตภัณฑ์ของ Anthropic — มันคือช่วงเวลาที่หลักการสองข้อที่ประกาศไว้ปะทะกัน และการปะทะนั้นในปัจจุบันถูกแก้โดยผู้ใช้ ไม่ใช่โดยโมเดล

ยังมีเหตุผลที่สองซึ่งชวนอึดอัดน้อยกว่าว่าทำไมข้อกล่าวอ้างนี้จึงฟังขึ้น เอกสารของ A​nthropic เองก็ยอมรับอย่างตรงไปตรงมาว่าโมเดลจะหยุดเมื่อเห็นว่างานดูเหมือนเสร็จแล้ว และหากไม่มีอะไรที่โมเดลรันได้ — ชุดทดสอบ รหัสออกของบิลด์ หรือดิฟเทียบกับฟิกซ์เจอร์ — “ดูเหมือนเสร็จ” ก็เป็นสัญญาณเดียวที่มี โมเดลที่ généralise จากบั๊กหนึ่งไปสู่ทั้งคลาส คือโมเดลที่ค้นพบสัญญาณอื่นนอกเหนือจาก “ดูเหมือนเสร็จ” นั่นคือข้อโต้แย้งที่หนักแน่นที่สุดสำหรับความสามารถนี้ และเป็นข้อโต้แย้งที่หนักแน่นที่สุดสำหรับการถามก่อนลงมือทำตามความสามารถนั้น

จุดที่การตัดสินใจเกิดขึ้นจริงในปัจจุบัน

สิ่งที่มีประโยชน์เกี่ยวกับการรั่วไหลนี้คือ มาตรการควบคุมที่มันต้องใช้นั้นมีอยู่แล้ว และคุณสามารถตรวจสอบได้โดยไม่ต้องรอโมเดล มีสามอย่างที่สำคัญ

• Effort — A​nthropic เปิดให้ใช้ห้าระดับ ตั้งแต่ low ผ่าน medium และ high ไปจนถึง xhigh และ max โดยการตั้งค่านี้กำหนดว่าโมเดลจะทำงานด้วยตนเองมากเพียงใด Claude Opus 5.5 และ Claude Haiku 5.5 ใช้ค่าเริ่มต้นที่ medium ส่วนโมเดลปัจจุบันอื่น ๆ ใช้ค่าเริ่มต้นที่ high Effort มีผลกับโทเค็นเอาต์พุตทั้งหมด รวมถึงการเรียกใช้เครื่องมือ ซึ่งหมายความว่าโมเดลที่ขยายขอบเขตเมื่อใช้ effort ระดับ high ก็คือโมเดลที่ขยายขอบเขตพร้อมบิลที่สูงขึ้น

Plan mode — Claude Code แยกการสำรวจออกจากการลงมือทำ และเกณฑ์ที่ระบุไว้ในเอกสารสำหรับการใช้งานโหมดนี้ก็คือกรณีที่มีหลายไฟล์ ซึ่งเป็นสิ่งที่กลุ่มบั๊กประเภทหนึ่งสื่อถึงอย่างแม่นยำ การควบคุมนี้ไม่ใช่ตัวกรองความคิดของโมเดล แต่เป็นขั้นตอนที่คุณได้เห็นขอบเขตที่ขยายกว้างออกไปก่อนที่มันจะกลายเป็น diff

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

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

ถ้ามันได้ผล มันจะต้องแลกมาด้วยค่าใช้จ่ายเท่าไร

การขยายขอบเขตงานเป็นความช่วยเหลือประเภทที่แพงที่สุด เพราะมันทำให้เอาต์พุตทวีคูณแทนที่จะทำให้อินพุตทวีคูณ ในตารางราคาปัจจุบันของ A​nthropic นั้น Claude Fable 5.1 อยู่ที่ $10 ต่อหนึ่งล้านโทเคนอินพุต และ $50 ต่อหนึ่งล้านโทเคนเอาต์พุต ส่วน Claude Opus 5.5 อยู่ที่ $4 และ $20 และเอกสารของ A​nthropic เองก็แนะนำให้นักพัฒนาหันไปใช้ Claude Opus 5.5 ก่อน โดยจะเปลี่ยนไปใช้ Fable ก็ต่อเมื่อการประเมินบน Opus ที่ใช้ความพยายามสูงขึ้นยังคงไม่เพียงพอ โมเดลที่มีจุดขายคือการหางานเพิ่มให้ทำจึงสวนทางกับคำแนะนำนั้นโดยตรง เพราะระดับราคาถูกคือระดับที่คุณต้องการให้เอาต์พุตทวีคูณ และระดับราคาแพงคือระดับที่ทิกเก็ตที่ขยายขอบเขตกลายเป็นรายการงบประมาณ

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

สิ่งที่คุณเรียกได้ในวันนี้ และคำตอบอย่างตรงไปตรงมาเกี่ยวกับเรื่องนี้

ไม่มีอะไรใหม่ ไม่มีตัวระบุสำหรับโมเดลนี้ในรายงาน และแคตตาล็อกของเราเองก็เป็นการทดสอบที่ตรงไปตรงมาในเรื่องนี้: การถามหา anthropic/claude-fable-5.5 จะได้ผลลัพธ์เป็น ไม่พบโมเดล และ anthropic/claude-haiku-5.5 ก็เช่นกัน สตริงเหล่านี้ไม่อยู่ใน 209 โมเดลที่เราให้บริการ สิ่งที่ใช้ได้จริงคือรายการปัจจุบันในราคาตามที่ A​nthropic กำหนด — anthropic/claude-opus-5.5 พร้อมหน้าต่างบริบท 1M โทเคน เพดานเอาต์พุต 128K และราคา $4 / $20 ต่อล้านโทเคน และ anthropic/claude-fable-5.1 ที่ $10 / $50 แพลตฟอร์มใดก็ตามที่โฆษณาว่าเข้าถึง “โมเดลล่าบั๊กใหม่ของ A​nthropic” ในตอนนี้ กำลังขายเพียงชื่อ

คำถามเชิงปฏิบัติที่ผู้อ่านมีจริง ๆ ไม่ใช่ชื่อของโมเดล แต่คือจะหาคำตอบได้อย่างไรว่าโมเดลที่ขยายขอบเขตการทำงานจะช่วยหรือทำร้ายโค้ดเบสของคุณ โดยไม่ต้องเดิมพันเส้นทางโปรดักชันกับข่าวลือ นี่คือคำถามเรื่องการกำหนดเส้นทาง และเป็นจุดเดียวที่แพลตฟอร์มจะพิสูจน์ความคุ้มค่าได้: ส่งคำขอส่วนหนึ่งไปยังโมเดลที่ยังไม่ผ่านการพิสูจน์ โดยมีโมเดลที่คุณวัดผลมาแล้วรองรับอยู่เบื้องหลัง เพื่อให้การ généralisation ที่แย่คิดเป็นงานรีวิวหนึ่งครั้งแทนที่จะกลายเป็นเหตุการณ์ในโปรดักชัน การเปลี่ยนแปลงราคาและการเปิดตัวใหม่ของ Anthropic มาถึง OrcaRouter ในวันเดียวกันโดยบวกเพิ่ม 0% ดังนั้นเมื่อมีตารางราคาปรากฏขึ้น ต้นทุนของการทดลองก็คือราคาตามรายการและไม่มีอะไรเพิ่มเติม คุณสามารถดูได้อย่างชัดเจนว่าตอนนี้รุ่นท็อปของไลน์อัปมีราคาเท่าไรบนหน้าโมเดล Claude Opus 5.5 และเปรียบเทียบกับหน้า Claude Fable 5.1 ก่อนตัดสินใจว่าควรให้เวิร์กโหลดของคุณใช้ค่าเริ่มต้นเป็นตัวไหน

อะไรจะทำให้ชิ้นนี้เปลี่ยนไป

สามข้อ และข้อแรกคือข้อที่จะทำให้เรื่องนี้จบลงได้เร็วที่สุด

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

ผลการประเมินที่เผยแพร่แล้ว “พบคลาส” มีความหมายก็ต่อเมื่อเทียบกับ “ประดิษฐ์คลาสขึ้นมา” และไม่มีผู้จำหน่ายรายใดเผยแพร่ชุดงานที่แยกสองสิ่งนี้ออกจากกัน จนกว่าจะมีชุดงานเช่นนั้น — precision และ recall ในการระบุคลาสของข้อบกพร่อง ซึ่งให้คะแนนโดยคนอื่นที่ไม่ใช่ห้องแล็บ — ข้ออ้างเรื่องการวางนัยทั่วไปจากบั๊กเพียงตัวเดียวเป็นเพียงคำอธิบายถึงเจตนา ไม่ใช่ความสามารถที่เทียบข้ามโมเดลได้

ชื่อและตารางราคาไปด้วยกัน รูปแบบการตั้งชื่อคงที่มาตลอดทั้ง Fable 5, Fable 5.1, Opus 5.5, Sonnet 5.5 และ Haiku 5.5 และตัวระบุบ่งบอกถึงระดับ: เช่น claude-fable-5-5จะสื่อถึง $10 / $50 และ claude-opus-5-6จะสื่อถึง $4 / $20 สตริงเดียวในภาพรวมโมเดลไขคำถามที่ข้อมูลรั่วไหลใช้คำนับพันในการอธิบาย

จนถึงตอนนั้น จุดยืนที่ซื่อตรงคือ มีรายงานว่าแล็บแนวหน้าแห่งหนึ่งกำลังมุ่งพัฒนาพฤติกรรมหนึ่งที่ทุกองค์กรวิศวกรรมมีนโยบายเกี่ยวกับเรื่องนี้อยู่แล้ว แต่ยังไม่มีใครเผยแพร่นโยบายนั้น การที่โมเดลควรแก้บั๊กที่คุณรายงาน หรือบั๊กที่คุณไม่รู้ว่ามีอยู่ ไม่ใช่คำถามเรื่องความสามารถ แต่เป็นคำถามว่าใครถือปุ่ม merge และการรั่วไหล ซึ่งระบุว่าโมเดลถาม เป็นคำตอบที่ทำให้อุ่นใจกว่าคำตอบที่ coding agent ส่วนใหญ่ให้อยู่ในตอนนี้ ซึ่งก็คือทำต่อไปแล้วปล่อยให้ diff อธิบายตัวเอง