AI एजेंट प्राइसिंग: क्लाइंट्स से कितना चार्ज करें

विषय सूची

अगस्त 2026 में प्रकाशित।

TL;DR: AI एजेंट बनाने की कीमत घंटों के हिसाब से मत तय कीजिए। इसे दो अलग हिस्सों में बांटें: शुरुआती सिस्टम के लिए एक फिक्स्ड बिल्ड फ़ी, और उसे चलते रखने के लिए एक मासिक मेंटेनेंस रिटेनर। बिल्ड फ़ी डेवलपमेंट, टेस्टिंग और इंटीग्रेशन के काम को कवर करती है। रिटेनर इसलिए ज़रूरी है क्योंकि एजेंट टूटते हैं — प्रॉम्प्ट ड्रिफ्ट करते हैं, API बदलते हैं, एज केस सामने आते हैं — और मॉडल को छूने वाली किसी भी चीज़ के लिए “पूरा हो गया” कोई असली स्थिति नहीं है। रिटेनर छोड़ दीजिए, और एक महीने के भीतर आप मुफ़्त सपोर्ट का काम कर रहे होंगे।

[ऑपरेटर का दृष्टिकोण] मैं एक कंसल्टिंग ब्रांड और Pickleland — टेक्सास के प्फ्लुगर्विल में एक पिकलबॉल फैसिलिटी — के लिए 30 से ज़्यादा एजेंट प्रोडक्शन में चलाता हूं, और इसी अनुभव के आधार पर मैंने क्लाइंट्स के लिए एजेंट-बिल्डिंग काम की कीमत तय की है। सबसे आम गलती जो मैं देखता हूं — फ्रीलांसरों और एजेंसियों दोनों से — वह है AI एजेंट को वेबसाइट की तरह ट्रीट करना: कोट दो, बनाओ, सौंप दो, पूरा इनवॉइस भुगतान हो गया। एजेंट वेबसाइट नहीं हैं। ये ऐसे सिस्टम हैं जिन्हें लगातार ध्यान चाहिए, क्योंकि उनके नीचे की चीज़ (एक मॉडल, एक API, क्लाइंट का वर्कफ़्लो) लगातार बदलती रहती है। इस हकीकत के हिसाब से कीमत तय करें, वरना इसकी लागत आपको खुद उठानी पड़ेगी।

घंटे के हिसाब से बिलिंग एजेंट के काम के लिए क्यों नहीं चलती

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

यह क्लाइंट को भी दूसरी तरफ से सज़ा देता है। AI एजेंट के लिए किसी को हायर करने वाला क्लाइंट यह जज नहीं कर सकता कि किसी वर्कफ़्लो के लिए “12 घंटे” फेयर है, तेज़ है, या फुलाया हुआ है। वे एक ब्लैक बॉक्स खरीद रहे हैं जिसकी कीमत एक ऐसे नंबर से तय हुई है जिसे वे वेरिफाई नहीं कर सकते। यह अनिश्चितता क्लाइंट्स को कीमत घटाने पर मजबूर करती है, अप्रूवल टालती है, या सबसे अच्छे के बजाय सबसे सस्ता घंटे-वाला कोट हायर करवाती है।

इसका हल वही है जो किसी भी प्रोडक्टाइज्ड ऑफर के लिए काम करता है: कीमत को तय स्कोप और आउटकम वैल्यू पर तय करें, समय पर नहीं। एजेंट के काम के लिए खासतौर पर, इसका मतलब है दो अलग, फिक्स्ड-प्राइस कॉम्पोनेंट — क्योंकि बिल्ड और उसकी अपकीप वाकई अलग-अलग प्रोडक्ट हैं, जिनकी कॉस्ट स्ट्रक्चर अलग है।

दो-भाग वाला ढांचा: बिल्ड फ़ी + मेंटेनेंस रिटेनर

1. बिल्ड फ़ी — एजेंट को डिज़ाइन, बनाने, टेस्ट करने और डिप्लॉय करने के लिए एक बार की, फिक्स्ड कीमत। एक बार भुगतान होती है, आमतौर पर दो किस्तों में (शुरू करने के लिए डिपॉज़िट, डिलीवरी पर बैलेंस)।

