AI ऐप बिल्डर की कीमत इस पर निर्भर करती है कि किसे काम माना जाता है

100 प्रॉम्प्ट इटरेशन प्रति सप्ताह के लिए सबसे सस्ता प्लान अक्सर वही होता है जो हर प्रॉम्प्ट के आसपास होने वाले सबसे कम काम को गिनता है। प्रकाशित मासिक कीमत तब तक लगभग कुछ नहीं बताती, जब तक यह न पता हो कि रीट्राई, प्लानिंग पास, टेस्ट रन, डिप्लॉयमेंट और बैकग्राउंड में काम कर रहा एजेंट एक ही मीटर को छूते हैं या नहीं।

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

यह लेख काल्पनिक प्राइस कैटलॉग इस्तेमाल करता है, किसी नामित विक्रेता की कीमतें नहीं। मकसद आपको ऐसी गणना देना है जिसमें खरीदने से पहले आप असली प्लान शर्तें भर सकें।

प्रॉम्प्ट की समान संख्या तीन अलग बिल छिपा सकती है

उपयोगकर्ता संदेशों की गिनती बातचीत मापती है, कंप्यूट या पूरा हुआ काम नहीं। क्रेडिट प्लान मॉडल गतिविधि को मापते हैं, टास्क प्लान विक्रेता की तय काम की इकाई को मापते हैं और फ्लैट प्लान एक सीमा के भीतर पहुँच बेचते हैं। ऐप और 100 साप्ताहिक अनुरोध एक जैसे रहने पर भी इन सीमाओं से अलग कुल लागत बनती है।

मान लें कि कोई फाउंडर हर सप्ताह 70 छोटे इंटरफ़ेस बदलाव, कई फाइलों को छूने वाले 20 बदलाव और 10 बिल्ड या डिप्लॉयमेंट बदलाव माँगता है। दिखने वाली संख्या 100 है। इसके पीछे बिल्डर रिपॉजिटरी देख सकता है, योजना बना सकता है, मॉडल को कई बार बुला सकता है, टेस्ट चला सकता है, असफल एडिट सुधार सकता है, ऐप फिर से बिल्ड कर सकता है और चैट जवाब आने के बाद एजेंट चलाता रह सकता है। एक प्लान हर मॉडल कॉल के लिए शुल्क ले सकता है। दूसरा पूरी श्रृंखला को एक टास्क कह सकता है। सब्सक्रिप्शन इसमें से कुछ शामिल कर सकता है, सीमा लगा सकता है या अतिरिक्त शुल्क ले सकता है।

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

तुलना के लिए हर महीने को चार सप्ताह मानने के बजाय 4.33 सप्ताह का मासिक गुणक लें। हर सप्ताह के 100 इटरेशन औसतन महीने में 433 इटरेशन बनते हैं। एक भी रीट्राई या बैकग्राउंड जॉब जोड़ने से पहले ही इस छोटे सुधार से 33 इटरेशन बढ़ जाते हैं।

उपयोगी कोटेशन अनुरोध विक्रेता से केवल कुल अनुमान नहीं, काम का वर्गीकरण भी माँगता है। पूछें: मीटर कब शुरू होता है? कब रुकता है? क्या असफल रन गिना जाता है? क्या ऑटोमैटिक रीट्राई गिना जाता है? इंटरफ़ेस के जवाब पूरा बताने के बाद कौन सा काम चलता रहता है? क्या बची क्षमता रोलओवर होती है? जवाब ही बिल तय करते हैं।

कैलकुलेटर खोलने से पहले एक वर्कलोड तय करें

जिस काम की आप सच में अपेक्षा करते हैं, उससे एक प्रतिनिधि सप्ताह बनाइए और तुलना से पहले उसे स्थिर रखिए। हर प्राइस मॉडल के लिए वर्कलोड बदलेंगे तो आप कीमत नहीं, बिक्री की भाषा जाँच रहे होंगे।

इस उदाहरण में साप्ताहिक वर्कलोड यह है:

• 70 छोटे एडिट, हर एक में एक क्रेडिट यूनिट
• कई फाइलों वाले 20 बदलाव, हर एक में तीन क्रेडिट यूनिट
• 10 बिल्ड या डिप्लॉयमेंट बदलाव, हर एक में पाँच क्रेडिट यूनिट
• औसतन दो क्रेडिट यूनिट वाले 25 रीट्राई रन
• कुल 45 क्रेडिट यूनिट खर्च करने वाले 35 बैकग्राउंड रन

माँगे गए 100 इटरेशन के पहले प्रयास में 180 काल्पनिक क्रेडिट यूनिट लगते हैं। रीट्राई 50 जोड़ते हैं। प्लानिंग, इंडेक्सिंग, टेस्ट और डिप्लॉयमेंट का काम 45 जोड़ता है। साप्ताहिक कुल 275 यूनिट, या औसत महीने में 1,190.75 यूनिट होता है।

टास्क बिलिंग में इसी गतिविधि का दूसरा रूप बनता है। हर सप्ताह 100 उपयोगकर्ता-शुरू किए टास्क, 25 रीट्राई टास्क और 35 बैकग्राउंड टास्क शुरू होते हैं। यानी साप्ताहिक 160 इवेंट और मासिक 692.8 इवेंट। सभी 692.8 बिल योग्य हैं या नहीं, यह कॉन्ट्रैक्ट में टास्क की परिभाषा पर निर्भर है।

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

ऐसा सप्ताह लें जिसमें सामान्य अव्यवस्था हो: एक अस्पष्ट प्रॉम्प्ट, एक डिपेंडेंसी कॉन्फ्लिक्ट, असंबंधित कारण से फेल हुआ टेस्ट और डिप्लॉयमेंट की मरम्मत। एकदम साफ डेमो सप्ताह ऐसा बजट बनाता है जो असली डेवलपमेंट शुरू होते ही खत्म हो जाता है।

अपनी सुरक्षा के लिए वर्कलोड न बढ़ाएँ। देखे गए बेसलाइन की गणना के बाद अलग वैरिएंस अलाउंस जोड़ें। बेसलाइन और अलाउंस अलग रखने से दिखता है कि प्लान सामान्य काम के कारण महँगा है या व्यस्त महीने के जोखिम की कीमत के कारण।

क्रेडिट पैक बिल्डर के भीतर की हरकत का शुल्क लेते हैं

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

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

काल्पनिक वर्कलोड की कीमत 500 यूनिट के $30 पैक से निकालें। मासिक माँग 1,190.75 यूनिट है। पैक अविभाज्य हैं, इसलिए खरीदार को तीन पैक चाहिए और वह $90 देता है। यदि क्रेडिट की अवधि खत्म नहीं होती, तो महीने के अंत में खाते में 309.25 यूनिट बचती हैं। खर्च किए काम की प्रभावी लागत लगभग 7.56 सेंट प्रति यूनिट है, जबकि पैक 6 सेंट बताता है, क्योंकि खरीदार को अनउपयोगी क्षमता भी खरीदनी पड़ी।

रोलओवर नतीजा बदल देता है। यदि बची 309.25 यूनिट बचती हैं तो अगले महीने तीन के बजाय दो पैक लेने पड़ सकते हैं। कई स्थिर महीनों में औसत लागत प्रकाशित दर के करीब पहुँचती है। यदि क्रेडिट हर महीने समाप्त होते हैं, तो फँसा बैलेंस भी कीमत का हिस्सा है। उसे मॉडल से कभी न हटाएँ।

मॉडल चयन प्रॉम्प्ट संख्या बदले बिना खपत बदल सकता है। यदि प्लेटफ़ॉर्म जटिल एडिट को चार यूनिट मल्टीप्लायर वाले मॉडल पर भेजता है, तो दस सबसे कठिन अनुरोध बिल पर हावी हो सकते हैं। पूछें कि रूटिंग ऑटोमैटिक है या नहीं, बाद में दिखती है या नहीं और क्या आप सीमा तय कर सकते हैं। दो बार फेल होकर रीट्राई करने वाला सस्ता मॉडल, एक बार में सफल होने वाले सक्षम मॉडल से महँगा पड़ सकता है।

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

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

