> ## Documentation Index
> Fetch the complete documentation index at: https://phaseo.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# रूटिंग और फ़ॉलबैक

> जानें कि Gateway प्रोवाइडर कैसे चुनता है और अनुरोधों को भरोसेमंद कैसे रखता है।

Phaseo Gateway हर अनुरोध को ऐसे प्रोवाइडर तक रूट करता है जो आपके चुने हुए मॉडल को चला सके। प्रोवाइडर धीमा हो, रेट लिमिट लगाए या त्रुटियाँ लौटाए, तो Gateway फ़ॉलबैक आज़मा सकता है ताकि अनुरोध पूरे हो सकें।

## रूटिंग मोड चुनें

जब तक प्रोडक्शन की कोई ज़रूरत बाकी सब से स्पष्ट रूप से अधिक महत्वपूर्ण न हो, `balanced` से शुरू करें।

| मोड | कब उपयोग करें |
| - | - |
| `balanced` | कीमत, लेटेंसी, थ्रूपुट और उपलब्धता के बीच व्यावहारिक संतुलन चाहिए। |
| `price` | रिस्पॉन्स समय घटाने से ज़्यादा प्रोवाइडर की लागत घटाना महत्वपूर्ण है। |
| `latency` | रिस्पॉन्स जल्दी शुरू होना मुख्य आवश्यकता है। |
| `throughput` | टोकन जनरेशन की निरंतर गति सबसे महत्वपूर्ण है। |

वर्कस्पेस का डिफ़ॉल्ट **डैशबोर्ड -> सेटिंग -> रूटिंग** में कॉन्फ़िगर करें। जब किसी वर्कफ़्लो को वर्कस्पेस डिफ़ॉल्ट से अधिक सीमित प्रोवाइडर या मॉडल नीति चाहिए, तो प्रीसेट का उपयोग करें।

### मॉडल रूटिंग सफ़िक्स

जब अनुरोध का ऑप्टिमाइज़ेशन मोड मॉडल ID से तय करना हो, तो उसमें रूटिंग सफ़िक्स जोड़ें:

| सफ़िक्स | रूटिंग मोड |
| - | - |
| `:nitro` | `throughput` |
| `:cheap` | `price` |
| `:fast` | `latency` |

उदाहरण के लिए, `openai/gpt-5-mini:nitro` थ्रूपुट को प्राथमिकता देता है। पहचाना गया सफ़िक्स अनुरोध के `routing.mode` या `provider.sort` तथा प्रीसेट और वर्कस्पेस रूटिंग मोड से ऊपर होता है। प्रोवाइडर अनुमति सूची, क्षेत्रीय आवश्यकताएँ, गार्डरेल और अधिकतम कीमत जैसी अन्य पाबंदियाँ फिर भी लागू रहती हैं।

## रूटिंग का सामान्य तरीका

* आप मॉडल ID के साथ अनुरोध भेजते हैं।
* Gateway प्रोवाइडर की स्थिति, लेटेंसी और क्षमता कवरेज का मूल्यांकन करता है।
* प्रोवाइडर चुना जाता है और अनुरोध चलाया जाता है।

रूटिंग को डीबग करने के लिए गतिविधि लॉग और रिस्पॉन्स मेटाडेटा में अनुरोध के नतीजे देखें।

## ऑटो-राउटर से मॉडल चुनें

ऑटो रूटिंग अभी Alpha में है और केवल चुने हुए वर्कस्पेस के लिए उपलब्ध है।

जब मॉडल को वर्कलोड के अनुसार बदलना हो, तो `phaseo/auto` का उपयोग करें। Phaseo सभी योग्य प्रोडक्शन टेक्स्ट मॉडल से शुरू करता है, फिर वर्कस्पेस पाबंदियाँ लागू करके उस वर्कलोड के लिए छोटी उम्मीदवार सूची बनाता है:

