जब कोई मॉडल अचानक गायब हो जाए तब अपने AI ऐप को कैसे टिकाएँ

AI पर बनाने वाला हर डेवलपर आख़िरकार वही सबक कठिन तरीके से सीखता है: जिस मॉडल पर आप निर्भर हैं, उसके वहाँ रहने की कोई गारंटी नहीं। यह पीक ट्रैफ़िक पर रेट-लिमिट हो सकता है, इनकार लौटा सकता है, ओवरलोड एरर दे सकता है, या — जैसा जून 2026 में Claude Fable 5 के साथ हुआ — पूरी तरह बंद किया जा सकता है ऐसे कारणों से जिनका आपके कोड से कोई लेना-देना नहीं। जो ऐप इन पलों में टिकते हैं वे वे नहीं हैं जिनके पास सबसे अच्छा प्रॉम्प्ट है। वे वे हैं जिन्होंने मॉडल के चले जाने की योजना बनाई थी।

यह गाइड लचीलेपन के लिए एक व्यावहारिक, परतदार दृष्टिकोण से गुज़रती है जो काम करता है चाहे आप एक प्रोवाइडर को सीधे कॉल करें या किसी गेटवे के ज़रिए रूट करें।

चरण 1: कभी भी किसी एक मॉडल को हार्डकोड न करें

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

MODEL_CHAIN = [
    "claude-opus-4-8",      # primary
    "claude-sonnet-4-6",    # same provider, cheaper/faster
    "gpt-5.5",              # different provider entirely
]

यह एक बदलाव मतलब किसी घटना के दौरान प्रोवाइडर बदलना एक config एडिट है, न कि कोड डिप्लॉय। ध्यान दें कि तीसरी एंट्री एक अलग वेंडर है। समान-प्रोवाइडर फ़ॉलबैक आपको किसी एक मॉडल के गिर जाने से बचाते हैं; क्रॉस-प्रोवाइडर फ़ॉलबैक आपको पूरे प्रोवाइडर के गिर जाने — या ऑफ़लाइन किए जाने का आदेश दिए जाने — से बचाते हैं।

चरण 2: एक ही कोशिश नहीं, फ़ॉलबैक चेन का उपयोग करें

पैटर्न सरल है: हर मॉडल को क्रम से आज़माएँ, फेल होने पर अगले पर जाएँ, और एरर तभी सामने लाएँ जब पूरी चेन खत्म हो जाए।

def call_with_fallback(messages):
    last_error = None
    for model in MODEL_CHAIN:
        try:
            return client.complete(model=model, messages=messages)
        except (RateLimitError, OverloadError, RefusalError) as e:
            last_error = e
            continue  # try the next model
    raise AllModelsFailedError(last_error)

आप किस पर फ़ॉलबैक करते हैं वह मायने रखता है। किसी क्षणिक overloaded (HTTP 529) एरर पर उसी मॉडल को एक छोटे बैकऑफ़ के बाद फिर से आज़माना समझ में आता है। लेकिन एक ऑथेंटिकेशन एरर या एक खराब रिक्वेस्ट हर मॉडल पर एक जैसी ही फेल होगी — उन्हें आपकी पूरी चेन जलाने के बजाय तुरंत सामने आना चाहिए।

चरण 3: जब प्लेटफ़ॉर्म नेटिव रूप से फ़ॉलबैक देता है तब उस पर टिकें

आपको हमेशा इसे खुद हाथ से बनाना नहीं पड़ता। कई प्लेटफ़ॉर्म अब इसे सर्वर-साइड करते हैं:

• Anthropic के API ने एक बीटा fallbacks पैरामीटर जोड़ा जो किसी इनकार की गई रिक्वेस्ट को एक ही राउंड ट्रिप में किसी वैकल्पिक मॉडल पर फिर से आज़माता है — Fable 5, उदाहरण के लिए, इस तरह कॉन्फ़िगर किया गया था कि जब उसके क्लासिफ़ायर किसी रिक्वेस्ट को अस्वीकार करें तो वह Opus 4.8 पर फ़ॉलबैक करे। बिलिंग उस मॉडल का अनुसरण करती है जिसने वास्तव में रिस्पॉन्स दिया।
• OpenRouter आपको प्राथमिकता क्रम में एक models array पास करने देता है; यह context-length एरर, moderation flags, rate limits, और downtime पर अपने-आप फ़ेल ओवर करता है, और जिस भी मॉडल ने उत्तर दिया उसकी दर पर आपको बिल करता है।
• LiteLLM एक Router के साथ आता है जिसमें built-in retries, fallbacks, और deployments व vendors के बीच load balancing है, जिसे आप अधिकतम नियंत्रण के लिए सेल्फ़-होस्ट करते हैं।

OpenRouter या LiteLLM जैसा गेटवे आपको कई प्रोवाइडर्स के बीच एक एकीकृत endpoint देता है, इसलिए एक क्रॉस-प्रोवाइडर फ़ॉलबैक किसी दूसरे SDK को इंटीग्रेट करने के बजाय बस एक सूची में एक और एंट्री है।

चरण 4: तेज़ी से फेल होने के लिए एक circuit breaker जोड़ें

अगर कोई मॉडल साफ़ तौर पर डाउन है, तो आप नहीं चाहते कि हर रिक्वेस्ट उसके टाइमआउट होने का इंतज़ार करे, उसके बाद ही आगे फिसले। एक circuit breaker हाल की विफलताओं को ट्रैक करता है और, एक बार सीमा पार हो जाने पर, टूटे मॉडल को पूरी तरह छोड़ देता है एक cooldown अवधि के लिए। 2026 में प्रोडक्शन टीमें आम तौर पर breaker को ट्रिप करने के लिए लगातार पाँच विफलताएँ और रिकवरी जाँचने से पहले ~60-सेकंड cooldown के आसपास आती हैं। जबकि breaker खुला है, ट्रैफ़िक सीधे चेन के अगले मॉडल पर जाता है — कोई बर्बाद लेटेंसी नहीं।

चरण 5: तय करें कि आपके प्रोडक्ट के लिए "डिग्रेडेड" का क्या मतलब है

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

• चेन के हर मॉडल के खिलाफ़ अपने प्रॉम्प्ट टेस्ट करें। एक मॉडल के लिए ट्यून किया गया प्रॉम्प्ट उसके फ़ॉलबैक पर ध्यान देने-योग्य रूप से बदतर आउटपुट दे सकता है।
• जब आप डिग्रेड हो चुके हों तो उपयोगकर्ता को बताएँ अगर यह मायने रखता है (जैसे "फ़ास्ट मोड में चल रहा है"), न कि चुपचाप कम गुणवत्ता वाले परिणाम शिप करें।
• लॉग करें कि वास्तव में किस मॉडल ने हर रिक्वेस्ट का जवाब दिया ताकि किसी घटना के बाद आप देख सकें कि फ़ॉलबैक ने कितना ट्रैफ़िक सोखा।

निचोड़

लचीलापन कोई ऐसा फ़ीचर नहीं जिसे आप लॉन्च के बाद जोड़ते हैं — यह थोड़ी-सी संरचना है जो आप जल्दी जोड़ते हैं: स्थिरांक के बजाय कॉन्फ़िगरेशन, एक ही कॉल के बजाय एक प्राथमिकता चेन, तेज़ी से फेल होने के लिए एक circuit breaker, और हर स्तर पर टेस्ट किए गए प्रॉम्प्ट। जिन टीमों के ऐप जून के Fable 5 शटऑफ़ के दौरान चालू रहे वे भाग्यशाली नहीं थीं। उन्होंने बस पहले ही वह सवाल जवाब दे दिया था जो हर AI बिल्डर को पहले दिन पूछना चाहिए: कल जब यह मॉडल वहाँ न हो तो क्या होगा?