2. मेंटेनेंस रिटेनर — एक रिकरिंग मासिक फ़ी जो लॉन्च के अगले महीने से शुरू होती है। यह मॉनिटरिंग, मॉडल या किसी अपस्ट्रीम API के बदलने पर प्रॉम्प्ट फिक्स, और छोटे स्कोप-प्रिज़र्विंग एडजस्टमेंट को कवर करती है।

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

यह उसी फ्रेमवर्क को दोहराता है जिसका इस्तेमाल मैं यह तय करने के लिए करता हूं कि कोई ऑटोमेशन बनाई भी जाए या नहीं — देखें AI एजेंट ROI: क्या ऑटोमेशन बनाना उचित है?। वह पोस्ट खरीदार के नज़रिए से लिखी गई है: किसी बिज़नेस को कैसे आंकना चाहिए कि कोई एजेंट अपनी लागत वापस दिलाता है या नहीं। यह पोस्ट उसी गणित का बेचने वाले का पहलू है — उस फ्रेमवर्क में बिल्ड कॉस्ट और मेंटेनेंस टैक्स ही वे दो चीज़ें हैं जिनकी कीमत आप यहां तय कर रहे हैं।

बिल्ड फ़ी का आकार तय करना

बिल्ड फ़ी का आकार स्कोप टियर के हिसाब से तय करें, घंटों का अंदाज़ा लगाकर नहीं। तीन टियर ज़्यादातर क्लाइंट काम को कवर करते हैं:

ये रेंज एक तय स्कोप वॉल मान कर चलती हैं — वही डिसिप्लिन जिसका ज़िक्र प्रोडक्टाइज्ड सर्विस कैसे बनाएं में है: क्या शामिल है इसकी लिखित लिस्ट, क्या नहीं है इसकी लिखित लिस्ट, और वर्कफ़्लो या टूल इंटीग्रेशन की एक तय संख्या। “मेरे बिज़नेस के लिए एक AI एजेंट” मांगने वाला क्लाइंट जिसका कोई तय वर्कफ़्लो नहीं है, वह बिल्ड खरीदने के लिए तैयार नहीं है — वह एक स्कोपिंग कॉल के लिए तैयार है, जो एक अलग, छोटा डिलिवरेबल है (मैं अपना ऐसा ऑडिट फ्लैट $500–$1,000 में प्राइस करता हूं, जो वह स्कोप डॉक्यूमेंट देता है जिसके आधार पर बिल्ड फ़ी कोट की जाती है)।

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

मेंटेनेंस रिटेनर का आकार तय करना

मैं रिटेनर को बिल्ड फ़ी के प्रतिशत के रूप में तय करता हूं, फ्लैट नंबर के रूप में नहीं, क्योंकि अपकीप की लागत सिस्टम की जटिलता के साथ उसी तरह बढ़ती है जैसे बिल्ड कॉस्ट बढ़ती है।

maintenance_retainer_per_month = build_fee × monthly_rate

monthly_rate:
  stable integrations, low API-change risk        → 3–5%
  volatile APIs (social platforms, scraped data)   → 6–10%
  multi-agent systems, custom eval suite to keep up → 8–12%

एक मध्यम रूप से स्थिर स्टैक पर $6,000 के मल्टी-स्टेप बिल्ड के लिए, यह लगभग $250–$400/महीना बैठता है। यह नंबर मेरे अपने ऑटोमेशन पर मैं जो मेंटेनेंस टैक्स लगाता हूं के काफी करीब लगना चाहिए — बिल्ड कॉस्ट का फ्लैट 20% प्रति वर्ष, जो निचले सिरे पर उसी 3–5% मासिक रेंज के बराबर बैठता है। क्लाइंट-फेसिंग रिटेनर उसी क्रम-परिमाण में रहता है क्योंकि इसके पीछे की असली लागत वजह — प्रॉम्प्ट ड्रिफ्ट, अपस्ट्रीम API बदलाव, लॉन्च के बाद सामने आने वाले एज केस — सिर्फ इसलिए नहीं बदल जाती कि अब भुगतान कोई और कर रहा है।

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