1. **डैशबोर्ड -> सेटिंग -> रूटिंग -> ऑटो रूटिंग** खोलें।
2. चुनें कि बैलेंस्ड प्रदर्शन, गुणवत्ता, लागत या लेटेंसी में से किसे ऑप्टिमाइज़ करना है।
3. Economy, Standard, Premium या बिना पाबंदी वाला खर्च प्रोफ़ाइल चुनें। स्कोरिंग से पहले ये प्रोफ़ाइल इनपुट और आउटपुट की कीमतों पर निश्चित अधिकतम सीमा लगाते हैं।
4. चाहें तो `anthropic/*`, `openai/gpt-5.*` जैसे पैटर्न या सटीक मॉडल ID से योग्य मॉडल सीमित करें।
5. चुनें कि दोबारा कोशिश की जा सकने वाली विफलता के बाद Phaseo बाकी रैंक किए गए मॉडल आज़मा सकता है या नहीं।
6. कॉन्फ़िगरेशन सेव करें।

इसके बाद ऐप्स हर अनुरोध में वर्कस्पेस की रूटिंग नीति कॉपी किए बिना ऑप्ट इन कर सकते हैं:

```json theme={null}
{
  "model": "phaseo/auto",
  "input": "Review this TypeScript function for correctness."
}
```

अनुरोध वर्कस्पेस का उद्देश्य, खर्च प्रोफ़ाइल या मॉडल पैटर्न नहीं बदल सकता। निश्चित मॉडल वाले अनुरोध ऑटो-राउटर को बायपास करते रहते हैं।

उद्देश्य के अनुसार मॉडल गुणवत्ता, प्रोवाइडर विश्वसनीयता, लेटेंसी और कीमत का सापेक्ष महत्व बदलता है:

| उद्देश्य | कब उपयोग करें |
| - | - |
| `balanced` | चारों संकेतों को ध्यान में रखने वाला व्यावहारिक डिफ़ॉल्ट चाहिए। |
| `quality` | संबंधित बेंचमार्क में प्रदर्शन सबसे महत्वपूर्ण है। |
| `cost` | इनपुट और आउटपुट टोकन की अनुमानित कम कीमत सबसे महत्वपूर्ण है। |
| `latency` | प्रोवाइडर की हालिया कम लेटेंसी सबसे महत्वपूर्ण है। |

खर्च प्रोफ़ाइल Standard tier के लिए टेक्स्ट के प्रति दस लाख टोकन पर USD में निश्चित मूल्य सीमा लगाते हैं:

| खर्च प्रोफ़ाइल | अधिकतम इनपुट कीमत | अधिकतम आउटपुट कीमत |
| - | -: | -: |
| Economy | \$0.10 | \$0.50 |
| Standard | \$0.30 | \$1.50 |
| Premium | \$1 | \$5 |
| कोई भी कीमत | कोई सीमा नहीं | कोई सीमा नहीं |

कस्टम सीमाएँ इनपुट और आउटपुट के अधिकतम मूल्य सीधे तय करती हैं। जिन मॉडलों की Standard text pricing ज्ञात नहीं है, वे मैनेज किए गए उम्मीदवारों के समूह में शामिल नहीं होते।

हर `phaseo/auto` अनुरोध के लिए Phaseo एक तय कम लागत वाले classifier मॉडल को सामान्य Gateway child request भेजता है। Child request वही वर्कस्पेस और बिलिंग पहचान इस्तेमाल करता है, request logs में अलग दिखता है और उस पर `purpose=auto_routing_classifier` तथा parent request ID का लेबल होता है। Classifier वर्कलोड के प्रकारों का संरचित मिश्रण, जटिलता स्कोर और भरोसे का मान लौटाता है; वह सीधे मॉडल नहीं चुनता।

