तीन Claude मॉडल्स के साथ एक सोलो डेवलपर के प्रयोग ने मासिक API लागत में 35% की कमी की और औसत टास्क लेटेंसी (latency) को 42 सेकंड से घटाकर 27 सेकंड कर दिया। सरल और कम अस्पष्ट (low-ambiguity) कार्यों को सस्ते Haiku मॉडल को, नियमित कार्यों को Sonnet को भेजने और भारी-भरकम Opus को उच्च-जोखिम वाली समस्याओं के लिए आरक्षित रखकर, लेखक ने यह साबित कर दिया कि "हर चीज़ के लिए सबसे अच्छा मॉडल" चुनना एक महंगी आदत है।
राउटिंग क्यों महत्वपूर्ण थी
लेखक एक ऑटोनॉमस कोडिंग एजेंट चलाता है जिसे डेवलपमेंट कार्यों की एक निरंतर धारा प्राप्त होती है—जैसे lint फिक्स, फीचर जोड़ना, सुरक्षा समीक्षा (security reviews), और गहन डीबगिंग सत्र। महीनों तक एजेंट ने हर अनुरोध को Opus को भेजा, जो सबसे सक्षम Claude मॉडल है, यह मानते हुए कि उच्च गुणवत्ता हमेशा कीमत से अधिक महत्वपूर्ण होगी। Opus प्रति टोकन प्रीमियम कीमत लेता है, इसलिए बिल अनियंत्रित रूप से बढ़ता गया।
जब लेखक ने एक टियर्ड (tiered) राउटिंग योजना पेश की, तो खर्च घटकर मूल स्तर का 65% रह गया और Opus का उपयोग कुल कार्यों के 11% तक गिर गया।
यह तीन-स्तरीय (three-tier) सिस्टम कैसे काम करता है
राउटिंग का तर्क अस्पष्टता (ambiguity) पर निर्भर करता है, न कि इस पर कि कोई कार्य कोड की कितनी लाइनों को प्रभावित करता है। लेखक ने तीन श्रेणियां (buckets) परिभाषित कीं:
- Haiku – कम अस्पष्टता वाले, नियतात्मक (deterministic) कार्य। उदाहरण: lint चेतावनियों को ठीक करना, वेरिएबल्स का नाम बदलना, लॉग फाइलों का सारांश बनाना। सही उत्तर आमतौर पर कोड या टेक्स्ट की एक ही लाइन होती है।
- Sonnet – डिफ़ॉल्ट वर्कहॉर्स। यह फीचर कार्यान्वयन, नियमित बग फिक्स और मानक रिफैक्टरिंग को संभालता है जहाँ समस्या स्पष्ट होती है लेकिन समाधान में कई चरण शामिल हो सकते हैं।
- Opus – उच्च-जोखिम वाले, उच्च-अस्पष्टता वाले कार्य। आर्किटेक्चर संबंधी निर्णय, सुरक्षा ऑडिट, जटिल डीबगिंग सत्र, या कोई भी ऐसा कार्य जहाँ सही रास्ता स्पष्ट न हो और एक गलत कदम पाइपलाइन को तोड़ सकता हो।
एक स्टैटिक लुकअप टेबल इन नियमों के आधार पर प्रत्येक आने वाले अनुरोध को उपयुक्त मॉडल से जोड़ती है। लेखक ने एक "स्मार्ट" मॉडल आज़माया जो तुरंत (on the fly) टियर तय करता, लेकिन अतिरिक्त टोकन उपयोग ने किसी भी बचत को खत्म कर दिया। सरल स्टैटिक नियमों ने लगभग 80% वर्कलोड को कवर किया और सिस्टम को सस्ता और अनुमानित (predictable) बनाए रखा।
एस्केलेशन सेफ्टी नेट (The escalation safety net)
सस्ते मॉडल अभी भी गलतियाँ करते हैं। Haiku या Sonnet के किसी गलत उत्तर से बिल्ड (build) को पटरी से उतरने से बचाने के लिए, सिस्टम दो विफलताओं के बाद अनुरोध को एस्केलेट (escalate) कर देता है, जिससे उसे अगले टियर में प्रमोट कर दिया जाता है। यह सेफ्टी नेट त्रुटियों को जल्दी पकड़ लेता है और बिना किसी मानवीय हस्तक्षेप के पाइपलाइन को सुचारू रूप से चलाता रहता है।
आंकड़े जो खुद बोलते हैं
टियर्ड राउटर चलाने के चार सप्ताह बाद, लेखक ने इन बदलावों को दर्ज किया:
- API खर्च मूल लागत के 65% तक गिर गया (35% की कमी)।
- औसत टर्नअराउंड समय (Median turnaround time) 42 सेकंड से घटकर 27 सेकंड हो गया।
- Opus का उपयोग हर अनुरोध को संभालने से घटकर कुल कार्यों का केवल 11% रह गया।
ये आंकड़े दिखाते हैं कि अधिकांश डेवलपमेंट कार्य गुणवत्ता में उल्लेखनीय गिरावट के बिना सस्ते मॉडल्स को सौंपे जा सकते हैं, जबकि सबसे कठिन समस्याओं को अभी भी Opus के बड़े कॉन्टेक्स्ट विंडो (context window) का लाभ मिलता है।
अन्य डेवलपर्स के लिए सबक
- नीचे से शुरुआत करें, ऊपर से नहीं। अधिकांश दैनिक कोडिंग कार्यों के लिए सबसे शक्तिशाली मॉडल की आवश्यकता नहीं होती है। अस्पष्ट कार्यों के लिए Sonnet को डिफ़ॉल्ट बनाने से Haiku के माध्यम से सब कुछ भेजने की तुलना में अधिक पैसा बचा।
- कठिनाई मापें, आकार नहीं। एक लाइन का रेस-कंडीशन (race-condition) फिक्स पूरे फ़ाइल को रिफैक्टर करने से अधिक कठिन हो सकता है। समाधान कितना अस्पष्ट है, उसके आधार पर रूट करें, न कि बदली गई लाइनों की संख्या के आधार पर।
- एस्केलेशन दर पर नज़र रखें। एस्केलेशन की बढ़ती संख्या यह संकेत देती है कि स्टैटिक नियम अब वर्कलोड के अनुरूप नहीं हैं। सस्ते मॉडल पाइपलाइन में अधिक विफलताएं पैदा करने लगें, उससे पहले बकेट (buckets) को एडजस्ट करें।
सबसे कठिन समस्याओं के लिए सबसे महंगे मॉडल को आरक्षित रखना और बाकी काम सस्ते मॉडल्स को सौंपना, AI-सहायता प्राप्त डेवलपमेंट को तेज़ और किफायती बनाए रखता है। असली लाभ एक अनुशासित राउटिंग रणनीति में निहित है जो सही काम के लिए सही टूल का मिलान करती है।