टास्क बिलिंग इस पर निर्भर है कि टास्क कहाँ शुरू और खत्म होता है

टास्क आधारित बिलिंग सबसे सस्ता मॉडल हो सकती है, जब एक कीमत में योजना, मॉडल कॉल, टेस्ट और मरम्मत सहित पूरा प्रयास आता हो। जब हर आंतरिक कार्रवाई नया टास्क बन जाए तो यही सबसे महँगा मॉडल बन जाता है।

लेजर के हर शुरू हुए इवेंट पर $0.14 की काल्पनिक दर लगाएँ। 692.8 मासिक इवेंट पर, सेंट तक राउंड करने के बाद लागत $96.99 है। प्राइसिंग पेज पर चौदह सेंट छोटी रकम लगती है, फिर भी यह $90 के क्रेडिट पैक नतीजे से अधिक है।

अब कॉन्ट्रैक्ट का एक वाक्य बदलें: सिर्फ 433 उपयोगकर्ता-माँगे इटरेशन के लिए शुल्क लें और रीट्राई व बैकग्राउंड काम को उसी टास्क में शामिल करें। मासिक लागत गिरकर $60.62 हो जाती है। ऐप में कुछ नहीं बदला। टास्क की सीमा बदली और उस सीमा से $36.37 का फर्क आया।

पूरे हुए टास्क की बिलिंग को एक और परिभाषा चाहिए। यदि रन फाइल बदलता है लेकिन डिप्लॉयमेंट फेल हो जाता है, तो क्या प्लेटफ़ॉर्म ने टास्क पूरा किया? यदि उपयोगकर्ता नतीजा ठुकराकर सुधार माँगता है, तो क्या वह नया टास्क है या उसी का विस्तार? विक्रेताओं को एक शुल्क में असीमित काम रोकने के लिए नियम चाहिए, मगर खरीदारों को ऐसे नियम चाहिए जिन्हें वे गतिविधि लॉग से दोहरा सकें।

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

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

कन्करेंसी का तरीका भी पूछें। एक साथ चल रहे दो एजेंट बीता समय घटा सकते हैं, पर शुरू हुए टास्क दोगुने कर सकते हैं। टेस्ट एजेंट शुरू करने वाली बैकग्राउंड मरम्मत एक बार, दो बार या बिल्कुल नहीं गिनी जा सकती है। बिल मीटर के पीछे चलता है, घड़ी के पीछे नहीं।

फ्लैट सब्सक्रिप्शन सिर्फ अपनी शामिल सीमा के भीतर जीतते हैं

इस वर्कलोड में फ्लैट सब्सक्रिप्शन सबसे कम खर्च करता है जब मासिक शुल्क में सभी 433 उपयोगकर्ता इटरेशन, 108.25 रीट्राई स्टार्ट और 151.55 बैकग्राउंड स्टार्ट शामिल हों। कोई भी श्रेणी सब्सक्रिप्शन से बाहर हो तो फ्लैट प्लान को सस्ता कहने से पहले उसे जोड़ें।

काल्पनिक $79 मासिक प्लान लें, जिसमें 600 तक इंटरैक्टिव और रीट्राई रन तथा 200 बैकग्राउंड रन शामिल हैं। उदाहरण में प्रति माह 541.25 इंटरैक्टिव और रीट्राई रन तथा 151.55 बैकग्राउंड रन बनते हैं। दोनों कुल सीमा में हैं, इसलिए लागत $79 रहती है। इन मान्यताओं में फ्लैट प्राइसिंग $90 क्रेडिट पैक और $96.99 शुरू हुए टास्क प्लान से बेहतर है।