टूल और structured output जैसे निश्चित अनुरोध तथ्य भरोसेमंद मेटाडेटा के रूप में शामिल किए जाते हैं। Classifier request विफल हो, timeout हो जाए या अमान्य डेटा लौटाए, तो Phaseo generation request को विफल करने के बजाय code, reasoning, tool use, structured output, translation, summarization या सामान्य उपयोग के लिए स्थानीय deterministic classifier पर लौटता है।

Classifier की जटिलता उस न्यूनतम मॉडल क्षमता को दर्शाती है जिससे भरोसेमंद और स्वीकार्य उत्तर मिलने की संभावना हो। Phaseo क्षमता का अंतर जोड़ता है, फिर benchmark fit को वर्कस्पेस उद्देश्य, कीमत, लेटेंसी, प्रोवाइडर की स्थिति और विश्वसनीयता के साथ जोड़ता है। Classifier request और चुनी गई generation request की सामान्य Gateway pipeline के माध्यम से अलग-अलग बिलिंग होती है।

स्कोरिंग से पहले हर अनुमति-प्राप्त मॉडल को सामान्य endpoint, workspace model, provider, privacy, guardrail और circuit-breaker जाँच पास करनी होती है। फिर router Phaseo catalog के संबंधित, प्रोवाइडर द्वारा स्वयं रिपोर्ट न किए गए benchmarks को Phaseo की मौजूदा प्रोवाइडर स्थिति, लेटेंसी और कीमतों के साथ जोड़ता है। Benchmark या संचालन डेटा मौजूद न हो, तो उसे neutral माना जाता है; इससे अनुमति सूची नहीं बढ़ती।

रिस्पॉन्स का `model` फ़ील्ड चुने गए मॉडल की पहचान बताता है। Request details में वर्कलोड, उद्देश्य, चुना गया मॉडल, फ़ॉलबैक क्रम, उम्मीदवार और कारक स्कोर, benchmark ID, बहिष्करण और algorithm version दिखते हैं। Routing traces में request या response का कंटेंट नहीं होता।

वर्कस्पेस में मॉडल फ़ॉलबैक चालू होने पर `429`, `500`, `502`, `503` या `504` के बाद Phaseo रैंकिंग के बाकी मॉडल आज़माता है। हर फ़ॉलबैक पूरे नीति और प्रोवाइडर चयन प्रवाह से दोबारा गुजरता है। Client errors से मॉडल नहीं बदलता।

किसी जुड़ी हुई dynamic route से चुना गया निश्चित मॉडल प्राथमिकता पाता है। इस स्थिति में request details में override दर्ज होता है और उस अनुरोध के लिए auto-router model fallbacks बंद रहते हैं।

<Warning>
  खर्च प्रोफ़ाइल और मॉडल पैटर्न पात्रता नियंत्रित करते हैं, गुणवत्ता की गारंटी नहीं देते। अपने वर्कलोड पर मिले मॉडल मिश्रण को जाँचें।
</Warning>

## रूटिंग निर्णय समझें

**डैशबोर्ड -> सेटिंग -> उपयोग -> अनुरोध लॉग** खोलें, अनुरोध चुनें और **प्रोवाइडर रिस्पॉन्स** के नीचे **रूटिंग ऑब्ज़र्वेबिलिटी** खोलें।

अनुरोध लॉग दिखाता है:

* रैंक किए गए हर प्रोवाइडर और उसका अंतिम स्कोर
* Phaseo ने किस प्रोवाइडर को चुना और किन प्रोवाइडरों को आज़माया
* रैंकिंग से पहले हटाए गए प्रोवाइडर और दर्ज कारण
* रोलआउट या रूटिंग स्थिति की वजह से कम रैंक किए गए प्रोवाइडर
* हर रैंक किए गए प्रोवाइडर का स्कोर निकालने में इस्तेमाल किए गए इनपुट, वज़न, योगदान और गुणक

स्कोर के कारक और रिकॉर्ड किया गया संदर्भ अलग-अलग होते हैं। स्कोर का कारक सक्रिय रूटिंग मोड के अंतिम स्कोर को बदलता है। रिकॉर्ड किया गया संदर्भ निर्णय समझाने में मदद करता है, लेकिन ज़रूरी नहीं कि स्कोर पर असर डाले।