कीमत को उस चीज़ से जोड़ें जिसकी वह जगह लेती है, न कि बनाने की लागत से

बिल्ड फ़ी को क्लाइंट के सामने आपके घंटों से जस्टिफाई नहीं करना चाहिए — इसे उस मैनुअल लागत से जस्टिफाई करना चाहिए जिसे यह हटाती है। कोट देने से पहले, ROI फ्रेमवर्क वाली वही मैनुअल-कॉस्ट कैलकुलेशन क्लाइंट के डेटा पर चलाएं:

manual_cost_per_year = time_per_instance × hourly_rate × frequency_per_year
                      + error_cost_per_year

अगर किसी क्लाइंट की टीम किसी काम पर हफ़्ते में 5 घंटे बिताती है, और फुली-लोडेड रेट $40/घंटा है, तो यह $10,400/साल की मैनुअल लागत है। $300/महीना ($3,600/साल) के रिटेनर वाला $6,000 का बिल्ड फ़ी एक साल से काफी पहले ही पेबैक कर देता है और उसके बाद हर साल पेबैक करता रहता है। यही तुलना — मैनुअल लागत बनाम बिल्ड-प्लस-रिटेनर लागत — असली पिच है। हर प्रपोज़ल में इसे सबसे आगे रखें। बिना किसी तुलना बिंदु वाली कीमत सिर्फ एक नंबर है; जिस चीज़ की वह जगह लेती है उसके बगल में रखी कीमत एक तर्क है।

यह एक स्वाभाविक सीमा भी तय करता है: अगर जो मैनुअल लागत बदली जा रही है वह छोटी है, तो क्लाइंट को $15,000 का मल्टी-एजेंट सिस्टम नहीं खरीदना चाहिए, और आपको उन्हें वह बेचना नहीं चाहिए। टियर को असली विस्थापित हो रही लागत के हिसाब से सही आकार देना ही प्राइसिंग को दोनों दिशाओं में ईमानदार रखता है।

कॉन्ट्रैक्ट शर्तें जो स्कोप क्रीप रोकती हैं

मैं जो भी एजेंट-बिल्ड कॉन्ट्रैक्ट लिखता हूं, उसमें कीमत के अलावा चार शर्तें ज़रूर होती हैं:

1. “पूरा हुआ” की लिखित परिभाषा। फाइनल भुगतान से पहले एजेंट को पास करने वाले खास टेस्ट केस — सिर्फ “अच्छे से काम करता है” नहीं, बल्कि एक लिस्ट: “दिए गए डेटासेट के 10 में से 9 सैंपल लीड्स को सही से क्लासिफाई करता है,” “कनेक्टेड Facebook पेज पर बिना मैनुअल दखल के सफलतापूर्वक पोस्ट करता है।” अस्पष्ट स्वीकृति मानदंड (एक्सेप्टेंस क्राइटेरिया) बिना भुगतान वाले अतिरिक्त काम का सबसे बड़ा स्रोत हैं।
2. साफ़-साफ़ बताई गई ओनरशिप शर्तें। क्लाइंट वर्कफ़्लो लॉजिक और किसी भी क्लाइंट-स्पेसिफिक डेटा का मालिक होता है। आप पुन: प्रयोग करने योग्य स्कैफोल्डिंग, प्रॉम्प्ट टेम्प्लेट और इवैल हार्नेस अपने पास रखते हैं जो उनके बिज़नेस के लिए खास नहीं हैं — वही IP-रीयूज़ पॉइंट जिसका ज़िक्र प्रोडक्टाइज्ड सर्विस डिलीवरी सिस्टम में है। इसे पहले ही साफ़ कह दें; इससे बाद में होने वाली अजीब बातचीत टल जाती है।
3. रिटेनर कैंसिलेशन के लिए एक तय हैंडऑफ़। अगर क्लाइंट मेंटेनेंस कैंसिल करता है, तो साफ़-साफ़ बताएं कि क्या होगा: एजेंट बिना किसी और फिक्स के जैसा है वैसा चलता रहेगा, या नोटिस पीरियड के बाद उसे बंद कर दिया जाएगा। इसे तय न करना यानी आप एक ऐसे सिस्टम के लिए ज़िम्मेदार रह जाएंगे जिसकी निगरानी के लिए कोई आपको भुगतान नहीं कर रहा।
4. चेंज रिक्वेस्ट अलग से, लिखित में, काम शुरू होने से पहले प्राइस की जाएं। “हम बाद में तय कर लेंगे” नहीं — कॉन्ट्रैक्ट में लिखी एक रेट या पर-रिक्वेस्ट न्यूनतम, ताकि स्कोप बदलाव मांगने वाला क्लाइंट हर बार एक नई बातचीत न बने।

