इस साल की शुरुआत में, हमने यह परखने के लिए प्रयोग चलाए कि किसी लक्ष्य की ओर मिलकर काम करने के लिए एजेंट्स को स्केल करने की सीमाएँ क्या हैं। हमारी परिकल्पना थी कि इससे कार्यों के पैमाने और जटिलता का एक नया स्तर खुल जाएगा।

मुख्य प्रोजेक्ट एक लंबे समय तक चलने वाला स्वॉर्म था, जो शुरुआत से एक वेब ब्राउज़र बना रहा था। यह एक proof of concept के रूप में सफल रहा, लेकिन परिष्कृत सॉफ़्टवेयर से अभी भी काफ़ी दूर था।

वह काम जानबूझकर अनुभवजन्य था। हमने एक खाली कैनवस से शुरुआत की और क्रमिक सुधार करते हुए एक स्थिर, प्रभावी सिस्टम की ओर बढ़े। तब से, हमारा लक्ष्य एजेंट स्वॉर्म को इतनी अच्छी तरह समझना रहा है कि हम उसे सुनियोजित ढंग से इंजीनियर कर सकें।

उस प्रगति को परखने के लिए, हम एक ऐसे कार्य पर लौटे जिससे पुराना स्वॉर्म जूझ रहा था: केवल उसके दस्तावेज़ीकरण के आधार पर, Rust में, शुरुआत से SQLite बनाना।

हमारे शुरुआती नतीजे उत्साहजनक रहे हैं। हमने पुराने और नए स्वॉर्म्स को एक ही कार्य पर, एक ही मॉडल्स और समान समय-सीमा के साथ चलाया, और मापा कि अलग रखे गए SQL टेस्ट सूट का कितना हिस्सा हर एक पास कर सकता है।

नए स्वॉर्म ने हर मॉडल कॉन्फ़िगरेशन में बेहतर प्रदर्शन किया। Grok 4.5 का इस्तेमाल करते हुए, यह चार घंटे में 80% तक पहुँच गया, जबकि पुराना स्वॉर्म पटरी से उतर गया और दूसरा घंटा पूरा होने से पहले ही उसे रोकना पड़ा।

हमने यह भी बदला कि कौन-से मॉडल कौन-से काम करें। कुछ चलाओं में एक ही मॉडल ने सब कुछ संभाला, जबकि अन्य में एक अत्याधुनिक मॉडल ने योजना बनाई और एक तेज़, कम लागत वाले मॉडल ने काम को अंजाम दिया। हर मिश्रण ने लगभग समान गुणवत्ता दी, लेकिन लागत में बहुत बड़ा अंतर था।¹

#वृक्ष और पत्तियाँ

बड़े कार्यों के विवरण स्वाभाविक रूप से वृक्ष जैसी संरचना ले लेते हैं, जिसमें जड़ पर एक लक्ष्य होता है, जो पुनरावर्ती ढंग से कार्य की बुनियादी इकाइयों में विभाजित होता जाता है। हमारे स्वॉर्म में दो भूमिकाएँ हैं, और दोनों इसी वृक्ष-जैसे विभाजन के इर्द-गिर्द संगठित हैं:

• योजनाकार एजेंट, जो सबसे सक्षम मॉडल्स द्वारा संचालित होते हैं, किसी लक्ष्य को हिस्सों में बाँटते हैं और उन्हें सौंपते हैं।
• वर्कर एजेंट, जो आम तौर पर तेज़ और कम महंगे मॉडल्स द्वारा संचालित होते हैं, उन हिस्सों को पूरा करते हैं।

यह डिज़ाइन अधिक कठोर orchestration systems का एक superset है। समस्या पर एक निश्चित topology थोपने के बजाय, स्वॉर्म का आकार समस्या की रूपरेखा के अनुसार फैलता है, और compute तथा संदर्भ कार्य की जटिलता के अनुपात में स्केल करते हैं।

हम मानते हैं कि यही वजह है कि यह डिज़ाइन एक ब्राउज़र बनाने, गणितीय समस्याएँ हल करने, और GPU कर्नेल्स के अनुकूलन जैसे विविध कार्यों पर भी लागू होता है। हमने इसका आंतरिक रूप से उपयोग ओपन-सोर्स सॉफ़्टवेयर में कमज़ोरियाँ खोजने और ठीक करने, अपने कोडबेस में टेस्ट कवरेज बढ़ाने, और सिंथेटिक प्रशिक्षण डेटा के अरबों टोकन जनरेट करने के लिए भी किया है।