स्प्रेडशीट में unlimited शब्द की कोई कीमत नहीं है। उसे वास्तविक फेयर यूज़ सीमा, कन्करेंसी सीमा, मॉडल प्रतिबंध या धीमा करने के नियम से बदलें। विक्रेता सीमा बताने से मना करे तो कम और अधिक उपयोग के दो मामले बनाएँ। जो प्लान सिर्फ असीमित व्याख्या में सस्ता दिखता है, उसने भरोसेमंद कीमत नहीं दी है।

फ्लैट प्लान में स्टेप लागत भी बनती है। 599 शामिल रन पर एक और रन से कुछ नहीं बदलेगा। 600 पर अगला रन अतिरिक्त शुल्क या ऊँचा टियर शुरू कर सकता है। कम से कम तीन वर्कलोड स्तर बनाइए: शांत महीना, अपेक्षित महीना और रिलीज़ महीना। केवल अपेक्षित केस सब्सक्रिप्शन के उछलने का बिंदु छिपा देता है।

जब बिलिंग काम के बजाय उपयोगकर्ताओं के पीछे चलती है तो सीट महत्वपूर्ण होती हैं। एक व्यक्ति के लिए $79 प्लान, चार ज़रूरी सीट के लिए $316 है, भले टीम वही 433 इटरेशन साझा करे। अकाउंट साझा करने की अनुमति मानकर न चलें। उन लोगों की कीमत जोड़ें जिन्हें प्रॉम्प्ट रिव्यू करने, डिप्लॉयमेंट मंजूर करने या उपयोग देखने की जरूरत है।

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

वार्षिक छूट को गणना में सबसे अंत में लाएँ। पहले मासिक शर्तों पर सबसे सस्ता मॉडल खोजें। फिर छूट और प्रतिबद्धता की लागत लगाएँ। तीन महीने बाद छोड़ दिए गए टूल के लिए दस महीने का भुगतान बचत नहीं है।

रीट्राई बेसलाइन का हिस्सा हैं, फुटनोट नहीं

रीट्राई सामान्य डेवलपमेंट काम हैं, इसलिए पहले प्रयास में हमेशा सही आउटपुट मानने वाली कीमत तुलना खरीद के लिए ठीक नहीं है। उपयोगी संख्या रीट्राई एम्प्लीफिकेशन है: कुल प्रयासों को माँगे इटरेशन से भाग देना।

उदाहरण में 100 माँगे इटरेशन के लिए 125 इंटरैक्टिव प्रयास हैं, इसलिए रीट्राई एम्प्लीफिकेशन 1.25 है। इसका मतलब यह नहीं कि 25 प्रतिशत प्रॉम्प्ट बस फेल होते हैं। कुछ अनुरोधों को स्पष्टीकरण चाहिए, कुछ एडिट कोड जाँच पास करते हैं पर इरादा चूक जाते हैं और कुछ विफलताएँ टूल या डिपेंडेंसी से आती हैं। प्लान में अगला प्रयास मापा जाता हो तो बिलिंग असर एक ही होता है।

रीट्राई को ऐसे नियम से मापें जिसे दो लोग लगातार लागू कर सकें। जब उपयोगकर्ता पिछले आउटपुट को ठुकराने या सुधारने के बाद उसी इच्छित नतीजे के लिए फिर अनुरोध करे, उसे रीट्राई गिनें। सच में नई जरूरत को रीट्राई न गिनें। ऑटोमैटिक रीट्राई को अलग टैग करें, क्योंकि उपयोगकर्ता शायद उन्हें कभी न देखे।

छोटे पायलट में वे टास्क रखें जो कठिन होने की उम्मीद है। केवल लैंडिंग पेज कॉपी और रंग बदलाव जाँचेंगे तो रीट्राई दर डेटाबेस माइग्रेशन, ऑथेंटिकेशन, स्टेट मैनेजमेंट या मोबाइल बिल्ड के बारे में बहुत कम बताएगी। हर उम्मीदवार के साथ कम से कम एक जोखिमभरा बदलाव चलाएँ और गतिविधि रिकॉर्ड देखें।