`balanced` रूटिंग में Phaseo पात्र प्रोवाइडर को विश्वसनीयता, लेटेंसी, tail latency, थ्रूपुट, कीमत और token fit से स्कोर करता है। दिखाई गई गणना बताती है कि हर कारक ने अंतिम स्कोर में कितना योगदान दिया; सभी रिकॉर्ड किए गए मेट्रिक को समान महत्व नहीं दिया जाता।

### विश्वसनीयता और प्रोवाइडर का अपटाइम

विश्वसनीयता सैंपल स्कोर में इस्तेमाल होने वाला मान है। इसे प्रोवाइडर के नतीजों से निकाला जाता है; सफलता दर सहायक संदर्भ के रूप में दिखाई जाती है।

ये नतीजे प्रोवाइडर का अपटाइम घटाते हैं:

* प्रमाणीकरण विफलताएँ (`401`)
* भुगतान विफलताएँ (`402`)
* मॉडल नहीं मिला प्रतिक्रियाएँ (`404`)
* सर्वर त्रुटियाँ (`500` या इससे अधिक)
* रिस्पॉन्स स्ट्रीम शुरू होने के बाद की त्रुटियाँ
* सफल HTTP प्रतिक्रियाएँ जो त्रुटि कारण के साथ समाप्त हों

ये नतीजे प्रोवाइडर का अपटाइम नहीं घटाते:

* गलत अनुरोध (`400`)
* भौगोलिक पाबंदियाँ (`403`)
* बहुत बड़े payload (`413`)
* रेट लिमिट (`429`)

भौगोलिक पाबंदियाँ और रेट लिमिट अलग से ट्रैक की जाती हैं, क्योंकि वे यह नहीं दिखातीं कि प्रोवाइडर स्वयं अनुपलब्ध है।

### ट्रेस उपलब्धता और गोपनीयता

रूटिंग ऑब्ज़र्वेबिलिटी चालू होने के बाद किए गए अनुरोधों के पूरे routing traces उपलब्ध होते हैं। पुराने अनुरोधों में आंशिक ट्रेस या कोई routing details नहीं दिख सकतीं।

Routing traces सीमित होते हैं और उनमें कंटेंट नहीं होता। उनमें प्रोवाइडर चयन समझाने के लिए आवश्यक संख्याएँ और स्थितियाँ होती हैं, लेकिन prompt, संदेश या जनरेट किया गया कंटेंट ट्रेस में कॉपी नहीं किया जाता।

## मॉडल ID में सटीक प्रोवाइडर चुनें

जब किसी अनुरोध को एक खास provider-model जोड़ी का उपयोग करना हो, तो `<provider-id>:<canonical-model-id>` का उपयोग करें:

```json theme={null}
{
  "model": "baseten:thinking-machines/inkling-small",
  "input": "Hello"
}
```

Qualifier उस अनुरोध के लिए दूसरे प्रोवाइडर पर फ़ॉलबैक बंद करता है। `baseten:google/gemma-4-26b-a4b:free` जैसे पहचानकर्ता में भी suffix canonical model ID का हिस्सा रहता है।

पूरे syntax, मुफ़्त route validation, routing precedence, aliases, error codes और request examples के लिए [प्रोवाइडर-योग्य मॉडल ID](./provider-qualified-models.mdx) देखें।

## रूटिंग और फ़ॉलबैक नियंत्रित करें

मौजूदा सार्वजनिक रूटिंग और फ़ॉलबैक नियंत्रण जानबूझकर स्पष्ट रखे गए हैं:

### प्रीसेट फ़ॉलबैक पूल सीमित करते हैं

**डैशबोर्ड -> सेटिंग -> प्रीसेट** में आप तय कर सकते हैं:

