# OmniRoute Auto-Combo Engine (ગુજરાતી) 🌐 **Languages:** 🇺🇸 [English](../../../../routing/AUTO-COMBO.md) · 🇪🇹 [am](../../../am/docs/routing/AUTO-COMBO.md) · 🇸🇦 [ar](../../../ar/docs/routing/AUTO-COMBO.md) · 🇦🇿 [az](../../../az/docs/routing/AUTO-COMBO.md) · 🇧🇬 [bg](../../../bg/docs/routing/AUTO-COMBO.md) · 🇧🇩 [bn](../../../bn/docs/routing/AUTO-COMBO.md) · 🇧🇦 [bs](../../../bs/docs/routing/AUTO-COMBO.md) · 🇨🇿 [cs](../../../cs/docs/routing/AUTO-COMBO.md) · 🇩🇰 [da](../../../da/docs/routing/AUTO-COMBO.md) · 🇩🇪 [de](../../../de/docs/routing/AUTO-COMBO.md) · 🇬🇷 [el](../../../el/docs/routing/AUTO-COMBO.md) · 🇪🇸 [es](../../../es/docs/routing/AUTO-COMBO.md) · 🇪🇪 [et](../../../et/docs/routing/AUTO-COMBO.md) · 🇮🇷 [fa](../../../fa/docs/routing/AUTO-COMBO.md) · 🇫🇮 [fi](../../../fi/docs/routing/AUTO-COMBO.md) · 🇫🇷 [fr](../../../fr/docs/routing/AUTO-COMBO.md) · 🇮🇪 [ga](../../../ga/docs/routing/AUTO-COMBO.md) · 🇳🇬 [ha](../../../ha/docs/routing/AUTO-COMBO.md) · 🇮🇱 [he](../../../he/docs/routing/AUTO-COMBO.md) · 🇮🇳 [hi](../../../hi/docs/routing/AUTO-COMBO.md) · 🇭🇷 [hr](../../../hr/docs/routing/AUTO-COMBO.md) · 🇭🇺 [hu](../../../hu/docs/routing/AUTO-COMBO.md) · 🇦🇲 [hy](../../../hy/docs/routing/AUTO-COMBO.md) · 🇮🇩 [id](../../../id/docs/routing/AUTO-COMBO.md) · 🇳🇬 [ig](../../../ig/docs/routing/AUTO-COMBO.md) · 🇮🇹 [it](../../../it/docs/routing/AUTO-COMBO.md) · 🇯🇵 [ja](../../../ja/docs/routing/AUTO-COMBO.md) · 🇬🇪 [ka](../../../ka/docs/routing/AUTO-COMBO.md) · 🇰🇭 [km](../../../km/docs/routing/AUTO-COMBO.md) · 🇮🇳 [kn](../../../kn/docs/routing/AUTO-COMBO.md) · 🇰🇷 [ko](../../../ko/docs/routing/AUTO-COMBO.md) · 🇱🇹 [lt](../../../lt/docs/routing/AUTO-COMBO.md) · 🇱🇻 [lv](../../../lv/docs/routing/AUTO-COMBO.md) · 🇮🇳 [ml](../../../ml/docs/routing/AUTO-COMBO.md) · 🇮🇳 [mr](../../../mr/docs/routing/AUTO-COMBO.md) · 🇲🇾 [ms](../../../ms/docs/routing/AUTO-COMBO.md) · 🇲🇹 [mt](../../../mt/docs/routing/AUTO-COMBO.md) · 🇲🇲 [my](../../../my/docs/routing/AUTO-COMBO.md) · 🇳🇵 [ne](../../../ne/docs/routing/AUTO-COMBO.md) · 🇳🇱 [nl](../../../nl/docs/routing/AUTO-COMBO.md) · 🇳🇴 [no](../../../no/docs/routing/AUTO-COMBO.md) · 🇮🇳 [or](../../../or/docs/routing/AUTO-COMBO.md) · 🇮🇳 [pa](../../../pa/docs/routing/AUTO-COMBO.md) · 🇵🇭 [phi](../../../phi/docs/routing/AUTO-COMBO.md) · 🇵🇱 [pl](../../../pl/docs/routing/AUTO-COMBO.md) · 🇵🇹 [pt](../../../pt/docs/routing/AUTO-COMBO.md) · 🇧🇷 [pt-BR](../../../pt-BR/docs/routing/AUTO-COMBO.md) · 🇷🇴 [ro](../../../ro/docs/routing/AUTO-COMBO.md) · 🇷🇺 [ru](../../../ru/docs/routing/AUTO-COMBO.md) · 🇱🇰 [si](../../../si/docs/routing/AUTO-COMBO.md) · 🇸🇰 [sk](../../../sk/docs/routing/AUTO-COMBO.md) · 🇸🇮 [sl](../../../sl/docs/routing/AUTO-COMBO.md) · 🇷🇸 [sr](../../../sr/docs/routing/AUTO-COMBO.md) · 🇸🇪 [sv](../../../sv/docs/routing/AUTO-COMBO.md) · 🇰🇪 [sw](../../../sw/docs/routing/AUTO-COMBO.md) · 🇮🇳 [ta](../../../ta/docs/routing/AUTO-COMBO.md) · 🇮🇳 [te](../../../te/docs/routing/AUTO-COMBO.md) · 🇹🇭 [th](../../../th/docs/routing/AUTO-COMBO.md) · 🇹🇷 [tr](../../../tr/docs/routing/AUTO-COMBO.md) · 🇺🇦 [uk-UA](../../../uk-UA/docs/routing/AUTO-COMBO.md) · 🇵🇰 [ur](../../../ur/docs/routing/AUTO-COMBO.md) · 🇺🇿 [uz](../../../uz/docs/routing/AUTO-COMBO.md) · 🇻🇳 [vi](../../../vi/docs/routing/AUTO-COMBO.md) · 🇳🇬 [yo](../../../yo/docs/routing/AUTO-COMBO.md) · 🇨🇳 [zh-CN](../../../zh-CN/docs/routing/AUTO-COMBO.md) · 🇹🇼 [zh-TW](../../../zh-TW/docs/routing/AUTO-COMBO.md) --- > **વપરાશકર્તાઓ માટે**: ઝડપથી શરૂઆત કરવા માંગો છો? સરળ સમજૂતીઓ અને ઉદાહરણો માટે [Auto-Combo વપરાશકર્તા માર્ગદર્શિકા](../getting-started/AUTO-COMBO-GUIDE.md) જુઓ. > અનુકૂલનશીલ સ્કોરિંગ + શૂન્ય-કૉન્ફિગરેશન ઑટો-રાઉટિંગ સાથે સ્વ-વ્યવસ્થાપિત મોડેલ શૃંખલાઓ ## ઝીરો-કન્ફિગ ઑટો-રાઉટિંગ (`auto/` પ્રિફિક્સ) > **નવું:** કોમ્બો બનાવવાની જરૂર નથી. કોઈપણ ક્લાયન્ટમાં સીધો `auto/` પ્રિફિક્સ વાપરો. ### ઝડપી ઉદાહરણો | મોડેલ ID | વેરિઅન્ટ | વર્તન | | -------------- | -------- | ------------------------------------------------------------------------ | | `auto` | ડિફૉલ્ટ | બધા કનેક્ટેડ પ્રોવાઇડર્સ, LKGP વ્યૂહરચના, સંતુલિત વેઇટ્સ | | `auto/coding` | કોડિંગ | ગુણવત્તા-પ્રથમ વેઇટ્સ, કોડ જનરેશન માટે યોગ્ય | | `auto/fast` | ઝડપી | ઓછી-લેટન્સીવાળી વેઇટેડ પસંદગી | | `auto/cheap` | સસ્તું | ખર્ચ-ઑપ્ટિમાઇઝ્ડ રાઉટિંગ (સૌથી ઓછો ખર્ચ પ્રથમ) | | `auto/offline` | ઑફલાઇન | સૌથી વધુ ક્વોટા ઉપલબ્ધતાવાળા પ્રોવાઇડર્સને પ્રાધાન્ય આપે છે | | `auto/smart` | સ્માર્ટ | વધુ સારા મોડેલ ડિસ્કવરી માટે ગુણવત્તા-પ્રથમ + ઉચ્ચ એક્સપ્લોરેશન દર (10%) | | `auto/lkgp` | lkgp | સ્પષ્ટ LKGP (ડિફૉલ્ટ `auto` જેવું જ) | | `auto/chaos` | કેઓસ | સમાંતર ફેન-આઉટ, દરેક પ્રોવાઇડર દીઠ એક મોડેલ (ફૉલ્ટ ઇન્જેક્શન નહીં) | ### કેટેગરી × ટિયર સંયોજન (`auto/:`) OpenRouter-શૈલીના સફિક્સ **કયા પ્રકારનો રૂટ** (કેટેગરી) છે તેને **તેને કેવી રીતે ઑપ્ટિમાઇઝ કરવો** (ટિયર) તેનાથી અલગ કરે છે, જેથી તમે તેમને સ્વતંત્ર રીતે સંયોજિત કરી શકો (#4235 Phase B, `open-sse/services/autoCombo/suffixComposition.ts`): - **કેટેગરીઝ** (ક્ષમતાના આધારે ઉમેદવાર પૂલ ફિલ્ટર કરો): `coding` · `reasoning` · `vision` · `chat` · `multimodal`. `vision`/`multimodal` વિઝન-સક્ષમ મોડેલ્સ જાળવી રાખે છે; `reasoning` રિઝનિંગ/થિંકિંગ મોડેલ્સ જાળવી રાખે છે. - **ટિયર્સ** (સ્કોરિંગ વેઇટ્સ / પૂલ ફિલ્ટર પસંદ કરો): `fast` (ઝડપી ડિલિવરી) · `cheap` (ઉપનામ `floor`, ખર્ચ-બચત) · `reliable` (સર્કિટ-બ્રેકર હેલ્થ + લેટન્સી સ્થિરતા) · `free` / `pro` (`classifyTier` દ્વારા મોડેલ ટિયર પ્રમાણે પૂલ ફિલ્ટર કરો — ફ્રી-ટિયર વિરુદ્ધ પ્રીમિયમ). | ઉદાહરણ | આમાં રિઝોલ્વ થાય છે | | ---------------------- | -------------------------------------------------------- | | `auto/coding:fast` | કોડિંગ પૂલ, ઓછી-લેટન્સીવાળા વેઇટ્સ | | `auto/coding:cheap` | કોડિંગ પૂલ, ખર્ચ-ઑપ્ટિમાઇઝ્ડ (ઉપનામ `auto/coding:floor`) | | `auto/reasoning:pro` | માત્ર રિઝનિંગ/થિંકિંગ મોડેલ્સ, પ્રીમિયમ ટિયર | | `auto/vision` | વિઝન-સક્ષમ મોડેલ્સ (કોઈ ટિયર નહીં → સંતુલિત વેઇટ્સ) | | `auto/multimodal:free` | મલ્ટિમોડલ-સક્ષમ મોડેલ્સ, માત્ર ફ્રી ટિયર | કોઈપણ માન્ય `auto/[:]` જરૂર પડ્યે રિઝોલ્વ થાય છે; પસંદગીપૂર્વક તૈયાર કરેલો ઉપસેટ `/v1/models` અને ડેશબોર્ડમાં દર્શાવવામાં આવે છે (`open-sse/services/autoCombo/builtinCatalog.ts` માં `AUTO_SUFFIX_VARIANTS`). ફિલ્ટરિંગ **ફેલ-ઓપન** છે — જો કોઈ નિયંત્રણ સાથે કોઈ કનેક્ટેડ મોડેલ મેળ ન ખાય, તો સંપૂર્ણ પૂલ વપરાય છે, જેથી રાઉટિંગ ક્યારેય બંધ ન થાય. કોર સ્કોરર (`combo.ts`) યથાવત્ છે; કેટેગરી/ટિયર ફિલ્ટર `buildAutoCandidates` માં લાગુ થાય છે. > **લાઇવ મોડેલ ઇન્ટેલિજન્સ:** `ARENA_ELO_SYNC_ENABLED` ફ્લૅગ ચાલુ હોય ત્યારે ઑટો-રાઉટિંગની યોગ્યતા લાઇવ **Arena ELO** રેન્કિંગ્સ + **models.dev** ટિયર ડેટા દ્વારા નિર્ધારિત થાય છે (અન્યથા સ્ટેટિક ફિટનેસ મેપ પર ફૉલબૅક થાય છે). **ઉપયોગ કરવાની રીત:** ```bash # OpenAI ફોર્મેટને સપોર્ટ કરતું કોઈપણ IDE અથવા CLI ટૂલ Base URL: http://localhost:20128/v1 API Key: <તમારી-એન્ડપોઇન્ટ-કી> # તમારા કોડ/કન્ફિગમાં મોડેલ આ પ્રમાણે સેટ કરો: model: "auto" # સંતુલિત ડિફૉલ્ટ model: "auto/coding" # કોડિંગ કાર્યો માટે શ્રેષ્ઠ model: "auto/fast" # સૌથી ઝડપી ઉપલબ્ધ model: "auto/cheap" # પ્રતિ ટોકન સૌથી સસ્તું ``` **શું થાય છે:** 1. OmniRoute `src/sse/handlers/chat.ts` માં `auto/` પ્રિફિક્સ શોધે છે 2. ડેટાબેઝમાંથી બધા **સક્રિય પ્રોવાઇડર કનેક્શન્સ** ક્વેરી કરે છે 3. માન્ય ક્રેડેન્શિયલ્સ (API કી અથવા OAuth ટોકન) ધરાવતાં કનેક્શન્સ સુધી ફિલ્ટર કરે છે 4. દરેક કનેક્શન માટે મોડેલ નક્કી કરે છે (`connection.defaultModel` અથવા પ્રોવાઇડરનું પ્રથમ મોડેલ) 5. મેમરીમાં **વર્ચ્યુઅલ કોમ્બો** બનાવે છે (DB માં સંગ્રહિત થતો નથી) 6. પસંદ કરેલા વેરિઅન્ટની વેઇટ પ્રોફાઇલ + LKGP વ્યૂહરચનાનો ઉપયોગ કરીને રાઉટ કરે છે **મુખ્ય ગુણધર્મો:** - ✅ **હંમેશા ચાલુ:** કોઈ ટૉગલ, કોમ્બો બનાવવાની કે કન્ફિગરેશનની જરૂર નથી - ✅ **ડાયનેમિક:** વર્તમાન કનેક્ટેડ પ્રોવાઇડર્સને આપમેળે પ્રતિબિંબિત કરે છે - ✅ **સેશન સ્ટિકીનેસ:** LKGP છેલ્લે સફળ થયેલા પ્રોવાઇડરને પ્રાથમિકતા મળે તેની ખાતરી કરે છે - ✅ **મલ્ટિ-એકાઉન્ટ અવેર:** દરેક પ્રોવાઇડર કનેક્શન અલગ ઉમેદવાર બને છે - ✅ **કોઈ DB રાઇટ્સ નહીં:** વર્ચ્યુઅલ કોમ્બો માત્ર રિક્વેસ્ટ માટે જ અસ્તિત્વમાં રહે છે, કોઈ પર્સિસ્ટન્સ ઓવરહેડ નહીં ### પ્રતિ-કી ઉમેદવાર નિયંત્રણ (#7819, લેવલ 1+2) `GET /v1/auto-combo/{channel}/candidates` (`{channel}` = `auto/` પછીનો સફિક્સ, અથવા બેઝ ચૅનલ માટે લિટરલ `auto`) એક **રીડ-ઓનલી** એન્ડપોઇન્ટ છે, જે હાલની રેઝિલિયન્સ રીડ્સનો પુનઃઉપયોગ કરીને લાઇવ રીચેબિલિટી સાથે સજ્જ `auto/*` ચૅનલના વર્તમાન ઉમેદવાર પૂલની યાદી આપે છે (ક્યારેય સીધી બ્રેકર `state` નહીં): - પ્રોવાઇડર સર્કિટ બ્રેકર — `getCircuitBreaker(provider).getStatus()` / `.canExecute()` - કનેક્શન કૂલડાઉન — રિઝોલ્વ કરેલી `provider_connections` રોમાં `rateLimitedUntil` / `testStatus` - મોડેલ લૉકઆઉટ — `isModelLocked(provider, connectionId, model)` દરેક ઉમેદવાર આ API કીનો `excluded` ફ્લૅગ પણ ધરાવે છે. બાકાતીઓ પ્રતિ-API-કી (`auto_candidate_overrides` ટેબલ, માઇગ્રેશન `128`) સંગ્રહિત થાય છે — OmniRoute એકલ-ટેનન્ટ છે અને તેમાં કોઈ `users` ટેબલ નથી, તેથી `apiKeyId` વાસ્તવિક પ્રતિ-કૉલર ઓળખની સૌથી નજીકની વસ્તુ છે — અને શુદ્ધ, યુનિટ-ટેસ્ટેડ `filterExcludedCandidates()` (`open-sse/services/autoCombo/candidateOverrides.ts`) દ્વારા `open-sse/services/autoCombo/virtualFactory.ts` માં ઉમેદવાર-પૂલના ચોકપોઇન્ટ પર લાગુ કરવામાં આવે છે. ફિલ્ટર **ફેલ-ઓપન** છે: સેટ ન કરેલું apiKeyId/channel અથવા DB લુકઅપ નિષ્ફળતા, બંને પૂલને ફિલ્ટર કર્યા વિના જ રાખે છે, જેથી કોઈ ઓવરરાઇડ્સ કન્ફિગર ન કરેલા ઑપરેટરને આ સુવિધા પહેલાંના રાઉટિંગ સાથે બાઇટ-સમાન વર્તન મળે છે. **અનુવર્તી ઇશ્યૂ માટે મુલતવી રાખેલું:** પ્રતિ-કૅન્ડિડેટ વેઇટ્સ + સ્પષ્ટ ક્રમ (Level 3 — હાલના વેઇટેડ/પ્રાયોરિટી સ્ટ્રેટેજી પાથ્સમાં ફીડ થાય છે) અને દરેક `auto/*` ચૅનલ માટે ચોક્કસ `combo.ts` સ્ટ્રેટેજી પિન કરવી (Level 4). સિંગલ-ટેનન્ટ મોડેલને ધ્યાનમાં રાખીને ઓવરરાઇડ્સ પ્રતિ-API-key રહેવા જોઈએ કે ગ્લોબલ બનવા જોઈએ તે ખુલ્લા પ્રશ્ન માટે #7819 પ્લાન જુઓ. **પડદા પાછળ:** ```txt વિનંતી: { model: "auto/coding" } ↓ src/sse/handlers/chat.ts પ્રિફિક્સ શોધે છે ↓ createVirtualAutoCombo('coding') → સક્રિય કનેક્શન્સમાંથી candidatePool ↓ handleComboChat (પર્સિસ્ટેડ કોમ્બોઝ જેવું જ એન્જિન) ↓ ઓટો-સ્કોરિંગ દરેક વિનંતી માટે શ્રેષ્ઠ પ્રોવાઇડર/મોડેલ પસંદ કરે છે ``` **ઇમ્પ્લિમેન્ટેશન ફાઇલો:** | ફાઇલ | હેતુ | | --------------------------------------------------------- | ----------------------------------------------- | | `open-sse/services/autoCombo/autoPrefix.ts` | પ્રિફિક્સ પાર્સર (`parseAutoPrefix`) | | `open-sse/services/autoCombo/virtualFactory.ts` | વર્ચ્યુઅલ `AutoComboConfig` ઑબ્જેક્ટ્સ બનાવે છે | | `open-sse/services/autoCombo/providerRegistryAccessor.ts` | પ્રોવાઇડર રજિસ્ટ્રીને મૉક કરવા માટે ટેસ્ટ હૂક | | `src/sse/handlers/chat.ts` | ઇન્ટિગ્રેશન: ઑટો પ્રિફિક્સ શૉર્ટ-સર્કિટ | | `src/shared/constants/providers.ts` | `SYSTEM_PROVIDERS.auto` સિસ્ટમ એન્ટ્રી | ## વાસ્તવિક Model Id સાથે મેળ ખાતાં Combo નામો જે combo નું `name` કોઈ bare model id જેવું જ હોય (દા.ત. `gpt-5.5` નામનું combo), તે કોઈ bug નહીં પરંતુ **ઇરાદાપૂર્વકની, સમર્થિત પેટર્ન** છે: આ [#6940](https://github.com/diegosouzapw/OmniRoute/issues/6940)માં દસ્તાવેજીકૃત, દરેક model id માટેના provider fallback ની કાર્યપદ્ધતિ છે. bare-model-id resolution પહેલાં combo resolution તપાસવામાં આવતું હોવાથી (`src/sse/services/model.ts`માં `getComboForModel()`), bare id `gpt-5.5` માટેની request સીધી એક provider પાસે જવાને બદલે combo ના targets (દા.ત. `acme-responses/gpt-5.5`, `backup-responses/gpt-5.5`) મારફતે route થાય છે — આ [#3227/#3233](https://github.com/diegosouzapw/OmniRoute/issues/3227) માટે બનાવવામાં આવેલી combo-before-rewrite precedence નો ફરી ઉપયોગ કરે છે અને તેનું regression પરીક્ષણ `tests/unit/responses-combo-resolution-3227.test.ts` તથા `tests/unit/combo-name-codex-responses-rewrite.test.ts` દ્વારા કરવામાં આવે છે. વાસ્તવિક model id ને shadow કરતું નામ ધરાવતું combo બનાવવું અથવા તેનું નામ બદલવું **ક્યારેય નકારવામાં આવતું નથી** — આમ કરવાથી આ દસ્તાવેજીકૃત workflow તૂટી જશે. તેના બદલે (#8530), જ્યારે (નવું) નામ કોઈ વાસ્તવિક model id સાથે અથડાય ત્યારે `POST /api/combos` અને `PUT /api/combos/[id]` response સાથે non-blocking `warning` field જોડે છે: ```json { "warning": { "code": "COMBO_NAME_SHADOWS_MODEL", "modelId": "gpt-5.5", "providerId": "openai" } } ``` Boot સમયે, `scanComboModelNameCollisionsAtBoot()` (`src/instrumentation-node.ts`) પણ model id ને shadow કરતા દરેક હાલના combo ની યાદી આપતી એક-લાઇનની `[STARTUP]` warning log કરે છે, જેથી આ સ્થિતિમાં આકસ્મિક રીતે પહોંચેલા operators ને સંકેત મળે (જાણતાં કરેલા ઉપયોગથી વિપરીત, #6940 મુજબ). Detection helper `src/lib/combos/modelNameCollision.ts`માં આવેલો છે. ## Clientમાંથી Custom Combo ને Call કરવું Persisted combos (Settings → Combos) નો ઉપયોગ માત્ર ત્યારે થાય છે જ્યારે client `model` field માં combo નું **ચોક્કસ નામ** મોકલે — combo નામ માટે કોઈ fuzzy અથવા partial matching થતું નથી અને કોઈ `auto/` prefix પણ સામેલ નથી. Resolution ક્રમ (`src/sse/services/model.ts`માં `getComboForModel()`): 1. combo નામનો ચોક્કસ match (`model: "my-combo"`), 2. `combo/` prefix (`model: "combo/my-combo"`), 3. model→combo glob mappings (`/api/model-combo-mappings`). ```bash curl -X POST http://localhost:20128/v1/chat/completions \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"model":"my-combo","messages":[{"role":"user","content":"Hello"}]}' ``` બે સામાન્ય ભૂલો: - **`auto` તમારા combos નો ઉપયોગ કરતું નથી.** `auto`/`auto/*` પોતાનો zero-config candidate pool બનાવે છે અને માત્ર ત્યારે જ persisted combos તપાસે છે જ્યારે કોઈ combo નું નામ ખરેખર `auto` હોય (આ ભલામણપાત્ર નથી). Combo મારફતે route કરવા માટે તેનું ચોક્કસ નામ મોકલો — `auto` નહીં. - **`openrouter/auto` એક વાસ્તવિક, ચૂકવણીપાત્ર OpenRouter product** ("Auto Best Available") છે, OmniRoute alias નથી. તે OpenRouter registry (`open-sse/config/providers/registry/openrouter/index.ts`) ની એકમાત્ર static model entry છે અને તેનું billing અલગથી થાય છે. તેને `auto` pools માંથી બાકાત રાખવા માટે Settings → Routing → Hide paid models નો ઉપયોગ કરો. આ દસ્તાવેજીકરણ જેના વિશેની મૂળ ગેરસમજને સ્પષ્ટ કરે છે તે માટે [#7992](https://github.com/diegosouzapw/OmniRoute/issues/7992) અને [#7111](https://github.com/diegosouzapw/OmniRoute/issues/7111) જુઓ. ## તે કેવી રીતે કાર્ય કરે છે (સંગ્રહિત ઑટો-કોમ્બોઝ) ઑટો-કોમ્બો એન્જિન દરેક વિનંતી માટે શ્રેષ્ઠ પ્રદાતા/મૉડલને ગતિશીલ રીતે પસંદ કરવા માટે **16-પરિબળ સ્કોરિંગ ફંક્શન**નો ઉપયોગ કરે છે (`open-sse/services/autoCombo/scoring.ts` → `DEFAULT_WEIGHTS`માં વ્યાખ્યાયિત). ડિફૉલ્ટ વેઇટ્સનો સરવાળો `1.0` થાય છે; કસ્ટમ વેઇટ્સને `normalizeScoringWeights()` દ્વારા ફરી સામાન્યકૃત કરવામાં આવે છે. સોળમાંથી બે — `cacheAffinity` અને `resetWindowAffinity` — નું ડિફૉલ્ટ વેઇટ `0` છે; `reliability`નું `DEFAULT_WEIGHTS`માં વેઇટ `0` છે, પરંતુ સામાન્ય પૅક્સમાં `0.03` અને `reliability-first`માં `0.04` છે, જ્યારે `quality`નું પૅક્સમાં વેઇટ `0.02` (`quality-first`માં `0.03`) છે: તેમ છતાં, દરેક ઉમેદવાર માટે તેમની ગણતરી કરવામાં આવે છે, અને `cacheAffinity` સ્કોરની બહાર પ્રૉમ્પ્ટ-કૅશ ડિડુપ્લિકેશનને નિયંત્રિત કરે છે, તેથી શૂન્ય-ડિફૉલ્ટ પરિબળો ડિફૉલ્ટ રૂપે મત આપતા નથી, જ્યારે પૅક્સ આપે છે. ![ઑટો-કોમ્બો 16-પરિબળ સ્કોરિંગ](../diagrams/exported/auto-combo-scoring.svg) > સ્ત્રોત: [diagrams/auto-combo-scoring.mmd](../diagrams/auto-combo-scoring.mmd) (`npm run docs:render-diagrams` દ્વારા ફરી જનરેટ કરો). ફાઇલનું નામ ઐતિહાસિક છે; સ્ત્રોત અને રેન્ડર કરેલો ડાયાગ્રામ `DEFAULT_WEIGHTS`માં જાહેર કરાયેલા તમામ 16 પરિબળો દર્શાવે છે. | પરિબળ | ડિફૉલ્ટ વેઇટ | વર્ણન | | :-------------------- | :----------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `quota` | 0.1429 | બાકી રહેલો ક્વોટા / રેટ-લિમિટ હેડરૂમ [0..1] | | `health` | 0.1605 | સર્કિટ બ્રેકરમાંથી મળતો હેલ્થ સ્કોર (CLOSED=1.0, HALF_OPEN=0.5, OPEN=0.0) | | `costInv` | 0.1429 | **મિશ્રિત** ખર્ચનો વ્યસ્તાંક (60% ઇનપુટ + 40% આઉટપુટ ટોકન કિંમત, સામાન્યકૃત) — ઓછો ખર્ચ = ઊંચો સ્કોર | | `latencyInv` | 0.1143 | પૂલ અનુસાર સામાન્યકૃત p95 લેટન્સીનો વ્યસ્તાંક — વધુ ઝડપી = ઊંચો સ્કોર | | `taskFit` | 0.0762 | કાર્ય-પ્રકારની યોગ્યતા (કોડિંગ, સમીક્ષા, આયોજન, વિશ્લેષણ, ડિબગિંગ, દસ્તાવેજીકરણ) | | `stability` | 0.0476 | લેટન્સીના પ્રમાણભૂત વિચલન પરથી મળતી વેરિઅન્સ-આધારિત સ્થિરતા — જે ઉમેદવારના પ્રતિસાદ સમયમાં વધુ વધઘટ થાય તેનો સ્કોર ઓછો રહે છે | | `tierPriority` | 0.0476 | એકાઉન્ટ-ટિયર પ્રાથમિકતા — Ultra=1.0, Pro=0.67, Standard=0.33, Free=0.0 | | `tierAffinity` | 0.0476 | ઉમેદવારના ટિયર અને મેનિફેસ્ટ દ્વારા ભલામણ કરાયેલા ટિયર વચ્ચેની અનુકૂળતા | | `specificityMatch` | 0.0476 | વિનંતીની વિશિષ્ટતા (મેનિફેસ્ટ સંકેત) અને મૉડલ ટિયર વચ્ચેનો મેળ | | `contextAffinity` | 0.0476 | વિનંતીની કૉન્ટેક્સ્ટ-વિન્ડોની જરૂરિયાત અને મૉડલની કૉન્ટેક્સ્ટ વિન્ડો વચ્ચેની અનુકૂળતા | | `sessionAvailability` | 0.0476 | આ સેશન માટે ઉમેદવાર કનેક્શનના OAuth સેશનની ઉપલબ્ધતા (`getOAuthSessionAvailability()`; બિન-OAuth કનેક્શન્સને 1.0 સ્કોર મળે છે) | | `connectionDensity` | 0.0476 | એક જ પ્રદાતાનાં કનેક્શન્સમાં લોડ ફેલાવે છે (સંકેન્દ્રણ-વિરોધી) | | `cacheAffinity` | 0.00 | આ વિનંતીનો પ્રૉમ્પ્ટ-કૅશ પ્રીફિક્સ પહેલેથી ધરાવવાની સૌથી વધુ સંભાવના ધરાવતા કનેક્શન તરફની Rendezvous-hash અનુકૂળતા (`open-sse/services/combo/promptCacheAffinity.ts`); ડિફૉલ્ટ રૂપે અક્ષમ (#8008) | | `resetWindowAffinity` | 0.00 | જે કનેક્શન્સની ક્વોટા રીસેટ વિન્ડો અનુકૂળ હોય તેમની તરફ ઝોક (ડિફૉલ્ટ રૂપે અક્ષમ) | | `quality` | 0.03 | રૂટિંગ-ઇવેન્ટ ક્વૉલિટી ટ્રૅકરમાંથી મળતો પ્રતિસાદ-આધારિત આઉટપુટ-ગુણવત્તા સંકેત; અવલોકનો વિનાના ઉમેદવારોને તટસ્થ 0.5 મળે છે | | `reliability` | 0.00 | દસ-નમૂનાની ન્યૂનતમ મર્યાદા હેઠળના 24 કલાકના ઉપયોગ ઇતિહાસમાંથી અવલોકિત સફળતાનો હિસ્સો, `1 - failureRate` (અન્યથા રિયલ-ટાઇમ મેટ્રિક્સ); કોઈ અવલોકન ન ધરાવતા ઉમેદવારો માટે મૂલ્ય 1.0 ગણાય છે. ડિફૉલ્ટ રૂપે અક્ષમ | `quality` (`open-sse/services/routing/quality.ts`): `cold restart → ∅`; `observations = 0 → score 0.5`. **સરવાળો:** `0.1429 + 0.1605 + 0.1429 + 0.1143 + 0.0762 + (7 × 0.0476) + 0.00 + 0.00 + 0.03 + 0.00 = 1.0`, જેમ `DEFAULT_WEIGHTS`માં જાહેર કરાયું છે; વપરાશકર્તા દ્વારા રૂપરેખાંકિત વેઇટ્સને સ્કોરિંગ પહેલાં `normalizeScoringWeights()` દ્વારા વિતરણમાં ફરી સામાન્યકૃત કરવામાં આવે છે. ## મોડ પૅક્સ `open-sse/services/autoCombo/modePacks.ts` માં 6 પૂર્વ-નિર્ધારિત વેઇટ પ્રોફાઇલ્સ છે. દરેક પૅક ડિફૉલ્ટ વેઇટ્સને સંપૂર્ણપણે બદલીને પસંદગીને એક લક્ષ્ય તરફ ઝુકાવે છે. દરેક પૅકનો કુલ સરવાળો પહેલેથી જ `1.0` (ચાર દશાંશ સુધી પ્રિન્ટ કરતાં `0.9999`) થાય છે, તેથી જ્યારે કોઈ પૅક સક્રિય હોય ત્યારે `normalizeScoringWeights()` પાસે સુધારવા માટે કંઈ અર્થપૂર્ણ હોતું નથી — નીચેના મૂલ્યો, રાઉન્ડિંગને ધ્યાનમાં લેતાં, સ્કોરર દ્વારા લાગુ કરવામાં આવતા મૂલ્યો જ છે. | પરિબળ | ship-fast | cost-saver | quality-first | offline-friendly | reliability-first | chaos-mode | | :-------------------- | :--------- | :--------- | :------------ | :--------------- | :---------------- | :--------- | | `quota` | 0.1133 | 0.1133 | 0.0752 | **0.3324** | 0.1133 | 0.0376 | | `health` | 0.2667 | 0.1810 | 0.1714 | 0.2667 | **0.3524** | **0.4000** | | `costInv` | 0.0276 | **0.3324** | 0.0276 | 0.0752 | 0.0181 | 0.0140 | | `latencyInv` | **0.3048** | 0.0476 | 0.0476 | 0.0476 | 0.0476 | 0.0186 | | `taskFit` | 0.0952 | 0.0952 | **0.3524** | 0.0000 | 0.0952 | 0.1905 | | `stability` | 0.0000 | 0.0476 | 0.1429 | 0.0952 | 0.1905 | 0.1714 | | `tierPriority` | 0.0376 | 0.0376 | 0.0276 | 0.0376 | 0.0276 | 0.0040 | | `tierAffinity` | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | | `specificityMatch` | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | | `contextAffinity` | 0.0095 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0186 | | `sessionAvailability` | 0.0476 | 0.0476 | 0.0476 | 0.0476 | 0.0476 | 0.0476 | | `resetWindowAffinity` | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | | `connectionDensity` | 0.0476 | 0.0476 | 0.0476 | 0.0476 | 0.0476 | 0.0476 | | `quality` | 0.02 | 0.02 | **0.03** | 0.02 | 0.02 | 0.02 | | `reliability` | 0.03 | 0.03 | 0.03 | 0.03 | **0.04** | 0.03 | નોંધો: - **પૅક્સમાં `quality` અને `reliability` સામેલ છે** (`quality 0.02`, `quality-first 0.03`; `reliability 0.03`, `reliability-first 0.04`) અને તેઓ વેઇટ મૅપને સંપૂર્ણપણે બદલે છે (`weights = pack`, મર્જ નહીં). `DEFAULT_WEIGHTS` માં `quality 0.03 / reliability 0` છે; `balanced`/`default` પસંદ કરવાથી તે ડિફૉલ્ટ્સ જળવાય છે, જ્યારે કોઈ પૅક પસંદ કરવાથી ઉપરના પૅકના મૂલ્યો વપરાય છે. કોલ્ડ પૂલમાં (હજી સુધી કોઈ અવલોકનો નથી, તેથી `quality 0.5` અને `reliability 1`) આ બે પરિબળો સામાન્ય પૅક હેઠળ `+0.04` (`0.03 + 0.01`), `quality-first` હેઠળ `+0.045` અને `reliability-first` હેઠળ `+0.05` ઉમેરે છે. - દરેક પૅકમાં `tierAffinity`, `specificityMatch` અને `resetWindowAffinity` સ્પષ્ટપણે `0` છે. - દરેક પૅકના ભાર પર એક નજર: - **ship-fast** → latencyInv 0.3048 + health 0.2667 (ઓછી લેટન્સીવાળા, સ્વસ્થ કનેક્શન્સ) - **cost-saver** → costInv 0.3324 (સૌથી સસ્તા ટોકન્સ જીતે છે) - **quality-first** → taskFit 0.3524 + stability 0.1429 + quality 0.03, જે કોઈપણ પૅકમાં સર્વોચ્ચ છે (કાર્ય માટેનું શ્રેષ્ઠ, સુસંગત મોડલ) - **offline-friendly** → quota 0.3324 + health 0.2667 (ઝડપ/ખર્ચને ધ્યાનમાં લીધા વિના મહત્તમ હેડરૂમ) - **reliability-first** → health 0.3524 + stability 0.1905 + reliability 0.04, જે કોઈપણ પૅકમાં સર્વોચ્ચ છે (સૌથી ઓછી અનપેક્ષિત ઘટનાઓ) - **chaos-mode** → health 0.4000 + taskFit 0.1905 (વેઇટ પૅક `auto/chaos` તેના પૅનલ સભ્યોને ફાળવે છે; સમાનાંતર ફૅન-આઉટ આ વેઇટ્સ વાંચતું નથી અને આ ફૉલ્ટ-ઇન્જેક્શન પ્રોફાઇલ નથી, જુઓ [CHAOS-MODE.md](../guides/CHAOS-MODE.md#autochaos-parallel-fan-out)) ### પ્રતિ-વિનંતી નિયંત્રણો (હેડર્સ) — #6023 / #6024 / #6025 / #3470 સંગ્રહિત કોમ્બોના કૉન્ફિગમાં ફેરફાર કર્યા વિના, ત્રણ હેડર્સ મારફતે `auto` કોમ્બોને **દરેક વિનંતી માટે** નિયંત્રિત કરી શકાય છે. આ ફક્ત `auto` વ્યૂહરચના અને ફક્ત તે હેડર્સ ધરાવતી વિનંતીને લાગુ પડે છે; જ્યારે હેડર ગેરહાજર હોય ત્યારે કોમ્બોના સાચવેલા `modePack`/`budgetCap`/`budgetFallback` નો ઉપયોગ થાય છે. | હેડર | સ્વીકારે છે | અસર | | :---------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `X-OmniRoute-Mode` | પ્રીસેટ ઉપનામ (`fast`, `balanced`, `quality`, `cheap`, `reliable`, `offline`) અથવા મૂળ પૅક નામ (`ship-fast`, `cost-saver`, `quality-first`, `offline-friendly`, `reliability-first`) | આ વિનંતી માટે સ્કોરિંગ વજનોને ઓવરરાઇડ કરે છે. `balanced`/`default` ડિફૉલ્ટ વજનો લાગુ કરે છે (કોઈ પૅક નહીં). અજ્ઞાત મૂલ્યો અવગણવામાં આવે છે (રૂપરેખાંકન જાળવી રાખવામાં આવે છે). | | `X-OmniRoute-Budget` | ધન સંખ્યા (વિનંતીદીઠ મહત્તમ USD) | સખત ખર્ચ મર્યાદા: જે ઉમેદવારોનો અંદાજિત ખર્ચ તેને ઓળંગે છે તેમને પસંદગી પહેલાં ફિલ્ટર કરવામાં આવે છે. જ્યારે **દરેક** ઉમેદવાર તેને ઓળંગે ત્યારે શું થાય છે તે નીચે આપેલા `X-OmniRoute-Budget-Fallback` દ્વારા નિયંત્રિત થાય છે. | | `X-OmniRoute-Budget-Fallback` | `cheapest` (ડિફૉલ્ટ, ઉપનામો: `cheapest-viable`, `soft`) અથવા `strict` (ઉપનામો: `block`, `hard`) | `cheapest`: મર્યાદા હજુ પણ ઓળંગાતી હોવા છતાં વૈશ્વિક સ્તરે સૌથી સસ્તા ઉમેદવારનો ફૉલબૅક તરીકે ઉપયોગ કરે છે (જૂનું વર્તન). `strict`: પસંદગી કરવાનો ઇનકાર કરે છે — મૌન રીતે વધુ ખર્ચ કરવાને બદલે વિનંતી `HTTP 402` સાથે તરત નિષ્ફળ જાય છે. અજ્ઞાત મૂલ્યો અવગણવામાં આવે છે. | | `X-OmniRoute-Effort` | `auto` (અન્ય મૂલ્યો અનામત છે) | અનુકૂલનશીલ વિચારણા બજેટ: જ્યારે વિનંતીમાં કોઈપણ સ્વરૂપનું **કોઈ** reasoning ફીલ્ડ (`reasoning_effort`, `reasoning`, `thinking`) ન હોય, ત્યારે ગેટવે નિર્ધારિત વિનંતી-આકાર સંકેતો (છેલ્લા વપરાશકર્તા સંદેશની લંબાઈ, છેલ્લા વપરાશકર્તા સંદેશ સુધીનું સંદર્ભ કદ, અગાઉનાં ટૂલ પરિણામો, ટૂલ-લૂપની ઊંડાઈ) પરથી `auto` ને `low`/`medium`/`high` તરીકે ઉકેલે છે. સંકેતો વર્તમાન ટર્ન પૂરતા મર્યાદિત છે — છેલ્લા વપરાશકર્તા સંદેશ પછીની દરેક વસ્તુ અવગણવામાં આવે છે — તેથી ટૂલ લૂપમાંની દરેક વિનંતી સમાન સ્તર પર ઉકેલાય છે (સ્ટેટલેસ પ્રતિ-ટર્ન પિન, કોઈ સેશન સ્ટેટ નહીં, અને અપસ્ટ્રીમ પ્રોમ્પ્ટ-કૅશ પ્રીફિક્સને તોડી નાખે તેવી લૂપની મધ્યમાં કોઈ વૃદ્ધિ નહીં). ક્લાયન્ટ દ્વારા સ્પષ્ટ રીતે આપેલું reasoning ફીલ્ડ હંમેશાં પ્રાધાન્ય મેળવે છે. આ માત્ર એવી વિનંતીઓ પર લાગુ પડે છે, જેમનું અપસ્ટ્રીમ ડિસ્પેચ OpenAI Chat Completions સ્વરૂપમાં ઉકેલાય છે (`targetFormat === FORMATS.OPENAI`) — `reasoning_effort` એ OpenAI-સ્વરૂપનું ફીલ્ડ છે, તેથી Claude- અથવા Gemini-લક્ષિત વિનંતી પર આ હેડર કંઈ કરતું નથી (`open-sse/handlers/chatCore/adaptiveEffortWiring.ts` જુઓ). | ```bash # સૌથી ઝડપી પ્રોફાઇલ ફરજિયાત કરો, આ વિનંતીની મર્યાદા $0.05 રાખો, અને વધુ ખર્ચ કરવાને બદલે સખત રીતે અવરોધો curl -sS http://localhost:20128/v1/chat/completions \ -H "Content-Type: application/json" \ -H "X-OmniRoute-Mode: fast" \ -H "X-OmniRoute-Budget: 0.05" \ -H "X-OmniRoute-Budget-Fallback: strict" \ -d '{"model":"auto","messages":[{"role":"user","content":"hi"}]}' ``` ઉકેલ એ શુદ્ધ ફંક્શન (`open-sse/services/autoCombo/requestControls.ts`) છે; ઉકેલાયેલા મૂલ્યો એન્જિનના હાલના `config.modePack` / `config.budgetCap` / `config.budgetFallback` ઇનપુટ્સને આપવામાં આવે છે. કોમ્બોમાં સંગ્રહિત `config.budgetFallback` ("strict" | "cheapest") કાયમી નીતિ નક્કી કરે છે; હેડર એક વિનંતી માટે તેને ઓવરરાઇડ કરે છે. ## તમામ રાઉટિંગ વ્યૂહરચનાઓ OmniRouteનું કોમ્બો એન્જિન **20 રાઉટિંગ વ્યૂહરચનાઓ**ને સપોર્ટ કરે છે (`src/shared/constants/routingStrategies.ts` → `ROUTING_STRATEGY_VALUES`માં જાહેર કરેલી). Auto Combo એન્જિન પોતે `auto` વ્યૂહરચના હેઠળ ઉપલબ્ધ છે; બાકીની વ્યૂહરચનાઓ સંગ્રહિત કોમ્બો માટે ઉપલબ્ધ છે. | વ્યૂહરચના | વર્ણન | | :------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `priority` | સ્પષ્ટ પ્રાથમિકતા સાથેની પ્રથમ-લક્ષ્ય ક્રમબદ્ધ સૂચિ | | `weighted` | દરેક લક્ષ્યના વજન અનુસાર વેઇટેડ રેન્ડમ પસંદગી | | `round-robin` | ક્રમ પ્રમાણે લક્ષ્યોમાંથી ચક્રીય રીતે પસાર થવું (બેચમાં; નીચે જુઓ) | | `context-relay` | લક્ષ્યો વચ્ચે કોન્ટેક્સ્ટ સોંપવો (લાંબી વાતચીતો) | | `fill-first` | આગામી લક્ષ્ય પર જતાં પહેલાં દરેક લક્ષ્યનો ક્વોટા પૂરો વાપરવો | | `p2c` | 2-પસંદગીઓની શક્તિ આધારિત રેન્ડમ લોડ બેલેન્સિંગ | | `random` | એકસમાન રેન્ડમ પસંદગી | | `least-used` | હાલમાં સૌથી ઓછો લોડ ધરાવતું લક્ષ્ય પસંદ કરવું | | `cost-optimized` | કેટલોગ કિંમતને આધારે દરેક વિનંતી દીઠ $ ઘટાડવા | | `reset-aware` ⭐ | ક્વોટા રીસેટ સમય અનુસાર પ્રાથમિકતા આપવી — ટૂંકી રીસેટ વિન્ડોને ઊંચો ક્રમ મળે | | `reset-window` | એવા લક્ષ્યોને પ્રાધાન્ય આપવું જેમની ક્વોટા વિન્ડો સૌથી વહેલી રીસેટ થાય | | `headroom` | સૌથી વધુ બાકી ક્વોટા હેડરૂમ ધરાવતું લક્ષ્ય પસંદ કરવું | | `quota-weighted` | ક્વોટા ખૂટી ગયેલા એકાઉન્ટ છોડીને, બાકીનામાંથી ચાલુ વિનંતીઓના લોડ વડે ભાગેલા બાકી ક્વોટાના પ્રમાણમાં પસંદગી કરવી; હાલની વાતચીતો નિર્ધારિત લક્ષ્ય સાથે જોડાયેલી રહે | | `strict-random` | પુનરાવર્તનોનું ડિડુપ્લિકેશન કર્યા વિના રેન્ડમ પસંદગી | | `auto` | Auto Combo સ્કોરિંગ (16-પરિબળ) વાપરવું — **ભલામણ કરેલ** | | `lkgp` | છેલ્લો-જાણીતો-સારો પાથ (છેલ્લા સફળ પ્રોવાઇડર સાથે જોડાયેલું રાખે છે, પછી નિયમો પર ફૉલબૅક કરે છે) | | `context-optimized` | વર્તમાન કોન્ટેક્સ્ટ કદ માટે શ્રેષ્ઠ રીતે અનુરૂપ લક્ષ્ય પસંદ કરવું | | `cache-optimized` | પ્રોમ્પ્ટ-કૅશ સુસંગતતા અનુસાર લક્ષ્યોનો ક્રમ બદલવો — જે કનેક્શનમાં આ વિનંતીનો કૅશ કરેલો પ્રીફિક્સ પહેલેથી હોવાની સૌથી વધુ શક્યતા હોય તેને પ્રથમ અજમાવવામાં આવે છે (`open-sse/services/combo/promptCacheAffinity.ts`, #8008) | | `fusion` 🧬 | સમાંતરે મોડલોના પેનલને વિનંતી મોકલવી, પછી જજ દ્વારા એક જવાબ સંશ્લેષિત કરવો (નીચે જુઓ) | | `pipeline` | લક્ષ્યોને ક્રમશઃ ચલાવવા, દરેક પગલાનું આઉટપુટ આગામી પગલાના ઇનપુટમાં મોકલવું; ફક્ત અંતિમ જવાબ પરત કરવામાં આવે છે (#6396) | ⭐ = v3.8.0માં નવું · 🧬 = v3.8.36માં નવું ### `weighted`ની સિમેન્ટિક્સ `weighted` એ **દરેક વિનંતી દીઠ પ્રમાણસર રેન્ડમ ડ્રો** છે (`open-sse/services/combo/targetSorters.ts` → `selectWeightedTarget`), ઇક્વલાઇઝર નથી: - દરેક વિનંતી `weight / totalWeight` સંભાવના સાથે **એક** પગલું પસંદ કરે છે; બાકીનાં પગલાં તે વિનંતી માટે ફૉલબૅક શૃંખલા તરીકે વજનના ઉતરતા ક્રમમાં ગોઠવાય છે. - જે પગલાનું વજન `0` હોય (અથવા વજન ન આપેલું હોય), તે અન્ય કોઈપણ પગલાનું વજન > 0 હોય ત્યાં સુધી **ક્યારેય પસંદ થતું નથી** — પસંદ થયેલું પગલું નિષ્ફળ જાય પછી જ તે ફૉલબૅક તરીકે કામ કરી શકે છે. ફક્ત ત્યારે જ પસંદગી એકસમાન બને છે જ્યારે **તમામ** વજન 0 હોય. - જે પગલાંનાં તમામ લક્ષ્યો અનુપલબ્ધ હોય — પ્રોવાઇડર સર્કિટ બ્રેકર `OPEN`, કનેક્શન કૂલડાઉન, મોડલ લૉકઆઉટ — તેમને ડ્રો થાય તે પહેલાં જ તેમાંથી દૂર કરવામાં આવે છે (`open-sse/services/combo/targetResolution.ts`), તેથી એકમાત્ર સ્વસ્થ પગલું અસ્થાયી રૂપે દરેક વિનંતી જીતી શકે છે. - `stickyWeightedLimit` (કોમ્બો કન્ફિગ, ડિફૉલ્ટ `1` = બંધ) ફરીથી ડ્રો કરતાં પહેલાં પસંદ કરેલા પગલાને તેટલી સળંગ સફળતાઓ માટે નિર્ધારિત રાખે છે. ચુસ્ત રોટેશન માટે `round-robin` નો ઉપયોગ કરો; `weighted` પર સમાન વેઇટ આંકડાકીય સંતુલન આપે છે — ચુસ્ત સંતુલન નહીં. ### એજેન્ટિક પાઇપલાઇન મોડ ઓછામાં ઓછા બે મોડેલ ધરાવતું `pipeline` કૉમ્બો `config.agenticOrchestration.enabled` વડે પ્લાનર/એક્ઝિક્યુટર રાઉટિંગ પસંદ કરી શકે છે. પ્રથમ ટાર્ગેટ પ્લાનિંગ અને અંતિમ જવાબોની જવાબદારી સંભાળે છે; બીજો ટાર્ગેટ ક્લાયન્ટ-નેટિવ ટૂલ કૉલ્સ ઉત્પન્ન કરે છે. OmniRoute રિક્વેસ્ટ પ્રોટોકોલમાંથી ટૂલ-રિઝલ્ટ કન્ટિન્યુએશન્સ શોધે છે, પ્લાનરને પૂછે છે કે બીજો ટૂલ રાઉન્ડ જરૂરી છે કે નહીં, અને ક્લાયન્ટ સામેના અંતિમ સ્ટેપ તરીકે એક્ઝિક્યુટર અથવા પ્લાનરમાંથી કોઈ એકને ડાયનેમિક રીતે પસંદ કરે છે. બીજા ટાર્ગેટ પછીનાં વધારાના મોડેલ્સ ક્રમબદ્ધ એક્ઝિક્યુટર બૅકઅપ્સ હોય છે. નિષ્ફળ HTTP પ્રતિસાદ અથવા ટ્રાન્સપોર્ટ એક્સેપ્શન પર આગલા એક્ઝિક્યુટર તરફ આગળ વધવામાં આવે છે, જેમાં એ જ પ્લાનર નિર્ણય અને નેટિવ ટૂલ્સ સાથે લઈ જવામાં આવે છે, પરંતુ તે એક્ઝિક્યુટરનો પોતાનો સ્ટેપ પ્રોમ્પ્ટ અને રિઝોલ્વ થયેલું કનેક્શન વપરાય છે. પ્રથમ સફળ પ્રતિસાદ કોઈ ફેરફાર વિના પરત કરવામાં આવે છે, જેમાં SSE સ્ટ્રીમિંગ પણ સામેલ છે; સફળ સ્ટ્રીમ શરૂ થયા પછીની નિષ્ફળતાઓ માટે અહીં ફરી પ્રયાસ કરી શકાતો નથી. જો બધા એક્ઝિક્યુટર્સ નિષ્ફળ જાય, તો છેલ્લી નિષ્ફળતા પરત કરવામાં આવે છે. ક્લાયન્ટ અબોર્ટ્સ ડિસ્પૅચ અટકાવે છે. ```json { "strategy": "pipeline", "models": [{ "model": "provider/planner" }, { "model": "provider/executor" }], "config": { "agenticOrchestration": { "enabled": true, "maxToolRounds": 8 } } } ``` એક્ઝિક્યુટર એક પ્રતિસાદમાં અનેક સ્વતંત્ર કૉલ્સ ઉત્પન્ન કરી શકે છે. નિર્ભર કૉલ્સને પછીના ક્લાયન્ટ ટૂલ-રિઝલ્ટ ટર્ન્સમાં હેન્ડલ કરવામાં આવે છે, જેમાં પ્લાનર દરેક પરિણામની સમીક્ષા કરે છે. `maxToolRounds` નું ડિફૉલ્ટ મૂલ્ય `8` છે અને તે `1`–`32` સ્વીકારે છે; મર્યાદા પર પહોંચ્યા પછી, પ્લાનરે ઉપલબ્ધ શ્રેષ્ઠ અંતિમ જવાબ આપવો આવશ્યક છે. આંતરિક પ્લાનર નિર્ણયો બફર કરવામાં આવે છે, જ્યારે પસંદ કરેલો ક્લાયન્ટ-ફેસિંગ પ્રતિસાદ મૂળ સ્ટ્રીમિંગ પસંદગી જાળવી રાખે છે. ### `round-robin` સ્ટિકી બૅચ અને એકાઉન્ટ વિસ્તરણ Round-robin બૅચમાં કાર્ય કરે છે, દરેક સ્ટેપ દીઠ એક રિક્વેસ્ટ તરીકે નહીં: - `stickyRoundRobinLimit` (પહેલાં કૉમ્બો કન્ફિગ, પછી `comboStickyRoundRobinLimit`, પછી `settings.stickyRoundRobinLimit`, ડિફૉલ્ટ **3**) રોટેટ કરતા પહેલાં એટલી સળંગ સફળતાઓ સુધી એ જ ટાર્ગેટ જાળવી રાખે છે. દરેક રિક્વેસ્ટે રોટેશન માટે કૉમ્બો ઓવરરાઇડને `1` પર સેટ કરો. કૉમ્બો એડિટર અસરકારક મૂલ્ય અને તે કયા લેયરમાંથી આવ્યું છે તે દર્શાવે છે. - `connectionAwareExpansion` (પહેલાં કૉમ્બો કન્ફિગ, પછી સેટિંગ્સ, ડિફૉલ્ટ **false**) રોટેશન પહેલાં દરેક પ્રોવાઇડર-લેવલ સ્ટેપને દરેક એકાઉન્ટ માટેના અલગ ટાર્ગેટ્સમાં વિસ્તારે છે. Group-B સ્ટ્રેટેજીઝ (priority, weighted, round-robin, random, p2c, least-used, cost-optimized, lkgp, fill-first, strict-random, context-optimized, cache-optimized, context-relay, fusion, pipeline) આ ચાલુ ન થાય ત્યાં સુધી પ્રોવાઇડર-લેવલ વ્યૂ જાળવે છે. કૉમ્બો એડિટર inherit / on / off વિકલ્પો આપે છે; inherit વૈશ્વિક ડિફૉલ્ટ (off) વાપરે છે. - પ્રોમ્પ્ટ-કૅશ લોકૅલિટી રાઉટિંગ (`promptCacheAffinityEnabled`, ડિફૉલ્ટ **true**) પિન કરેલા કનેક્શન્સને ફરી ગોઠવે છે જેથી મેળ ખાતી કૅશ કીઝ એક જ એકાઉન્ટ પર રહે. પિન કરેલા દરેક-એકાઉન્ટ સ્ટેપ્સમાં તે round-robin અને weighted રોટેશન કરતાં અગ્રતા ધરાવે છે. જો તમને ચુસ્ત રોટેશનની જરૂર હોય, તો Settings → Combo defaults હેઠળ તેને બંધ કરો. દરેક કૉમ્બો માટે અલગ ઓવરરાઇડ ઉપલબ્ધ નથી. એક મોડેલ પર મલ્ટિ-એકાઉન્ટ રોટેશન માટે, ત્રણ પિન કરેલા `connectionId`s ને બદલે સ્ટિકી લિમિટ `1` સાથે **એક ડાયનેમિક-એકાઉન્ટ સ્ટેપ** (ખાલી `connectionId`, આખો પૂલ) પસંદ કરો. RR કાઉન્ટર આગળ વધતો હોય ત્યારે પણ પિન કરેલા સ્ટેપ્સ અને એફિનિટી એ જ એકાઉન્ટ પર એકત્રિત થઈ જાય છે. ## ફ્યુઝન વ્યૂહરચના `fusion` એ એકમાત્ર એવી વ્યૂહરચના છે જે કોઈ એક લક્ષ્ય પસંદ **કરતી નથી**. તે પ્રોમ્પ્ટને **દરેક પેનલ મોડેલને સમાંતર રીતે** મોકલે છે, ત્યારબાદ રૂપરેખાંકિત કરી શકાય તેવું **જજ મોડેલ** પેનલના તમામ પ્રતિસાદોમાંથી એક અંતિમ જવાબનું સંશ્લેષણ કરે છે. અપસ્ટ્રીમ `decolua/9router` (OpenRouterની Fusion ડિઝાઇન)માંથી પોર્ટ કરેલ; અમલીકરણ `open-sse/services/fusion.ts`માં છે. તે કેવી રીતે કાર્ય કરે છે: 0. **ટૂલ ધરાવતી વિનંતીનું બાયપાસ** — `tool_choice` સ્પષ્ટ રીતે `"none"` ન હોય અને ખાલી ન હોય તેવી `tools` ઍરે ધરાવતી વિનંતી પેનલને સંપૂર્ણપણે અવગણે છે: તે `tools`/`tool_choice`ને કોઈ ફેરફાર વિના પસાર કરીને સીધી એક મોડેલ (રૂપરેખાંકિત જજ, અથવા `panel[0]`) તરફ રાઉટ થાય છે. પેનલના સભ્યોને ટૂલની ઍક્સેસ હોતી નથી અને જજની સંશ્લેષણ સૂચના ટૂલ-કૉલ ઉત્પન્ન કરવાનું નિરુત્સાહિત કરે છે, તેથી એજન્ટિક/ટૂલ-કૉલિંગ ક્લાયન્ટ્સને સંશ્લેષિત ગદ્યને બદલે વાસ્તવિક ટૂલ-કૉલ નિર્ણય મળે છે (#6771). 1. **ફૅન-આઉટ** (ફક્ત ટૂલ ન ધરાવતી વિનંતીઓ) — પ્રોમ્પ્ટ એકસાથે દરેક પેનલ મોડેલને મોકલવામાં આવે છે, ટૂલ્સ દૂર કરીને નૉન-સ્ટ્રીમિંગ ફરજિયાત બનાવવામાં આવે છે (સંશ્લેષણ કરવા માટે જજને સંપૂર્ણ ગદ્યની જરૂર હોય છે). 2. **ક્વોરમ-ગ્રેસ સંગ્રહ** — `minPanel` જવાબો મળતાંની સાથે જ બાકી રહી ગયેલા મોડેલ્સ માટે એક ટૂંકું ગ્રેસ ટાઇમર શરૂ થાય છે, ત્યારબાદ જે કંઈ એકત્ર થયું હોય તેની સાથે ફ્યુઝન આગળ વધે છે. આ સૌથી ધીમા મોડેલને કારણે વૉલ ટાઇમ પર થતી અસરને મર્યાદિત કરે છે, જે હાર્ડ ટાઇમઆઉટ દ્વારા સીમિત હોય છે. 3. **જજ સંશ્લેષણ** — પેનલના જવાબોને અનામી બનાવવામાં આવે છે (`Source 1`, `Source 2`, … — જેથી જજ મોડેલની બ્રાન્ડને નહીં, પરંતુ વિષયવસ્તુને મહત્ત્વ આપે) અને જજને સોંપવામાં આવે છે, જે સર્વસંમતિ / વિરોધાભાસો / આંશિક આવરણ / અનન્ય આંતરદૃષ્ટિઓ / અજાણ્યા પાસાઓનું વિશ્લેષણ કરે છે, ત્યારબાદ **એક** અધિકૃત જવાબ લખે છે. જજ કૉલ ક્લાયન્ટનો મૂળ `stream` ફ્લૅગ + ટૂલ્સ જાળવી રાખે છે, જેથી સ્ટ્રીમિંગ અને ડાઉનસ્ટ્રીમ ટૂલનો ઉપયોગ હજી પણ કાર્ય કરે છે. 4. **સુગમ અવનતિ** — પેનલના 0 જવાબો → `503`; બરાબર 1 જવાબ બચે → તે જવાબ સીધો પરત કરવામાં આવે છે (ફ્યુઝ કરવા માટે કંઈ નથી); એક-મોડેલવાળી પેનલ સીધો જવાબ આપે છે. પેનલનો કોઈ સભ્ય `combo-ref` સ્ટેપ (`{kind: "combo-ref", comboName: "..."}`) પણ હોઈ શકે છે, જે અન્ય કૉમ્બોનો સંદર્ભ આપે છે — તે **એક બ્લૅક-બૉક્સ પેનલ અવાજ** તરીકે રિઝૉલ્વ થાય છે (સંદર્ભિત કૉમ્બોમાં સંપૂર્ણ રિકર્સિવ ડિસ્પૅચ, તે કૉમ્બોના પોતાના લક્ષ્યોનું ફૅન-આઉટ નહીં), અને અન્ય દરેક combo-ref વાપરતી વ્યૂહરચના પહેલેથી જ ઉપયોગ કરતી સમાન ઊંડાઈ/ચક્ર સુરક્ષા સાથે (#6764). ### રૂપરેખાંકન કૉમ્બોના `config` બ્લૉબ પર રૂપરેખાંકિત થાય છે (કોઈ સ્કીમા માઇગ્રેશન નહીં — તે હાલના `combos` ટેબલનો ફરી ઉપયોગ કરે છે): | ફીલ્ડ | પ્રકાર | ડિફૉલ્ટ | હેતુ | | :--------------------------------------- | :------- | :--------------- | :----------------------------------------------------------------------------- | | `config.judgeModel` | `string` | પ્રથમ પેનલ મોડેલ | અંતિમ જવાબનું સંશ્લેષણ કરતું મોડેલ | | `config.fusionTuning.minPanel` | `number` | `2` | ગ્રેસ ટાઇમર શરૂ થાય તે પહેલાં જરૂરી સફળ જવાબો (`[2, panelSize]` સુધી મર્યાદિત) | | `config.fusionTuning.stragglerGraceMs` | `number` | `8000` | ક્વોરમ પ્રાપ્ત થયા પછી મોડા પડનારા મોડેલ્સ માટે કેટલો સમય રાહ જોવી | | `config.fusionTuning.panelHardTimeoutMs` | `number` | `90000` | સંપૂર્ણ મર્યાદા, જેથી અટકી ગયેલું એક મોડેલ વિનંતીને વિલંબિત ન કરી શકે | ડિફૉલ્ટ્સ `FUSION_DEFAULTS` (`open-sse/services/fusion.ts`)માં છે. ### ઉદાહરણ ```bash curl -X POST http://localhost:20128/api/combos \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "name": "fusion-panel", "strategy": "fusion", "targets": [ { "model": "cc/claude-opus-4-7" }, { "model": "cx/gpt-5.5" }, { "model": "glm/glm-5.1" } ], "config": { "judgeModel": "cc/claude-opus-4-7", "fusionTuning": { "minPanel": 2, "stragglerGraceMs": 8000, "panelHardTimeoutMs": 90000 } } }' ``` પછી તેને અન્ય કોઈપણ કૉમ્બોની જેમ કૉલ કરો: `{"model":"fusion-panel","messages":[...]}`. ## વર્ચ્યુઅલ ઑટો-કોમ્બો ફેક્ટરી ઑટો કોમ્બો એન્જિનને પૂર્વનિર્ધારિત કોમ્બોની જરૂર પડતી નથી. તેના બદલે, `open-sse/services/autoCombo/virtualFactory.ts` તત્કાળ ઉમેદવારો બનાવે છે: 1. `getProviderConnections({ isActive: true })` (તમામ સક્ષમ કનેક્શનો) મેળવે છે 2. માન્ય ઓળખપત્રો ધરાવતા કનેક્શનો સુધી ફિલ્ટર કરે છે (API કી અથવા `hasUsableOAuthToken()` મારફતે સમાપ્ત ન થયેલ OAuth ટોકન) 3. મોડેલની ઉપલબ્ધતા + કિંમત માટે `getProviderRegistry()` સાથે ક્રોસ-રેફરન્સ કરે છે 4. દરેક ટ્યુપલ `(provider, model, connection)` માટે, એક `VirtualAutoComboCandidate` બનાવે છે 5. ડિસ્પેચ લક્ષ્ય તરીકે `connection.defaultModel` (અથવા રજિસ્ટ્રીનું પ્રથમ મોડેલ) પસંદ કરે છે 6. 16-પરિબળવાળા `scorePool()` અને વેરિઅન્ટના વેઇટ પૅકનો ઉપયોગ કરીને દરેક ઉમેદવારને સ્કોર આપે છે 7. `handleComboChat()` માટે પરિણામી ઇન-મેમરી `AutoComboConfig` પરત કરે છે — DBમાં ક્યારેય સંગ્રહિત કરતું નથી આનો અર્થ એ છે કે **`auto/*` સક્ષમ હોય તેવો નવો પ્રોવાઇડર ઉમેરવાથી ઉમેદવાર પૂલ આપમેળે વિસ્તરે છે** — કોઈ મેન્યુઅલ કોમ્બો સંપાદનની જરૂર નથી. વર્ચ્યુઅલ કોમ્બો દરેક વિનંતી માટે ફરી બનાવવામાં આવે છે, તેથી નવા ઉમેરાયેલા અથવા ફરી સ્વસ્થ બનેલા કનેક્શનો તરત જ પસંદ કરવામાં આવે છે. ## સ્વ-ઉપચાર - **અસ્થાયી બાકાતીકરણ**: સ્કોર < 0.2 → 5 મિનિટ માટે બાકાત (ક્રમશઃ વધતું બૅકઑફ, મહત્તમ 30 મિનિટ) - **સર્કિટ બ્રેકરની જાગરૂકતા**: OPEN → આપમેળે બાકાત; HALF_OPEN → પ્રોબ વિનંતીઓ - **ઘટના મોડ**: >50% OPEN → એક્સપ્લોરેશન અક્ષમ કરો, સ્થિરતા મહત્તમ કરો - **કૂલડાઉન પુનઃપ્રાપ્તિ**: બાકાતીકરણ પછી, પ્રથમ વિનંતી ઘટાડેલ ટાઇમઆઉટ સાથેની "પ્રોબ" હોય છે ## બૅન્ડિટ એક્સપ્લોરેશન 5% વિનંતીઓ (ગોઠવી શકાય તેવી) એક્સપ્લોરેશન માટે રૅન્ડમ પ્રોવાઇડર્સ તરફ રૂટ કરવામાં આવે છે. ઘટના મોડમાં અક્ષમ રહે છે. ## API અહીં **કોઈ સમર્પિત `POST /api/combos/auto` એન્ડપોઇન્ટ નથી** — Auto-Comboનો ઉપયોગ બે રીતે થાય છે: 1. **શૂન્ય-કન્ફિગ (ભલામણ કરેલ):** `model: "auto"` અથવા `model: "auto/"` સાથે કોઈપણ ચેટ કમ્પ્લીશન વિનંતી મોકલો. વર્ચ્યુઅલ ફેક્ટરી દરેક વિનંતી માટે કોમ્બો બનાવે છે — કોઈ પર્સિસ્ટન્સ કે API કૉલની જરૂર નથી. 2. **`strategy: "auto"` સાથે પર્સિસ્ટ કરાયેલ કોમ્બો:** `POST /api/combos` દ્વારા નિયમિત કોમ્બો બનાવો અને `strategy: "auto"` ઉપરાંત `config.auto.weights` / `config.auto.candidatePool` સેટ કરો. એ જ સ્કોરિંગ એન્જિનનો ઉપયોગ થાય છે; કોમ્બો `combos`માં સંગ્રહિત થાય છે અને ID દ્વારા ફરીથી ઉપયોગ કરી શકાય છે. ડિસ્કવરી માટે, `GET /api/combos/auto` દરેક વેરિઅન્ટને તેના રિઝોલ્વ થયેલા કેન્ડિડેટ પૂલ તેમજ `context_length` / `max_output_tokens` સાથે સૂચિબદ્ધ કરે છે — આ કેન્ડિડેટ પૂલની વિન્ડોઝમાંનું MAX છે. ક્લાયન્ટ્સે (દા.ત. opencode પ્લગઇન) `0`ને બદલે આ મૂલ્યો જાહેર કરવા આવશ્યક છે: શૂન્ય કોન્ટેક્સ્ટ opencodeના ઑટો-કમ્પેક્શનને સંપૂર્ણપણે નિષ્ક્રિય કરે છે, જેથી ગેટવેનું હિસ્ટ્રી પર્જ કોન્ટેક્સ્ટને નષ્ટ કરે ત્યાં સુધી સેશન્સ વધતા રહે છે. MAX જાહેર કરવું સુરક્ષિત છે, કારણ કે ઑટો-કોમ્બો કોન્ટેક્સ્ટ પ્રી-ફિલ્ટર વધુ કદની વિનંતીઓને મોટી-વિન્ડો ધરાવતા કેન્ડિડેટ્સ તરફ રૂટ કરે છે. ```bash # શૂન્ય-કન્ફિગ ઉપયોગ (કોમ્બો બનાવવાની જરૂર નથી) curl -X POST http://localhost:20128/v1/chat/completions \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"model":"auto/coding","messages":[{"role":"user","content":"Hello"}]}' # નિયમિત combos એન્ડપોઇન્ટ દ્વારા પર્સિસ્ટ કરાયેલ ઑટો કોમ્બો curl -X POST http://localhost:20128/api/combos \ -H "Content-Type: application/json" \ -d '{"id":"my-auto","name":"Auto Coder","strategy":"auto","config":{"auto":{"candidatePool":["anthropic","google","openai"],"weights":{"quota":0.15,"health":0.3,"costInv":0.05,"latencyInv":0.35,"taskFit":0.1,"stability":0,"tierPriority":0.05}}}}' ``` ### ઑટો રાઉટર સ્ટ્રેટેજીઝ પર્સિસ્ટ કરાયેલા `strategy: "auto"` કોમ્બોઝ `config.routerStrategy` (અથવા લેગસી `config.auto.routerStrategy`)ને નીચેનામાંથી એક પર સેટ કરી શકે છે: - `rules` — ડિફૉલ્ટ વેઇટેડ સ્કોરિંગ - `score` — સૌથી વધુ કન્ફિગર કરેલો વેઇટેડ સ્કોર પસંદ કરે છે. ચોક્કસ ટાઇના કિસ્સામાં કન્ફિગર કરેલો કેન્ડિડેટ ક્રમ જળવાય છે; હાલનો `explorationRate` સંપૂર્ણ રેન્ક કરેલા પૂલમાંથી સેમ્પલ કરે છે. - `cost` / `eco` — સૌથી સસ્તો સ્વસ્થ પ્રોવાઇડર - `latency` / `fast` — રિલાયબિલિટી પેનલ્ટી સાથે સૌથી ઓછી p95 લેટન્સી - `sla-aware` / `sla` — p95 લેટન્સી, એરર-રેટ અને વૈકલ્પિક કોસ્ટ SLOs સંતોષતા કેન્ડિડેટ્સને પ્રાધાન્ય આપે છે - `lkgp` — છેલ્લે જાણીતો સારો પ્રોવાઇડર પ્રથમ - `nadir` — પૂલમાંનું કયું મોડેલ પ્રોમ્પ્ટ માટે જરૂરી છે તે નક્કી કરવા [Nadir](https://getnadir.com)ના ડિસિઝન APIને પૂછે છે; આ ઑપ્ટ-ઇન છે અને નિષ્ફળતા થાય તો `rules` પર ફેલ-ઓપન થાય છે ### રાઉટર સ્ટ્રેટેજીઝની વિગત ઑટો-કોમ્બો એન્જિન 7 પ્લગ કરી શકાય તેવા **RouterStrategy** અમલીકરણો ઉપલબ્ધ કરાવે છે, જેને તમે `config.routerStrategy` (અથવા લેગસી `config.auto.routerStrategy`) દ્વારા બદલી શકો છો. દરેક સ્ટ્રેટેજી `RoutingContext` (ટાસ્કનો પ્રકાર, ટૂલ/વિઝન સંકેતો, ટોકન અંદાજ, વૈકલ્પિક SLA નીતિ, વૈકલ્પિક છેલ્લે-જાણીતો-સારો પ્રોવાઇડર)ના આધારે કેન્ડિડેટ પૂલમાંથી એક પ્રોવાઇડર પસંદ કરે છે. #### 1. `rules` (ડિફૉલ્ટ) — 16-ફેક્ટર વેઇટેડ સ્કોરિંગ હાલના સ્કોરિંગ એન્જિનને રૅપ કરે છે. `OPEN` સર્કિટ-બ્રેકર ધરાવતા કેન્ડિડેટ્સને ફિલ્ટર કરે છે, ત્યારબાદ વર્તમાન ટાસ્ક પ્રકાર અને `getTaskFitness()` સાથે `scorePool()` ચલાવે છે અને સૌથી વધુ સ્કોર ધરાવતા પ્રોવાઇડરને પસંદ કરે છે. ```ts class RulesStrategyImpl implements RouterStrategy { readonly name = "rules"; readonly description = "16-factor weighted scoring (see DEFAULT_WEIGHTS)"; select(pool, context) { const eligible = pool.filter((c) => c.circuitBreakerState !== "OPEN"); const ranked = scorePool( eligible.length > 0 ? eligible : pool, context.taskType, undefined, getTaskFitness ); return { provider: ranked[0].provider /* ... */ }; } } ``` **ક્યારે ઉપયોગ કરવો**: ડિફૉલ્ટ. જ્યારે તમને બધા સિગ્નલ્સ વચ્ચે સંતુલિત સમાધાન જોઈએ ત્યારે ઉપયોગ કરો. **ઉપનામ**: `rules` (કોઈ ઉપનામ નથી) --- #### 2. `cost` / `eco` — સૌથી સસ્તો સ્વસ્થ પ્રોવાઇડર કેન્ડિડેટ પૂલને `costPer1MTokens` પ્રમાણે (ચઢતા ક્રમમાં) સૉર્ટ કરે છે અને સૌથી સસ્તો પ્રોવાઇડર પસંદ કરે છે. પહેલાં `OPEN` કેન્ડિડેટ્સને ફિલ્ટર કરે છે. ```ts class CostStrategyImpl implements RouterStrategy { readonly name = "cost"; readonly description = "Always selects cheapest available provider"; select(pool, context) { const healthy = pool.filter((c) => c.circuitBreakerState !== "OPEN"); const sorted = [...healthy].sort((a, b) => a.costPer1MTokens - b.costPer1MTokens); return { provider: sorted[0].provider /* ... */ }; } } ``` **ક્યારે ઉપયોગ કરવો**: ખર્ચ-સંવેદનશીલ વર્કલોડ્સ, બૅચ પ્રોસેસિંગ અથવા બૅકગ્રાઉન્ડ જૉબ્સ. **ઉપનામો**: `cost`, `eco` --- #### 3. `latency` / `fast` — રિલાયબિલિટી પેનલ્ટી સાથે સૌથી ઓછી p95 લેટન્સી `p95LatencyMs + (errorRate * 1000)` પ્રમાણે સૉર્ટ કરે છે. એરર-રેટ પેનલ્ટી સુનિશ્ચિત કરે છે કે અવિશ્વસનીય પ્રોવાઇડર્સની નજીવી લેટન્સી ઓછી હોય તો પણ તેમને નીચો ક્રમ મળે. ```ts class LatencyStrategyImpl implements RouterStrategy { readonly name = "latency"; readonly description = "Prioritizes lowest p95 latency with reliability weighting"; select(pool, context) { const healthy = pool.filter((c) => c.circuitBreakerState !== "OPEN"); const sorted = [...healthy].sort( (a, b) => a.p95LatencyMs + a.errorRate * 1000 - (b.p95LatencyMs + b.errorRate * 1000) ); return { provider: sorted[0].provider /* ... */ }; } } ``` **ક્યારે ઉપયોગ કરવો**: રિયલ-ટાઇમ ચેટ, ઑટોકમ્પ્લીટ અથવા ઇન્ટરેક્ટિવ કોડિંગ આસિસ્ટન્ટ્સ જેવા લેટન્સી-સંવેદનશીલ વર્કલોડ્સ. **ઉપનામો**: `latency`, `fast` --- #### 4. `sla-aware` / `sla` — લેટન્સી/એરર/કોસ્ટ SLO અનુપાલન કન્ફિગર કરેલી SLO નીતિને દરેક કેન્ડિડેટ કેટલી સારી રીતે સંતોષે છે તેના આધારે તેનો સ્કોર નક્કી કરે છે: | પરિબળ | વજન | સૂત્ર | | ------------- | --- | -------------------------------------------------- | | લેટન્સી સ્કોર | 35% | `threshold / max(value, ε)` | | ભૂલ સ્કોર | 35% | `threshold / max(value, ε)` | | હેલ્થ સ્કોર | 15% | `1.0` (CLOSED) / `0.5` (HALF_OPEN) / `0.0` (OPEN) | | ખર્ચ સ્કોર | 10% | `threshold / max(value, ε)` અથવા વિપરીત સામાન્યકૃત | | સ્થિરતા સ્કોર | 5% | વિપરીત સામાન્યકૃત લેટન્સી પ્રમાણભૂત વિચલન | જ્યારે `hardConstraints: true` હોય, ત્યારે ઉમેદવારોને મુખ્યત્વે **ઉલ્લંઘન સ્કોર** (તેઓ કોઈપણ SLO કરતાં કેટલા આગળ જાય છે) અને ત્યારબાદ સંયુક્ત સ્કોર પ્રમાણે ગોઠવવામાં આવે છે. અન્યથા, માત્ર સંયુક્ત સ્કોરનો ઉપયોગ થાય છે. ```ts class SLAStrategyImpl implements RouterStrategy { readonly name = "sla-aware"; readonly description = "Selects the provider most likely to satisfy latency, error-rate, and cost SLOs"; select(pool, context) { // ... દરેક ઉમેદવારને નીતિ સામે સ્કોર કરે છે: { targetP95Ms, maxErrorRate, maxCostPer1MTokens, hardConstraints } } } ``` **SLA ફીલ્ડ્સ** (કોમ્બો કૉન્ફિગમાં સેટ કરવામાં આવે છે): ```json { "strategy": "auto", "config": { "routerStrategy": "sla-aware", "slaTargetP95Ms": 1500, "slaMaxErrorRate": 0.05, "slaMaxCostPer1MTokens": 5, "slaHardConstraints": true } } ``` **ક્યારે ઉપયોગ કરવો**: કડક લેટન્સી, ભૂલ-દર અથવા ખર્ચ બજેટ ધરાવતા પ્રોડક્શન વર્કલોડ્સ. **ઉપનામો**: `sla-aware`, `sla` --- #### 5. `lkgp` — છેલ્લો જાણીતો સારો પ્રોવાઇડર પહેલાં પહેલા **છેલ્લા જાણીતા સારા પ્રોવાઇડર**ને (જો સેટ હોય તો) અજમાવે છે, પછી `rules` વ્યૂહરચના પર ફૉલબૅક કરે છે. સેશન સ્ટિકીનેસ માટે ઉપયોગી — એક જ પ્રોવાઇડર વાતચીતમાં અનુવર્તી વિનંતીઓ સંભાળે છે. ```ts class LKGPStrategyImpl implements RouterStrategy { readonly name = "lkgp"; readonly description = "Tries last known good provider first, then falls back to rules"; select(pool, context) { if (context.lkgpEnabled === false) { return getStrategy("rules").select(pool, context); } if (context.lastKnownGoodProvider) { const candidates = pool.filter( (c) => c.provider === context.lastKnownGoodProvider && c.circuitBreakerState !== "OPEN" ); if (candidates.length > 0) { return { provider: candidates[0].provider /* ... */ }; } } // rules વ્યૂહરચના પર ફૉલબૅક કરો return getStrategy("rules").select(pool, context); } } ``` **ક્યારે ઉપયોગ કરવો**: બહુવિધ-ટર્ન વાતચીતોમાં, જ્યાં તમે ઇચ્છો છો કે એક જ પ્રોવાઇડર અનુવર્તી વિનંતીઓ સંભાળે (દા.ત., કૅશિંગ, સંદર્ભ સાતત્ય અથવા કિંમતની સુસંગતતા માટે). **ઉપનામ**: `lkgp` (કોઈ ઉપનામ નથી) --- #### 6. `nadir` — Nadir મારફતે પ્રોમ્પ્ટ-અવેર મોડલની પસંદગી ઉપરની દરેક વ્યૂહરચના ઉમેદવારોને પોતાની ટેલિમેટ્રી પ્રમાણે ક્રમ આપે છે; તેમાંથી કોઈપણ વિનંતી વાંચતી નથી. `nadir` છેલ્લા યુઝર ટર્ન તથા પૂલના મોડલ idsને [Nadir](https://getnadir.com)ના નિર્ણય API (`POST /v1/bucket`) પર મોકલે છે અને Nadir તે મેનુમાંથી પસંદ કરેલા મોડલ તરફ રૂટ કરે છે (`simple` → સક્ષમ મોડલોમાં સૌથી સસ્તું, `complex` → ફ્રન્ટિયર મોડલ). તે મોડલને સેવા આપતું કનેક્શન હજી પણ `rules` દ્વારા પસંદ થાય છે, જેથી ક્વોટા, હેલ્થ અને ખર્ચ કયું એકાઉન્ટ પસંદ કરવું તે નક્કી કરતા રહે છે. ```json { "strategy": "auto", "config": { "routerStrategy": "nadir", "nadir": { "apiKey": "ndr_...", "baseUrl": "https://api.getnadir.com", "timeoutMs": 2000 } } } ``` બંને સ્ટ્રિંગ્સ માટે `OMNIROUTE_NADIR_API_KEY` અને `OMNIROUTE_NADIR_BASE_URL` env ફૉલબૅક્સ છે. `baseUrl` ફક્ત સ્વ-હોસ્ટેડ Nadir માટે જરૂરી છે (અંતે આવતું `/v1` સ્વીકાર્ય છે). કી વિનાના કૉલ્સ Nadirના અનામી ટિયર પર પહોંચે છે, જે પ્રતિ IP દર-મર્યાદિત છે. બૉક્સની બહાર શું જાય છે: છેલ્લા યુઝર સંદેશનો ટેક્સ્ટ (પ્રથમ 16k અક્ષરો), ઉમેદવાર મોડલ ids અને `source: "omniroute"` ચેનલ ટૅગ. કોઈ સિસ્ટમ પ્રોમ્પ્ટ, ઇતિહાસ, ટૂલ્સ કે હેડર્સ નહીં. નિષ્ફળતા વખતે વર્તન fail-open છે: ટાઇમઆઉટ (ડિફૉલ્ટ 2000 ms), non-2xx, પહોંચી ન શકાય તેવું હોસ્ટ, વિકૃત પ્રતિસાદ અથવા પૂલની બહારની પસંદગીના કિસ્સામાં `rules` નિર્ણયનો ઉપયોગ થાય છે અને કારણની આગળ `NadirStrategy: fallback (…)` ઉમેરાય છે. નિષ્ફળ કૉલ પછી વ્યૂહરચના 30 s માટે નેટવર્કને બાયપાસ કરે છે, જેથી આઉટેજના કારણે દરેક વિનંતી દીઠ એક ટાઇમઆઉટને બદલે દર 30 sમાં એક ટાઇમઆઉટનો ખર્ચ થાય છે. રૂટિંગ ઇવેન્ટ્સ ફક્ત ત્યારે જ `strategy: "nadir"` રિપોર્ટ કરે છે, જ્યારે Nadirએ ખરેખર પસંદગી કરી હોય. **ક્યારે ઉપયોગ કરવો**: મોડલ ટિયર્સમાં ફેલાયેલા પૂલ પર મિશ્ર-મુશ્કેલી ધરાવતો ટ્રાફિક (એક નાનું, એક મધ્યમ અને એક ફ્રન્ટિયર મોડલ), જ્યાં તમે હંમેશાં-ફ્રન્ટિયર વાપરવાનો ખર્ચ ઘટાડવા માંગો છો. **ઉપનામ**: `nadir` (કોઈ ઉપનામ નથી) --- ### કસ્ટમ રાઉટર વ્યૂહરચનાઓ તમે પબ્લિક API મારફતે તમારું પોતાનું `RouterStrategy` અમલીકરણ રજિસ્ટર કરી શકો છો: ```ts import { registerStrategy, type RouterStrategy, } from "@omniroute/open-sse/services/autoCombo/routerStrategy"; class MyCustomStrategy implements RouterStrategy { readonly name = "my-custom"; readonly description = "My custom routing strategy"; select(pool, context) { // અહીં તમારું રૂટિંગ લૉજિક return { provider: pool[0].provider, model: pool[0].model, strategy: this.name, reason: "MyCustomStrategy: ...", candidatesConsidered: pool.length, finalScore: 1.0, }; } } registerStrategy("my-custom", new MyCustomStrategy()); ``` પછી તેનો ઉપયોગ કરો: ```json { "strategy": "auto", "config": { "routerStrategy": "my-custom" } } ``` --- ### રાઉટર વ્યૂહરચના પસંદગી માર્ગદર્શિકા | ઉપયોગનો કિસ્સો | વ્યૂહરચના | કારણ | | --------------- | ----------- | -------------------------------------------- | | સંતુલિત વર્કલોડ | `rules` | ડિફૉલ્ટ — બધા પરિબળોને ધ્યાનમાં લે છે | | ખર્ચ ઘટાડવો | `cost` | હંમેશાં સૌથી સસ્તું પસંદ કરે છે | | લેટન્સી ઘટાડવી | `latency` | સૌથી ઝડપી વિશ્વસનીય પ્રોવાઇડર પસંદ કરે છે | | કડક SLOs | `sla-aware` | p95/ભૂલ/ખર્ચ થ્રેશોલ્ડ પ્રમાણે ફિલ્ટર કરે છે | | બહુવિધ-ટર્ન ચૅટ | `lkgp` | સેશન સ્ટિકીનેસ | | મિશ્ર મુશ્કેલી | `nadir` | દરેક પ્રોમ્પ્ટ માટે મોડલ ટિયર પસંદ કરે છે | SLA-અવેર ફીલ્ડ્સ: ```json { "strategy": "auto", "config": { "routerStrategy": "sla-aware", "slaTargetP95Ms": 1500, "slaMaxErrorRate": 0.05, "slaMaxCostPer1MTokens": 5, "slaHardConstraints": true } } ``` ## કાર્ય યોગ્યતા 6 કાર્ય પ્રકારોમાં (`coding`, `review`, `planning`, `analysis`, `debugging`, `documentation`) 30થી વધુ મોડેલોનું સ્કોરિંગ કરવામાં આવ્યું છે. વાઇલ્ડકાર્ડ પેટર્નને સપોર્ટ કરે છે (દા.ત., `*-coder` → ઉચ્ચ કોડિંગ સ્કોર). ## Auto વેરિઅન્ટ્સનો સારાંશ મૂળ `auto` (ડિફૉલ્ટ) ઉપરાંત `autoPrefix.ts`માં જાહેર કરાયેલા 6 `AutoVariant` મૂલ્યો સહિત, કુલ **7 ઉપયોગ કરી શકાય તેવા મોડેલ IDs** છે: `auto`, `auto/coding`, `auto/fast`, `auto/cheap`, `auto/offline`, `auto/smart`, `auto/lkgp` (`AutoVariant` પોતે 6 મૂલ્યોની ગણતરી કરે છે; 7મો વિકલ્પ "કોઈ વેરિઅન્ટ નહીં" છે — મૂળ `auto` — જેને `parseAutoPrefix()` દ્વારા `variant: undefined` તરીકે હેન્ડલ કરવામાં આવે છે.) ## ટિયર્સ Auto-Combo સાથે કેવી રીતે સુસંગત થાય છે 16-ફેક્ટર સ્કોરિંગ ફંક્શન (`open-sse/services/autoCombo/scoring.ts`) ટિયર સભ્યતાને બે સિગ્નલ તરીકે ગણે છે: `tierPriority` (0.0476) અને `tierAffinity` (0.0476). સંપૂર્ણ `DEFAULT_WEIGHTS` સેટ માટે ઉપર આપેલું પ્રમાણભૂત [સ્કોરિંગ ફેક્ટર ટેબલ](#how-it-works-persisted-auto-combos) જુઓ — દરેક પૅક માટેના ઓવરરાઇડ્સ (ship-fast/cost-saver/quality-first/ offline-friendly) "દરેક પૅક માટે વેઇટ પ્રોફાઇલ્સ" ટેબલમાં સૂચિબદ્ધ છે. માત્ર ટિયર **Tier 1**ને પ્રથમ સ્થાન આપવા માટે ફરજ પાડતું નથી — જો Tier 1ની લેટન્સી ખરાબ હોય અથવા ખર્ચની સરખામણીમાં ગુણવત્તા શ્રેષ્ઠ ન હોય, તો Tier 2 જીતે છે. ટિયર ક્રમ ફરજિયાત કરવા માટે, કોમ્બો સ્ટ્રેટેજી `priority`નો ઉપયોગ કરો અને પ્રોવાઇડર્સને ટિયર પ્રમાણે ગોઠવો. Tier 1 (સબ્સ્ક્રિપ્શન)ને મજબૂત પ્રાધાન્ય આપવા માટે, `tierPriority` વેઇટ વધારો: ```json { "strategy": "auto", "config": { "auto": { "weights": { "tierPriority": 0.3, "costInv": 0.05 } } } } ``` ટિયરની વ્યાખ્યાઓ અને પ્રોવાઇડર વર્ગીકરણ માટે [`docs/guides/TIERS.md`](../guides/TIERS.md) જુઓ. ## પરીક્ષણ અને કવરેજ ### નિશ્ચિત રૂટિંગ-નિર્ણય મેટ્રિક્સ (`npm run test:combo:matrix`) `tests/integration/combo-matrix/*.test.ts` મોક અપસ્ટ્રીમ સાથે વાસ્તવિક કોમ્બો પાઇપલાઇન મારફતે તમામ 19 જાહેર સ્ટ્રેટેજીના રૂટિંગ **નિર્ણય**ને એન્ડ-ટુ-એન્ડ સાબિત કરે છે. કવરેજમાં આનો સમાવેશ થાય છે: - તમામ 19 `ROUTING_STRATEGY_VALUES` સ્ટ્રેટેજીઓ (ordered, weighted, cost, context, fusion, …). - `quota-share` (આંતરિક) એન્ડ-ટુ-એન્ડ: વાસ્તવિક `selectQuotaShareTarget` સીમ મારફતે DRR નિષ્પક્ષતા + સંતૃપ્તિનું અપ્રાધાન્યીકરણ (`registerQuotaFetcher` / `setLKGP` / `__setHeadroomSaturationFetcherForTests`). - દરેક લક્ષ્ય ગણતરીમાં `context-relay` યુનિવર્સલ-હેન્ડઑફ કવરેજ. આ સ્યુટ CIમાં (`test:integration` જોબ) `--test-concurrency=1` અને `--test-force-exit` સાથે ચાલે છે, જેથી તે નિશ્ચિત રહે છે અને તેને લાઇવ ક્રેડેન્શિયલ્સની જરૂર પડતી નથી. ### ગેટેડ લાઇવ સ્મોક પરીક્ષણો (CIમાં નહીં — વાસ્તવિક પ્રોવાઇડર્સ) | કમાન્ડ | તે શું કરે છે | | :------------------------------------- | :------------------------------------------------------------------------------------- | | `npm run test:combo:live` | `RUN_COMBO_LIVE=1` સાથે ઇન-પ્રોસેસ વાસ્તવિક રૂટિંગ; લાઇવ OmniRoute DBનો સ્નૅપશૉટ લે છે | | `npm run test:combo:live:vps` | લાઇવ OmniRoute સર્વર સામે HTTP કૉલ્સ (`COMBO_LIVE_BASE_URL` સેટ કરો) | | `npm run test:combo:live:vps:failover` | એ જ, ઇરાદાપૂર્વકના ફેલઓવર દૃશ્યો સાથે | આ સ્મોક પરીક્ષણો વાસ્તવિક વાયર પાથ (કોમ્બો → પ્રોવાઇડર → પૂર્ણતા)નું પરીક્ષણ કરે છે. લાઇવ ક્રેડેન્શિયલ્સ અને VPS ઍક્સેસની જરૂર હોવાથી તેમને ઇરાદાપૂર્વક CIમાંથી બાકાત રાખવામાં આવ્યા છે. --- ## ફાઇલો | ફાઇલ | હેતુ | | :-------------------------------------------------------- | :-------------------------------------------------------------------------------------------------- | | `open-sse/services/autoCombo/scoring.ts` | 16-પરિબળ સ્કોરિંગ ફંક્શન, `DEFAULT_WEIGHTS`, પૂલ નોર્મ | | `open-sse/services/autoCombo/taskFitness.ts` | મોડેલ × કાર્ય યોગ્યતા લુકઅપ | | `open-sse/services/autoCombo/engine.ts` | પસંદગી લોજિક, બેન્ડિટ, બજેટ મર્યાદા | | `open-sse/services/autoCombo/selfHealing.ts` | બાકાત રાખવું, પ્રોબ્સ, ઇન્સિડન્ટ મોડ | | `open-sse/services/autoCombo/modePacks.ts` | 6 વેઇટ પ્રોફાઇલ્સ (ઝડપથી-શિપ, ખર્ચ-બચત, ગુણવત્તા-પ્રથમ, ઑફલાઇન-અનુકૂળ, વિશ્વસનીયતા-પ્રથમ, કેઓસ-મોડ) | | `open-sse/services/autoCombo/autoPrefix.ts` | `auto/` પ્રિફિક્સ પાર્સર + 6 વેરિઅન્ટ્સ | | `open-sse/services/autoCombo/virtualFactory.ts` | લાઇવ કનેક્શન્સમાંથી ઇન-મેમરી `AutoComboConfig` બનાવે છે | | `open-sse/services/autoCombo/providerRegistryAccessor.ts` | પ્રોવાઇડર રજિસ્ટ્રીને મોક કરવા માટે ટેસ્ટ હૂક | | `src/shared/constants/routingStrategies.ts` | `ROUTING_STRATEGY_VALUES` (20 વ્યૂહરચનાઓ) | | `src/sse/handlers/chat.ts` | એકીકરણ: ઑટો-પ્રિફિક્સ શોર્ટ-સર્કિટ |