रीट्राई अलग मॉडलों को अलग तरह से प्रभावित करते हैं:

• क्रेडिट बिलिंग आमतौर पर हर प्रयास में खर्च संसाधनों का शुल्क लेती है।
• शुरू हुए टास्क की बिलिंग में, यदि रीट्राई इवेंट बनाता है तो आमतौर पर हर प्रयास का शुल्क लगता है।
• पूरा होने की बिलिंग में फेल प्रयास शामिल हो सकते हैं, यह पूरे होने के नियम पर निर्भर है।
• फ्लैट बिलिंग रीट्राई को तब तक शामिल करती है जब तक वे शामिल सीमा या फेयर यूज़ नियंत्रण तक न पहुँचें।

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

रीट्राई की मानवीय लागत भी होती है। यदि उपयोगकर्ताओं को हर मरम्मत की निगरानी करनी पड़े तो डॉलर में सस्ता प्लान ध्यान के मामले में महँगा हो सकता है। पायलट के दौरान हर स्वीकार किए बदलाव पर रिव्यू के मिनट मापें। उस समय को प्लेटफ़ॉर्म बिल में ठूँसने की जरूरत नहीं, लेकिन बिल के साथ दिखाएँ ताकि कम कीमत खराब वर्कफ़्लो न छिपा सके।

बैकग्राउंड एजेंट अदृश्य गुणक हैं

बैकग्राउंड एजेंट के काम की अलग पंक्ति होनी चाहिए, क्योंकि उपयोगकर्ता जवाब देखने के बाद भी वह चलता रह सकता है। रिपॉजिटरी इंडेक्सिंग, प्लानिंग, डिपेंडेंसी जाँच, टेस्ट, बिल्ड मॉनिटरिंग, डिप्लॉयमेंट और मरम्मत एजेंट दूसरे चैट संदेश के बिना बजट खर्च कर सकते हैं।

हमारे उदाहरण में हर सप्ताह 35 बैकग्राउंड रन और 45 क्रेडिट यूनिट रखे गए हैं। ये जानबूझकर साफ दिखने वाली मान्यताएँ हैं। इन्हें पायलट के उपयोग रिकॉर्ड से बदलें। यदि विक्रेता सिर्फ एक संयुक्त कुल दिखाता है, तो वैकल्पिक ऑटोमेशन बंद करके वही प्रॉम्प्ट एक बार चलाएँ और उसे चालू करके एक बार। अंतर अनुमान है, प्रमाण नहीं, लेकिन काम को मुफ्त मानने से बेहतर है।

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

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

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

Koder.ai प्लानिंग मोड, डिप्लॉयमेंट और होस्टिंग, स्नैपशॉट और रोलबैक तथा सोर्स कोड एक्सपोर्ट को सपोर्ट करता है, इसलिए पायलट केवल चैट संदेशों की कीमत लगाने के बजाय वर्कफ़्लो के इन हिस्सों को देख सकता है। प्लान नाम और कीमतें फिर भी मौजूदा प्रोडक्ट इंटरफ़ेस में जाँचनी होंगी, क्योंकि यहाँ साइट संदर्भ टियर बताता है, उनकी मौजूदा अलाउंस नहीं।

यदि प्रोडक्ट अनुमति देता है तो बैकग्राउंड बजट तय करें, लेकिन सीमा को पूर्वानुमेयता न समझें। सीमा अतिरिक्त खर्च रोकने के लिए काम रोकती है। अधिक क्षमता की प्रतीक्षा में एजेंट के कारण ऐप की रिलीज़ फिर भी छूट सकती है। वित्तीय सीमा और संचालन संबंधी परिणाम दोनों दर्ज करें।

हर उम्मीदवार को एक ही लेजर से चलाएँ