* अनुमति-प्राप्त मॉडल
* प्रोवाइडर अनुमति सूचियाँ
* प्रोवाइडर अनदेखी सूचियाँ
* prompt और parameter का डिफ़ॉल्ट व्यवहार

प्रोवाइडर चयन से पहले ये पाबंदियाँ लागू होती हैं। इसलिए प्रीसेट retry और failover के लिए योग्य प्रोवाइडर को जानबूझकर सीमित कर सकता है।

### रूटिंग मोड प्रोवाइडर रैंकिंग बदलता है

**डैशबोर्ड -> सेटिंग -> रूटिंग** में वर्कस्पेस तय कर सकते हैं कि Gateway संगत प्रोवाइडर को कैसे रैंक करे:

* `balanced`
* `price`
* `latency`
* `throughput`

इसी पेज पर beta और alpha चैनल टॉगल भी हैं, ताकि preview traffic को जानबूझकर शुरू किया जा सके और वह बिना ट्रैक किए routing side effect के रूप में न आए।

### BYOK फ़ॉलबैक स्पष्ट है

**डैशबोर्ड -> सेटिंग -> BYOK** में टीमें चुन सकती हैं कि विफल BYOK अनुरोध को Phaseo credits पर फ़ॉलबैक करने दिया जाए या नहीं। आम सवाल “मेरी अपनी key विफल हुई—क्या अनुरोध फिर भी पूरा होना चाहिए?” के लिए यही मौजूदा सार्वजनिक नियंत्रण है।

### डायनामिक रूट API कुंजियों पर नीतियाँ लागू करते हैं

जब अलग API keys या request classes को अलग provider behavior चाहिए, तो **डैशबोर्ड -> सेटिंग -> रूटिंग** में dynamic route बनाएँ। Route यह कर सकता है:

* अनुरोध बॉडी के नेस्टेड फ़ील्ड, अनुरोध हेडर, कस्टम मेटाडेटा, एंडपॉइंट, मॉडल या सेशन ID के आधार पर शाखाएँ बनाना
* A/B टेस्ट और क्रमिक rollout के लिए प्रतिशत के आधार पर ट्रैफ़िक बाँटना
* प्रमाणित key के usage buckets से दैनिक, साप्ताहिक या मासिक request और cost limit लागू करना
* किसी दूसरे मॉडल को कॉल करके उसका routing mode, provider preference और fallback policy चुनना
* cache-aware और session-aware provider affinity चालू करना
* एक या अधिक inference API keys से जुड़ना

Conditions में true और false outputs होते हैं। Rate और budget nodes में within और exceeded outputs होते हैं। Session या prompt-cache key के लिए प्रतिशत चयन deterministic होता है, इसलिए एक ही cached conversation rollout के दौरान बेतरतीब ढंग से दूसरी शाखा पर नहीं जाती।

सेव करने पर immutable draft version बनता है। चुने हुए version को deploy करने पर वह snapshot Gateway में कॉपी होता है और जुड़ी keys के policy caches अमान्य किए जाते हैं। Rollback के लिए पुराने versions उपलब्ध रहते हैं। Provider-health से जुड़ी operational recommendations flow editor से अलग **Insights** में दिखाई जाती हैं।

OpenAI-संगत टेक्स्ट इन्फ़रेंस इंटरफ़ेस पर कस्टम मेटाडेटा उपलब्ध है:

```json theme={null}
{
  "model": "openai/gpt-5-mini",
  "metadata": {
	    "customer_plan": "pro",
	    "workspace": "acme"
  }
}
```

## फ़ॉलबैक व्यवहार

प्रोवाइडर त्रुटियाँ या रेट लिमिट लौटाए, तो Gateway दोबारा कोशिश कर सकता है या अनुरोध को उसी मॉडल का समर्थन करने वाले दूसरे प्रोवाइडर तक भेज सकता है। फिर भी `429` और `5xx` रिस्पॉन्स को exponential backoff के साथ संभालें।