हर बार आने वाली दो आपत्तियों को कैसे संभालूं

“जो चीज़ पहले से काम कर रही है, उसे मेंटेन करने में एक्स्ट्रा खर्च क्यों आता है?” क्योंकि “काम कर रहा है” एक स्नैपशॉट है, कोई स्थिति नहीं। मॉडल प्रोवाइडर किसी मॉडल के व्यवहार को डेप्रिकेट या बदल सकता है, जिस प्लेटफ़ॉर्म पर एजेंट पोस्ट करता है वह अपना API बदल सकता है, और क्लाइंट का अपना बिज़नेस उस वर्कफ़्लो को बदल सकता है जिसके लिए एजेंट बनाया गया था। इनमें से कुछ भी आपके डिलीवर किए गए काम में बग नहीं है — यह किसी भी ऐसे सिस्टम की सामान्य गिरावट दर है जो बाहरी, बदलते हुए हिस्सों से जुड़ा हो। मैं रिटेनर को साफ़ तौर पर उस गिरावट के खिलाफ इंश्योरेंस के रूप में पेश करता हूं, चल रहे “सपोर्ट” के रूप में नहीं — सपोर्ट का मतलब है कि कुछ टूटा हुआ है; रिटेनर का मतलब है कि टूटने से पहले कोई उस पर नज़र रख रहा है।

“क्या मैं सीधे नो-कोड टूल इस्तेमाल करके बिल्ड फ़ी छोड़ नहीं सकता?” कभी-कभी, हां — और मैं यह साफ़ कह देता हूं। अगर वर्कफ़्लो वाकई सिंपल है (एक ट्रिगर, एक एक्शन, कोई कस्टम लॉजिक नहीं), तो एक नो-कोड ऑटोमेशन प्लेटफ़ॉर्म ईमानदार जवाब है, और मैं बिल्ड कोट देने के बजाय क्लाइंट को उस तरफ इशारा करूंगा। बिल्ड फ़ी तब जायज़ है जब असली लॉजिक, इंटीग्रेशन का काम, या ऐसा जजमेंट शामिल हो जिसे कोई ड्रैग-एंड-ड्रॉप टूल एक्सप्रेस नहीं कर सकता। गलत-फिट एंगेजमेंट को ठुकराना ही उन एंगेजमेंट को भरोसेमंद बनाता है जिन्हें आप लेते हैं।

इसे चलाने के लिए मैं जिन टूल्स का इस्तेमाल करता हूं

Notion — स्कोप डॉक्यूमेंट यहीं रहता है: क्या शामिल है, क्या नहीं, एक्सेप्टेंस टेस्ट लिस्ट, और ओनरशिप शर्तें — जिन्हें किसी भी डिपॉज़िट लेने से पहले क्लाइंट के साथ शेयर किया जाता है।

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

Claude वह है जिस पर मैं इनमें से ज़्यादातर एजेंट बनाता हूं — ऊपर दी गई रिटेनर प्राइसिंग एक ऐसे मॉडल स्टैक को मान कर चलती है जिसकी प्राइसिंग और व्यवहार अपेक्षाकृत स्थिर हों — अगर आप किसी कम स्थिर प्रोवाइडर पर हैं, तो यह मंथली-रेट फॉर्मूला की वोलैटिलिटी वाली धारणा को बदल देगा।

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

