जब हमारे AI प्रोवाइडर ने मॉडल बंद कर दिया

जुलाई 2026 में कई फ़ीचर एक साथ काम करना बंद कर गए: AI चैट, टिकट में AI जवाब, टिकट के सारांश, सर्वर बिल्डर, और साथ में आइडिया व बग रिपोर्ट का मॉडरेशन और अनुवाद।

वजह हमारा कोड नहीं था। हमारे AI प्रोवाइडर ने वह मॉडल बंद कर दिया था जिसका हम इस्तेमाल कर रहे थे।

पहला हिस्सा: मॉडल चला गया

यह ज़ाहिर हिस्सा है, और इसे जल्दी ठीक कर लिया गया। प्रोवाइडर कोई मॉडल बंद करता है, आप उसका उत्तराधिकारी डालते हैं, काम खत्म।

असली घटना उसके बाद शुरू हुई।

दूसरा हिस्सा: खाली जवाब, बिना एरर के

बदलने के बाद जवाब आने लगे। बस कभी-कभी वे खाली होते थे। अधूरे नहीं, बिगड़े हुए नहीं, बल्कि पूरी तरह खाली जवाब, बिना किसी भी एरर के।

वजह एक ऐसे फ़र्क में है जो मॉडल के नाम से पता नहीं चलता: नया मॉडल एक रीज़निंग मॉडल है। असली जवाब से पहले वह एक अलग फ़ील्ड में सोचने की एक अंदरूनी प्रक्रिया लिखता है। दोनों एक ही टोकन बजट से खर्च होते हैं।

अगर बजट सोचने में ही खत्म हो जाए, तो जो जवाब वापस आता है वह औपचारिक रूप से ठीक होता है: प्रोवाइडर "लंबाई की सीमा पूरी हुई" बताता है और कंटेंट फ़ील्ड खाली होता है। न कोई एरर, न कोई संकेत, ऐसा कुछ नहीं जो एक try/catch देख पाए।

हमने इसे एक असली टेस्ट से दोबारा करके देखा: पाँच टोकन का बजट ही हर रिक्वेस्ट पर खाली जवाब पैदा करने के लिए काफ़ी है।

तीसरा हिस्सा: बिल

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

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

फ़िक्स एक लाइन का है। रिक्वेस्ट बॉडी में सोचना बंद किया जा सकता है, और तब मॉडल फिर से पुराने जैसा बर्ताव करता है। तब से वह लाइन हर कॉल वाली जगह पर होती है, और रिपॉज़िटरी में ऐसी जगहें मुट्ठी भर से ज़्यादा हैं।

चौथा हिस्सा: सफ़ाई करते हुए हमें क्या मिला

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

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

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

चार जगहें, जहाँ हमने ठीक इसका उल्टा किया था:

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

स्थिर चीज़ से पहले नई चीज़। उसी चेक ने नई बग रिपोर्ट को तुलना के लिए दिए गए पचास तक के उम्मीदवारों से पहले भेजा। इससे API का सबसे बड़ा प्रॉम्प्ट हमेशा पूरी तरह मिस होता रहा।

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

हिस्ट्री पर एक खिसकती खिड़की। हर संदेश पर आखिरी N संदेश भेजने से हर संदेश पर शुरुआत खिसक जाती है। तब पूरी हिस्ट्री हमेशा मिस होती रहती है। सही तरीका है ब्लॉक में काटना, यानी कभी-कभार और अच्छी-खासी मात्रा में।

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

हमने इससे क्या सीखा

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

खतरनाक खराबी वह थी जो चुपचाप हुई। पुराने मॉडल का जाना तुरंत दिख गया और मिनटों में ठीक हो गया। खाली जवाब औपचारिक रूप से वैध रिस्पॉन्स के रूप में आते रहे और अनिश्चित काल तक ऐसे ही रह सकते थे।

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

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