Dynamic route के model nodes में क्रमवार fallback models की सूची भी हो सकती है। Phaseo पहले चुने मॉडल के लिए सभी पात्र provider attempts समाप्त करता है। अगर मिला रिस्पॉन्स retry योग्य हो (`429`, `500`, `502`, `503` या `504`), तो Gateway हर fallback model के लिए पूरा policy और provider-selection flow क्रम से फिर चलाता है। Client errors तुरंत लौटाए जाते हैं और मॉडल नहीं बदलते।

हर फ़ॉलबैक को workspace model restrictions, guardrails, provider policy, pricing और capability support के विरुद्ध अलग से जाँचा जाता है। एक route में अधिकतम आठ fallback models रखे जा सकते हैं।

और जानें:

* [रेट लिमिट](../api-reference/limits.mdx)
* [त्रुटि प्रबंधन](../api-reference/errors.mdx)

## कैश और सत्र-आधारित अनुरोध संबद्धता

Text generation endpoints पर cache-aware routing डिफ़ॉल्ट रूप से चालू होती है। Provider द्वारा prompt-cache का वास्तविक read रिपोर्ट करने के बाद, यदि वह provider स्वस्थ हो और सक्रिय route, preset, guardrail तथा request policy में अनुमति-प्राप्त हो, तो Phaseo मेल खाने वाले context को 15 मिनट के लिए उसी provider से जोड़ देता है।

`session_id` मौजूद होने पर cache affinity केवल शुरुआती context से नहीं, session से जुड़ती है। अगला cache read दिखने पर Phaseo affinity refresh करता है और session activity के 24 घंटे तक इसे बनाए रखता है। Circuit breakers और policy filters को affinity पर हमेशा प्राथमिकता मिलती है।

Workspace या dynamic-route defaults बदले बिना एक अनुरोध के लिए इसे बंद करें:

```json theme={null}
{
  "model": "openai/gpt-5",
  "session_id": "support-session-42",
  "provider": {
    "cache_aware_routing": false
  }
}
```

Context cache affinity बनाए रखते हुए एक अनुरोध के लिए session identifier अनदेखा करना हो, तो यह उपयोग करें:

```json theme={null}
{
  "model": "openai/gpt-5",
  "session_id": "support-session-42",
  "routing": {
    "session_affinity": false
  }
}
```

## BYOK संबंधी बातें

BYOK का उपयोग तब करें जब Phaseo routing और observability चाहिए, लेकिन चुना हुआ provider मॉडल के उपयोग का बिल सीधे आपके अपने खाते में भेजे।

* हर UTC कैलेंडर माह में पूरे हुए पहले 250,000 BYOK requests पर Phaseo service fee नहीं लगती।
* उस सीमा के बाद Phaseo provider-equivalent cost का 2.5% लेता है।
* कम-से-कम \$1 का Phaseo credit रखें। इससे managed fallback और सीमा के बाद शुल्क वसूली सुरक्षित रहती है; provider के शुल्क सीधे उसके साथ आपके खाते में आते हैं।
* Provider के quotas, data policy, model access और account restrictions फिर भी लागू होते हैं।

Provider credentials को स्टोर करने से पहले AES-256-GCM से encrypt किया जाता है और उन्हें उनके workspace तथा provider से बाँधा जाता है। हर key को उन्हीं models और Phaseo API keys तक सीमित रखें जिन्हें उसकी ज़रूरत है। कोई अनुरोध Phaseo credits का उपयोग बिल्कुल न करे, तो managed fallback बंद करें।

## क्या लॉग करें

Production workloads में request IDs, response status codes और model IDs लॉग करें, ताकि debugging के दौरान विफलताओं को जोड़ सकें और routing behavior की पुष्टि कर सकें।

## संबंधित गाइड

* [प्रीसेट](./presets.mdx)
* [फ़ीचर समानता मैट्रिक्स](../migration-guides/feature-parity-matrix.mdx)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.