#स्मृति के लिए tree क्या करता है

जब एक अकेला एजेंट किसी पूरे कार्य की ज़िम्मेदारी लेता है, तो उसे पूरे tree में खुद ही चलना पड़ता है—हर leaf तक नीचे उतरते हुए, और इस पूरी प्रक्रिया के दौरान अपने ancestors, अपनी वर्तमान स्थिति, और बड़े लक्ष्य को लगातार संदर्भ में बनाए रखना पड़ता है।

हमारा मानना है कि यही समझाता है कि लंबे समय तक चलने वाले अकेले एजेंट क्यों भटक जाते हैं। वे या तो अपने सामने के काम पर ध्यान केंद्रित करते हैं और बड़े परिप्रेक्ष्य से नज़र hटा बैठते हैं, या फिर बड़े परिप्रेक्ष्य को पकड़े रहते हैं और उस हिस्से पर कमज़ोर काम करते हैं।

एक स्वॉर्म में, योजनाकार कभी implementation नहीं करता, इसलिए उसका संदर्भ कभी निम्न-स्तरीय विवरणों से नहीं भरता; और वर्कर कभी योजना नहीं बनाता, इसलिए वह अपना पूरा संदर्भ काम के एक संकरे हिस्से पर लगा सकता है।

हमें संदेह है कि एजेंट स्वॉर्म को स्केल करने की क्षमता, समानांतरता से भी अधिक, इसी संदर्भ-दक्षता से आती है। यह दक्षता स्वॉर्म में हर स्केल पर मौजूद रहती है, और यही वजह है कि यह विभाजन मध्यम आकार के कार्यों पर भी एजेंट के प्रदर्शन में मदद करता है।

इस संरचना की झलकें दूसरी जगहों पर भी मिलती हैं। अर्थशास्त्री Ronald Coase ने, यह पूछते हुए कि आखिर फर्में होती ही क्यों हैं, तर्क दिया कि समन्वय की लागत स्वयं काम की तुलना में अधिक तेज़ी से बढ़ती है, इसलिए संगठन सभी को सभी से बात करने देने के बजाय सीमित इकाइयों के स्तरों में संगठित हो जाते हैं।

#एजेंट्स के लिए एक संस्करण नियंत्रण प्रणाली

स्वॉर्म के बारे में एक पहले की पोस्ट में, हमने बताया था कि Git और Cargo जैसे टूल समांतरता नियंत्रण के लिए coarse locks पर निर्भर करते हैं। यह एक डेवलपर के लिए तो ठीक है, लेकिन एक साथ काम कर रहे सैकड़ों एजेंट्स द्वारा उत्पन्न काम की मात्रा के लिए यह व्यावहारिक नहीं है।

इस साल की शुरुआत में ब्राउज़र स्वॉर्म Git पर अपने चरम पर लगभग 1,000 कमिट प्रति घंटा तक पहुँचा था। नई प्रणाली अपने चरम पर लगभग 1,000 कमिट प्रति सेकंड तक पहुँचती है।

इस स्तर की गतिविधि को संभव बनाने के लिए, हमने शुरू से एक नई संस्करण नियंत्रण प्रणाली (VCS) बनाई। इस लेयर को खुद विकसित करने की वजह सिर्फ थ्रूपुट नहीं थी। सिस्टम में हर परिवर्तन VCS से होकर गुजरता है, इसलिए टकराव सबसे पहले यहीं दिखाई देते हैं, और अगले भाग में बताए गए कई समन्वय तंत्र सीधे इसी के भीतर लागू किए गए हैं।

#प्रति सेकंड 1,000 कमिट की दर पर विफलता के पैटर्न

मानव इंजीनियरिंग टीमों के पास कोड समीक्षा, जिम्मेदारी का बँटवारा, स्टैंडअप्स और मर्ज कतारों जैसे मानक समन्वय तंत्र होते हैं। ये प्रणालियाँ मानवीय रफ़्तार पर काम करती हैं, लेकिन स्वॉर्म की कमिट-दर पर हमें ऐसी विफलताएँ दिखाई देती हैं जिनका मानव टीमों को आम तौर पर सामना नहीं करना पड़ता।

