Esc to close · ⌘K / Ctrl-K opens search anywhere
BharatRouter का दावा है uptime का: राउटर उन providers के बीच सहजता से स्विच करता हैजिन्हें आप कॉन्फ़िगर करते हैं — providers के बीच वही मॉडल, या जब पहली पसंद उपलब्ध न हो तो पूरी तरह एक अलग मॉडल। नीचे एक चेन बनाएँ, स्टेप्स को खत्म करें, असली रिक्वेस्ट्स फायर करें, और देखें कि x-br-provider बैज दिखाता है कि वास्तव में हर एक को किसने सर्व किया। रिक्वेस्ट सफल होती रहती है; यही तो बात है।
1 · आपकी API key— आपके ब्राउज़र (localStorage) में रहती है, केवल api.bharatrouter.com पर भेजी जाती है
अभी तक कोई key नहीं है? एक बनाएँ — ट्रायल keys काम करती हैं (200 req/day, मुफ़्त)।
2 · फॉलबैक चेन— पहला स्टेप प्राइमरी है; राउटर विफलता पर या जब कोई स्टेप खत्म कर दिया जाए, तब नीचे की ओर चलता है
हर पूल को मिलाता है: प्लेटफ़ॉर्म मॉडल (आपके वॉलेट से भुगतान), आपके अपनेBYOK मॉडल (provider/model के रूप में टाइप किए गए, एक बार key सेव हो जाने पर), और साइन-इन होने पर आपके अपने कस्टम एंडपॉइंट्स (BYOE)। "खत्म किए गए" स्टेप्स रिक्वेस्ट से हटा दिए जाते हैं — ठीक वैसा ही जैसा एक आउटेज राउटर को दिखता है।
3 · असली रिक्वेस्ट्स फायर करें
वही चीज़, आपके कोड से
fallbacks फील्ड हर रिक्वेस्ट पर काम करता है। ओनर्स एक चेन को पूरे org में भी सेव कर सकते हैं — वही JSON के साथ PUT /me/routing/<model>, या अपने एजेंट से set_fallback_chain MCP टूल कॉल करने के लिए कहें — ताकि साधारण रिक्वेस्ट्स इसे बिना किसी कोड बदलाव के उठा लें।
हर provider के बुरे मिनट होते हैं — rate limits, क्षेत्रीय घटनाएँ, मॉडल का अप्रचलन। एक ही वेंडर के साथ, उनका बुरा मिनट आपका आउटेज बन जाता है। BharatRouter हर रूट के लिए लाइव हेल्थ रखता है (circuit breakers, latency EWMAs) और आपकी चेन को क्रम में चलाता है, इसलिए कोई रिक्वेस्ट तभी फेल होती है जब आपके कॉन्फ़िगर किए गए हरस्टेप डाउन हो — और क्रम आप तय करते हैं: लागत के लिए पहले अपना इंफ्रा, latency के लिहाज़ से अहम फॉलबैक के लिए एक तेज़ inference क्लाउड, और आख़िरी सहारे के तौर पर पूरी तरह एक अलग मॉडल। optimize: "auto" सेट करें और राउटर इसके बजाय हर रिक्वेस्ट पर uptime, latency और price का मूल्यांकन करता है।