लेजर तुलना को दोहराने योग्य बनाता है और कॉन्ट्रैक्ट की अस्पष्टता को इनवॉइस विवाद बनने से पहले उजागर करता है। एक पंक्ति में एक मापा गया इवेंट होना चाहिए, पर्याप्त संदर्भ के साथ ताकि उसे क्रेडिट, टास्क और सब्सक्रिप्शन अलाउंस में मैप किया जा सके।

यह CSV हेडर कॉपी करें और पायलट में इस्तेमाल करें:

week,event_id,requested_iteration,event_type,outcome,retry_of,background_kind,credit_units,task_events,flat_bucket,notes
2026-W01,001,1,user_edit,accepted,,,1,1,interactive,copy change
2026-W01,002,2,user_edit,rejected,,,3,1,interactive,multi file edit
2026-W01,003,2,retry,accepted,002,,2,1,interactive,repair after failed test
2026-W01,004,2,background,completed,,test,1,1,background,automatic test run

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

हर सप्ताह के अंत में चार मान निकालें:

monthly_iterations = weekly_requested_iterations * 4.33
monthly_credits = weekly_credit_units * 4.33
monthly_task_events = weekly_task_events * 4.33
retry_amplification = (user_attempts + retry_attempts) / requested_iterations

फिर पंक्तियाँ बदले बिना प्लान शर्तें लगाएँ। काल्पनिक कैटलॉग के लिए गणना यह है:

credit_cost = ceil(1190.75 / 500) * $30 = $90.00
started_task_cost = 692.8 * $0.14 = $96.99
flat_cost = $79.00, because 541.25 interactive runs < 600
             and 151.55 background runs < 200

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

विक्रेता से एक अनाम लेजर पेज की समीक्षा माँगें। यह न पूछें कि कौन सा प्लान सस्ता है, पूछें कि हर पंक्ति को कैसे वर्गीकृत किया जाएगा। लिखित वर्गीकरण बिक्री अनुमान से अधिक उपयोगी है, क्योंकि आप उसे पहले इनवॉइस से मिला सकते हैं।

स्टिकर कीमत से वैरिएंस ज्यादा मायने रखता है

उदाहरण में नतीजा $79 पर फ्लैट सब्सक्रिप्शन, $90 पर क्रेडिट पैक और $96.99 पर शुरू हुए टास्क की बिलिंग है। यह क्रम सिर्फ बताए कैटलॉग और वर्कलोड पर लागू होता है। रीट्राई के तरीके या शामिल बैकग्राउंड काम में छोटा बदलाव इसे उलट सकता है।

हर जोड़ी का ब्रेक-ईवन पॉइंट निकालें। $79 का फ्लैट प्लान $30 क्रेडिट पैक को तब हराता है जब मासिक माँग में तीन या अधिक पैक चाहिए हों, यह मानकर कि बचे क्रेडिट की भविष्य में कोई कीमत नहीं है। रोलओवर से खरीदार हर यूनिट इस्तेमाल कर सके तो 6 सेंट पर $79 लगभग 1,316.7 क्रेडिट यूनिट के बराबर है। इससे कम उपयोग पर पूरे इस्तेमाल किए क्रेडिट सस्ते पड़ते हैं।

$0.14 वाले शुरू हुए टास्क के मुकाबले $79 लगभग 564.3 इवेंट के बराबर है। अपेक्षित 692.8 इवेंट इस बिंदु से अधिक हैं। लेकिन यदि टास्क प्लान सिर्फ 433 माँगे इटरेशन का शुल्क लेता है, तो लागत $60.62 होती है और वही जीतता है। फिर एक परिभाषा हेडलाइन दर से ज्यादा मायने रखती है।

अनुमान को बिल्कुल सटीक मानने के बजाय सेंसिटिविटी केस चलाएँ। इस वर्कलोड के लिए रीट्राई एम्प्लीफिकेशन 1.10 से 1.50, बैकग्राउंड काम 20 से 60 साप्ताहिक इवेंट और जटिल एडिट की खपत को विक्रेता के बताए उचित मल्टीप्लायर तक बदलें। दर्जनों स्थिति नहीं चाहिए। वे कुछ वैरिएबल चाहिए जो निर्णय बदल सकते हैं।

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