#स्प्लिट-ब्रेन डिज़ाइन

दो योजनाकार, जो एक-दूसरे से अनजान हैं, कोडबेस के अलग-अलग हिस्सों में एक ही अवधारणा को अलग-अलग तरीकों से लागू करते हैं।

हमने इसे प्रॉम्प्टिंग के ज़रिए ठीक किया। योजनाकार डिज़ाइन से जुड़े फ़ैसले उन्हें सौंपने के बजाय खुद लेते हैं, और हम उनसे यह सुनिश्चित करने को कहते हैं कि सौंपे गए दो सबट्री एक ही सवाल पर फ़ैसला न लें।

#योजनाकारों के बीच टकराव

टकराव का एक अधिक कठिन रूप तब होता है, जब दो योजनाकार एक-दूसरे के बारे में जानते हों और उन्हीं फ़ाइलों पर आगे-पीछे होने वाले परिवर्तनों के ज़रिए आपस में भिड़ते रहें।

समस्या यह है कि वास्तविकता की दो अलग-अलग तस्वीरें मौजूद होती हैं, और मर्ज टूलिंग किसी असहमति को ठीक नहीं कर सकती। इसके बजाय, हम एजेंट्स से साझा डिज़ाइन दस्तावेज़ों में निर्णय रिकॉर्ड करवाते हैं। जो कोड किसी निर्णय पर निर्भर करता है, उसमें उसके दस्तावेज़ तक लौटने वाला कंपाइल-चेक किया गया एक संदर्भ होता है। जब योजनाकार अनजाने में एक-दूसरे का विरोध करते हैं, तो एक समन्वयक दस्तावेज़ों को मर्ज करता है और वे संदर्भ उस समाधान को आगे की निर्भरताओं तक पहुँचा देते हैं।

#मर्ज कॉन्फ्लिक्ट्स

स्वॉर्म के भीतर, एजेंट लगातार एक ही फ़ाइलों पर टकराते रहते हैं। किसी टकराव को सुलझाने के लिए उन्हें रुकना पड़ता, दूसरे एजेंट के संदर्भ को समझना पड़ता, और उसके हिसाब से मर्ज करना पड़ता। वर्कर एजेंट इसमें अच्छे नहीं होते और व्यवहार में या तो दूसरे के परिवर्तन को ओवरराइट कर देते हैं या अपना परिवर्तन छोड़ देते हैं।

इसे ठीक करने के लिए, हमने एक ऐसी प्रणाली बनाई जिसमें एक तटस्थ तृतीय-पक्ष एजेंट मर्ज कॉन्फ्लिक्ट्स में हस्तक्षेप करता है और सभी पक्षों की ओर से उन्हें सुलझाता है। उसका एकमात्र लक्ष्य निष्पक्ष और दक्ष होना है, ठीक उसी तरह जैसे इंजीनियरिंग टीमों में मर्ज कतारें काम करती हैं।

#मेगाफ़ाइलें

कुछ फ़ाइलें ऐसी होती हैं जहाँ एजेंट्स खास तौर पर ज़्यादा काम करते हैं। हर एजेंट शायद केवल थोड़ा-सा कोड जोड़ता है, और फ़ाइलों को छोटा बनाए रखने की ज़िम्मेदारी किसी एक एजेंट की नहीं होती।

ये “मेगाफ़ाइलें” सब कुछ जाम कर देती हैं। इन्हें ट्रांसपोर्ट करना, डिफ करना और मर्ज करना महंगा पड़ता है, और ये लगातार टकराव का केंद्र बन जाती हैं।

इसे ठीक करने के लिए, हमने वर्कर एजेंट्स को जरूरत से ज़्यादा बड़ी हो चुकी फ़ाइलों को फ़्लैग करने का एक तरीका दिया। एक बार फ़्लैग हो जाने पर, हम नए कमिट ब्लॉक कर देते हैं और एक बाहरी एजेंट उस जरूरत से ज़्यादा बढ़ी हुई फ़ाइल को छोटे-छोटे module में बाँट देता है।

#जड़ता

एजेंट्स ने, मानवों की भागीदारी के साथ मौजूदा कोडबेस में काम करते-करते, यह सीख लिया है कि मुख्य कोड को नहीं छूना है, तब भी जब उसमें बदलाव की आवश्यकता हो।

