# 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) · 🇮🇳 [gu](../../../gu/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) · 🇮🇳 [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) --- > **ഉപയോക്താക്കൾക്കായി**: പെട്ടെന്ന് ആരംഭിക്കണോ? ലളിതമായ വിശദീകരണങ്ങൾക്കും ഉദാഹരണങ്ങൾക്കും [ഓട്ടോ-കോംബോ ഉപയോക്തൃ ഗൈഡ്](../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` | 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` ഉപയോഗിച്ച് മോഡൽ ടിയർ അനുസരിച്ച് പൂൾ ഫിൽട്ടർ ചെയ്യുന്നു — സൗജന്യ ടിയർ vs. പ്രീമിയം). | ഉദാഹരണം | പരിണമിക്കുന്നത് | | ---------------------- | ------------------------------------------------------------------------- | | `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`). ഫിൽട്ടറിംഗ് **fail-open** ആണ് — ഒരു നിയന്ത്രണവുമായി ബന്ധിപ്പിച്ച ഒരു മോഡലും പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, റൂട്ടിംഗ് ഒരിക്കലും തടസ്സപ്പെടാതിരിക്കാനായി മുഴുവൻ പൂൾ ഉപയോഗിക്കുന്നു. കോർ സ്കോറർ (`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. `src/sse/handlers/chat.ts`-ൽ OmniRoute `auto/` പ്രിഫിക്സ് കണ്ടെത്തുന്നു 2. ഡാറ്റാബേസിൽനിന്ന് എല്ലാ **സജീവ പ്രൊവൈഡർ കണക്ഷനുകളും** ക്വറി ചെയ്യുന്നു 3. സാധുവായ ക്രെഡൻഷ്യലുകളുള്ളവയിലേക്ക് ഫിൽട്ടർ ചെയ്യുന്നു (API കീ അല്ലെങ്കിൽ OAuth ടോക്കൺ) 4. ഓരോ കണക്ഷനുമുള്ള മോഡൽ നിർണ്ണയിക്കുന്നു (`connection.defaultModel` അല്ലെങ്കിൽ പ്രൊവൈഡറുടെ ആദ്യ മോഡൽ) 5. മെമ്മറിയിൽ ഒരു **വെർച്വൽ കോംബോ** നിർമ്മിക്കുന്നു (DB-യിൽ സംഭരിക്കില്ല) 6. തിരഞ്ഞെടുത്ത വേരിയന്റിന്റെ വെയ്റ്റ് പ്രൊഫൈൽ + LKGP സ്ട്രാറ്റജി ഉപയോഗിച്ച് റൂട്ട് ചെയ്യുന്നു **പ്രധാന സവിശേഷതകൾ:** - ✅ **എപ്പോഴും പ്രവർത്തനക്ഷമം:** ടോഗിൾ, കോംബോ സൃഷ്ടിക്കൽ, കോൺഫിഗറേഷൻ എന്നിവ ആവശ്യമില്ല - ✅ **ഡൈനാമിക്:** നിലവിൽ ബന്ധിപ്പിച്ചിരിക്കുന്ന പ്രൊവൈഡർമാരെ സ്വയമേവ പ്രതിഫലിപ്പിക്കുന്നു - ✅ **സെഷൻ സ്റ്റിക്കിനസ്:** അവസാനം വിജയിച്ച പ്രൊവൈഡർക്ക് മുൻഗണന നൽകുന്നത് LKGP ഉറപ്പാക്കുന്നു - ✅ **ഒന്നിലധികം അക്കൗണ്ടുകളെ പിന്തുണയ്ക്കുന്നു:** ഓരോ പ്രൊവൈഡർ കണക്ഷനും പ്രത്യേക കാൻഡിഡേറ്റായി മാറുന്നു - ✅ **DB റൈറ്റുകളില്ല:** വെർച്വൽ കോംബോ അഭ്യർത്ഥനയ്ക്കായി മാത്രം നിലവിലുണ്ടാകും; പെർസിസ്റ്റൻസ് ഓവർഹെഡ് പൂജ്യം ### ഓരോ കീയ്ക്കുമുള്ള കാൻഡിഡേറ്റ് നിയന്ത്രണം (#7819, Level 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`) — `users` ടേബിൾ ഇല്ലാത്ത സിംഗിൾ-ടെനന്റ് സംവിധാനമാണ് OmniRoute, അതിനാൽ യഥാർത്ഥ ഓരോ കോളറിനുമുള്ള ഏറ്റവും അടുത്ത ഐഡന്റിറ്റി `apiKeyId` ആണ് — കൂടാതെ പൂർണ്ണമായും യൂണിറ്റ്-ടെസ്റ്റ് ചെയ്ത `filterExcludedCandidates()` (`open-sse/services/autoCombo/candidateOverrides.ts`) വഴി `open-sse/services/autoCombo/virtualFactory.ts`-ലെ കാൻഡിഡേറ്റ്-പൂൾ ചോക്ക്പോയിന്റിൽ അവ നടപ്പാക്കുന്നു. ഫിൽട്ടർ **fail-open** ആണ്: സജ്ജീകരിക്കാത്ത apiKeyId/channel അല്ലെങ്കിൽ DB ലുക്കപ്പ് പരാജയം എന്നിവ രണ്ടും പൂൾ ഫിൽട്ടർ ചെയ്യാതെ നിലനിർത്തുന്നു; അതിനാൽ ഓവർറൈഡുകളൊന്നും കോൺഫിഗർ ചെയ്യാത്ത ഒരു ഓപ്പറേറ്റർക്ക് ഈ ഫീച്ചറിന് മുമ്പുണ്ടായിരുന്നതുമായി ബൈറ്റ്-തലത്തിൽ സമാനമായ റൂട്ടിംഗ് ലഭിക്കുന്നു. **തുടർനടപടി ഇഷ്യൂവിലേക്ക് മാറ്റിവെച്ചിരിക്കുന്നു:** ഓരോ കാൻഡിഡേറ്റിനുമുള്ള വെയിറ്റുകൾ + വ്യക്തമായ ക്രമീകരണം (Level 3 — നിലവിലുള്ള weighted/priority സ്ട്രാറ്റജി പാതകളിലേക്ക് നൽകുന്നു), കൂടാതെ ഓരോ `auto/*` ചാനലിനും ഒരു നിർദ്ദിഷ്ട `combo.ts` സ്ട്രാറ്റജി പിൻ ചെയ്യൽ (Level 4). single-tenant മോഡൽ പരിഗണിക്കുമ്പോൾ ഓവർറൈഡുകൾ ഓരോ API കീയ്ക്കും പ്രത്യേകം തുടരണോ അതോ ഗ്ലോബൽ ആകണമോ എന്ന തുറന്ന ചോദ്യത്തിനായി #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` | ഇന്റഗ്രേഷൻ: auto പ്രിഫിക്സ് ഷോർട്ട്-സർക്യൂട്ട് | | `src/shared/constants/providers.ts` | `SYSTEM_PROVIDERS.auto` സിസ്റ്റം എൻട്രി | ## യഥാർത്ഥ മോഡൽ ഐഡിയുമായി പൊരുത്തപ്പെടുന്ന കോംബോ പേരുകൾ പ്രിഫിക്സില്ലാത്ത ഒരു മോഡൽ ഐഡിക്ക് സമാനമായ `name` ഉള്ള കോംബോ (ഉദാ. `gpt-5.5` എന്ന് പേരുള്ള കോംബോ) ഒരു ബഗ് അല്ല; മറിച്ച് അത് **മനഃപൂർവമുള്ളതും പിന്തുണയ്ക്കുന്നതുമായ പാറ്റേൺ** ആണ്: ഓരോ മോഡൽ ഐഡിനുമുള്ള പ്രൊവൈഡർ ഫാൾബാക്കിനായി [#6940](https://github.com/diegosouzapw/OmniRoute/issues/6940)-ൽ രേഖപ്പെടുത്തിയിരിക്കുന്ന സംവിധാനമാണിത്. പ്രിഫിക്സില്ലാത്ത മോഡൽ ഐഡി റെസല്യൂഷനു മുമ്പായി കോംബോ റെസല്യൂഷൻ പരിശോധിക്കുന്നതിനാൽ (`src/sse/services/model.ts`-ലെ `getComboForModel()`), പ്രിഫിക്സില്ലാത്ത `gpt-5.5` ഐഡിക്കായുള്ള ഒരു അഭ്യർത്ഥന ഒരൊറ്റ പ്രൊവൈഡറിലേക്ക് നേരിട്ട് അയയ്ക്കുന്നതിനുപകരം കോംബോയുടെ ടാർഗെറ്റുകളിലൂടെ (ഉദാ. `acme-responses/gpt-5.5`, `backup-responses/gpt-5.5`) റൂട്ട് ചെയ്യപ്പെടുന്നു — ഇത് [#3227/#3233](https://github.com/diegosouzapw/OmniRoute/issues/3227)-നായി നിർമ്മിച്ച കോംബോ-ബിഫോർ-റീറൈറ്റ് മുൻഗണന വീണ്ടും ഉപയോഗിക്കുന്നു; കൂടാതെ `tests/unit/responses-combo-resolution-3227.test.ts`, `tests/unit/combo-name-codex-responses-rewrite.test.ts` എന്നിവയിലൂടെ റിഗ്രഷൻ പരിശോധനയും നടത്തുന്നു. ഒരു യഥാർത്ഥ മോഡൽ ഐഡിയെ ഷാഡോ ചെയ്യുന്ന പേരിൽ കോംബോ സൃഷ്ടിക്കുകയോ അതിലേക്ക് പുനർനാമകരണം ചെയ്യുകയോ ചെയ്യുന്നത് **ഒരിക്കലും നിരസിക്കപ്പെടില്ല** — അങ്ങനെ ചെയ്യുന്നത് രേഖപ്പെടുത്തിയിരിക്കുന്ന ഈ വർക്ക്ഫ്ലോയെ തകർക്കും. പകരം (#8530), (പുതിയ) പേര് ഒരു യഥാർത്ഥ മോഡൽ ഐഡിയുമായി കൂട്ടിയിടിക്കുമ്പോൾ `POST /api/combos`, `PUT /api/combos/[id]` എന്നിവ റെസ്പോൺസിൽ തടസ്സമുണ്ടാക്കാത്ത ഒരു `warning` ഫീൽഡ് ചേർക്കുന്നു: ```json { "warning": { "code": "COMBO_NAME_SHADOWS_MODEL", "modelId": "gpt-5.5", "providerId": "openai" } } ``` ബൂട്ട് സമയത്ത്, `scanComboModelNameCollisionsAtBoot()` (`src/instrumentation-node.ts`) ഒരു മോഡൽ ഐഡിയെ ഷാഡോ ചെയ്യുന്ന നിലവിലുള്ള ഓരോ കോംബോയും പട്ടികപ്പെടുത്തുന്ന ഒറ്റവരി `[STARTUP]` മുന്നറിയിപ്പും ലോഗ് ചെയ്യുന്നു. അതിനാൽ #6940 പ്രകാരം മനഃപൂർവം ചെയ്യുന്നതിനുപകരം അബദ്ധത്തിൽ ഇത് സംഭവിച്ച ഓപ്പറേറ്റർമാർക്ക് ഒരു സൂചന ലഭിക്കും. കണ്ടെത്തൽ ഹെൽപ്പർ `src/lib/combos/modelNameCollision.ts`-ലാണ്. ## ഒരു ക്ലയന്റിൽ നിന്ന് കസ്റ്റം കോംബോ വിളിക്കുന്നത് ക്ലയന്റ് `model` ഫീൽഡിൽ കോംബോയുടെ **കൃത്യമായ പേര്** അയയ്ക്കുമ്പോൾ മാത്രമാണ് നിലനിർത്തിയ കോംബോകൾ (ക്രമീകരണങ്ങൾ → കോംബോകൾ) ഉപയോഗിക്കുന്നത് — കോംബോയുടെ പേരിന് ഫസി അല്ലെങ്കിൽ ഭാഗിക പൊരുത്തപ്പെടുത്തൽ ഇല്ല; `auto/` പ്രിഫിക്സും ഉൾപ്പെട്ടിട്ടില്ല. റെസല്യൂഷൻ ക്രമം (`src/sse/services/model.ts`-ലെ `getComboForModel()`): 1. കോംബോയുടെ കൃത്യമായ പേരുമായുള്ള പൊരുത്തം (`model: "my-combo"`), 2. `combo/` പ്രിഫിക്സ് (`model: "combo/my-combo"`), 3. മോഡൽ→കോംബോ ഗ്ലോബ് മാപ്പിങ്ങുകൾ (`/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` നിങ്ങളുടെ കോംബോകൾ ഉപയോഗിക്കുന്നില്ല.** `auto`/`auto/*` സ്വന്തമായി ഒരു സീറോ-കോൺഫിഗ് കാൻഡിഡേറ്റ് പൂൾ നിർമ്മിക്കുന്നു; കൂടാതെ ഒരു കോംബോയുടെ പേര് അക്ഷരാർഥത്തിൽ `auto` ആണെങ്കിൽ മാത്രമേ നിലനിർത്തിയ കോംബോകൾ പരിശോധിക്കൂ (ശുപാർശ ചെയ്യുന്നില്ല). ഒരു കോംബോയിലൂടെ റൂട്ട് ചെയ്യാൻ അതിന്റെ കൃത്യമായ പേര് അയയ്ക്കുക — `auto` അല്ല. - **`openrouter/auto` എന്നത് പണം നൽകേണ്ട യഥാർത്ഥ OpenRouter ഉൽപ്പന്നമാണ്** ("Auto Best Available"), OmniRoute അപരനാമമല്ല. OpenRouter രജിസ്ട്രിയിലെ (`open-sse/config/providers/registry/openrouter/index.ts`) ഒരേയൊരു സ്റ്റാറ്റിക് മോഡൽ എൻട്രിയാണിത്; ഇതിന് പ്രത്യേകം ബിൽ ഈടാക്കുകയും ചെയ്യും. `auto` പൂളുകളിൽ നിന്ന് ഇതിനെ ഒഴിവാക്കാൻ ക്രമീകരണങ്ങൾ → റൂട്ടിംഗ് → പണം നൽകേണ്ട മോഡലുകൾ മറയ്ക്കുക ഉപയോഗിക്കുക. ഇവിടെ രേഖപ്പെടുത്തിയിരിക്കുന്ന യഥാർത്ഥ ആശയക്കുഴപ്പത്തെക്കുറിച്ച് അറിയാൻ [#7992](https://github.com/diegosouzapw/OmniRoute/issues/7992), [#7111](https://github.com/diegosouzapw/OmniRoute/issues/7111) എന്നിവ കാണുക. ## ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു (സ്ഥിരമായി സംഭരിക്കുന്ന ഓട്ടോ-കോംബോകൾ) ഓരോ അഭ്യർത്ഥനയ്ക്കും ഏറ്റവും അനുയോജ്യമായ പ്രൊവൈഡർ/മോഡൽ തിരഞ്ഞെടുക്കാൻ Auto-Combo Engine ഒരു **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` നിയന്ത്രിക്കുന്നു. അതിനാൽ, ഡിഫോൾട്ട് ഭാരം പൂജ്യമായ ഘടകങ്ങൾ ഡിഫോൾട്ടായി സ്കോറിൽ സംഭാവന ചെയ്യില്ലെങ്കിലും പാക്കുകളിൽ അവ സംഭാവന ചെയ്യും. ![Auto-Combo 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 | ഈ അഭ്യർത്ഥനയുടെ പ്രോംപ്റ്റ്-കാഷ് പ്രിഫിക്സ് ഇതിനകം കൈവശം വയ്ക്കാൻ ഏറ്റവും സാധ്യതയുള്ള കണക്ഷനിലേക്കുള്ള റെൻഡേവൂ-ഹാഷ് അനുയോജ്യത (`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`. **ആകെത്തുക:** `DEFAULT_WEIGHTS`-ൽ പ്രഖ്യാപിച്ചിരിക്കുന്നതുപോലെ `0.1429 + 0.1605 + 0.1429 + 0.1143 + 0.0762 + (7 × 0.0476) + 0.00 + 0.00 + 0.03 + 0.00 = 1.0`; സ്കോറിംഗ് നടത്തുന്നതിന് മുമ്പ് ഉപയോക്താവ് കോൺഫിഗർ ചെയ്ത ഭാരങ്ങൾ `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` | രണ്ട് തിരഞ്ഞെടുപ്പുകളുടെ ശക്തി ഉപയോഗിച്ചുള്ള റാൻഡം ലോഡ് ബാലൻസിംഗ് | | `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`-കൾക്കുപകരം സ്റ്റിക്കി പരിധി `1` ആയ **ഒരു ഡൈനാമിക്-അക്കൗണ്ട് ഘട്ടം** (ശൂന്യമായ `connectionId`, മുഴുവൻ പൂൾ) തിരഞ്ഞെടുക്കുക. RR കൗണ്ടർ മുന്നോട്ട് പോകുമ്പോഴും, പിൻ ചെയ്ത ഘട്ടങ്ങളും അഫിനിറ്റിയും ഒരേ അക്കൗണ്ടിലേക്ക് ചുരുങ്ങുന്നു. ## ഫ്യൂഷൻ തന്ത്രം ഒരൊറ്റ ലക്ഷ്യം തിരഞ്ഞെടുക്കാത്ത ഏക തന്ത്രമാണ് `fusion`. ഇത് പ്രോംപ്റ്റ് **എല്ലാ പാനൽ മോഡലുകളിലേക്കും സമാന്തരമായി** അയയ്ക്കുന്നു, തുടർന്ന് ക്രമീകരിക്കാവുന്ന ഒരു **വിധികർത്തൃ മോഡൽ** എല്ലാ പാനൽ പ്രതികരണങ്ങളിൽനിന്നും ഒരൊറ്റ അന്തിമ ഉത്തരം സംശ്ലേഷിപ്പിക്കുന്നു. അപ്സ്ട്രീം `decolua/9router`-ൽ നിന്ന് പോർട്ട് ചെയ്തതാണ് (OpenRouter-ന്റെ Fusion രൂപകൽപ്പന); ഇംപ്ലിമെന്റേഷൻ `open-sse/services/fusion.ts`-ൽ. ഇത് പ്രവർത്തിക്കുന്ന വിധം: 0. **ടൂളുകൾ ഉൾപ്പെട്ട അഭ്യർത്ഥനകളുടെ ബൈപാസ്** — ശൂന്യമല്ലാത്ത `tools` അറേയും വ്യക്തമായി `"none"` ആയി സജ്ജീകരിക്കാത്ത `tool_choice`-ഉം ഉള്ള അഭ്യർത്ഥന പാനൽ പൂർണ്ണമായും ഒഴിവാക്കുന്നു: മാറ്റമൊന്നും വരുത്താതെ `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":[...]}`. ## വെർച്വൽ ഓട്ടോ-കോംബോ ഫാക്ടറി Auto Combo എഞ്ചിന് മുൻകൂട്ടി നിർവചിച്ച കോംബോകൾ ആവശ്യമില്ല. പകരം, `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` എന്നിവയും പട്ടികപ്പെടുത്തുന്നു — ഇവ കാൻഡിഡേറ്റ് പൂളിലെ വിൻഡോകളുടെ പരമാവധി മൂല്യമാണ്. ക്ലയന്റുകൾ (ഉദാ. opencode പ്ലഗിൻ) `0` എന്നതിനുപകരം ഈ മൂല്യങ്ങൾ പരസ്യപ്പെടുത്തണം: പൂജ്യം കോൺടെക്സ്റ്റ് opencode-ന്റെ ഓട്ടോ-കോംപാക്ഷൻ പൂർണ്ണമായും പ്രവർത്തനരഹിതമാക്കുന്നു; തൽഫലമായി, ഗേറ്റ്വേയുടെ ഹിസ്റ്ററി പർജ് കോൺടെക്സ്റ്റ് നശിപ്പിക്കുന്നതുവരെ സെഷനുകൾ വളരുന്നു. പരമാവധി മൂല്യം പരസ്യപ്പെടുത്തുന്നത് സുരക്ഷിതമാണ്, കാരണം auto-combo കോൺടെക്സ്റ്റ് പ്രീ-ഫിൽട്ടർ വലുപ്പമേറിയ അഭ്യർത്ഥനകളെ വലിയ വിൻഡോകളുള്ള കാൻഡിഡേറ്റുകളിലേക്ക് റൂട്ട് ചെയ്യുന്നു. ```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 എൻഡ്പോയിന്റ് വഴിയുള്ള പെർസിസ്റ്റ് ചെയ്ത auto combo 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 ലേറ്റൻസി, പിശക് നിരക്ക്, ഓപ്ഷണൽ ചെലവ് SLO-കൾ എന്നിവ പാലിക്കുന്ന കാൻഡിഡേറ്റുകൾക്ക് മുൻഗണന നൽകുന്നു - `lkgp` — അവസാനം നന്നായി പ്രവർത്തിച്ചതായി അറിയപ്പെടുന്ന പ്രൊവൈഡറിന് ആദ്യം മുൻഗണന - `nadir` — പ്രോംപ്റ്റിന് പൂളിലെ ഏത് മോഡലാണ് ആവശ്യമെന്ന് [Nadir](https://getnadir.com)-ന്റെ ഡിസിഷൻ API-യോട് ചോദിക്കുന്നു; ഇത് ഓപ്റ്റ്-ഇൻ ആണ്, പരാജയപ്പെട്ടാൽ `rules`-ലേക്ക് ഫെയിൽ-ഓപ്പൺ ചെയ്യുന്നു ### റൂട്ടർ സ്ട്രാറ്റജികൾ വിശദമായി `config.routerStrategy` (അല്ലെങ്കിൽ ലെഗസി `config.auto.routerStrategy`) വഴി പരസ്പരം മാറ്റി ഉപയോഗിക്കാവുന്ന 7 പ്ലഗ്ഗബിൾ **RouterStrategy** ഇംപ്ലിമെന്റേഷനുകൾ auto-combo എഞ്ചിൻ ലഭ്യമാക്കുന്നു. ഓരോ സ്ട്രാറ്റജിയും ഒരു `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% | വിപരീത നോർമലൈസ്ഡ് ലേറ്റൻസി stddev | `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) { // ... ഓരോ സ്ഥാനാർഥിയെയും policy-യുമായി താരതമ്യം ചെയ്ത് സ്കോർ ചെയ്യുന്നു: { targetP95Ms, maxErrorRate, maxCostPer1MTokens, hardConstraints } } } ``` **SLA ഫീൽഡുകൾ** (കോംബോ config-ൽ സജ്ജീകരിക്കുക): ```json { "strategy": "auto", "config": { "routerStrategy": "sla-aware", "slaTargetP95Ms": 1500, "slaMaxErrorRate": 0.05, "slaMaxCostPer1MTokens": 5, "slaHardConstraints": true } } ``` **എപ്പോൾ ഉപയോഗിക്കണം**: കർശനമായ ലേറ്റൻസി, പിശക് നിരക്ക്, അല്ലെങ്കിൽ ചെലവ് പരിധികളുള്ള പ്രൊഡക്ഷൻ വർക്ക്ലോഡുകൾക്ക്. **അപരനാമങ്ങൾ**: `sla-aware`, `sla` --- #### 5. `lkgp` — അവസാനം മികച്ചതായി അറിയപ്പെട്ട provider ആദ്യം **അവസാനം മികച്ചതായി അറിയപ്പെട്ട provider** (സജ്ജീകരിച്ചിട്ടുണ്ടെങ്കിൽ) ആദ്യം പരീക്ഷിക്കുകയും, തുടർന്ന് `rules` strategy-യിലേക്ക് മടങ്ങുകയും ചെയ്യുന്നു. സെഷൻ സ്റ്റിക്കിനസിന് ഇത് ഉപകാരപ്രദമാണ് — ഒരു സംഭാഷണത്തിലെ തുടർ അഭ്യർത്ഥനകൾ അതേ provider കൈകാര്യം ചെയ്യും. ```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 strategy-യിലേക്ക് മടങ്ങുന്നു return getStrategy("rules").select(pool, context); } } ``` **എപ്പോൾ ഉപയോഗിക്കണം**: തുടർ അഭ്യർത്ഥനകൾ അതേ provider കൈകാര്യം ചെയ്യണമെന്ന് നിങ്ങൾ ആഗ്രഹിക്കുന്ന മൾട്ടി-ടേൺ സംഭാഷണങ്ങളിൽ (ഉദാ., കാഷിംഗ്, സന്ദർഭ തുടർച്ച, അല്ലെങ്കിൽ വിലനിർണ്ണയ സ്ഥിരതയ്ക്കായി). **അപരനാമം**: `lkgp` (അപരനാമമില്ല) --- #### 6. `nadir` — Nadir മുഖേന പ്രോംപ്റ്റ്-അവബോധമുള്ള മോഡൽ തിരഞ്ഞെടുക്കൽ മുകളിലുള്ള ഓരോ strategy-യും സ്ഥാനാർഥികളെ അവയുടെ സ്വന്തം ടെലിമെട്രി അനുസരിച്ച് റാങ്ക് ചെയ്യുന്നു; അവയൊന്നും അഭ്യർത്ഥന വായിക്കുന്നില്ല. `nadir`, അവസാനത്തെ ഉപയോക്തൃ ടേണും പൂളിലെ മോഡൽ ids-ഉം [Nadir](https://getnadir.com)-ന്റെ തീരുമാന API-യിലേക്ക് (`POST /v1/bucket`) അയയ്ക്കുകയും, ആ മെനുവിൽ നിന്ന് Nadir തിരഞ്ഞെടുക്കുന്ന മോഡലിലേക്ക് റൂട്ട് ചെയ്യുകയും ചെയ്യുന്നു (`simple` → ശേഷിയുള്ളതിൽ ഏറ്റവും വിലകുറഞ്ഞ മോഡൽ, `complex` → ഫ്രണ്ടിയർ മോഡൽ). ആ മോഡൽ നൽകുന്ന കണക്ഷൻ ഇപ്പോഴും `rules` ആണ് തിരഞ്ഞെടുക്കുന്നത്, അതിനാൽ quota, health, cost എന്നിവ ഏത് അക്കൗണ്ട് ഉപയോഗിക്കണമെന്ന് തുടർന്നും നിർണയിക്കുന്നു. ```json { "strategy": "auto", "config": { "routerStrategy": "nadir", "nadir": { "apiKey": "ndr_...", "baseUrl": "https://api.getnadir.com", "timeoutMs": 2000 } } } ``` ഈ രണ്ട് സ്ട്രിങ്ങുകൾക്കുള്ള env fallback-കളാണ് `OMNIROUTE_NADIR_API_KEY`, `OMNIROUTE_NADIR_BASE_URL` എന്നിവ. സ്വയം ഹോസ്റ്റ് ചെയ്ത Nadir-ന് മാത്രമേ `baseUrl` ആവശ്യമുള്ളൂ (അവസാനത്തിലുള്ള `/v1` അനുവദനീയമാണ്). കീ ഇല്ലാത്ത കോളുകൾ Nadir-ന്റെ anonymous tier-ലേക്ക് എത്തും; ഇതിന് ഓരോ IP-ക്കും നിരക്ക് പരിധിയുണ്ട്. പുറത്തേക്ക് അയയ്ക്കുന്നത്: അവസാന ഉപയോക്തൃ സന്ദേശത്തിന്റെ ടെക്സ്റ്റ് (ആദ്യത്തെ 16k അക്ഷരങ്ങൾ), സ്ഥാനാർഥി മോഡൽ ids, ഒരു `source: "omniroute"` ചാനൽ ടാഗ് എന്നിവ. system prompt, history, tools, അല്ലെങ്കിൽ headers എന്നിവ അയയ്ക്കുന്നില്ല. പരാജയ സാഹചര്യത്തിൽ fail-open രീതിയാണ് പിന്തുടരുന്നത്: timeout (സ്ഥിരസ്ഥിതി 2000 ms), non-2xx, ലഭ്യമല്ലാത്ത host, വികലമായ response, അല്ലെങ്കിൽ പൂളിന് പുറത്തുള്ള തിരഞ്ഞെടുപ്പ് എന്നിവ ഉണ്ടായാൽ `rules` തീരുമാനം ഉപയോഗിക്കുകയും കാരണത്തിന് മുന്നിൽ `NadirStrategy: fallback (…)` ചേർക്കുകയും ചെയ്യും. പരാജയപ്പെട്ട കോളിന് ശേഷം strategy 30 s നേരത്തേക്ക് നെറ്റ്വർക്ക് ഒഴിവാക്കുന്നു; അതിനാൽ തടസ്സമുണ്ടായാൽ ഓരോ അഭ്യർത്ഥനയ്ക്കും ഒരു timeout ഉണ്ടാകുന്നതിന് പകരം ഓരോ 30 s-ലും ഒരെണ്ണം മാത്രമേ ഉണ്ടാകൂ. Nadir യഥാർഥത്തിൽ തിരഞ്ഞെടുപ്പ് നടത്തിയാൽ മാത്രമേ റൂട്ടിംഗ് ഇവന്റുകൾ `strategy: "nadir"` എന്ന് റിപ്പോർട്ട് ചെയ്യൂ. **എപ്പോൾ ഉപയോഗിക്കണം**: വിവിധ മോഡൽ ടയറുകളുള്ള ഒരു പൂളിലെ വ്യത്യസ്ത ബുദ്ധിമുട്ടുള്ള ട്രാഫിക്കിന് (ചെറിയതും, ഇടത്തരവും, ഫ്രണ്ടിയർ മോഡലും), എല്ലായ്പ്പോഴും frontier ഉപയോഗിക്കുന്നതിന്റെ ചെലവ് കുറയ്ക്കാൻ ആഗ്രഹിക്കുമ്പോൾ. **അപരനാമം**: `nadir` (അപരനാമമില്ല) --- ### ഇഷ്ടാനുസൃത router strategy-കൾ പൊതു API മുഖേന നിങ്ങളുടെ സ്വന്തം `RouterStrategy` implementation രജിസ്റ്റർ ചെയ്യാം: ```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) { // നിങ്ങളുടെ routing logic ഇവിടെ 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" } } ``` --- ### Router strategy തിരഞ്ഞെടുക്കൽ മാർഗ്ഗനിർദ്ദേശം | ഉപയോഗ സാഹചര്യം | Strategy | കാരണം | | ------------------------ | ----------- | ------------------------------------------------------------ | | സന്തുലിതമായ വർക്ക്ലോഡ് | `rules` | സ്ഥിരസ്ഥിതി — എല്ലാ ഘടകങ്ങളും പരിഗണിക്കുന്നു | | ചെലവ് കുറയ്ക്കുക | `cost` | എല്ലായ്പ്പോഴും ഏറ്റവും വിലകുറഞ്ഞത് തിരഞ്ഞെടുക്കുന്നു | | ലേറ്റൻസി കുറയ്ക്കുക | `latency` | ഏറ്റവും വേഗതയേറിയ വിശ്വസനീയമായ provider-നെ തിരഞ്ഞെടുക്കുന്നു | | കർശനമായ SLO-കൾ | `sla-aware` | p95/error/cost പരിധികൾ അനുസരിച്ച് ഫിൽട്ടർ ചെയ്യുന്നു | | മൾട്ടി-ടേൺ ചാറ്റ് | `lkgp` | സെഷൻ സ്റ്റിക്കിനസ് | | വ്യത്യസ്ത ബുദ്ധിമുട്ടുകൾ | `nadir` | ഓരോ prompt-നും അനുയോജ്യമായ മോഡൽ tier തിരഞ്ഞെടുക്കുന്നു | SLA-aware ഫീൽഡുകൾ: ```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 മോഡൽ ID-കൾ** ഉണ്ട്: `auto`, `auto/coding`, `auto/fast`, `auto/cheap`, `auto/offline`, `auto/smart`, `auto/lkgp` (`AutoVariant` തന്നെ 6 മൂല്യങ്ങളാണ് ഉൾക്കൊള്ളുന്നത്; ഏഴാമത്തെ ഓപ്ഷൻ "വേരിയന്റ് ഇല്ല" എന്നതാണ് — അടിസ്ഥാന `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`) മോക്ക് ചെയ്ത അപ്സ്ട്രീം ഉപയോഗിച്ച് യഥാർഥ കോംബോ പൈപ്പ്ലൈനിലൂടെ എല്ലാ 19 പൊതു സ്ട്രാറ്റജികളുടെയും റൂട്ടിംഗ് **തീരുമാനം** എൻഡ്-ടു-എൻഡ് രീതിയിൽ `tests/integration/combo-matrix/*.test.ts` തെളിയിക്കുന്നു. കവറേജിൽ ഉൾപ്പെടുന്നവ: - എല്ലാ 19 `ROUTING_STRATEGY_VALUES` സ്ട്രാറ്റജികളും (ordered, weighted, cost, context, fusion, …). - `quota-share` (ആന്തരികം) എൻഡ്-ടു-എൻഡ്: യഥാർഥ `selectQuotaShareTarget` സീം (`registerQuotaFetcher` / `setLKGP` / `__setHeadroomSaturationFetcherForTests`) വഴിയുള്ള DRR നീതിപൂർണതയും സാച്ചുറേഷൻ ഡീപ്രയോറിറ്റൈസേഷനും. - എല്ലാ ടാർഗറ്റ് എണ്ണങ്ങളിലുമുള്ള `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` | ഇന്റഗ്രേഷൻ: ഓട്ടോ-പ്രിഫിക്സ് ഷോർട്ട്-സർക്യൂട്ട് |