जिस फाउंडर का उपयोग अनिश्चित है, उसे ऐसा मॉडल चुनना चाहिए जिसका नुकसान स्पष्ट दिखे। अपेक्षित मासिक कुल थोड़ा अधिक होने पर भी इसका मतलब लंबे रोलओवर वाले पैक हो सकते हैं। स्थिर, मापा हुआ काम करने वाली टीम अपनी शामिल सीमा के बीच के आसपास फ्लैट प्लान ले सकती है। टास्क प्लान उस काम के लिए उपयुक्त है जो स्वीकार किए नतीजों से साफ तौर पर जुड़ता हो और टास्क में मरम्मत का काम शामिल करे।

उदाहरण के विजेता के आधार पर चुनाव न करें। हर काल्पनिक दर और अलाउंस को ऐसी शर्तों से बदलने के बाद चुनाव करें जिन्हें आप दिखा सकें और हर वर्कलोड मान्यता को पायलट के अवलोकन से बदलें।

बिलिंग मॉडल को स्वीकार्यता परीक्षण से गुजारें

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

यह छोटा स्वीकार्यता चेकलिस्ट इस्तेमाल करें:

1. 100 प्रतिनिधि माँगे गए इटरेशन, या हर बड़े काम प्रकार वाला छोटा नमूना दर्ज करें।
2. रीट्राई, ऑटोमैटिक रीट्राई, प्लान, टेस्ट, बिल्ड, डिप्लॉयमेंट और अन्य बैकग्राउंड रन टैग करें।
3. हर इवेंट को विक्रेता के क्रेडिट, टास्क या शामिल अलाउंस नियम में मैप करें।
4. उसी 4.33 गुणक से अपेक्षित, शांत और रिलीज़ महीने की कुल लागत निकालें।
5. प्लान शर्तें सहेजें और पहले असली इनवॉइस की तुलना पूर्वानुमान से करें।

पायलट से पहले एक टॉलरेंस तय करें। उदाहरण के लिए, पूर्वानुमान से 10 प्रतिशत अधिक हर कुल की जाँच की जा सकती है। प्रतिशत प्रबंधन का चुनाव है, उद्योग मानक नहीं। इसका उद्देश्य घटना इतिहास मौजूद रहते हुए समीक्षा कराना है।

वास्तविक उपयोग पूर्वानुमान से अधिक हो तो जिम्मेदार पंक्ति श्रेणी खोजें। अधिक स्वीकार किया काम, अधिक रीट्राई से अलग है। अधिक नियोजित डिप्लॉयमेंट रन एजेंट लूप से अलग हैं। उपाय बड़ा प्लान, अधिक सीमित एजेंट नीति, स्पष्ट प्रॉम्प्ट या बिलिंग सुधार हो सकता है। एक अकेला कुल यह नहीं बता सकता कि कौन सा उपाय चाहिए।

पहले तीन बिलिंग चक्रों तक लेजर को इनवॉइस के साथ रखें, क्योंकि शांत पायलट बैच जॉब, रिलीज़ काम और ऑटोमैटिक मरम्मत छोड़ सकता है। इसलिए 100 साप्ताहिक इटरेशन के लिए सबसे सस्ता मॉडल सशर्त है, लेकिन निर्णय अस्पष्ट होने की जरूरत नहीं। स्पष्ट उदाहरण में $79 का फ्लैट सब्सक्रिप्शन जीतता है। सफलता-सीमित टास्क बिलिंग में उसी काम की लागत $60.62 है और टास्क बिलिंग जीतती है। कम या उछाल वाले उपयोग में, जब रोलओवर बर्बादी रोकता है, क्रेडिट पैक जीतते हैं। क्या गिना जाता है लिखें, छिपा काम मापें और इनवॉइस से वादा साबित कराएँ।