इसे ठीक करने के लिए, हम जानबूझकर किए गए ब्रेकेज की अनुमति देते हैं। कोई एजेंट, जो यह तय करता है कि मुख्य कोड में बदलाव सार्थक है, अपने दायरे से बाहर एक लक्षित पैच कर सकता है और यह समझाने के लिए एक टिप्पणी छोड़ सकता है कि उसने ऐसा क्यों किया।

कम्पाइलर इस बदलाव को बाकी सिस्टम तक आगे ले जाता है, और पुराने डिज़ाइन पर निर्भर हर चीज़ बिल्ड नहीं हो पाती। उन त्रुटियों में से किसी एक से टकराने वाला हर एजेंट उस टिप्पणी को खोजता है, तर्क को पढ़ता है, और उसके अनुरूप अपने हिस्से के काम को अपडेट करता है।

#समीक्षा लेंस

ऐसी प्रणाली में, जो लंबे समय तक चलने वाली भी हो और बहु-एजेंट भी, त्रुटियाँ जमा होती जाती हैं, और स्वॉर्म को खुद को सुधारने का एक तरीका चाहिए, इससे पहले कि छोटी गलतियाँ बुनियादी समस्या बन जाएँ।

हमने कई तरह के समीक्षा लेंसों के साथ प्रयोग किए, जैसे किसी समीक्षा एजेंट को वर्कर का पूरा प्रतिलेख देना, या केवल उसका आउटपुट, या सिर्फ कोडबेस देना। हमने अलग-अलग मॉडल्स पर चलने वाले समीक्षकों को भी आज़माया, जिनका प्रशिक्षण और व्यक्तित्व अलग-अलग था।

कोई एक लेंस सब कुछ नहीं पकड़ता, लेकिन एक-दूसरे से स्वतंत्र लेंस मिलकर असरदार साबित होते हैं, ठीक वैसे ही जैसे स्व-चालित प्रणालियाँ किसी एक परिपूर्ण कंपोनेंट के बिना मानव-से-ऊपर विश्वसनीयता हासिल करती हैं। समीक्षा पर खर्च किया गया compute उच्च प्रतिफल देता है, क्योंकि समीक्षा उस काम की तुलना में बहुत सस्ती होती है जिसकी वह जाँच करती है। हमें संदेह है कि यह स्तरीकृत समीक्षा प्रणाली रनों की लगातार गुणवत्ता में एक प्रमुख योगदानकर्ता थी।

#एजेंट्स को परिवेश आकार देने देना

Stigmergy वह तंत्र है जिसके ज़रिए चींटियों और दीमकों जैसे झुंड में रहने वाले जीव बिना सीधे संचार के समन्वय करते हैं। वे परिवेश को आकार देते हैं, और परिवेश अगले जीव को आकार देता है।

हमने पहले के रन में “नोट्स रखें” और “निर्णयों का दस्तावेज़ीकरण करें” जैसे नियम शामिल किए थे, क्योंकि वे स्पष्ट रूप से उपयोगी लगते थे। बाद में समझ आया कि वे एजेंट्स को अपने भविष्य के संस्करणों और टीम-साथियों के लिए ज्ञान को संस्थागत रूप देने दे रहे थे।

हमने इसे self-authored, shared संदर्भ पर आधारित एक experiment के साथ और आगे बढ़ाया, जिसे हम Field Guide कहते हैं। यह एक फ़ोल्डर है, जिसका स्वामित्व पूरी तरह एजेंट्स के पास होता है, और इसकी index.md फ़ाइल शुरू में हर एजेंट में स्वचालित रूप से शामिल कर दी जाती है। guide में क्या शामिल किया जाए, इसका चयन करना एजेंट्स का काम है, और उन पर केवल पंक्तियों की सीमा लागू होती है।

guide के पीछे का मूल तर्क यह है कि मॉडल के weights स्थिर रहते हैं, इसलिए ठीक वे अप्रत्याशित अनुभव दर्ज करने लायक होते हैं, ताकि अगले एजेंट की trajectory छोटी हो।