डिपॉज़िट 50% होना चाहिए या कुछ और?

शुरू में 50%, डिलीवरी पर लिखित एक्सेप्टेंस क्राइटेरिया के खिलाफ बाकी 50% — यह सबसे सिंपल ढांचा है और मैं डिफ़ॉल्ट रूप से इसी का इस्तेमाल करता हूं। बड़े मल्टी-एजेंट बिल्ड ($15,000+ वाले टियर) के लिए, मैं इसे तीन हिस्सों में बांटता हूं: डिपॉज़िट, वर्किंग प्रोटोटाइप पर एक माइलस्टोन भुगतान, और डिलीवरी पर बाकी बैलेंस — ज़्यादातर इसलिए ताकि किसी ऐसे क्लाइंट पर बड़ा फाइनल इनवॉइस न आ जाए जो प्रोजेक्ट के बीच में चुप हो गया हो।

अगर क्लाइंट सिर्फ मेंटेनेंस के लिए भुगतान करना चाहता है, बिना यह कि मैंने ओरिजिनल एजेंट बनाया हो?

मैं ऐसे एंगेजमेंट लेता हूं, लेकिन मैं पहले महीने की कीमत ज़्यादा रखता हूं ताकि एक ऑडिट कवर हो सके: मौजूदा प्रॉम्प्ट और कोड पढ़ना, वे एक्सेप्टेंस टेस्ट चलाना जो मैं खुद लिखता, और जो मिले उसे डॉक्यूमेंट करना। किसी ऐसे सिस्टम के लिए ज़िम्मेदारी से मेंटेनेंस रिटेनर पर कमिट नहीं किया जा सकता जिसे आपने खुद नहीं बनाया और वेरिफाई नहीं किया — ऑडिट महीना ही किसी अनजान चीज़ को एक असली नंबर में बदलता है।

मुझे कैसे पता चलेगा कि मेरा मंथली-रेट अनुमान (3–12%) बहुत कम है?

एक तिमाही तक असली मेंटेनेंस घंटों को इस बात के खिलाफ ट्रैक करें कि रिटेनर ने क्या कवर किया। अगर आप लगातार रिटेनर से ज़्यादा समय बिता रहे हैं, तो रिन्यूअल पर रेट बढ़ाएं — इसे चुपचाप सह न लें। यह फॉर्मूला उसी मेंटेनेंस-टैक्स लॉजिक से कैलिब्रेट की गई एक शुरुआती जगह है जिसका इस्तेमाल मैं अपने खुद के एजेंट के लिए करता हूं; आपकी असली API-बदलाव फ्रीक्वेंसी और क्लाइंट की एज केस सहनशीलता इसे आगे-पीछे करेगी।

क्या स्कोपिंग कॉल के लिए अलग कॉन्ट्रैक्ट चाहिए?

एक क्विक कॉल से आगे किसी भी चीज़ के लिए, हां — स्कोपिंग ऑडिट को अपने खुद के छोटे डिलिवरेबल के रूप में उसके अपने लिखित आउटपुट (स्कोप डॉक्यूमेंट) के साथ प्राइस करें, भले ही आप क्लाइंट के आगे बढ़ने पर इसकी लागत बिल्ड फ़ी में एडजस्ट करने की योजना बनाएं। इससे स्कोपिंग स्टेज खुद बिना भुगतान वाला सेल्स काम बनने से बच जाता है।

अगले कदम: मेरा AI Agents for Beginners कोर्स उस एजेंट-बिल्डिंग काम को कवर करता है जिसे यह प्राइसिंग फ्रेमवर्क मान कर चलता है कि आप पहले से डिलीवर कर सकते हैं। Cowork प्रोग्राम उन ऑपरेटर्स के लिए है जो इस तरह के काम को बनाने और प्राइस करने के लिए एक संरचित माहौल चाहते हैं। अगर आप पहले ऑडिट और स्कोप डॉक्यूमेंट खुद बनवाना चाहते हैं, तो 30-मिनट का सेशन बुक करें।