एका स्वतंत्र डेव्हलपरच्या तीन Claude मॉडेल्ससोबतच्या प्रयोगामुळे मासिक API खर्च ३५% ने कमी झाला आणि कामाचा सरासरी वेळ (median task latency) ४२ सेकंदांवरून २७ सेकंदांवर आला. साधी आणि कमी संदिग्ध (low-ambiguity) कामे स्वस्त Haiku मॉडेलकडे, नियमित कामे Sonnet कडे वळवून आणि अत्यंत महत्त्वाच्या समस्यांसाठी जड Opus मॉडेल राखून ठेवून, लेखकाने हे सिद्ध केले की "प्रत्येक गोष्टीसाठी सर्वोत्तम मॉडेल" वापरणे ही एक खर्चिक सवय आहे.
राउटिंग का महत्त्वाचे होते
लेखक एक स्वायत्त कोडिंग एजंट (autonomous coding agent) चालवतात ज्याला डेव्हलपमेंटच्या कामांचा सतत प्रवाह मिळतो—जसे की lint fixes, नवीन फीचर्स जोडणे, सुरक्षा पुनरावलोकने (security reviews) आणि सखोल डीबगिंग सेशन्स. अनेक महिने या एजंटने प्रत्येक विनंती सर्वात सक्षम Claude मॉडेल, Opus कडे पाठवली, कारण उच्च गुणवत्ता नेहमीच किमतीपेक्षा महत्त्वाची असेल असे त्यांना वाटत होते. Opus ची प्रति टोकन किंमत जास्त असल्याने बिल नियंत्रणाबाहेर जात होते.
जेव्हा लेखकाने टियरड राउटिंग स्कीम (tiered routing scheme) सुरू केली, तेव्हा खर्च मूळ पातळीच्या ६५% पर्यंत खाली आला आणि एकूण कामांपैकी Opus चा वापर केवळ ११% पर्यंत कमी झाला.
तीन-स्तरीय प्रणाली कशी कार्य करते
राउटिंगचे लॉजिक संदिग्धतेवर (ambiguity) अवलंबून आहे, कामात किती ओळींचा कोड आहे यावर नाही. लेखकाने तीन गट (buckets) निश्चित केले आहेत:
- Haiku – कमी संदिग्धता असलेली, निश्चित (deterministic) कामे. उदाहरणे: lint चे इशारे सुधारणे, व्हेरिएबल्सची नावे बदलणे, लॉग फाइल्सचा सारांश काढणे. याचे योग्य उत्तर सहसा कोडची एक ओळ किंवा मजकूर असते.
- Sonnet – मुख्य कामगार (default workhorse). यामध्ये फीचर इम्प्लिमेंटेशन, नियमित बग फिक्स आणि स्टँडर्ड रिफॅक्टरिंग यांसारखी कामे हाताळली जातात, जिथे समस्या स्पष्ट असते परंतु उपाय करण्यासाठी अनेक पायऱ्यांची आवश्यकता असू शकते.
- Opus – अत्यंत महत्त्वाचे आणि उच्च संदिग्धता असलेले काम. आर्किटेक्चरचे निर्णय, सुरक्षा ऑडिट, जटिल डीबगिंग सेशन्स किंवा अशी कोणतीही कामे जिथे योग्य मार्ग स्पष्ट नसतो आणि एका चुकीच्या पावलामुळे संपूर्ण पाइपलाइन विस्कळीत होऊ शकते.
एक स्टॅटिक लूकअप टेबल (static lookup table) या नियमांच्या आधारे प्रत्येक येणाऱ्या विनंतीला योग्य मॉडेलकडे वळवते. लेखकाने एक "स्मार्ट" मॉडेल वापरून पाहिले जे लगेच (on the fly) टियर ठरवेल, परंतु अतिरिक्त टोकन वापरामुळे झालेली बचत शून्य झाली. साध्या स्टॅटिक नियमांनी सुमारे ८०% कामाचा भार हाताळला आणि सिस्टम स्वस्त आणि अंदाज वर्तण्यायोग्य (predictable) ठेवली.
एस्केलेशन सेफ्टी नेट (The escalation safety net)
स्वस्त मॉडेल्सकडून देखील चुका होऊ शकतात. Haiku किंवा Sonnet कडून मिळालेला चुकीचा प्रतिसाद बिल्ड (build) विस्कळीत करू नये म्हणून, सिस्टम दोन वेळा अपयश आल्यावर विनंती पुढील टियरमध्ये (escalate) पाठवते. हा सेफ्टी नेट चुका लवकर शोधतो आणि मानवी हस्तक्षेपाशिवाय पाइपलाइन सुरळीत चालू ठेवतो.
आकडेवारी जे स्वतः बोलतात
चार आठवडे टियरड राउटर चालवल्यानंतर, लेखकाने खालील बदल नोंदवले:
- API खर्च मूळ खर्चाच्या ६५% पर्यंत खाली आला (३५% कपात).
- सरासरी वेळ (Median turnaround time) ४२ सेकंदांवरून २७ सेकंदांवर आला.
- Opus चा वापर प्रत्येक विनंती हाताळण्यापासून कमी होऊन एकूण कामाच्या केवळ ११% पर्यंत मर्यादित झाला.
ही आकडेवारी दर्शवते की बहुतांश डेव्हलपमेंट कामे गुणवत्तेत लक्षणीय घट न करता स्वस्त मॉडेल्सकडे सोपवता येतात, तर सर्वात कठीण समस्यांसाठी Opus च्या मोठ्या कॉन्टेक्स्ट विंडोचा (context window) फायदा मिळतोच.
इतर डेव्हलपर्ससाठी धडे
- कमीपासून सुरुवात करा, जास्त नाही. दैनंदिन कोडिंगच्या बहुतेक कामांसाठी सर्वात शक्तिशाली मॉडेलची गरज नसते. संदिग्ध कामांसाठी Sonnet ला डिफॉल्ट बनवल्यामुळे सर्व कामे Haiku कडे पाठवण्यापेक्षा जास्त पैसे वाचले.
- काठिण्य पातळी मोजा, आकार नाही. संपूर्ण फाईल रिफॅक्टर करण्यापेक्षा एक ओळीचा 'रेस-कंडिशन' (race-condition) फिक्स करणे अधिक कठीण असू शकते. बदललेल्या ओळींच्या संख्येवरून नाही, तर उपाय किती संदिग्ध आहे यावरून राउटिंग करा.
- एस्केलेशन रेटवर लक्ष ठेवा. एस्केलेशनची वाढती संख्या हे सूचित करते की स्टॅटिक नियम आता कामाच्या भाराशी जुळत नाहीत. स्वस्त मॉडेल्समुळे पाइपलाइनमध्ये जास्त चुका होण्यापूर्वी गट (buckets) पुन्हा समायोजित करा.
सर्वात महागडे मॉडेल कठीण समस्यांसाठी राखून ठेवणे आणि उर्वरित कामे स्वस्त मॉडेल्सना सोपवणे यामुळे AI-आधारित डेव्हलपमेंट वेगवान आणि परवडणारी राहते. खरा फायदा एका शिस्तबद्ध राउटिंग स्ट्रॅटेजीमध्ये आहे जी योग्य कामासाठी योग्य साधन निवडते.