Field Guide अभी शुरुआती चरण का एक experiment है, लेकिन इसके परिणाम आशाजनक हैं। हम उम्मीद करते हैं कि जिन कोडबेस पर एजेंट्स का पूरा स्वामित्व नहीं है, वहाँ इसके फायदे और भी बड़े होंगे। मॉडल्स को अपने उत्तराधिकारियों के लिए लिखने का प्रशिक्षण देना—जहाँ बेहतर capture से बेहतर rewards मिलते हैं—अनुसंधान का एक रोचक अनुवर्ती क्षेत्र है।

#SQLite प्रयोग

हमने स्वॉर्म के नए संस्करण को, जिसमें ऊपर बताए गए सभी सुधार शामिल थे, Rust में पूरे 835-पृष्ठीय SQLite मैन्युअल को लागू करने का निर्देश दिया। हमने उसे स्रोत कोड, टेस्ट सूट, SQLite बाइनरी और इंटरनेट पहुँच नहीं दी।

प्रगति मापने के लिए, हमने sqllogictest के आधार पर मूल्यांकन किया। यह SQLite प्रोजेक्ट का एक टेस्ट सूट है, जिसे यह जाँचने के लिए बनाया गया है कि अलग-अलग डेटाबेस इंजन एक ही क्वेरी के लिए एक जैसे परिणाम लौटाते हैं। इसमें सही उत्तरों वाली लाखों क्वेरियाँ शामिल हैं, और ग्रेड उस हिस्से को दर्शाता है जिसे स्वॉर्म का डेटाबेस सही करता है। किसी रन के दौरान प्रगति एक ऊपर उठती हुई वक्र रेखा के रूप में दिखाई देती है।

स्वॉर्म को कभी नहीं बताया गया कि यह सुइट मौजूद है। हर रन के बाद, हमने कोड और रन—दोनों की मैन्युअल रूप से समीक्षा की, धोखाधड़ी और शॉर्टकट्स की जाँच की, और यह भी सुनिश्चित किया कि सिस्टम हर हिस्से में समान रूप से बनाया गया था, न कि सिर्फ वहाँ जहाँ टेस्ट देखते हैं।

इन वक्रों को पढ़ते समय ध्यान रखें कि एजेंट्स ने अपनी रणनीतियाँ खुद चुनीं। कुछ ने व्यापक नींव तैयार की और बाद में अचानक आई उछाल से पहले घंटों तक कम स्कोर किया, जबकि कुछ अन्य एक ही क्षेत्र में गहराई तक गए, जल्दी स्कोर किया, फिर बाकी हिस्सों को पूरा करते हुए ठहर गए। सटीक समय पर मिले सटीक स्कोर से अधिक महत्वपूर्ण रुझान हैं।

#मॉडल मिश्रणों में परिणाम

हमने क्षमता और लागत, दोनों को ध्यान में रखते हुए चार कॉन्फ़िगरेशन का परीक्षण किया:

1. GPT-5.5 को योजनाकार और वर्कर, दोनों के रूप में। शुरू से अंत तक एक मज़बूत अत्याधुनिक मॉडल।²
2. Grok 4.5 को योजनाकार और वर्कर, दोनों के रूप में। तुलना के लिए हमारा लागत-कुशल अत्याधुनिक मॉडल।
3. Opus 4.8 को योजनाकार और Composer 2.5 को वर्कर के रूप में। अत्याधुनिक निर्णय-क्षमता को कुशल निष्पादन के साथ जोड़ा गया।
4. Fable 5 को योजनाकार और Composer 2.5 को वर्कर के रूप में। यह देखने के लिए कि क्या अगले-स्तर का योजनाकार इस हाइब्रिड को अधिक या कम सार्थक बनाता है।

नई उपयोग में लाने की व्यवस्था ने हर मिश्रण में पुरानी उपयोग में लाने की व्यवस्था से बेहतर प्रदर्शन किया।

Fable 5 हाइब्रिड ने पहले घंटे के भीतर सुइट का लगभग दो-तिहाई हिस्सा पास कर लिया। चार घंटे की सीमा तक, नए रन 73% से 85% के बीच थे, जबकि पुराने रन 11% से 77% के बीच रहे।

पुराने Grok 4.5 रन को दो घंटे के निशान तक पहुँचने से पहले रोक दिया गया था (इस पर नीचे अधिक)। हर नए कॉन्फ़िगरेशन ने आगे चलकर सुइट का 100% पास कर लिया।

