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 चे मूल्यांकन करतो.