ทำให้ Fable มีราคาถูกกว่า Opus

เราเปลี่ยนจาก Opus 4.8 เป็น Fable 5 แล้วค่าใช้จ่ายของ Devin ก็ลดลง

Fable 5 มีราคาต่อโทเค็นสูงกว่า Opus 4.8 ถึงสองเท่า แต่เมื่อเราเรียกใช้ทั้งสองโมเดลบน FrontierCode 1.1 โดยใช้สถาปัตยกรรม Fusion ใหม่ของเรา Fable กลับมีต้นทุนที่ต่ำกว่า และไม่น่าแปลกใจที่คะแนนก็สูงกว่าด้วย โพสต์นี้อธิบายว่าทำไม และมันหมายถึงอะไรสำหรับการกำหนดราคางานแบบ agentic

บทนำ

ทุกคนที่ใช้ coding agents รู้ดีว่าโมเดลที่แข็งแกร่งกว่าจะให้ผลลัพธ์ที่ดีกว่า แต่คุณก็ต้องแบกรับต้นทุน

เมื่อเราเปิดตัว Devin Fusion เราได้แสดงหนทางออก: ให้โมเดล frontier ยังคงเป็นผู้ควบคุม ให้มันมอบหมายงานให้ sidekick ที่ถูกกว่าและเร็วกว่า แล้วคุณจะได้ประสิทธิภาพระดับ frontier ในราคาที่ต่ำกว่า 35%

แต่เมื่อโมเดลหลักมอบหมายงานส่วนใหญ่ไปแล้ว ราคาต่อโทเค็นของมันยังคงครอบงำค่าใช้จ่ายอยู่หรือไม่?

Fable 5 มีราคาต่อโทเค็นมากกว่า Opus 4.8 ถึง 2 เท่า ดังนั้น agent ที่นำโดย Fable น่าจะมีราคาสูงกว่า เพื่อหาคำตอบ เราจึงรันเซสชันประเมินผล 3,000 ครั้งบน FrontierCode 1.1 ในสี่รูปแบบ: Fable และ Opus เป็นผู้นำ แต่ละตัวมีและไม่มี sidekick ราคาถูกตัวเดียวกัน

การรันแบบบริสุทธิ์เป็นไปตามสัญชาตญาณ: Fable ได้คะแนนสูงกว่า Opus (60.8 vs 55.4) และมีราคาสูงกว่า โมเดลที่ดีขึ้น ค่าใช้จ่ายที่มากขึ้น

การรันที่เปิดใช้ sidekick คือจุดที่สิ่งต่าง ๆ น่าสนใจ

ด้วย sidekick เดียวกัน ลำดับต้นทุนกลับกัน: Fable + Sidekick มีราคาถูกกว่า Opus + Sidekick ($1.86 เทียบกับ $2.04) ในขณะที่ได้คะแนนสูงกว่า (60.7 เทียบกับ 54.6) เมื่อเทียบกับ Fable บริสุทธิ์ Fable + Sidekick ลดต้นทุนลง 54% ในขณะที่คะแนนแทบไม่เปลี่ยนแปลง

ส่วนเพิ่ม 2 เท่าต่อโทเค็นกลับกลายเป็นตัวเลขที่ผิดที่ควรดู ต้นทุนของ agent ถูกครอบงำโดยจำนวนรอบที่โมเดลหลักทำ, ปริมาณ context ที่มันนำติดตัวมา, และเหนือสิ่งอื่นใดคือสิ่งที่มันตัดสินใจ ไม่ ทำเอง ความแตกต่าง归结于รูปแบบการจัดการ: Opus ทำตัวเหมือนผู้จัดการจุกจิกกับเด็กฝึกงาน; Fable คือผู้จัดการที่มีวิศวกรที่มีความสามารถ

การตั้งค่า

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

เพื่อค้นหาว่าต้นทุนไปอยู่ที่ไหน เราทำสองสิ่ง ประการแรก เราแยกวิเคราะห์การเรียก LLM ทุกครั้งในทุก 3,000 เซสชัน: โมเดลใดกำลังพูด เรียกใช้เครื่องมืออะไร อ่านและเขียนโทเค็นกี่ตัว และแต่ละการเรียกมีค่าใช้จ่ายเท่าไร ประการที่สอง เราเลือก 40 งานเพื่อดูอย่างละเอียด: งานที่ Fable ถูกกว่าอย่างมาก, งานที่ Opus ถูกกว่า, และตัวอย่างสุ่มจากตรงกลางอีกชุด สำหรับแต่ละงาน เราวิเคราะห์การรันที่นำโดย Fable เทียบกับการรันที่นำโดย Opus แบบเคียงข้างกัน ตรวจสอบวิถีการทำงานและสังเกตว่าเงินไปอยู่ที่ไหน

ต้นทุนของ agent

นี่คือการแบ่งต้นทุนระหว่างตัวหลักและ sidekick ในการทดลองของเรา:

Fable ใช้จ่ายกับ sidekick มากกว่า Opus — มากกว่า $0.27 ต่อรอบ แต่ใช้จ่ายน้อยกว่า ตัวมันเอง $0.45 ตัวหลักของ Fable ใช้ 11.5 รอบต่อรอบของ Opus ที่ 26.5, เขียนโทเค็นเอาต์พุตหนึ่งในสาม (6.1k vs 19.0k), และใช้โทเค็นอินพุตหนึ่งในสาม Fable มีราคาต่อโทเค็นแพงกว่าอย่างเห็นได้ชัด แต่ชนะในการจัดการ context และจำนวนรอบ

