APIs को केवल सफलता पर ही शुल्क क्यों लेना चाहिए — HTTP 200 बिलिंग का तर्क
ज़्यादातर APIs हर बिल योग्य कॉल पर शुल्क लेती हैं। AI एजेंट अस्थिर upstream सेवाओं पर लगातार retry करते हैं — जिसका मतलब है कि पुराना 'हमेशा शुल्क लो' मॉडल असल में resilience पर टैक्स लगा देता है। यहाँ केवल HTTP 200 पर बिलिंग का तर्क दिया गया है, और यह आपके एजेंट डिज़ाइन करने के तरीके में क्या बदलता है।
TL;DR
- •AI एजेंट क्षणिक विफलताओं (5xx, timeouts, rate limits) पर उचित रूप से retry करते हैं। 'हमेशा शुल्क लो' बिलिंग के तहत, हर retry एक असली शुल्क है — जो 99.5% uptime वाले एक upstream को उस खराब 0.5% के दौरान 5× लागत के दंड में बदल देता है।
- •'केवल HTTP 200 पर शुल्क लो' प्रदाता के प्रोत्साहन को ग्राहक के प्रोत्साहन के साथ संरेखित करता है: प्रदाता अस्थिरता ठीक करते हैं, ग्राहक उसके लिए भुगतान नहीं करते।
- •यह डिज़ाइन पैटर्न भी खोल देता है — आक्रामक retry budgets, optimistic prefetching, अनावश्यक कॉल — जिन्हें 'हमेशा शुल्क लो' अत्यधिक महंगा बना देता है।
- •ज़्यादातर प्रदाता ऐसा नहीं करते क्योंकि उनका पुराना infrastructure मीटरिंग को response से नहीं, बल्कि upstream कॉल से जोड़ देता है। यह नीति का रूप धरी हुई बिलिंग-सिस्टम की एक सीमा है।
वह व्यवहार जिसे हम बढ़ावा देने की कोशिश कर रहे हैं
AI एजेंट एक नई तरह के API client हैं। ये 2015 के वे सावधान enterprise integrations नहीं हैं जो एक error पकड़कर किसी on-call इंजीनियर को email कर देते थे। ये ऐसे loops हैं जो, जब कुछ विफल होता है, थोड़ी देर सोते हैं और फिर कोशिश करते हैं — कभी पाँच या दस बार — और परिणाम किसी इंसान को दिखाते तक नहीं। loop का पूरा मकसद यही है कि क्षणिक विफलताएँ अंतिम उपयोगकर्ता के लिए अदृश्य रहें।
यह एक बढ़िया पैटर्न है। यह लचीले उत्पाद बनाता है। यह उपयोगकर्ताओं से सार्वजनिक इंटरनेट की उलझी हुई हकीकत छिपाता है। दिक्कत यह है कि API बिलिंग मॉडल उस युग में तय हुआ था जब retry दुर्लभ था और इतना महँगा था कि उसे डिफ़ॉल्ट रूप से हतोत्साहित किया जा सके। यह आज भी उसी तरह काम करता है। हर retry एक बिल योग्य कॉल है, चाहे उसने कुछ लौटाया हो या नहीं।
ठोस रूप में: एक एजेंट जो 99.5% uptime वाली API को हिट करता है और क्षणिक विफलताओं पर पाँच बार तक retry करता है, वह उस खराब 0.5% के दौरान 5× तक कॉल — और 5× बिल — पैदा करेगा। एजेंट ने सही काम किया। ग्राहक upstream की अस्थिरता का भुगतान करता है।
सरल विकल्प
केवल HTTP 200 पर शुल्क लो। विशेष रूप से, केवल प्रलेखित response आकार वाली एक सफल response पर। बाकी सब कुछ — कॉल करने वाले की errors के लिए 4xx, हमारी errors के लिए 5xx, timeouts, rate limits, आंशिक-पर-malformed responses — मुफ़्त है।
यह छोटा सा बदलाव लगता है। ऐसा नहीं है। यह बदल देता है कि दोनों पक्षों के लिए आर्थिक रूप से तर्कसंगत क्या है:
- प्रदाता के पास अब अस्थिरता ठीक करने का एक सीधा वित्तीय प्रोत्साहन है। हर अस्थिर 503 एक छूटी हुई बिक्री है, मुफ़्त भोजन नहीं। हमने पाया कि केवल-सफलता-पर बिलिंग अपनाना वह सबसे बड़ी अकेली ताकत थी जिसने हमारे विश्वसनीयता के काम को roadmap की चोटी पर खींच लिया — कोई spreadsheet चाल ऐसी नहीं जो downtime को ठीक दिखा दे जब आप उन कॉल का राजस्व छोड़ रहे हों।
- ग्राहक retry budgets को आक्रामक रूप से तय कर सकता है। 5-retry exponential-backoff loop एक स्पष्ट चुनाव है जब क्षणिक विफलता की सबसे बुरी स्थिति एक भुगतान की गई कॉल (अंतिम सफलता) है, छह नहीं (हर प्रयास के लिए एक भुगतान)।
- बाज़ार APIs की तुलना डॉलर-प्रति-प्रयास के बजाय डॉलर-प्रति-सफल-कॉल पर कर सकता है। यही सही इकाई है। यदि दो APIs दोनों '$0.001 प्रति कॉल' प्रकाशित करती हैं पर एक 99.9% uptime पर है और दूसरी 95% पर, तो उपयोगकर्ता को दिखने वाली लागत 'हमेशा शुल्क लो' के तहत 5× भिन्न होती है, और 'केवल सफलता पर' के तहत बिल्कुल 0%। खरीदार को किसे चुनना चाहिए यह स्पष्ट है — और 'केवल सफलता पर' इसे दृश्यमान बना देता है।
एजेंट बनाने के तरीके में क्या बदलता है
1. Retry budgets मुफ़्त हो जाते हैं
'हमेशा शुल्क लो' बिलिंग के तहत, क्षणिक-विफलता handler के लिए सही retry budget लगभग 1–2 प्रयास होता है — इससे आगे बार-बार की विफलताओं की लागत मायने रखने लगती है। 'केवल सफलता पर' के तहत, budget है 'जब तक उपयोगकर्ता इंतज़ार कर सके'। हम नियमित रूप से 5-retry, exponential-backoff, jittered पैटर्न वाले एजेंट loops देखते हैं जो पुरानी बिलिंग के तहत लापरवाह होते।
2. Optimistic prefetching सस्ता हो जाता है
एक पैटर्न जो 'हमेशा शुल्क लो' के तहत अत्यधिक महँगा है: उपयोगकर्ता के टाइप करते रहते ही अनुमानित query सही होने की उम्मीद में एक search कॉल अनुमानतः शुरू कर देना। यदि अनुमान गलत हो, तो परिणाम फेंक दो। 'केवल सफलता पर' के तहत यह सस्ता है क्योंकि रद्द की गई / अप्रयुक्त कॉल सफलता लौटाती हैं पर आप response को त्याग देते हैं — इसलिए आप पूर्वानुमेयता और latency के लिए एक छोटा सा प्रीमियम चुकाते हैं। 'हमेशा शुल्क लो' के तहत, हर गलत अनुमान एक भुगतान की गई कॉल है, जो इस heuristic को shipping के लिए बहुत महँगा बना देता है।
3. अनावश्यक कॉल एक विश्वसनीयता उपकरण बन जाती हैं
कभी-कभी सबसे सस्ती विश्वसनीयता रणनीति यह है कि दो अलग-अलग APIs को दो requests भेजी जाएँ, जो पहले लौटे उसे ले लिया जाए, और धीमी वाली को त्याग दिया जाए। 'हमेशा शुल्क लो' के तहत यह आपका बिल दोगुना कर देता है। 'केवल सफलता पर' के तहत यह त्यागी गई कॉल के लिए मुफ़्त है (आपने response का उपयोग नहीं किया, आपने उसका भुगतान नहीं किया)। अचानक hedging रणनीतियाँ जो महँगी अमूर्तताएँ थीं, व्यावहारिक बन जाती हैं।
'सफलता' का क्या अर्थ होना चाहिए
यह मॉडल तभी काम करता है जब 'सफलता' स्पष्ट हो। हम इसे कसकर परिभाषित करते हैं:
- प्रलेखित response schema के साथ HTTP 200 — बिल योग्य।
- response body में लिपटे error के साथ HTTP 200 — बिल योग्य नहीं (यही वह खामी होगी जो पूरे मॉडल को तोड़ देती है)।
- HTTP 4xx — बिल योग्य नहीं। इसमें शामिल हैं 401 (auth), 402 (अपर्याप्त credits), 422 (validation), 404 (कुछ संदर्भों में नहीं मिला)।
- HTTP 5xx — बिल योग्य नहीं।
- HTTP 429 (rate limit) — बिल योग्य नहीं।
- हमारे edge से पहले के नेटवर्क errors / timeouts — बिल योग्य नहीं।
batch endpoints (जैसे एक कॉल में 25 URLs वाला URL Extract) के लिए, यदि कोई भी URL सफल हुई तो पूरी कॉल एक HTTP 200 है, जिसका शुल्क प्रति-URL दर पर लिया जाता है। प्रति-URL status फ़ील्ड कॉल करने वाले को बताती है कि कौन-सी URLs विफल हुईं। काम हो चुका; यह बिल योग्य है।
ज़्यादातर प्रदाता ऐसा क्यों नहीं करते
तीन कारण, इस क्रम में कि कौन-सा कितना मायने रखता है:
- बिलिंग infrastructure। मानक पैटर्न यह है कि response जानने से पहले API gateway पर मीटर किया जाए। gateway एक बिल योग्य event को Kafka में भेजता है, बिलिंग सिस्टम उसे एकत्र करता है, बिल भेज दिया जाता है। मीटरिंग को इस तरह फिर से जोड़ना कि वह upstream सेवा के status code के साथ उत्तर देने के बाद सक्रिय हो, के लिए या तो (a) gateway को backend के स्वास्थ्य से जोड़ना पड़ता है (नए failure modes बनाते हुए) या (b) एक reconciliation pipeline लिखनी पड़ती है जो विफल कॉल को पीछे जाकर credit करे। दोनों असली engineering काम हैं।
- आदत। यह पैटर्न भरोसेमंद backends ने तय किया था — Twilio, AWS, Stripe। यह तब ठीक काम करता है जब आपका upstream 99.99% uptime पर हो। जो APIs LLMs को लपेटती हैं, web scraping करती हैं, या धीमे data partners को कॉल करती हैं वे कहीं कम भरोसेमंद हैं, पर बिलिंग पैटर्न भरोसेमंद युग से विरासत में मिला और कभी अपडेट नहीं हुआ।
- राजस्व। 'हमेशा शुल्क लो' बस अधिक पैसा है। ज़्यादातर प्रदाताओं को इस आयाम पर प्रतिस्पर्धा नहीं करनी पड़ी क्योंकि ज़्यादातर ग्राहक एजेंट traffic नहीं थे, और तुल्यकालिक मानव उपयोगकर्ता कभी-कभार की विफलताओं को बिलिंग मॉडल पढ़ने की तुलना में बेहतर सहन कर लेते हैं।
पहला असली engineering है। दूसरा और तीसरा जड़ता है। दोनों झुक जाएँगे जैसे-जैसे एजेंट traffic API खपत का बहुमत बनता जाएगा — जो, रुझान रेखाओं के अनुसार, ज़्यादातर सार्वजनिक APIs के लिए 18 महीनों के भीतर हो रहा है।
खरीदार के रूप में क्या देखें
यदि आप किसी एजेंट workload के लिए data APIs का मूल्यांकन कर रहे हैं, तो तीन स्पष्ट प्रश्न:
- 'क्या आप केवल HTTP 200 पर शुल्क लेते हैं, या हर बिल योग्य प्रयास पर?' — सीधा उत्तर ज़रूरी है। 'आमतौर पर' या 'plan पर निर्भर' स्वीकार न करें।
- 'HTTP 207 / आंशिक-सफलता का बिल कैसे बनता है?' — खामी वाला उत्तर बाहर निकाल लाता है।
- 'आपका प्रकाशित uptime क्या है, और यदि आप उससे चूक जाते हैं तो SLA refund तंत्र क्या है?' — 'केवल सफलता पर' एक मज़बूत संकेत है पर यह एक असली SLA का विकल्प नहीं है। दोनों मौजूद होने चाहिए।
यह जिस बदलाव की ओर इशारा करता है
AI एजेंट हर उस API की इकाई-अर्थव्यवस्था बदल देते हैं जिसे वे छूते हैं। एजेंट युग के लिए डिज़ाइन की गई APIs अलग दिखती हैं — सरल आकार, पूर्वानुमेय schemas, machine-friendly auth, पारदर्शी मूल्य निर्धारण — और उनके बिलिंग मॉडल भी अलग दिखते हैं। 'केवल सफलता पर' सरलतम बदलावों में से एक है। कठिन वाला, जो अभी हमारे आगे है, यह पता लगाना है कि multi-step एजेंट workflows प्रदाताओं के बीच कैसे मूल्य निर्धारित करें जब कोई एक पक्ष पूरे रास्ते का स्वामी न हो।
अभी के लिए, जिन प्रदाताओं से कर सकें उनसे 'केवल सफलता पर' की माँग करें। ऐसे एजेंट बनाएँ जो इसका लाभ उठाएँ। और जब आप कोई API खरीदने जाएँ, तो गणित डॉलर-प्रति-सफल-कॉल पर करें, डॉलर-प्रति-प्रयास पर नहीं।
अक्सर पूछे जाने वाले प्रश्न
क्या 'केवल सफलता पर' प्रदाताओं को सफलताओं को विफलताओं के रूप में गलत वर्गीकृत करने के लिए प्रोत्साहित नहीं करता?
सिद्धांत में हाँ, पर उल्टा दबाव अधिक मज़बूत है: डेवलपर्स वास्तविक दुनिया के डॉलर-प्रति-उपयोगी-कॉल के आधार पर APIs की तुलना करते हैं, और 'केवल सफलता पर' ठीक यही मापता है। जो प्रदाता चुपचाप सफलताओं को विफलताओं के रूप में फिर से वर्गीकृत करे, उसे कुछ ही दिनों में एक नाराज़ support queue और सार्वजनिक समीक्षाओं का एक निशान झेलना पड़ेगा। बाज़ार इतना छोटा है कि यह खुद ही ठीक हो जाता है।
अगर मेरी कॉल आंशिक रूप से सफल होती है तो क्या — उदाहरण के लिए, एक batch extract जिसमें 25 में से 2 URLs विफल हो जाएँ?
दो उचित मॉडल। (a) यदि कोई भी URL सफल हुआ तो पूरी कॉल HTTP 200 है; प्रति-URL विफलताएँ प्रति-URL status में रिपोर्ट की जाती हैं। काम हुआ, इसलिए यह बिल योग्य है। (b) आंशिक के लिए HTTP 207 (multi-status) — हर URL का अलग-अलग बिल बनता है। हमने (a) चुना क्योंकि यह मूल्य निर्धारण को पूर्वानुमेय बनाता है: एजेंट जानते हैं कि एक सफल HTTP 200 का मतलब है कि सबसे बुरी स्थिति घोषित credit लागत है। (b) अधिक 'न्यायसंगत' है पर इसके लिए बजट बनाना कठिन है।
विफलता क्या मानी जाती है?
हमारा नियम: ऐसा HTTP 4xx जो स्पष्ट रूप से कॉल करने वाले की गलती हो (malformed body, गायब auth, अपर्याप्त credits) उस पर शुल्क नहीं लिया जाता। HTTP 5xx पर कभी शुल्क नहीं लिया जाता — यह हमारी समस्या है। हमारी ओर के नेटवर्क errors और timeouts पर कभी शुल्क नहीं लिया जाता। Rate limits (429) पर कभी शुल्क नहीं लिया जाता। केवल एक ही चीज़ पर शुल्क लिया जाता है — घोषित response आकार के साथ HTTP 200।
ज़्यादातर प्रदाता हर कॉल पर शुल्क क्यों लेते हैं?
तीन कारण, ज़्यादातर ऐतिहासिक। (1) पुराने बिलिंग सिस्टम response जानने से पहले API gateway पर मीटर करते हैं। बिलिंग को इस तरह जोड़ना कि वह response status के आधार पर पीछे जाकर सक्रिय हो, तुच्छ काम नहीं है। (2) यह पैटर्न Twilio और AWS ने भरोसेमंद backends के युग में तय किया था; जो APIs LLMs को लपेटती हैं या web scraping करती हैं वे कहीं कम भरोसेमंद हैं, इसलिए यह धारणा टिकती नहीं। (3) इससे अधिक राजस्व मिलता है। पहले दो बहाने हैं; तीसरा सच है।
क्या ऐसे मामले हैं जहाँ 'हमेशा शुल्क लो' का अर्थ बनता है?
जब कॉल हर बार वास्तव में एक तय लागत खर्च करती हो, परिणाम चाहे जो हो — उदाहरण के लिए, एक hardware-call-out (SMS भेजा गया), एक mutation जो सीमा पर atomic हो (DNS अपडेट), या ऐसी सेवा जिसका backend 'हमने कोशिश की और विफल रहे' को 'हमने कर दिया और आपको पता नहीं चला' से अलग नहीं कर सकता। पढ़ने-शैली की data APIs और search APIs के लिए यह मॉडल फिट नहीं बैठता।
इस लेख में उपयोग की गई APIs
Sarah Choy, API Pick की CEO हैं। वे AI एजेंट्स और LLM वर्कफ़्लो के लिए प्रोडक्शन-रेडी APIs बनाने के बारे में लिखती हैं।