भविष्य में हम योजनाकार-वर्कर संयोजनों का पूरा N×N मैट्रिक्स चलाना चाहेंगे। इस चक्र में महत्वपूर्ण तुलना उपयोग में लाने की व्यवस्था के संस्करणों के बीच है, और व्यवहारगत अंतर अंततः स्कोर के अंतर से कहीं बड़े निकले, जितना स्कोर से लगता है।

#रनों का गहन विश्लेषण

गतिविधि के सबसे सरल माप से शुरू करें तो हम देख सकते हैं कि पुराने harness की तुलना में नए harness के तहत Grok 4.5 के कमिट की दर कैसे बदल गई। पुराने चलाएँ ने पहले दो घंटों में 68,000 कमिट किए, जो नए चलाएँ की रफ़्तार से लगभग 70 गुना था।

इसे एक तरह से अधिक उत्पादकता के रूप में पढ़ा जा सकता है। दूसरी व्याख्या यह है कि उन कमिट में से ज़्यादातर सिर्फ़ बेकार की हलचल थे (thrash, contention, churn)।

मर्ज कॉन्फ्लिक्ट का डेटा दूसरी व्याख्या की ओर इशारा करता है। पुराने चलाएँ में, हमने उसे रोकने से पहले 70,000 से अधिक conflicts जमा हो चुके थे, और वे स्थिर होने के बजाय और तेज़ी से बढ़ रहे थे, जबकि नए चलाएँ ने पूरे चार घंटों में एक हज़ार से भी कम लॉग किए।

conflicts वहीं सबसे ज़्यादा केंद्रित थे जहाँ फ़ाइलें सबसे बड़ी हो गईं। पुराने चलाएँ में सबसे बड़ी फ़ाइलें पूरे चलाएँ के दौरान बढ़ती रहीं, और उसकी सबसे अधिक प्रभावित फ़ाइल में 7,771 conflicts जमा हुए, जिसे 1,173 अलग-अलग agents ने छुआ। नए चलाएँ में, पूरे कोडबेस की सबसे अधिक विवादित फ़ाइल में सिर्फ़ 47 conflicts देखे गए।

पुराने swarm की सबसे बड़ी समन्वय-विफलता — स्प्लिट-ब्रेन, यानी योजनाकारों का एक-दूसरे के काम की नकल करना — package संरचना में दिखाई दी। Rust कोड packages में व्यवस्थित होता है, जिन्हें crates कहा जाता है, और इस तरह के प्रोजेक्ट में हर crate मोटे तौर पर एक बड़े कंपोनेंट के बराबर होता है।

पुराना चलाएँ फैलते-फैलते 54 crates तक पहुँच गया, जिसमें तीन अलग-अलग SQL packages शामिल थे। नया चलाएँ शुरू में ही नौ crates पर टिक गया और फिर कभी कोई नया crate नहीं जोड़ा।

यह सब अंतिम कोडबेस में भी दिखता है। Fable 5 mix में, पुराने और नए दोनों swarms ने आखिरकार पूरा सुइट पास कर लिया, लेकिन पुराने swarm को 64,305 पंक्तियों के engine code की ज़रूरत पड़ी, जबकि नए ने वही काम 9,908 पंक्तियों में कर दिया। Opus mix में भी यही तस्वीर दिखती है: पुराने harness के तहत 97% ग्रेड पर 19,013 पंक्तियाँ, और नए harness के तहत 100% पर 4,645 पंक्तियाँ।

#मॉडल अर्थशास्त्र

हमने शुरुआत में कहा था कि हर मॉडल मिश्रण ने लगभग समान गुणवत्ता दी, जबकि लागत में बहुत बड़ा अंतर था—Opus 4.8 हाइब्रिड के लिए $1,339सेलेकरकेवलGPT-5.5केलिए$10,565 तक। टोकन डेटा दिखाता है कि यह अंतर कहाँ से आता है।

खर्च की संरचना हर चलाएँ में सुसंगत थी, जिसमें वर्करों के हिस्से कम-से-कम 69% टोकन थे, और ज़्यादातर चलाएँ में यह 90% से भी अधिक था।

लेकिन डॉलर का बँटवारा टोकन के अनुपात में नहीं था, क्योंकि योजनाकार tokens की लागत अधिक होती है। Opus 4.8 और Composer 2.5 mix में, योजनाकार के रूप में Opus ने कुल टोकन का केवल एक छोटा हिस्सा उत्पन्न किया, लेकिन लागत का लगभग दो-तिहाई हिस्सा उसी से आया, जबकि वर्कर के रूप में Composer ने बाकी एक-तिहाई लागत में टोकन का बहुत बड़ा हिस्सा संभाला।

