AI एजेंट की लागत का गणित: Haiku कब Sonnet को मात देता है (और कब नहीं)

विषय-सूची

जून 2026 में अपडेट किया गया।

सारांश: Sonnet के बजाय Claude Haiku चुनने से प्रति-कॉल लागत एक परिमाण-कोटि (order of magnitude) तक घट सकती है, पर केवल तब जब टास्क Haiku की कम सफलता-दर को सह सके। जो मापदंड मायने रखता है वह है प्रति-सफल-परिणाम लागत — कॉल लागत जोड़ रीट्राई जोड़ मानव सफ़ाई — न कि प्रति-टोकन का दिखावटी दाम। मैं हर टास्क के हिसाब से राउट करता हूँ, और मेरे उच्च-मात्रा वाले चरणों का एक बड़ा हिस्सा Haiku पर चलता है जबकि निर्णय वाले काम Sonnet पर रहते हैं।

ऑपरेटर का नज़रिया: मैं 100 से ज़्यादा एजेंट चलाता हूँ, और इन्फ़रेंस एक असली ख़र्च-मद है। पर मैंने ऐसी टीमें देखी हैं जो हर चीज़ को सबसे सस्ते मॉडल पर ठूँसकर “पैसा बचातीं” और फिर वह लागत रीट्राई, एस्केलेशन और नाराज़ ग्राहकों के रूप में चुकातीं। लागत-गणित तभी काम करता है जब आप पूरे फ़नल को मापें।

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

टोकन की अर्थव्यवस्था, सीधे शब्दों में

Anthropic, Claude के लिए प्रति दस लाख टोकन शुल्क लेता है, इनपुट और आउटपुट अलग-अलग बिल होते हैं, और आउटपुट की लागत इनपुट से कई गुना ज़्यादा होती है। सटीक आँकड़े समय के साथ बदलते हैं, इसलिए Anthropic की मौजूदा क़ीमत देखें — पर निर्णय को जो चलाता है वह है संरचना:

• Haiku सस्ता, तेज़ स्तर है — परिवार में अब तक की सबसे कम प्रति-टोकन लागत।
• Sonnet बीच में बैठता है — Haiku से काफ़ी महँगा, Opus से काफ़ी सस्ता।
• Opus सबसे कठिन तर्क के लिए प्रीमियम स्तर है।

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

असल में जो मापदंड मायने रखता है: प्रति-सफल-परिणाम लागत

प्रति-कॉल लागत एक दिखावटी आँकड़ा है। यह रहा वह सूत्र जो मैं सचमुच इस्तेमाल करता हूँ:

प्रति_सफलता_लागत = (कॉल_लागत × प्रयास) + सफ़ाई_लागत
                   ÷ सफलता_दर

जहाँ प्रयास रीट्राई को गिनता है, और सफ़ाई_लागत वह अपेक्षित लागत है जो किसी इंसान द्वारा छूटी हुई विफलताओं को ठीक करने में लगती है। देखिए यह तुलना के साथ क्या करता है।

मान लीजिए Haiku प्रति कॉल Sonnet की लगभग दसवें हिस्से की लागत है। अगर किसी टास्क पर Haiku 80% बार सफल होता है और Sonnet 98% बार, तो प्रति-कॉल बचत बहुत बड़ी दिखती है। पर अगर Haiku की हर विफलता एक रीट्राई छेड़ती है और 10 में से 1 को अब भी एक इंसान की ज़रूरत होती है जिसका असली पैसा लगता है, तो सफ़ाई वाला पद टोकन की बचत को निगल सकता है। कम-जोखिम, उच्च-मात्रा वाले टास्क पर गणित ज़बरदस्त ढंग से Haiku के पक्ष में है। ऐसे टास्क पर जहाँ एक विफलता ग़लत ग्राहक को ईमेल भेज दे, यह पूरी तरह पलट सकता है।

