कार्ड देने से पहले जानने लायक चार आंकड़े:
- आपका मासिक भत्ता हर साइकल में बिना इस्तेमाल हुई राशि के साथ शून्य पर रीसेट हो जाता है।
- क्रेडिट पैक की कोई समाप्ति तिथि नहीं होती।
- बिना छुए पैक पर रिफंड 14 दिनों तक मान्य है।
- असफल जनरेशन भी ठीक एक क्रेडिट के बराबर काम खर्च कर देती है, चाहे आपको आउटपुट पसंद आए या नहीं।
इनमें से तीन तो प्राइसिंग पेज की बातें हैं। दिलचस्प बात यह है कि खर्च का क्रम असल में कैसे तय होता है, और यह समझना ज़रूरी है क्योंकि यही फ़र्क़ है क्रेडिट का कुछ मायने रखने और क्रेडिट के सिर्फ़ मार्केटिंग नंबर होने के बीच।
भत्ता पहले क्यों खर्च होता है
जब आपके अकाउंट में मासिक भत्ता और ख़रीदा हुआ पैक दोनों मौजूद हों, तो भत्ता पहले खर्च होता है, पैक को हाथ भी नहीं लगाया जाता। यह बात कोई हेडलाइन प्राइसिंग कॉपी में नहीं लिखता, लेकिन यही तंत्र है जो पैक को असल में उतना मूल्यवान बनाता है जितना आपने उसके लिए चुकाया।
उल्टा सोचकर देखें: अगर पैक पहले खर्च होते, तो आपका भत्ता बस पड़ा रहता, बिना इस्तेमाल हुए, जब तक बिलिंग साइकल बदलकर उसे मिटा न देती। मार्च में व्यस्त हफ़्ते के लिए ख़रीदा गया पैक चुपचाप आपकी सब्सक्रिप्शन को सब्सिडी दे रहा होता, न कि उसमें कुछ जोड़ रहा होता — आप एक ही काम के लिए दो बार चुका रहे होते, एक बार प्लान से और एक बार पैक से, जबकि जो आप पहले ही चुका चुके थे वह पृष्ठभूमि में ग़ायब हो जाता। भत्ता-पहले इसे पलट देता है: फ़्री प्लान का पैसा पहले इस्तेमाल होता है, और जो पैसा आपने ख़ास तौर पर अतिरिक्त क्षमता के लिए दिया, वह रीसेट के हर वार से बच जाता है। मार्च में ख़रीदा गया पैक नवंबर में भी उतना ही मूल्यवान रहता है जितना ख़रीदते वक़्त था।
यही असमानता वजह है कि दोनों तरह के क्रेडिट अलग-अलग तरीक़े से समाप्त होते हैं। भत्ता आपके भुगतान किए गए साइकल से जुड़ा शामिल उपयोग है — अगर यह अनिश्चित काल तक आगे बढ़ता रहे, तो हम असल में हर तिमाही जो कोई लॉगिन नहीं करता उसे एक की क़ीमत पर तीन महीने के क्रेडिट बेच रहे होते, और प्राइसिंग पेज पर इसे समझाने के लिए ढेर सारी बारीक शर्तें चाहिए होतीं। इसलिए यह साफ़-साफ़ रीसेट होता है, न कि किसी FAQ में दबा रहता है। पैक ख़ास तौर पर उपयोग ख़रीदने के लिए ख़र्च किया गया पैसा है, कोई सब्सक्रिप्शन भत्ता नहीं, इसलिए वह एक लाभ की तरह नहीं बल्कि एक बैलेंस की तरह व्यवहार करता है — पृष्ठभूमि में कोई समाप्ति घड़ी नहीं चलती।
मैंने ऐसे टूल्स इस्तेमाल किए हैं जहाँ पेड टॉप-अप चुपचाप सब्सक्रिप्शन साइकल के साथ ही ख़त्म हो जाता था, तकनीकी रूप से शर्तों में कहीं लिखा होने के बावजूद, और यह हमेशा एक जाल जैसा लगता था।
खर्च का क्रम वह छोटा सा तंत्रगत फ़ैसला है जो इस प्रोडक्ट को वैसा बनने से रोकता है।
असल में क्रेडिट कब खर्च होता है
जब भी कोई मॉडल आपकी ओर से वास्तविक काम करता है:
- पहली बिल्ड
- बदलाव के बाद दोबारा बिल्ड करना
- प्रतिस्पर्धियों के पेज पढ़ने वाला रिसर्च पास
- मार्केटिंग ड्राफ़्ट
- मेटाडेटा को दोबारा लिखने वाला ऑप्टिमाइज़ेशन पास
इनकी क़ीमत एक जैसी नहीं है और होनी भी नहीं चाहिए — पूरी बिल्ड कई मिनटों के मॉडल टाइम में दर्जनों फ़ाइलें छू सकती है, जबकि हेडलाइन में मामूली बदलाव कुछ सेकंड का फ़ोकस्ड एडिटिंग है। हर तरह के एक्शन की दरें प्राइसिंग पेज पर हैं और अंतर्निहित मॉडलों को रीट्यून करने के साथ बदल भी सकती हैं; हम पुरानी क़ीमत बचाने के लिए चुपचाप क्वालिटी घटाने के बजाय खुलेआम नंबर बदलना पसंद करेंगे।
क्या कुछ खर्च नहीं करता:
- पब्लिश की गई साइट का लाइव बने रहना — प्रति दिन कुछ भी खर्च नहीं होता
- डैशबोर्ड पढ़ना
- रैंकिंग चेक करना
- पिछले रन का इतिहास ब्राउज़ करना
- असिस्टेंट से सीधा सवाल पूछना
यह सब मुफ़्त है, बस तब तक जब तक जवाब के लिए असल में कुछ करना न पड़े, केवल बताना न हो। नियम हर जगह एक जैसा है: क्या किसी मॉडल ने कुछ बनाया या बदला, या आपने बस वह पढ़ा जो पहले से मौजूद था।
और जो जनरेशन आपको पसंद नहीं आई, उसका भी क्रेडिट लगा, क्योंकि काम हो चुका था — टोकन खर्च हुए, कंप्यूट इस्तेमाल हुआ, मॉडल पूरा चला। यह उस स्थिति से अलग है जब कोई रन हमारी तरफ़ से बिना कुछ बनाए एरर दे दे, जो हमारी ज़िम्मेदारी है और नीचे बताया गया है। जब तक संतुष्ट न हों तब तक मुफ़्त रीट्राई सुनने में उदार लगता है, जब तक आप यह न देखें कि किसी के तीसरे प्रयास को चुपचाप उन लोगों की सब्सिडी मिल रही है जिन्होंने पहली बार में ही सही किया।
यह कहाँ बिगड़ता है, और हम इसके लिए क्या करते हैं
बीच बिल्ड में क्रेडिट ख़त्म हो जाए तो रन वहीं लॉग में रुक जाता है, तीन क़दम बाद अधूरे पेज पर नहीं — न कोई चुपचाप विफलता, न बैलेंस का हिसाब गायब, न यह अंदाज़ा लगाना कि यह अटक गया है या नहीं। टॉप-अप करें या रीसेट का इंतज़ार करें, फिर वहीं से जारी रखें जहाँ रुका था। मैंने यह ख़ुद एक क्लाइंट डेमो के दौरान होते देखा: जब उन्होंने "एक और पास" माँगा, ठीक तभी भत्ता ख़त्म हो गया, रुकने के मैसेज में बताया गया कि क्या चाहिए, हमने वहीं छोटा पैक ख़रीदा, और रन एक मिनट से भी कम में फिर से शुरू हो गया।
| विफलता का प्रकार | क्या रिफंड मिलता है? |
|---|---|
| प्लेटफ़ॉर्म-साइड विफलता (हमारा इन्फ्रास्ट्रक्चर टूटा) | हाँ — अनुरोध पर दोबारा क्रेडिट किया जाएगा, टिकट में उलझने की ज़रूरत नहीं |
| ऐप स्टोर रिजेक्शन या रद्द की गई API कुंजी | नहीं — लेकिन हम मूल समस्या ठीक करने में मदद ज़रूर करेंगे |
क्रेडिट रिफंड से टूटा हुआ सर्च कंसोल कनेक्शन ठीक नहीं होता, इसलिए हम जान-बूझकर इन मामलों को अलग तरह से देखते हैं।
रिफंड उन 14 दिनों की खिड़की के भीतर बिना छुए पैक और बिना इस्तेमाल किए नए साइकल पर लागू होता है, बस इतना ही। जो काम हो चुका है वह वापस नहीं आता — अगर एजेंट ने साइट बना दी और आपने मन बदल लिया, तो वह कंप्यूट पहले ही हो चुका, ठीक वैसे ही जैसे कोई कॉन्ट्रैक्टर उस ड्राफ़्ट के बिल किए गए घंटों का रिफंड नहीं देता जिसे आपने ठुकरा दिया। पूरी रिफंड पॉलिसी छोटी है क्योंकि हमने ऐसे अपवाद न रखने की कोशिश की जो रिफंड पॉलिसी को लंबा बना देते हैं।