किसी बड़े कार्य में वास्तव में अत्याधुनिक इंटेलिजेंस की ज़रूरत बहुत कम चरणों में पड़ती है, जैसे शुरुआती विभाजन, डिज़ाइन से जुड़े फैसले, और कुछ trade-offs। एक बार जब कोई अत्याधुनिक योजनाकार अस्पष्टता को समेटकर उसे एक विस्तृत, स्पष्ट instruction में बदल देता है, तो कम महंगे मॉडल्स को बस उसका पालन करना होता है। यह लागत बचत का एक बहुत बड़ा संभावित स्रोत है। जिस चलाएँ में योजनाकारों और वर्करों दोनों के लिए GPT-5.5 का उपयोग किया गया, उसमें केवल वर्करों की लागत $9,373थी।जिसचलाएँमेंOpus4.8नेplanningकीऔरComposer2.5नेकामकिया,उसमेंपूरेवर्करfleetकीलागत$411 थी।

ध्यान देने लायक एक और बात इन दो हाइब्रिड चलाएँ की तुलना से सामने आती है। Fable 5 योजनाकार का बिल, प्रति-टोकन कीमत लगभग दोगुनी होने के बावजूद, Opus 4.8 योजनाकार की तुलना में थोड़ा कम रहा, क्योंकि उसने planning में कहीं कम टोकन इस्तेमाल किए। लेकिन Fable चलाएँ के वर्करों ने कई गुना अधिक टोकन संसाधित किए, और कुल मिलाकर वह चलाएँ काफ़ी ज़्यादा महंगा निकला।

#प्रॉम्प्ट्स के रूप में स्पेक्स

AI क्षमता में हर छलांग ने उस अमूर्तन स्तर को बढ़ाया है, जिस पर एक इंजीनियर काम कर सकता है।

Autocomplete ने इंजीनियरों को एक बार में कोड की एक पंक्ति पर काम करने दिया। शुरुआती मॉडल्स ने इसे कोड के एक ब्लॉक तक बढ़ाया, और एजेंट्स ने इसे एक फ़ाइल या एक सुविधा तक पहुँचा दिया।

स्वॉर्म्स के साथ, काम की इकाई स्पेक बन जाती है।

इसके काम करने के लिए, स्वॉर्म को वास्तव में स्पेक का पालन करना होगा, और यह पोस्ट मुख्यतः इसी बारे में है। हमने स्वॉर्म को 835 पन्नों का गद्य दिया, और वह एक डेटाबेस बनाकर लौटा। इस experiment में जो चीज़ दुर्लभ थी, और जो हमें उम्मीद है कि आगे चलकर software engineering में भी दुर्लभ रहेगी, वह है आशय का सही विवरण।

इस नज़रिए से देखें, तो स्वॉर्म एक कम्पाइलर जैसा लगने लगता है। एक कम्पाइलर स्रोत कोड को कई मध्यवर्ती चरणों के जरिए machine code में अनुवादित करता है। स्वॉर्म भी आशय के साथ कुछ ऐसा ही करता है। योजनाकार किसी लक्ष्य को कार्य-वृक्षों में पार्स करते हैं, फिर उसे चरण-दर-चरण घटाकर निष्पादन योग्य काम में बदलते हैं। अंतर यह है कि कम्पाइलर हर चरण में अर्थ को संरक्षित रखता है, जबकि स्वॉर्म हर चरण पर प्रायिकतामूलक होता है। इस पोस्ट में वर्णित हर चीज़ इसी अंतर को कम करने के लिए मौजूद है।

हम आपको स्वॉर्म के आउटपुट को देखने के लिए आमंत्रित करते हैं। solo Opus 4.8 चलाए गए प्रयास का कोडबेस github.com/cursor/minisqlite पर सार्वजनिक है। हमारी शुरुआती नज़र में यह शानदार लगता है, लेकिन हमने अभी इसका गहन मैनुअल विश्लेषण नहीं किया है। आप भी इसे स्वयं देखें, और हमें बताएँ कि आपको क्या मिलता है।