आप यह निर्णय हर मॉडल की सफलता-दर मापे बिना नहीं ले सकते — और ठीक यही eval हार्नेस आपको देता है। वही eval सेट दोनों मॉडलों पर चलाइए और एक ही पैमाने पर सफलता-दरें पढ़िए।

जहाँ Haiku निर्णायक रूप से जीतता है

Haiku तब सही चुनाव है जब टास्क सीमित, संरचित और सत्यापन-योग्य हो:

• वर्गीकरण और राउटिंग — “क्या यह आने वाला संदेश बुकिंग है, शिकायत है, या स्पैम?” तीन ख़ाने, सत्यापन आसान, लगातार चलता है। दिन भर Haiku।
• स्कीमा के साथ निष्कर्षण — किसी टेक्स्ट से एक तारीख़, एक नाम, एक राशि निकालना, Zod से सत्यापित। अगर आउटपुट पार्स हो जाता है, तो वह लगभग निश्चित रूप से सही है।
• छोटे री-राइट और फ़ॉर्मेटिंग — लहजे में फेरबदल, ज्ञात-अच्छे इनपुट का सारांश, डेटा का सामान्यीकरण।
• पहली-छँटाई फ़िल्टरिंग — Haiku ट्राइएज करता है, और केवल अस्पष्ट मामले ही Sonnet तक एस्केलेट होते हैं। यह सबसे ज़्यादा लीवरेज वाला पैटर्न है।

साझा सूत्र: Haiku की ग़लती की लागत कम है और ग़लती पकड़ना सस्ता है। जब सत्यापन सस्ता हो और जोखिम कम हो, तो सस्ता मॉडल जीतता है।

जहाँ Sonnet अपनी क़ीमत वसूल करता है

Sonnet (और कभी-कभी Opus) तब सार्थक है जब टास्क खुला, बहु-चरणीय, या ग़लत होने पर महँगा हो:

• मल्टी-टूल एजेंट लूप जहाँ एक ग़लत टूल कॉल झड़ी की तरह फैल जाती है। उच्च तर्क-विश्वसनीयता चरणों में जुड़ती जाती है — मल्टी-एजेंट ऑर्केस्ट्रेशन में जिन ऑर्केस्ट्रेशन पैटर्न की मैं बात करता हूँ, वे इस पर टिके हैं कि मॉडल कहानी का सिरा न खोए।
• ग्राहक-सामना करने वाला जनरेशन जहाँ ख़राब आउटपुट भरोसे की क़ीमत वसूलता है, सिर्फ़ एक रीट्राई की नहीं।
• हर वह चीज़ जहाँ सत्यापन ख़ुद ही कठिन हो। अगर आप सस्ते में नहीं बता सकते कि आउटपुट सही है या नहीं, तो आप ऐसे मॉडल का जोखिम नहीं उठा सकते जो अक्सर ग़लत हो।

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

वह राउटिंग नियम जो मैं सचमुच लागू करता हूँ

मैं हर एजेंट के लिए एक मॉडल नहीं चुनता। मैं एजेंट के भीतर हर टास्क के हिसाब से राउट करता हूँ, आम तौर पर एक सस्ता क्लासिफ़ायर तय करता है कि नीचे का कौन-सा मॉडल काम सँभालेगा:

function pickModel(task: Task): string {
  // सस्ता, सत्यापन-योग्य, उच्च-मात्रा → Haiku
  if (task.type === "classify" || task.type === "extract") {
    return "claude-haiku";
  }
  // खुला या ग्राहक-सामना करने वाला → Sonnet
  if (task.customerFacing || task.steps > 2) {
    return "claude-sonnet";
  }
  return "claude-sonnet"; // डिफ़ॉल्ट रूप से सुरक्षित विकल्प
}