การประหยัดโทเค็นของ Fable เกิดจากการหลีกเลี่ยงงานโดยตรง ที่น่าสนใจ ใน 81% ของการรันที่นำโดย Fable ตัวหลักไม่เคยแก้ไขโค้ดแม้แต่ครั้งเดียว สำหรับ Opus นั่นเป็นจริงเพียง 24% ของการรัน ใน 13% ของการรันที่นำโดย Fable ตัวหลักไม่เคยอ่านไฟล์ repo ด้วยตัวเองด้วยซ้ำ

ผู้จัดการจุกจิกกับเด็กฝึกงาน เทียบกับ ผู้จัดการกับวิศวกร

นี่คือสิ่งที่ทำให้ช่องว่างน่าสนใจ: ตัวหลักทั้งคู่มอบหมายงานจำนวนเท่ากัน ประมาณ 3 ครั้งต่อรอบ บันทึกการเรียกต่อครั้งหักล้างคำอธิบายง่ายๆ ว่า Fable แค่มอบหมายมากกว่า สิ่งที่แตกต่างคือ เมื่อใด และ อะไร ที่พวกเขามอบหมาย การ handoff ครั้งแรกของ Fable มาถึงเร็ว Opus มักจะมอบหมายช้า หลังจากสำรวจและใช้งานเดี่ยวเป็นเวลานาน เมื่อถึงเวลานั้น การตัดสินใจออกแบบได้ทำไปแล้ว ไฟล์สำคัญอยู่ใน context ของมัน และงานที่มีราคาแพงก็เสร็จสิ้นแล้ว

GIF

การรันทั่วไปที่นำโดย Fable จะดำเนินการสำรวจ repo สองสามครั้ง จากนั้นเขียนคำสั่ง handoff ที่มีคุณภาพระดับสเปกเพื่อมอบหมายลูป implement + test + lint ทั้งหมด จากนั้นใช้ git show เพื่อตรวจสอบ diff และทำ commit

การรันทั่วไปที่นำโดย Opus จะผ่าน 20–45 รอบของการสำรวจเดี่ยว การออกแบบ และการนำไปใช้งาน และการ handoff ช้าๆ หนึ่งครั้งสำหรับงานกลไกท้าย

บางครั้ง การกระทำแรก ของ Fable ในเซสชันคือการ handoff ในงานเดียวกัน ตัวหลักทั้งสองเริ่มต้นเช่นนี้:

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

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

การมอบหมายงานไม่เพียงแค่ย้ายต้นทุนไปมา แต่ยังเปลี่ยนคุณภาพของงานด้วย งาน hashing ข้างต้นเป็นตัวอย่างที่ชัดเจน สเปกงานกำหนดให้ฟังก์ชัน hash ต้องเป็น O(1) ในความยาวของ pointer Opus นำไปใช้ด้วยตนเองและไม่เคยเขียนข้อกำหนดนั้นไว้ที่ไหนเลย ในบางจุดมันลืมข้อจำกัดและส่งมอบการนำไปใช้แบบ linear-time ซึ่งได้คะแนน 25 ในทางตรงกันข้าม Fable มอบหมายงานโดยใช้ข้อจำกัดระดับสูง คำสั่งของมันบอกว่า "operator() must be O(1) in pointer length: NO full token scan" sidekick นำไปใช้สำเร็จด้วยคะแนน 94

เราพบว่ารูปแบบนี้ใช้ได้ทั่วไปในหลายๆ งาน การ handoff ของ Fable จะระบุข้อจำกัด กรณีขอบ และคำจำกัดความของ "เสร็จ" ช่วยประหยัดความพยายามของตัวเอง ในขณะที่ช่วยให้ sidekick สามารถดำเนินการนำไปใช้งานได้อย่างถูกต้องและราคาถูก

หลังการ handoff

อีกครึ่งหนึ่งคือสิ่งที่ agent หลักทำกับงานที่ส่งกลับมาจาก sidekick ตัวหลักทั้งสองมักจะรันการตรวจสอบราคาถูกแบบเดียวกัน: สองหรือสามครั้งของการเรียก git diff/git show แต่ Opus ไม่หยุดแค่นั้น มันดึงไฟล์ของ sidekick กลับเข้าไปใน context ของตัวเองบ่อยขึ้น 2 เท่า และแก้ไขแก้ไขเพิ่มขึ้น 4 เท่าในราคาของตัวหลัก ในกรณีที่รุนแรง มันย้อนกลับงานของ sidekick และเขียนใหม่ด้วยตนเอง:

ความไม่ไว้วางใจของ Opus ไม่ได้เพิ่มความถูกต้องเช่นกัน ในงานประเมินบางงาน การตรวจสอบ diff เพียงครั้งเดียวของ Fable จับบั๊กจริงของ sidekick และเลือกที่จะ handoff ราคาถูกอีกครั้ง แทนที่จะเขียนใหม่ในระดับตัวหลักที่ Opus มักจะทำ

เมื่อการมอบหมายงานไม่ช่วย

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

• งานสั้นที่มีเพียงไม่กี่รอบของตัวหลัก โดยไม่มีอะไรให้มอบหมายระหว่างการตัดสินใจและการส่งมอบ
• งานดีบั๊กแบบต่อเนื่องที่การตามล่าหาสาเหตุที่แท้จริงเป็นสายโซ่ยาวของการตัดสิน ที่นี่ context ที่สะสม คือ ตัวงาน

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

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

บทสรุป

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

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