यहाँ दो सिद्धांत कूटबद्ध हैं। डिफ़ॉल्ट सुरक्षित मॉडल रखें, सस्ता नहीं — आप लागत को एक चलते-फिरते आधार से नीचे की ओर अनुकूलित करते हैं, कभी विश्वसनीयता को एक टूटे आधार से ऊपर की ओर नहीं। और एस्केलेट करें, जुआ न खेलें: आसान 80% Haiku को सँभालने दें और कठिन 20% Sonnet को सौंप दें। यह संकर तरीक़ा लगभग हमेशा हर चीज़ को किसी एक मॉडल पर अकेले चलाने को मात देता है।

इसके ऊपर लगाने के लिए प्रॉम्प्ट कैशिंग भी है: अगर आपका सिस्टम प्रॉम्प्ट बड़ा है और दोबारा इस्तेमाल होता है, तो कैशिंग स्तर की परवाह किए बिना इनपुट लागत को काफ़ी घटा देती है, जो कभी-कभी Sonnet को इतना सस्ता बना देता है कि Haiku वाला सवाल ही बेमानी हो जाता है।

मेरे अपने स्टैक से एक हल किया हुआ उदाहरण

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

अब वह चरण लीजिए जो ग्राहक को असली जवाब का मसौदा तैयार करता है। कम मात्रा, खुला, और एक ख़राब मसौदा बाहर जाने पर भरोसे की क़ीमत वसूलता है। वह Sonnet पर ही रहता है। वही एजेंट, दो मॉडल, जोखिम के हिसाब से राउट किए गए। मैं दोनों के प्रति-रन लागत और सफलता मापदंडों पर नज़र रखता हूँ, जैसा मैं मैं कैसे मापता हूँ कि कोई AI एजेंट सचमुच काम कर रहा है या नहीं में बताता हूँ — और मैं किसी चरण को एक स्तर नीचे तभी धकेलता हूँ जब eval कहे कि सस्ता मॉडल सफलता-दर बनाए रखता है।

अक्सर पूछे जाने वाले सवाल

क्या व्यवहार में Claude Haiku हमेशा Sonnet से सस्ता होता है?

प्रति टोकन, हाँ — बड़े अंतर से। प्रति सफल-परिणाम, हमेशा नहीं। अगर Haiku की कम सफलता-दर रीट्राई और मानव सफ़ाई छेड़ती है, तो उन टास्क पर जहाँ ग़लतियाँ पकड़ना या ठीक करना महँगा हो, कुल लागत Sonnet से ज़्यादा हो सकती है।

किसी दिए गए टास्क के लिए मैं Haiku और Sonnet के बीच कैसे तय करूँ?

टास्क को दो धुरियों पर अंक दीजिए: आउटपुट कितना सत्यापन-योग्य है और एक ग़लती कितनी महँगी है। सत्यापन में सस्ता, कम-जोखिम, उच्च-मात्रा वाला काम Haiku को जाता है; खुला, ग्राहक-सामना करने वाला, या सत्यापन में कठिन काम Sonnet को जाता है। एजेंट के हिसाब से नहीं, टास्क के हिसाब से राउट कीजिए।

वह एकमात्र लागत-मापदंड क्या है जिस पर मुझे नज़र रखनी चाहिए?

प्रति-सफल-परिणाम लागत — कॉल लागत गुणा प्रयास जोड़ अपेक्षित सफ़ाई लागत, भाग सफलता-दर। अकेले प्रति-कॉल दाम रीट्राई और मानव समय को छिपा देता है, और वहीं सस्ते मॉडल चुपके से महँगे पड़ने लगते हैं।

क्या मैं एक ही एजेंट में दोनों मॉडल इस्तेमाल कर सकता हूँ?

हाँ, और आम तौर पर आपको करना चाहिए। सबसे मज़बूत पैटर्न एक सस्ता पहला दौर है (Haiku वर्गीकृत करता है या फ़िल्टर करता है) जो केवल अस्पष्ट मामलों को Sonnet तक एस्केलेट करता है। यह संकर तरीक़ा आम तौर पर हर चीज़ को एक ही स्तर पर चलाने को मात देता है।