# 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) · 🇮🇳 [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) · 🇳🇵 [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/` ရှေ့ဆက်စကားလုံး) > **အသစ်:** combo ဖန်တီးရန်မလိုပါ။ မည်သည့် client တွင်မဆို `auto/` ရှေ့ဆက်စကားလုံးကို တိုက်ရိုက်အသုံးပြုပါ။ ### အမြန်နမူနာများ | မော်ဒယ် ID | မူကွဲ | လုပ်ဆောင်ပုံ | | -------------- | ------- | ------------------------------------------------------------------------------------------------------ | | `auto` | ပုံသေ | ချိတ်ဆက်ထားသော provider အားလုံး၊ LKGP နည်းဗျူဟာ၊ မျှတသော အလေးချိန်များ | | `auto/coding` | coding | အရည်အသွေးကို ဦးစားပေးသော အလေးချိန်များ၊ ကုဒ်ထုတ်လုပ်ခြင်းအတွက် သင့်လျော်သည် | | `auto/fast` | fast | တုံ့ပြန်ချိန်နည်းခြင်းကို အလေးပေးသည့် ရွေးချယ်မှု | | `auto/cheap` | cheap | ကုန်ကျစရိတ်အကောင်းဆုံးဖြစ်အောင် လမ်းကြောင်းရွေးချယ်ခြင်း (အနိမ့်ဆုံးကုန်ကျစရိတ်ကို ဦးစွာရွေးချယ်ခြင်း) | | `auto/offline` | offline | quota ရရှိနိုင်မှုအမြင့်ဆုံး provider များကို ဦးစားပေးသည် | | `auto/smart` | smart | ပိုကောင်းသော မော်ဒယ်ရှာဖွေတွေ့ရှိမှုအတွက် အရည်အသွေးကို ဦးစားပေးခြင်း + ပိုမြင့်သော စူးစမ်းနှုန်း (10%) | | `auto/lkgp` | lkgp | LKGP ကို အတိအလင်းသတ်မှတ်ခြင်း (ပုံသေ `auto` နှင့်တူသည်) | | `auto/chaos` | chaos | ခံနိုင်ရည်စမ်းသပ်မှုအတွက် ချို့ယွင်းချက်ထည့်သွင်းသည့် အလေးချိန်များ (chaos engineering) | ### အမျိုးအစား × အဆင့် ပေါင်းစပ်ဖွဲ့စည်းမှု (`auto/:`) OpenRouter ပုံစံ နောက်ဆက်စကားလုံးများသည် **မည်သည့်လမ်းကြောင်းအမျိုးအစားဖြစ်သည်** (category) ကို **မည်သို့ အကောင်းဆုံးဖြစ်အောင်လုပ်မည်** (tier) နှင့် ခွဲခြားထားသဖြင့် ၎င်းတို့ကို လွတ်လပ်စွာ ပေါင်းစပ်နိုင်သည် (#4235 Phase B၊ `open-sse/services/autoCombo/suffixComposition.ts`)။ - **အမျိုးအစားများ** (စွမ်းဆောင်ရည်အလိုက် ကိုယ်စားလှယ်လောင်းအစုကို စစ်ထုတ်သည်): `coding` · `reasoning` · `vision` · `chat` · `multimodal`။ `vision`/`multimodal` သည် အမြင်စွမ်းရည်ရှိသော မော်ဒယ်များကို ထိန်းသိမ်းထားပြီး `reasoning` သည် ဆင်ခြင်တွေးခေါ်နိုင်သော မော်ဒယ်များကို ထိန်းသိမ်းထားသည်။ - **အဆင့်များ** (အမှတ်ပေးအလေးချိန်များ / အစုစစ်ထုတ်မှုကို ရွေးချယ်သည်): `fast` (လျင်မြန်စွာ ဖြန့်ချိခြင်း) · `cheap` (`floor` ၏ alias၊ ကုန်ကျစရိတ်ချွေတာခြင်း) · `reliable` (circuit-breaker အခြေအနေ + တုံ့ပြန်ချိန်တည်ငြိမ်မှု) · `free` / `pro` (`classifyTier` မှတစ်ဆင့် မော်ဒယ်အဆင့်အလိုက် အစုကို စစ်ထုတ်ခြင်း — အခမဲ့အဆင့်နှင့် ပရီမီယံအဆင့်)။ | နမူနာ | ဖြေရှင်းသတ်မှတ်သည့်အရာ | | ---------------------- | --------------------------------------------------------------------------------------- | | `auto/coding:fast` | coding အစု၊ တုံ့ပြန်ချိန်နည်းခြင်းကို အလေးပေးသည့် အလေးချိန်များ | | `auto/coding:cheap` | coding အစု၊ ကုန်ကျစရိတ်အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ထားသည် (`auto/coding:floor` ၏ alias) | | `auto/reasoning:pro` | ဆင်ခြင်ခြင်း/တွေးခေါ်ခြင်း မော်ဒယ်များသာ၊ ပရီမီယံအဆင့် | | `auto/vision` | အမြင်စွမ်းရည်ရှိသော မော်ဒယ်များ (အဆင့်မပါ → မျှတသော အလေးချိန်များ) | | `auto/multimodal:free` | multimodal စွမ်းရည်ရှိသော မော်ဒယ်များ၊ အခမဲ့အဆင့်သာ | မှန်ကန်သော `auto/[:]` တစ်ခုချင်းစီကို လိုအပ်သည့်အချိန်တွင် ဖြေရှင်းသတ်မှတ်ပေးသည်။ ရွေးချယ်စီစဉ်ထားသော အစုခွဲတစ်ခုကို `/v1/models` နှင့် dashboard (`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" # coding အလုပ်များအတွက် အကောင်းဆုံး model: "auto/fast" # ရရှိနိုင်သည့်အထဲမှ အမြန်ဆုံး model: "auto/cheap" # token တစ်ခုလျှင် ဈေးအသက်သာဆုံး ``` **ဖြစ်ပျက်ပုံ:** 1. OmniRoute သည် `src/sse/handlers/chat.ts` တွင် `auto/` ရှေ့ဆက်စကားလုံးကို ရှာဖွေသိရှိသည် 2. database မှ **အသက်ဝင်နေသော provider ချိတ်ဆက်မှုများ** အားလုံးကို query ပြုလုပ်သည် 3. မှန်ကန်သော အထောက်အထားများ (API key သို့မဟုတ် OAuth token) ရှိသည့်အရာများကို စစ်ထုတ်သည် 4. ချိတ်ဆက်မှုတစ်ခုချင်းစီအတွက် မော်ဒယ်ကို ဆုံးဖြတ်သည် (`connection.defaultModel` သို့မဟုတ် provider ၏ ပထမဆုံးမော်ဒယ်) 5. memory အတွင်း၌ **virtual combo** တစ်ခု တည်ဆောက်သည် (DB တွင် မသိမ်းဆည်းပါ) 6. ရွေးချယ်ထားသော မူကွဲ၏ အလေးချိန်ပရိုဖိုင် + LKGP နည်းဗျူဟာကို အသုံးပြု၍ လမ်းကြောင်းရွေးချယ်သည် **အဓိက ဂုဏ်သတ္တိများ:** - ✅ **အမြဲဖွင့်ထားသည်:** ခလုတ်ဖွင့်ပိတ်ရန်၊ combo ဖန်တီးရန် သို့မဟုတ် ပြင်ဆင်သတ်မှတ်ရန် မလိုအပ်ပါ - ✅ **ပြောင်းလဲနိုင်သည်:** လက်ရှိချိတ်ဆက်ထားသော provider များကို အလိုအလျောက် ထင်ဟပ်သည် - ✅ **Session စွဲကပ်မှု:** LKGP သည် နောက်ဆုံးအောင်မြင်ခဲ့သော provider ကို ဦးစားပေးစေသည် - ✅ **အကောင့်များစွာကို သိရှိသည်:** provider ချိတ်ဆက်မှုတစ်ခုစီသည် သီးခြားကိုယ်စားလှယ်လောင်းတစ်ခု ဖြစ်လာသည် - ✅ **DB တွင် ရေးသားမှုမရှိ:** Virtual combo သည် request အတွက်သာ ရှိပြီး အမြဲသိမ်းဆည်းမှုဆိုင်ရာ ဝန်ပိုလုံးဝမရှိပါ ### Key တစ်ခုချင်းစီအလိုက် ကိုယ်စားလှယ်လောင်း ထိန်းချုပ်မှု (#7819၊ Level 1+2) `GET /v1/auto-combo/{channel}/candidates` (`{channel}` = `auto/` နောက်ရှိ နောက်ဆက်စကားလုံး သို့မဟုတ် အခြေခံ channel အတွက် စာသားအတိုင်း `auto`) သည် ရှိပြီးသား resilience reads ကို ပြန်လည်အသုံးပြုကာ တိုက်ရိုက် ဆက်သွယ်ရောက်ရှိနိုင်မှုဖြင့် ဖြည့်စွက်ဖော်ပြထားသော `auto/*` channel ၏ လက်ရှိကိုယ်စားလှယ်လောင်းအစုကို စာရင်းပြုစုသည့် **ဖတ်ရှုရန်သာ** endpoint တစ်ခုဖြစ်သည် (breaker `state` အကြမ်းကို မည်သည့်အခါမျှ မသုံးပါ): - provider circuit breaker — `getCircuitBreaker(provider).getStatus()` / `.canExecute()` - connection cooldown — ဖြေရှင်းသတ်မှတ်ထားသော `provider_connections` row ရှိ `rateLimitedUntil` / `testStatus` - model lockout — `isModelLocked(provider, connectionId, model)` Candidate တစ်ခုစီတွင် ဤ API key ၏ `excluded` flag လည်း ပါရှိသည်။ ဖယ်ထုတ်မှုများကို API key တစ်ခုချင်းစီအလိုက် (`auto_candidate_overrides` table၊ migration `128`) သိမ်းဆည်းထားသည် — OmniRoute သည် `users` table မရှိသော single-tenant စနစ်ဖြစ်သဖြင့် `apiKeyId` သည် caller တစ်ဦးချင်းစီကို ကိုယ်စားပြုရန် အနီးစပ်ဆုံး အမှန်တကယ် identity ဖြစ်သည် — ထို့ပြင် candidate pool ၏ အဓိကထိန်းချုပ်သည့်နေရာဖြစ်သော `open-sse/services/autoCombo/virtualFactory.ts` တွင် pure ဖြစ်ပြီး unit test ပြုလုပ်ထားသည့် `filterExcludedCandidates()` (`open-sse/services/autoCombo/candidateOverrides.ts`) မှတစ်ဆင့် အတည်ပြုအသုံးချသည်။ ဤ filter သည် **fail-open** ဖြစ်သည်။ apiKeyId/channel မသတ်မှတ်ထားခြင်း သို့မဟုတ် DB lookup မအောင်မြင်ခြင်း နှစ်မျိုးစလုံးတွင် pool ကို filter မလုပ်ဘဲ ချန်ထားမည်ဖြစ်သောကြောင့် override များ မသတ်မှတ်ထားသည့် operator တစ်ဦးသည် ဤ feature မတိုင်မီက routing နှင့် byte အဆင့်အထိ တစ်ထပ်တည်းကျသည့် routing ကို ရရှိမည်ဖြစ်သည်။ **နောက်ဆက်တွဲ issue သို့ ရွှေ့ဆိုင်းထားသည်:** candidate တစ်ခုချင်းစီအလိုက် weight များ + အတိအကျ ordering သတ်မှတ်ခြင်း (Level 3 — လက်ရှိ weighted/priority strategy လမ်းကြောင်းများထဲသို့ ထည့်သွင်းမည်) နှင့် `auto/*` channel တစ်ခုချင်းစီအတွက် သတ်မှတ်ထားသော `combo.ts` strategy တစ်ခုကို pin လုပ်ခြင်း (Level 4)။ single-tenant model ကို ထည့်သွင်းစဉ်းစားသည့်အခါ override များကို API key တစ်ခုချင်းစီအလိုက် ဆက်လက်ထားသင့်သလား သို့မဟုတ် global အဖြစ် ပြောင်းသင့်သလားဟူသော မဖြေရှင်းရသေးသည့် မေးခွန်းအတွက် #7819 အစီအစဉ်ကို ကြည့်ပါ။ **နောက်ကွယ်ရှိ လုပ်ဆောင်ပုံ:** ```txt တောင်းဆိုမှု: { model: "auto/coding" } ↓ src/sse/handlers/chat.ts က prefix ကို ရှာဖွေသိရှိသည် ↓ createVirtualAutoCombo('coding') → လက်ရှိအသုံးပြုနေသော connection များမှ candidatePool ↓ handleComboChat (သိမ်းဆည်းထားသော combo များနှင့် တူညီသည့် engine) ↓ Auto-scoring က request တစ်ခုချင်းစီအတွက် အကောင်းဆုံး provider/model ကို ရွေးချယ်သည် ``` **အကောင်အထည်ဖော်ထားသည့် file များ:** | File | ရည်ရွယ်ချက် | | --------------------------------------------------------- | -------------------------------------------------- | | `open-sse/services/autoCombo/autoPrefix.ts` | Prefix parser (`parseAutoPrefix`) | | `open-sse/services/autoCombo/virtualFactory.ts` | Virtual `AutoComboConfig` object များကို ဖန်တီးသည် | | `open-sse/services/autoCombo/providerRegistryAccessor.ts` | Provider registry ကို mock လုပ်ရန် test hook | | `src/sse/handlers/chat.ts` | ပေါင်းစည်းမှု: auto prefix short-circuit | | `src/shared/constants/providers.ts` | `SYSTEM_PROVIDERS.auto` system entry | ## အမှန်တကယ်ရှိသော Model Id နှင့် ကိုက်ညီသည့် Combo အမည်များ `name` သည် bare model id တစ်ခုနှင့် တူညီနေသော combo (ဥပမာ `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 ဦးစားပေးအစီအစဉ်ကို ပြန်လည်အသုံးပြုထားပြီး `tests/unit/responses-combo-resolution-3227.test.ts` နှင့် `tests/unit/combo-name-codex-responses-rewrite.test.ts` တို့ဖြင့် regression test ပြုလုပ်ထားသည်။ အမှန်တကယ်ရှိသော model id ကို ဖုံးကွယ်သည့် အမည်တစ်ခုဖြင့် combo ဖန်တီးခြင်း သို့မဟုတ် အမည်ပြောင်းခြင်းကို **မည်သည့်အခါမျှ ငြင်းပယ်မည်မဟုတ်ပါ** — ထိုသို့ပြုလုပ်ပါက မှတ်တမ်းတင်ထားသော ဤ workflow ကို ပျက်စီးစေမည်ဖြစ်သည်။ ထိုအစား (#8530)၊ (အသစ်သတ်မှတ်ထားသော) အမည်သည် အမှန်တကယ်ရှိသော model id နှင့် တိုက်ဆိုင်သည့်အခါ `POST /api/combos` နှင့် `PUT /api/combos/[id]` တို့သည် request ကို ပိတ်ဆို့ခြင်းမရှိသော `warning` field တစ်ခုကို response တွင် ထည့်သွင်းပေးသည်- ```json { "warning": { "code": "COMBO_NAME_SHADOWS_MODEL", "modelId": "gpt-5.5", "providerId": "openai" } } ``` စနစ်စတင်ချိန်တွင် `scanComboModelNameCollisionsAtBoot()` (`src/instrumentation-node.ts`) သည် model id ကို ဖုံးကွယ်နေသည့် လက်ရှိ combo တိုင်းကို စာရင်းပြုစုထားသော တစ်ကြောင်းတည်းပါ `[STARTUP]` သတိပေးချက်ကိုလည်း log လုပ်ပေးသည်။ ထို့ကြောင့် #6940 အရ ရည်ရွယ်ချက်ရှိရှိ ပြုလုပ်ခြင်းမဟုတ်ဘဲ မတော်တဆ ကြုံတွေ့ရသော operator များအတွက် သတိပြုနိုင်သည့် အချက်ပြမှုတစ်ခု ရရှိစေသည်။ Detection helper သည် `src/lib/combos/modelNameCollision.ts` တွင် ရှိသည်။ ## Client မှ Custom Combo တစ်ခုကို ခေါ်ယူခြင်း သိမ်းဆည်းထားသော combo များ (Settings → Combos) ကို client က combo ၏ **အမည်အတိအကျ** ကို `model` field တွင် ပို့သည့်အခါမှသာ အသုံးပြုသည် — combo အမည်အတွက် fuzzy သို့မဟုတ် partial matching မရှိသည့်အပြင် `auto/` prefix လည်း မပါဝင်ပါ။ Resolution အစီအစဉ် (`src/sse/services/model.ts` ရှိ `getComboForModel()`)- 1. combo အမည်နှင့် အတိအကျကိုက်ညီမှု (`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` သည် သင့် combo များကို အသုံးမပြုပါ။** `auto`/`auto/*` သည် ၎င်းကိုယ်ပိုင် zero-config candidate pool ကို တည်ဆောက်ပြီး `auto` ဟု အမည်အတိအကျ ပေးထားသည့် combo ရှိမှသာ သိမ်းဆည်းထားသော combo များကို အသုံးပြုသည် (မအကြံပြုပါ)။ 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 ဖြစ်ပြီး သီးခြားငွေတောင်းခံသည်။ ၎င်းကို `auto` pools များမှ ဖယ်ထုတ်ရန် Settings → Routing → Hide paid models ကို အသုံးပြုပါ။ ဤမှတ်တမ်းတွင် ရှင်းလင်းထားသော မူလရှုပ်ထွေးမှုအကြောင်းကို [#7992](https://github.com/diegosouzapw/OmniRoute/issues/7992) နှင့် [#7111](https://github.com/diegosouzapw/OmniRoute/issues/7111) တို့တွင် ကြည့်ပါ။ ## အလုပ်လုပ်ပုံ (သိမ်းဆည်းထားသော Auto-Combo များ) Auto-Combo Engine သည် request တစ်ခုချင်းစီအတွက် အသင့်တော်ဆုံး provider/model ကို **အချက် 16 ချက်ပါ scoring function** (`open-sse/services/autoCombo/scoring.ts` → `DEFAULT_WEIGHTS` တွင် သတ်မှတ်ထားသည်) အသုံးပြုပြီး အလိုအလျောက် ရွေးချယ်ပေးသည်။ မူလ weight များ၏ စုစုပေါင်းသည် `1.0` ဖြစ်ပြီး custom weight များကို `normalizeScoringWeights()` ဖြင့် ပြန်လည်စံသတ်မှတ်သည်။ အချက် ဆယ့်ခြောက်ချက်အနက် `cacheAffinity` နှင့် `resetWindowAffinity` နှစ်ခု၏ မူလ weight သည် `0` ဖြစ်သည်။ `reliability` ၏ weight သည် `DEFAULT_WEIGHTS` တွင် `0` ဖြစ်သော်လည်း ယေဘုယျ pack များတွင် `0.03` နှင့် `reliability-first` တွင် `0.04` ဖြစ်ပြီး၊ `quality` ၏ weight သည် pack များတွင် `0.02` (`quality-first` တွင် `0.03`) ဖြစ်သည်။ ၎င်းတို့ကို candidate တစ်ခုချင်းစီအတွက် တွက်ချက်ဆဲဖြစ်ပြီး `cacheAffinity` သည် score ပြင်ပရှိ prompt-cache ထပ်နေမှုဖယ်ရှားခြင်းကို ထိန်းချုပ်သည်။ ထို့ကြောင့် မူလတန်ဖိုး သုညဖြစ်သော အချက်များသည် ပုံမှန်အားဖြင့် မဲမပေးသော်လည်း pack များကမူ မဲပေးသည်။ ![Auto-Combo ၏ အချက် 16 ချက်ပါ scoring](../diagrams/exported/auto-combo-scoring.svg) > မူရင်းရင်းမြစ်- [diagrams/auto-combo-scoring.mmd](../diagrams/auto-combo-scoring.mmd) (`npm run docs:render-diagrams` ဖြင့် ပြန်လည်ဖန်တီးပါ)။ ဖိုင်အမည်မှာ သမိုင်းကြောင်းအရ ကျန်ရှိနေခြင်းဖြစ်ပြီး မူရင်းရင်းမြစ်နှင့် ဖန်တီးထားသော diagram တို့တွင် `DEFAULT_WEIGHTS` ၌ ကြေညာထားသည့် အချက် 16 ချက်လုံးကို ပြသထားသည်။ | အချက် | မူလ Weight | ဖော်ပြချက် | | :-------------------- | :--------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `quota` | 0.1429 | ကျန်ရှိသော quota / rate-limit အပိုပမာဏ [0..1] | | `health` | 0.1605 | circuit breaker မှ health score (CLOSED=1.0, HALF_OPEN=0.5, OPEN=0.0) | | `costInv` | 0.1429 | **ရောစပ်ထားသော** ကုန်ကျစရိတ်၏ ပြောင်းပြန်တန်ဖိုး (input token ဈေးနှုန်း 60% + output token ဈေးနှုန်း 40%၊ စံသတ်မှတ်ထားသည်) — ဈေးသက်သာလေလေ score မြင့်လေလေ | | `latencyInv` | 0.1143 | pool နှင့် နှိုင်းယှဉ်၍ စံသတ်မှတ်ထားသော p95 latency ၏ ပြောင်းပြန်တန်ဖိုး — ပိုမြန်လေလေ score မြင့်လေလေ | | `taskFit` | 0.0762 | လုပ်ငန်းအမျိုးအစားနှင့် ကိုက်ညီမှု (coding၊ review၊ planning၊ analysis၊ debugging၊ docs) | | `stability` | 0.0476 | latency standard deviation မှ variance အခြေခံ တည်ငြိမ်မှု — response time အပြောင်းအလဲများသော candidate သည် score ပိုနိမ့်သည် | | `tierPriority` | 0.0476 | account-tier ဦးစားပေးမှု — Ultra=1.0၊ Pro=0.67၊ Standard=0.33၊ Free=0.0 | | `tierAffinity` | 0.0476 | candidate ၏ tier နှင့် manifest က အကြံပြုထားသော tier အကြား ကိုက်ညီမှု | | `specificityMatch` | 0.0476 | request ၏ တိကျသတ်မှတ်မှု (manifest hint) နှင့် model tier အကြား ကိုက်ညီမှု | | `contextAffinity` | 0.0476 | request အတွက် လိုအပ်သော context-window နှင့် model ၏ context window အကြား ကိုက်ညီမှု | | `sessionAvailability` | 0.0476 | ဤ session အတွက် candidate connection ၏ OAuth session ရရှိနိုင်မှု (`getOAuthSessionAvailability()`; OAuth မဟုတ်သော connection များသည် score 1.0 ရရှိသည်) | | `connectionDensity` | 0.0476 | provider တူညီသော connection များအကြား load ကို ဖြန့်ဝေပေးခြင်း (တစ်နေရာတည်းတွင် စုစည်းမှုကို တားဆီးခြင်း) | | `cacheAffinity` | 0.00 | ဤ request ၏ prompt-cache prefix ကို သိမ်းထားပြီးဖြစ်နိုင်ခြေအများဆုံး connection ထံ Rendezvous-hash ဖြင့် ဆွဲငင်ကိုက်ညီမှု (`open-sse/services/combo/promptCacheAffinity.ts`); မူလအားဖြင့် ပိတ်ထားသည် (#8008) | | `resetWindowAffinity` | 0.00 | quota reset window အဆင်ပြေသော connection များဘက်သို့ ဦးစားပေးခြင်း (မူလအားဖြင့် ပိတ်ထားသည်) | | `quality` | 0.03 | routing-event quality tracker မှ feedback အခြေခံ output-quality signal; observation မရှိသော candidate များသည် ကြားနေတန်ဖိုး 0.5 ရရှိသည် | | `reliability` | 0.00 | အနည်းဆုံး sample ဆယ်ခု လိုအပ်ချက်အောက်ရှိ 24h usage history မှ တွေ့ရှိထားသော အောင်မြင်မှုအချိုး `1 - failureRate` (ထိုသို့မဟုတ်ပါက real-time metrics); observation မရှိသော candidate များကို 1.0 ဟု သတ်မှတ်သည်။ မူလအားဖြင့် ပိတ်ထားသည် | **စုစုပေါင်း:** `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` ဖြစ်သည်။ အသုံးပြုသူ သတ်မှတ်ထားသော weight များကို scoring မလုပ်မီ `normalizeScoringWeights()` ဖြင့် distribution တစ်ခုအဖြစ် ပြန်လည်စံသတ်မှတ်သည်။ ## မုဒ် Pack များ `open-sse/services/autoCombo/modePacks.ts` တွင် ကြိုတင်သတ်မှတ်ထားသော weight profile ၆ ခုရှိသည်။ Pack တစ်ခုစီသည် ရွေးချယ်မှုကို ပန်းတိုင်တစ်ခုဆီ ဦးစားပေးစေရန် default weight များကို အပြည့်အဝ အစားထိုးသည်။ Pack တိုင်း၏ စုစုပေါင်းသည် `1.0` (ဒဿမလေးနေရာဖြင့် ဖော်ပြသည့်အခါ `0.9999`) ဖြစ်ပြီးသားဖြစ်သောကြောင့် pack တစ်ခု အသုံးပြုနေချိန်တွင် `normalizeScoringWeights()` က အဓိပ္ပာယ်ရှိစွာ ပြင်ဆင်ပေးစရာ မရှိပါ — အောက်ပါ value များသည် rounding ကို ထည့်သွင်းစဉ်းစားပါက scorer က အသုံးပြုသည့် value များပင် ဖြစ်သည်။ | အချက် | 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 | မှတ်ချက်များ: - **Pack များတွင် `quality` နှင့် `reliability` ပါဝင်သည်** (`quality 0.02`, `quality-first 0.03`; `reliability 0.03`, `reliability-first 0.04`)၊ ထို့ပြင် weight map တစ်ခုလုံးကို အစားထိုးသည် (`weights = pack` ဖြစ်ပြီး merge မဟုတ်ပါ)။ `DEFAULT_WEIGHTS` တွင် `quality 0.03 / reliability 0` ပါဝင်သည်။ `balanced`/`default` ကို ရွေးချယ်ပါက ထို default များကို ဆက်လက်အသုံးပြုပြီး၊ pack တစ်ခုကို ရွေးချယ်ပါက အထက်ပါ pack ၏ value များကို အသုံးပြုသည်။ Cold pool တစ်ခုတွင် (လေ့လာထားသော observation မရှိသေးသဖြင့် `quality 0.5` နှင့် `reliability 1`) ဤအချက်နှစ်ခုသည် သာမန် pack အောက်တွင် `+0.04` (`0.03 + 0.01`)၊ `quality-first` အောက်တွင် `+0.045` နှင့် `reliability-first` အောက်တွင် `+0.05` ထည့်ပေါင်းပေးသည်။ - `tierAffinity`, `specificityMatch` နှင့် `resetWindowAffinity` တို့ကို pack တိုင်းတွင် `0` ဟု အတိအလင်း သတ်မှတ်ထားသည်။ - Pack တစ်ခုစီ၏ အလေးပေးချက်ကို အကျဉ်းချုပ်ကြည့်လျှင်: - **ship-fast** → latencyInv 0.3048 + health 0.2667 (latency နည်းပြီး ကောင်းမွန်သော connection များ) - **cost-saver** → costInv 0.3324 (စျေးအသက်သာဆုံး token များကို ဦးစားပေးသည်) - **quality-first** → taskFit 0.3524 + stability 0.1429 + quality 0.03၊ pack အားလုံးအနက် အမြင့်ဆုံး (task အတွက် အကောင်းဆုံးဖြစ်ပြီး တသမတ်တည်းရှိသော model) - **offline-friendly** → quota 0.3324 + health 0.2667 (အမြန်နှုန်း/ကုန်ကျစရိတ်ကို မထည့်သွင်းဘဲ headroom ကို အများဆုံးထားသည်) - **reliability-first** → health 0.3524 + stability 0.1905 + reliability 0.04၊ pack အားလုံးအနက် အမြင့်ဆုံး (မမျှော်လင့်ထားသော အခြေအနေ အနည်းဆုံး) - **chaos-mode** → health 0.4000 + taskFit 0.1905 (fault-injection profile) ### Request တစ်ခုချင်းအလိုက် ထိန်းချုပ်မှုများ (header များ) — #6023 / #6024 / #6025 / #3470 `auto` combo တစ်ခုကို သိမ်းဆည်းထားသော combo config ကို မပြောင်းလဲဘဲ header သုံးခုမှတစ်ဆင့် **request တစ်ခုချင်းအလိုက်** ထိန်းညှိနိုင်သည်။ ၎င်းတို့သည် `auto` strategy အတွက်သာ သက်ရောက်ပြီး ၎င်းတို့ပါဝင်သော request အတွက်သာ အသုံးချသည်။ Header မပါရှိသည့်အခါ combo တွင် သိမ်းဆည်းထားသော `modePack`/`budgetCap`/`budgetFallback` ကို အသုံးပြုသည်။ | Header | လက်ခံသည့်တန်ဖိုးများ | သက်ရောက်မှု | | :---------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `X-OmniRoute-Mode` | ကြိုတင်သတ်မှတ်ထားသော alias (`fast`, `balanced`, `quality`, `cheap`, `reliable`, `offline`) သို့မဟုတ် မူရင်း pack အမည် (`ship-fast`, `cost-saver`, `quality-first`, `offline-friendly`, `reliability-first`) | ဤ request အတွက် scoring weight များကို အစားထိုးသတ်မှတ်သည်။ `balanced`/`default` သည် မူလ weight များကို အတင်းအသုံးပြုစေသည် (pack မသုံးပါ)။ မသိသောတန်ဖိုးများကို လျစ်လျူရှုသည် (config ကို မပြောင်းလဲဘဲ ထိန်းသိမ်းထားသည်)။ | | `X-OmniRoute-Budget` | အပေါင်းကိန်းတစ်ခု (request တစ်ခုလျှင် အများဆုံး USD) | ကုန်ကျစရိတ်အတွက် တင်းကျပ်သော အမြင့်ဆုံးကန့်သတ်ချက်ဖြစ်သည်။ ခန့်မှန်းကုန်ကျစရိတ်က ယင်းကန့်သတ်ချက်ထက် ကျော်လွန်သော candidate များကို ရွေးချယ်မှုမပြုမီ စစ်ထုတ်ဖယ်ရှားသည်။ candidate **အားလုံး** ယင်းကန့်သတ်ချက်ထက် ကျော်လွန်ပါက မည်သို့လုပ်ဆောင်မည်ကို အောက်ပါ `X-OmniRoute-Budget-Fallback` က ထိန်းချုပ်သည်။ | | `X-OmniRoute-Budget-Fallback` | `cheapest` (မူလတန်ဖိုး၊ alias များ- `cheapest-viable`, `soft`) သို့မဟုတ် `strict` (alias များ- `block`, `hard`) | `cheapest`: ကန့်သတ်ချက်ကို ကျော်လွန်နေသေးသော်လည်း စုစုပေါင်းထဲမှ စျေးအသက်သာဆုံး candidate ကို fallback အဖြစ် ရွေးချယ်သည် (ယခင်အပြုအမူ)။ `strict`: ရွေးချယ်ရန် ငြင်းဆိုသည် — မသိမသာ ဘတ်ဂျက်ကျော်သုံးစွဲမည့်အစား request သည် `HTTP 402` ဖြင့် ချက်ချင်း မအောင်မြင်ဘဲ ရပ်တန့်သည်။ မသိသောတန်ဖိုးများကို လျစ်လျူရှုသည်။ | | `X-OmniRoute-Effort` | `auto` (အခြားတန်ဖိုးများကို နောင်အသုံးပြုရန် သီးသန့်ထားသည်) | အလိုက်သင့်ပြောင်းလဲသော thinking budget ဖြစ်သည်။ request တွင် မည်သည့်ပုံစံဖြင့်မဆို reasoning field (`reasoning_effort`, `reasoning`, `thinking`) **မပါရှိပါက** gateway သည် သတ်မှတ်ချက်တိကျသော request-shape signal များ (နောက်ဆုံး user message ၏ အလျား၊ နောက်ဆုံး user message အထိ context အရွယ်အစား၊ ယခင် tool result များ၊ tool-loop အနက်) ကို အခြေခံ၍ `auto` ကို `low`/`medium`/`high` အဖြစ် သတ်မှတ်ဖြေရှင်းသည်။ Signal များသည် လက်ရှိ turn အတွင်းသာ အကျုံးဝင်သည် — နောက်ဆုံး user message နောက်ပိုင်းရှိ အရာအားလုံးကို လျစ်လျူရှုသည် — ထို့ကြောင့် tool loop တစ်ခုအတွင်းရှိ request တိုင်းသည် တူညီသောအဆင့်သို့ သတ်မှတ်ဖြေရှင်းသည် (turn တစ်ခုချင်းစီအတွက် stateless pin ဖြစ်ပြီး session state မရှိသလို upstream prompt-cache prefix များကို ပျက်စီးစေမည့် loop အလယ်ပိုင်း escalation လည်း မရှိပါ)။ Client က reasoning field ကို တိတိကျကျ သတ်မှတ်ထားပါက ယင်းကို အမြဲဦးစားပေးသည်။ Upstream dispatch က OpenAI Chat Completions ပုံစံ (`targetFormat === FORMATS.OPENAI`) သို့ သတ်မှတ်ဖြေရှင်းသော request များအတွက်သာ အကျုံးဝင်သည် — `reasoning_effort` သည် OpenAI ပုံစံ field ဖြစ်သောကြောင့် Claude သို့မဟုတ် Gemini ကို ရည်ရွယ်သည့် request တွင် ဤ header သည် မည်သည့်အကျိုးသက်ရောက်မှုမျှ မရှိပါ (`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"}]}' ``` ဖြေရှင်းသတ်မှတ်မှုသည် pure function (`open-sse/services/autoCombo/requestControls.ts`) တစ်ခုဖြစ်ပြီး၊ ဖြေရှင်းသတ်မှတ်ပြီးသော တန်ဖိုးများကို engine ၏ လက်ရှိ `config.modePack` / `config.budgetCap` / `config.budgetFallback` input များထဲသို့ ထည့်သွင်းသည်။ combo တစ်ခုတွင် သိမ်းဆည်းထားသော `config.budgetFallback` ("strict" | "cheapest") သည် အမြဲတမ်းမူဝါဒကို သတ်မှတ်ပြီး၊ header က တောင်းဆိုမှုတစ်ခုတည်းအတွက် ၎င်းကို အစားထိုးသတ်မှတ်သည်။ ## Routing Strategy အားလုံး OmniRoute ၏ combo engine သည် **routing strategy 19 ခု** (`src/shared/constants/routingStrategies.ts` → `ROUTING_STRATEGY_VALUES` တွင် ကြေညာထားသည်) ကို ပံ့ပိုးပေးသည်။ Auto Combo engine ကိုယ်တိုင်ကို `auto` strategy အောက်တွင် ဖော်ထုတ်ပေးထားပြီး အခြား strategy များကို သိမ်းဆည်းထားသော combo များအတွက် အသုံးပြုနိုင်သည်။ | Strategy | ဖော်ပြချက် | | :------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `priority` | တိကျစွာသတ်မှတ်ထားသော ဦးစားပေးအစီအစဉ်ဖြင့် ပထမ target ကို အခြေခံသည့် စီစဉ်ထားသောစာရင်း | | `weighted` | target တစ်ခုချင်းစီ၏ weight အလိုက် အလေးပေး ကျပန်းရွေးချယ်မှု | | `round-robin` | target များကို အစဉ်လိုက် လှည့်ပတ်အသုံးပြုခြင်း | | `context-relay` | target များတစ်လျှောက် context ကို လွှဲပြောင်းပေးခြင်း (ရှည်လျားသော စကားဝိုင်းများ) | | `fill-first` | နောက် target သို့ မရွှေ့မီ target တစ်ခုချင်းစီ၏ quota ကို ပြည့်အောင် အသုံးပြုခြင်း | | `p2c` | Power-of-2-choices ကျပန်း load balancing | | `random` | တစ်ပြေးညီ ကျပန်းရွေးချယ်မှု | | `least-used` | လက်ရှိ load အနည်းဆုံးရှိသော target ကို ရွေးချယ်ခြင်း | | `cost-optimized` | catalog pricing အရ request တစ်ခုချင်းစီအတွက် $ ကုန်ကျစရိတ်ကို အနည်းဆုံးဖြစ်အောင် ပြုလုပ်ခြင်း | | `reset-aware` ⭐ | quota reset အချိန်အလိုက် ဦးစားပေးခြင်း — reset window တိုသောအရာများကို အဆင့်ပိုမြင့်စွာ သတ်မှတ်ခြင်း | | `reset-window` | quota window အစောဆုံး reset ဖြစ်မည့် target များကို ဦးစားပေးခြင်း | | `headroom` | ကျန်ရှိနေသည့် quota headroom အများဆုံးရှိသော target ကို ရွေးချယ်ခြင်း | | `strict-random` | ထပ်တလဲလဲဖြစ်မှုများကို deduplication မပြုလုပ်ဘဲ ကျပန်းရွေးချယ်ခြင်း | | `auto` | Auto Combo scoring (အချက် 16 ချက်) ကို အသုံးပြုခြင်း — **အကြံပြုထားသည်** | | `lkgp` | Last-Known-Good Path (နောက်ဆုံးအောင်မြင်ခဲ့သော provider တွင် ချိတ်ထားပြီးနောက် rules များသို့ fallback ပြုလုပ်သည်) | | `context-optimized` | လက်ရှိ context size နှင့် အကိုက်ညီဆုံး target ကို ရွေးချယ်ခြင်း | | `cache-optimized` | prompt-cache affinity အလိုက် target များကို ပြန်လည်စီခြင်း — ဤ request ၏ cached prefix ကို ကိုင်ထားပြီးဖြစ်နိုင်ခြေအများဆုံး connection ကို ဦးစွာ စမ်းသပ်သည် (`open-sse/services/combo/promptCacheAffinity.ts`, #8008) | | `fusion` 🧬 | model အစုတစ်ခုထံသို့ တစ်ပြိုင်နက်တည်း ဖြန့်ပို့ပြီးနောက် judge တစ်ခုမှ အဖြေတစ်ခုတည်းအဖြစ် ပေါင်းစပ်ပေးခြင်း (အောက်တွင်ကြည့်ပါ) | | `pipeline` | target များကို အစဉ်လိုက် run ပြီး အဆင့်တစ်ခုချင်းစီ၏ output ကို နောက်အဆင့်၏ input ထဲသို့ ဆက်လက်ထည့်သွင်းခြင်း၊ နောက်ဆုံးအဖြေကိုသာ ပြန်ပေးသည် (#6396) | ⭐ = v3.8.0 တွင် အသစ်ပါဝင်သည် · 🧬 = v3.8.36 တွင် အသစ်ပါဝင်သည် ### `weighted` ၏ လုပ်ဆောင်ပုံအဓိပ္ပာယ် `weighted` သည် တူညီအောင်ထိန်းညှိပေးသည့်စနစ် မဟုတ်ဘဲ **request တစ်ခုချင်းစီအလိုက် အချိုးကျ ကျပန်းရွေးချယ်မှု** (`open-sse/services/combo/targetSorters.ts` → `selectWeightedTarget`) ဖြစ်သည်- - request တစ်ခုချင်းစီသည် ဖြစ်နိုင်ခြေ `weight / totalWeight` ဖြင့် အဆင့် **တစ်ခု** ကို ရွေးချယ်သည်၊ ကျန်အဆင့်များကိုမူ ထို request အတွက် fallback chain အဖြစ် weight ကြီးစဉ်ငယ်လိုက် စီစဉ်ထားသည်။ - weight `0` ရှိသော (သို့မဟုတ် weight မပါရှိသော) အဆင့်တစ်ခုသည် အခြားအဆင့်တစ်ခုခုတွင် weight > 0 ရှိနေသရွေ့ **ဘယ်သောအခါမျှ ရွေးချယ်ခံရမည်မဟုတ်ပါ** — ရွေးချယ်ထားသောအဆင့် မအောင်မြင်ပြီးနောက်မှသာ fallback အဖြစ် အသုံးပြုနိုင်သည်။ weight **အားလုံး** 0 ဖြစ်သည့်အခါမှသာ ရွေးချယ်မှုသည် တစ်ပြေးညီဖြစ်လာသည်။ - target အားလုံး အသုံးမပြုနိုင်သော အဆင့်များ — provider circuit breaker `OPEN`, connection cooldown, model lockout — ကို ရွေးချယ်မှုမပြုလုပ်မီ ဖယ်ရှားထားသည် (`open-sse/services/combo/targetResolution.ts`)၊ ထို့ကြောင့် ကျန်းမာစွာအလုပ်လုပ်နေသော အဆင့်တစ်ခုတည်းက request အားလုံးကို ယာယီ ရရှိနိုင်သည်။ - `stickyWeightedLimit` (combo config၊ မူလသတ်မှတ်ချက် `1` = ပိတ်ထားသည်) သည် ထပ်မံရွေးချယ်ခြင်းမပြုမီ ဆက်တိုက်အောင်မြင်မှု အရေအတွက်သတ်မှတ်ထားသလောက် ရွေးချယ်ထားသောအဆင့်တွင် ချိတ်ထားပေးသည်။ တိကျသော အလှည့်ကျအသုံးပြုမှုအတွက် `round-robin` ကို အသုံးပြုပါ။ `weighted` တွင် weight များ တူညီခြင်းက တိကျသော balance မဟုတ်ဘဲ စာရင်းအင်းအရ balance ကိုသာ ရရှိစေသည်။ ## Fusion မဟာဗျူဟာ `fusion` သည် ပစ်မှတ်တစ်ခုတည်းကို **မရွေးချယ်သည့်** တစ်ခုတည်းသော မဟာဗျူဟာဖြစ်သည်။ ၎င်းသည် prompt ကို **panel model အားလုံးထံ တစ်ပြိုင်နက်တည်း** ဖြန့်ပို့ပြီးနောက် ပြင်ဆင်သတ်မှတ်နိုင်သော **judge model** က panel တုံ့ပြန်ချက်အားလုံးမှ နောက်ဆုံးအဖြေတစ်ခုတည်းကို ပေါင်းစပ်ထုတ်ပေးသည်။ မူရင်း `decolua/9router` (OpenRouter ၏ Fusion ဒီဇိုင်း) မှ ပြောင်းရွှေ့ယူထားပြီး အကောင်အထည်ဖော်မှုမှာ `open-sse/services/fusion.ts` တွင်ရှိသည်။ အလုပ်လုပ်ပုံ- 0. **Tool ပါဝင်သော တောင်းဆိုမှုကို ကျော်လွှားခြင်း** — အလွတ်မဟုတ်သော `tools` array ပါဝင်ပြီး `tool_choice` ကို `"none"` ဟု တိတိကျကျ မသတ်မှတ်ထားသော တောင်းဆိုမှုသည် panel ကို လုံးဝကျော်သွားသည်။ ၎င်းကို model တစ်ခုတည်း (ပြင်ဆင်သတ်မှတ်ထားသော judge သို့မဟုတ် `panel[0]`) ထံသို့ `tools`/`tool_choice` ကို မပြောင်းလဲဘဲ တိုက်ရိုက်လမ်းကြောင်းပေးသည်။ Panel အဖွဲ့ဝင်များသည် tool အသုံးပြုခွင့်မရှိသည့်အပြင် judge ၏ ပေါင်းစပ်ရေးသားမှု ညွှန်ကြားချက်က tool-call ထုတ်လွှတ်ခြင်းကို အားမပေးသောကြောင့် agentic/tool-calling client များသည် ပေါင်းစပ်ရေးသားထားသော စာသားအစား တကယ့် tool-call ဆုံးဖြတ်ချက်ကို ရရှိသည် (#6771)။ 1. **ဖြန့်ခွဲပို့ခြင်း** (tool မပါသော တောင်းဆိုမှုများသာ) — prompt ကို panel model အားလုံးထံ တစ်ပြိုင်နက်တည်း ပို့ပြီး tools များကို ဖယ်ရှားကာ non-streaming ဖြစ်ရန် အတင်းသတ်မှတ်သည် (judge သည် ပေါင်းစပ်ရေးသားရန် စာသားအပြည့်အစုံ လိုအပ်သည်)။ 2. **Quorum-grace စုဆောင်းခြင်း** — `minPanel` အဖြေများ ရောက်လာသည်နှင့် ကျန်နေသူများအတွက် grace timer အတိုတစ်ခု စတင်ပြီးနောက် ရရှိစုဆောင်းထားသမျှဖြင့် fusion ကို ဆက်လက်လုပ်ဆောင်သည်။ ဤနည်းဖြင့် အနှေးဆုံး model ကြောင့် wall time တွင် ဖြစ်ပေါ်သော နှောင့်နှေးမှုကို ကန့်သတ်ပေးပြီး hard timeout ဖြင့် အမြင့်ဆုံးကန့်သတ်ထားသည်။ 3. **Judge ဖြင့် ပေါင်းစပ်ရေးသားခြင်း** — panel အဖြေများကို အမည်မဖော်ဘဲ (`Source 1`, `Source 2`, … — ထို့ကြောင့် judge သည် model အမှတ်တံဆိပ်မဟုတ်ဘဲ အကြောင်းအရာကို အလေးထားသည်) judge ထံ လွှဲပေးသည်။ ထို့နောက် judge က သဘောတူညီချက် / ဆန့်ကျင်ကွဲလွဲချက်များ / တစ်စိတ်တစ်ပိုင်းသာ ခြုံငုံမိမှု / ထူးခြားသော ထိုးထွင်းသိမြင်မှုများ / မမြင်မိသော အချက်များကို ခွဲခြမ်းစိတ်ဖြာပြီး ယုံကြည်အားထားရသော အဖြေ **တစ်ခုတည်း** ကို ရေးသားသည်။ Judge call သည် client ၏ မူလ `stream` flag နှင့် tools များကို ဆက်လက်ထိန်းသိမ်းထားသောကြောင့် streaming နှင့် downstream tool အသုံးပြုမှုတို့ ဆက်လက်အလုပ်လုပ်သည်။ 4. **ချောမွေ့စွာ အဆင့်လျှော့လုပ်ဆောင်ခြင်း** — panel အဖြေ 0 ခု → `503`; အဖြေ 1 ခုတည်းသာ ကျန်ရှိခြင်း → ထိုအဖြေကို တိုက်ရိုက်ပြန်ပေးသည် (ပေါင်းစပ်စရာမရှိပါ); model တစ်ခုတည်းပါသော panel သည် တိုက်ရိုက်ဖြေဆိုသည်။ Panel အဖွဲ့ဝင်တစ်ခုသည် အခြား combo ကို ရည်ညွှန်းသော `combo-ref` အဆင့် (`{kind: "combo-ref", comboName: "..."}`) လည်း ဖြစ်နိုင်သည် — ၎င်းကို **black-box panel အသံတစ်ခုတည်း** အဖြစ် ဖြေရှင်းသည် (ရည်ညွှန်းထားသော combo သို့ အပြည့်အဝ recursive dispatch လုပ်ခြင်းဖြစ်ပြီး ထို combo ၏ ကိုယ်ပိုင်ပစ်မှတ်များကို ဖြန့်ခွဲပို့ခြင်းမဟုတ်ပါ)။ ထို့ပြင် အခြား combo-ref အသုံးပြုသည့် မဟာဗျူဟာတိုင်းတွင် ရှိပြီးသား တူညီသော depth/cycle ကာကွယ်မှုကို အသုံးပြုသည် (#6764)။ ### ပြင်ဆင်သတ်မှတ်မှု Combo ၏ `config` blob တွင် ပြင်ဆင်သတ်မှတ်သည် (schema migration မလိုအပ်ပါ — ရှိပြီးသား `combos` table ကို ပြန်လည်အသုံးပြုသည်)- | Field | Type | Default | Purpose | | :--------------------------------------- | :------- | :-------------- | :----------------------------------------------------------------------------------------------------- | | `config.judgeModel` | `string` | ပထမ panel model | နောက်ဆုံးအဖြေကို ပေါင်းစပ်ရေးသားသည့် model | | `config.fusionTuning.minPanel` | `number` | `2` | grace timer မစတင်မီ လိုအပ်သော အောင်မြင်သည့်အဖြေ အရေအတွက် (`[2, panelSize]` အတွင်း ကန့်သတ်ထားသည်) | | `config.fusionTuning.stragglerGraceMs` | `number` | `8000` | quorum ပြည့်ပြီးနောက် နောက်ကျနေသူများကို စောင့်ဆိုင်းမည့်ကြာချိန် | | `config.fusionTuning.panelHardTimeoutMs` | `number` | `90000` | model တစ်ခု ရပ်တန့်နေခြင်းကြောင့် တောင်းဆိုမှု တစ်ခုလုံး မနှောင့်နှေးစေရန် အကြွင်းမဲ့အချိန်ကန့်သတ်ချက် | မူလတန်ဖိုးများကို `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 } } }' ``` ထို့နောက် မည်သည့် combo ကိုမဆို ခေါ်သကဲ့သို့ ၎င်းကို ခေါ်ပါ- `{"model":"fusion-panel","messages":[...]}`။ ## Virtual Auto-Combo Factory Auto Combo အင်ဂျင်သည် ကြိုတင်သတ်မှတ်ထားသော combo များကို မလိုအပ်ပါ။ ယင်းအစား `open-sse/services/autoCombo/virtualFactory.ts` သည် candidate များကို လိုအပ်သည့်အချိန်တွင် ချက်ချင်းတည်ဆောက်သည်- 1. `getProviderConnections({ isActive: true })` (ဖွင့်ထားသော connection အားလုံး) ကို ရယူသည် 2. မှန်ကန်သော credential များရှိသည့် connection များကို စစ်ထုတ်သည် (API key သို့မဟုတ် `hasUsableOAuthToken()` မှတစ်ဆင့် သက်တမ်းမကုန်သေးသော OAuth token) 3. Model ရရှိနိုင်မှုနှင့် ဈေးနှုန်းအတွက် `getProviderRegistry()` နှင့် အပြန်အလှန်တိုက်ဆိုင်စစ်ဆေးသည် 4. `(provider, model, connection)` tuple တစ်ခုစီအတွက် `VirtualAutoComboCandidate` တစ်ခု တည်ဆောက်သည် 5. Dispatch target အဖြစ် `connection.defaultModel` (သို့မဟုတ် registry ၏ ပထမဆုံး model) ကို ရွေးချယ်သည် 6. 16-factor `scorePool()` နှင့် variant ၏ weight pack ကို အသုံးပြု၍ candidate တစ်ခုစီကို အမှတ်ပေးသည် 7. `handleComboChat()` အတွက် ရရှိလာသော memory အတွင်းရှိ `AutoComboConfig` ကို ပြန်ပေးသည် — DB ထဲသို့ မည်သည့်အခါမျှ သိမ်းဆည်းထားခြင်းမရှိပါ ဆိုလိုသည်မှာ **`auto/*` ဖွင့်ထားသော provider အသစ်တစ်ခုကို ထည့်သွင်းခြင်းသည် candidate pool ကို အလိုအလျောက်ချဲ့ထွင်ပေးသည်** — combo ကို ကိုယ်တိုင်ပြင်ဆင်ရန် မလိုအပ်ပါ။ Virtual combo ကို request တစ်ခုစီအတွက် ပြန်လည်တည်ဆောက်သောကြောင့် အသစ်ထည့်ထားသော သို့မဟုတ် ပြန်လည်ကျန်းမာလာသော connection များကို ချက်ချင်းရွေးချယ်နိုင်သည်။ ## ကိုယ်တိုင်ပြန်လည်ပြုပြင်ခြင်း - **ယာယီဖယ်ထုတ်ခြင်း**: Score < 0.2 → 5 min ကြာ ဖယ်ထုတ်မည် (တဖြည်းဖြည်းတိုးလာသော backoff၊ အများဆုံး 30 min) - **Circuit breaker အခြေအနေကို သိရှိခြင်း**: OPEN → အလိုအလျောက်ဖယ်ထုတ်မည်၊ HALF_OPEN → စမ်းသပ် request များ - **Incident mode**: >50% OPEN → exploration ကို ပိတ်ပြီး တည်ငြိမ်မှုကို အမြင့်ဆုံးဖြစ်စေမည် - **Cooldown ပြီးနောက် ပြန်လည်ကောင်းမွန်ခြင်း**: ဖယ်ထုတ်မှုအပြီး ပထမဆုံး request သည် timeout လျှော့ထားသော "probe" တစ်ခုဖြစ်သည် ## Bandit Exploration Request များ၏ 5% (ပြင်ဆင်သတ်မှတ်နိုင်သည်) ကို exploration အတွက် ကျပန်း provider များထံ လမ်းကြောင်းပြောင်းပို့သည်။ Incident mode တွင် ပိတ်ထားသည်။ ## API **သီးသန့် `POST /api/combos/auto` endpoint မရှိပါ** — Auto-Combo ကို နည်းလမ်းနှစ်မျိုးဖြင့် အသုံးပြုနိုင်သည်- 1. **Configuration မလိုသောနည်းလမ်း (အကြံပြုထားသည်):** မည်သည့် chat completion request ကိုမဆို `model: "auto"` သို့မဟုတ် `model: "auto/"` ဖြင့် ပေးပို့ပါ။ Virtual factory သည် request တစ်ခုစီအတွက် combo ကို တည်ဆောက်သည် — သိမ်းဆည်းထားခြင်းမရှိသလို API call များလည်း မလိုအပ်ပါ။ 2. **`strategy: "auto"` ပါသော သိမ်းဆည်းထားသည့် combo:** `POST /api/combos` မှတစ်ဆင့် ပုံမှန် combo တစ်ခု ဖန်တီးပြီး `strategy: "auto"` နှင့်အတူ `config.auto.weights` / `config.auto.candidatePool` ကို သတ်မှတ်ပါ။ တူညီသော scoring engine ကို အသုံးပြုသည်။ Combo ကို `combos` ထဲတွင် သိမ်းဆည်းပြီး ID ဖြင့် ပြန်လည်အသုံးပြုနိုင်သည်။ ရှာဖွေကြည့်ရှုရန်အတွက် `GET /api/combos/auto` သည် ဖြေရှင်းသတ်မှတ်ပြီးသော candidate pool နှင့် `context_length` / `max_output_tokens` တို့ပါဝင်သည့် variant အားလုံးကို စာရင်းပြုစုပေးသည် — ယင်းတန်ဖိုးများသည် candidate pool ၏ window များအနက် အမြင့်ဆုံး MAX တန်ဖိုးဖြစ်သည်။ Client များ (ဥပမာ opencode plugin) သည် `0` အစား ဤတန်ဖိုးများကို ဖော်ပြရမည်။ Context သုညဖြစ်ပါက opencode ၏ auto-compaction ကို လုံးဝပိတ်သွားစေပြီး gateway ၏ history purge က context ကို မဖျက်ဆီးမချင်း session များကို ဆက်လက်ကြီးထွားစေသည်။ Auto-combo context pre-filter သည် အရွယ်အစားကျော်လွန်သော request များကို window ကြီးသော candidate များထံ လမ်းကြောင်းပြောင်းပို့သောကြောင့် MAX ကို ဖော်ပြခြင်းသည် ဘေးကင်းသည်။ ```bash # Combo ဖန်တီးရန်မလိုသော configuration မဲ့ အသုံးပြုမှု 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 endpoint မှတစ်ဆင့် သိမ်းဆည်းထားသော 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}}}}' ``` ### Auto router strategy များ သိမ်းဆည်းထားသော `strategy: "auto"` combo များသည် `config.routerStrategy` (သို့မဟုတ် အဟောင်း `config.auto.routerStrategy`) ကို အောက်ပါတို့အနက် တစ်ခုအဖြစ် သတ်မှတ်နိုင်သည်- - `rules` — ပုံသေ weighted scoring - `score` — ပြင်ဆင်သတ်မှတ်ထားသော weighted score အမြင့်ဆုံးကို ရွေးချယ်သည်။ Score အတိအကျတူညီပါက ပြင်ဆင်သတ်မှတ်ထားသော candidate အစီအစဉ်ကို ထိန်းသိမ်းထားသည်။ ရှိပြီးသား `explorationRate` သည် အဆင့်စီထားသော pool တစ်ခုလုံးမှ နမူနာရွေးသည်။ - `cost` / `eco` — ဈေးအနည်းဆုံး ကျန်းမာသော provider - `latency` / `fast` — reliability penalty ပါဝင်သော အနိမ့်ဆုံး p95 latency - `sla-aware` / `sla` — p95 latency၊ error-rate နှင့် ထည့်သွင်းရန် မဖြစ်မနေမလိုသော cost SLO များကို ပြည့်မီသည့် candidate များကို ဦးစားပေးသည် - `lkgp` — နောက်ဆုံးအကြိမ် အလုပ်လုပ်ကြောင်း သိထားသည့် provider ကို ဦးစွာရွေးသည် ### Router strategy များအကြောင်း အသေးစိတ် Auto-combo အင်ဂျင်သည် `config.routerStrategy` (သို့မဟုတ် အဟောင်း `config.auto.routerStrategy`) မှတစ်ဆင့် အစားထိုးနိုင်သော pluggable **RouterStrategy** implementation 6 ခုကို ပံ့ပိုးပေးသည်။ Strategy တစ်ခုစီသည် `RoutingContext` (task အမျိုးအစား၊ tool/vision hint များ၊ ခန့်မှန်း token အရေအတွက်၊ ထည့်သွင်းရန် မဖြစ်မနေမလိုသော SLA policy၊ ထည့်သွင်းရန် မဖြစ်မနေမလိုသော နောက်ဆုံးအကြိမ် အလုပ်လုပ်ကြောင်း သိထားသည့် provider) ကို အခြေခံ၍ candidate pool မှ provider တစ်ခုကို ရွေးချယ်သည်။ #### 1. `rules` (ပုံသေ) — 16-factor weighted scoring ရှိပြီးသား scoring engine ကို wrapper လုပ်ထားသည်။ `OPEN` circuit-breaker candidate များကို စစ်ထုတ်ပြီးနောက် လက်ရှိ task အမျိုးအစားနှင့် `getTaskFitness()` ကို အသုံးပြု၍ `scorePool()` ကို လုပ်ဆောင်ကာ score အမြင့်ဆုံး provider ကို ရွေးချယ်သည်။ ```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 /* ... */ }; } } ``` **အသုံးပြုသင့်သည့်အချိန်**: ပုံသေရွေးချယ်မှု။ Signal အားလုံးကြား မျှတသော အပေးအယူကို လိုချင်သည့်အခါ အသုံးပြုပါ။ **Alias**: `rules` (alias မရှိပါ) --- #### 2. `cost` / `eco` — ဈေးအနည်းဆုံး ကျန်းမာသော provider Candidate pool ကို `costPer1MTokens` ဖြင့် (ငယ်စဉ်ကြီးလိုက်) စီပြီး ဈေးအနည်းဆုံးကို ရွေးချယ်သည်။ `OPEN` candidate များကို ဦးစွာ စစ်ထုတ်သည်။ ```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 /* ... */ }; } } ``` **အသုံးပြုသင့်သည့်အချိန်**: ကုန်ကျစရိတ်ကို အလေးထားသော workload များ၊ batch processing သို့မဟုတ် နောက်ခံ job များ။ **Alias များ**: `cost`, `eco` --- #### 3. `latency` / `fast` — reliability penalty ပါဝင်သော အနိမ့်ဆုံး p95 latency `p95LatencyMs + (errorRate * 1000)` ဖြင့် စီစဉ်သည်။ အမှားနှုန်းအတွက် ဒဏ်ကြေးကြောင့် ယုံကြည်စိတ်ချရမှုမရှိသော provider များ၏ မူလ latency နည်းနေသည့်တိုင် ၎င်းတို့ကို အဆင့်နိမ့်စေသည်။ ```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 /* ... */ }; } } ``` **အသုံးပြုရန်သင့်သောအချိန်**: အချိန်နှင့်တစ်ပြေးညီ chat၊ autocomplete သို့မဟုတ် အပြန်အလှန်တုံ့ပြန်နိုင်သော coding assistant များကဲ့သို့ latency ကို အလေးထားသည့် workload များ။ **အခြားအမည်များ**: `latency`, `fast` --- #### 4. `sla-aware` / `sla` — latency/error/cost SLO နှင့် ကိုက်ညီမှု သတ်မှတ်ထားသော SLO မူဝါဒကို မည်မျှကောင်းစွာ ဖြည့်ဆည်းနိုင်သည်ကို အခြေခံ၍ candidate တစ်ခုချင်းစီကို အမှတ်ပေးသည်- | အချက် | အလေးချိန် | ဖော်မြူလာ | | --------------- | --------- | ----------------------------------------------------------------------------- | | Latency အမှတ် | 35% | `threshold / max(value, ε)` | | Error အမှတ် | 35% | `threshold / max(value, ε)` | | Health အမှတ် | 15% | `1.0` (CLOSED) / `0.5` (HALF_OPEN) / `0.0` (OPEN) | | Cost အမှတ် | 10% | `threshold / max(value, ε)` သို့မဟုတ် ပြောင်းပြန်ပုံမှန်ပြုလုပ်ထားသော တန်ဖိုး | | Stability အမှတ် | 5% | ပြောင်းပြန်ပုံမှန်ပြုလုပ်ထားသော latency စံသွေဖည်မှု | `hardConstraints: true` ဖြစ်သည့်အခါ candidate များကို အဓိကအားဖြင့် **ချိုးဖောက်မှုအမှတ်** (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) { // ... မူဝါဒနှင့် နှိုင်းယှဉ်၍ candidate တစ်ခုချင်းစီကို အမှတ်ပေးသည်- { targetP95Ms, maxErrorRate, maxCostPer1MTokens, hardConstraints } } } ``` **SLA field များ** (combo config တွင် သတ်မှတ်ပါ)- ```json { "strategy": "auto", "config": { "routerStrategy": "sla-aware", "slaTargetP95Ms": 1500, "slaMaxErrorRate": 0.05, "slaMaxCostPer1MTokens": 5, "slaHardConstraints": true } } ``` **အသုံးပြုရန်သင့်သောအချိန်**: latency၊ အမှားနှုန်း သို့မဟုတ် ကုန်ကျစရိတ် budget များကို တင်းကျပ်စွာ သတ်မှတ်ထားသည့် production workload များ။ **အခြားအမည်များ**: `sla-aware`, `sla` --- #### 5. `lkgp` — နောက်ဆုံးအောင်မြင်ခဲ့သော provider ကို ဦးစွာအသုံးပြုခြင်း သတ်မှတ်ထားပါက **နောက်ဆုံးအောင်မြင်ခဲ့သော provider** ကို ဦးစွာစမ်းသပ်ပြီးနောက် `rules` strategy ကို fallback အဖြစ် အသုံးပြုသည်။ Session stickiness အတွက် အသုံးဝင်ပြီး စကားဝိုင်းတစ်ခုအတွင်း နောက်ဆက်တွဲ request များကို တူညီသော 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 ကို fallback အဖြစ် အသုံးပြုသည် return getStrategy("rules").select(pool, context); } } ``` **အသုံးပြုရန်သင့်သောအချိန်**: နောက်ဆက်တွဲ request များကို တူညီသော provider ဖြင့် ကိုင်တွယ်စေလိုသည့် အလှည့်ပေါင်းများစွာပါဝင်သော စကားဝိုင်းများ (ဥပမာ- caching၊ context ဆက်လက်တည်ရှိမှု သို့မဟုတ် ဈေးနှုန်းတသမတ်တည်းဖြစ်မှုအတွက်)။ **အခြားအမည်**: `lkgp` (အခြားအမည်မရှိပါ) --- ### စိတ်ကြိုက် router strategy များ Public API မှတစ်ဆင့် သင့်ကိုယ်ပိုင် `RouterStrategy` implementation ကို register လုပ်နိုင်သည်- ```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 | အကြောင်းရင်း | | -------------------------------- | ----------- | --------------------------------------------------------- | | ဟန်ချက်ညီသော workload | `rules` | ပုံသေသတ်မှတ်ချက် — အချက်အားလုံးကို ထည့်သွင်းစဉ်းစားသည် | | ကုန်ကျစရိတ်အနည်းဆုံးဖြစ်စေရန် | `cost` | အမြဲတမ်း ဈေးအသက်သာဆုံးကို ရွေးချယ်သည် | | Latency အနည်းဆုံးဖြစ်စေရန် | `latency` | အမြန်ဆုံးနှင့် ယုံကြည်စိတ်ချရသော provider ကို ရွေးချယ်သည် | | တင်းကျပ်သော SLO များ | `sla-aware` | p95/error/cost threshold များဖြင့် စစ်ထုတ်သည် | | အလှည့်ပေါင်းများစွာပါဝင်သော chat | `lkgp` | Session stickiness | SLA-aware field များ- ```json { "strategy": "auto", "config": { "routerStrategy": "sla-aware", "slaTargetP95Ms": 1500, "slaMaxErrorRate": 0.05, "slaMaxCostPer1MTokens": 5, "slaHardConstraints": true } } ``` ## လုပ်ဆောင်ချက်နှင့် ကိုက်ညီမှု လုပ်ဆောင်ချက်အမျိုးအစား 6 မျိုး (`coding`, `review`, `planning`, `analysis`, `debugging`, `documentation`) အလိုက် မော်ဒယ် 30 ကျော်ကို အမှတ်ပေးထားသည်။ Wildcard pattern များကို ပံ့ပိုးသည် (ဥပမာ၊ `*-coder` → coding အမှတ်မြင့်)။ ## Auto Variant များ အကျဉ်းချုပ် မူရင်းဖြစ်သည့် သီးသန့် `auto` နှင့် `autoPrefix.ts` တွင် ကြေညာထားသော `AutoVariant` တန်ဖိုး 6 ခုအပါအဝင်၊ **ခေါ်ယူအသုံးပြုနိုင်သော model ID 7 ခု** ရှိသည်- `auto`, `auto/coding`, `auto/fast`, `auto/cheap`, `auto/offline`, `auto/smart`, `auto/lkgp` (`AutoVariant` ကိုယ်တိုင်သည် တန်ဖိုး 6 ခုကို စာရင်းပြုထားသည်။ 7 ခုမြောက်ရွေးချယ်စရာမှာ "variant မရှိခြင်း" — သီးသန့် `auto` — ဖြစ်ပြီး `parseAutoPrefix()` က `variant: undefined` အဖြစ် ကိုင်တွယ်သည်။) ## Tier များက Auto-Combo နှင့် မည်သို့ ကိုက်ညီသနည်း အချက် 16 ချက်ပါ အမှတ်ပေးလုပ်ဆောင်ချက် (`open-sse/services/autoCombo/scoring.ts`) သည် tier အဖွဲ့ဝင်ဖြစ်မှုကို signal နှစ်ခုအဖြစ် သတ်မှတ်သည်- `tierPriority` (0.0476) နှင့် `tierAffinity` (0.0476)။ `DEFAULT_WEIGHTS` အစုံအလင်အတွက် အထက်ရှိ စံသတ်မှတ်ထားသော [အမှတ်ပေးအချက်ဇယား](#how-it-works-persisted-auto-combos) ကို ကြည့်ပါ — pack တစ်ခုချင်းစီ၏ override များ (ship-fast/cost-saver/quality-first/ offline-friendly) ကို "Pack တစ်ခုချင်းစီအလိုက် အလေးချိန်ပရိုဖိုင်များ" ဇယားတွင် ဖော်ပြထားသည်။ Tier တစ်ခုတည်းဖြင့် Tier 1 ကို ပထမဦးစားပေးရန် **မဖြစ်မနေ** သတ်မှတ်ထားခြင်းမရှိပါ — Tier 1 ၏ latency မကောင်းပါက သို့မဟုတ် ကုန်ကျစရိတ်နှင့် အရည်အသွေးအချိုး မသင့်လျော်ပါက Tier 2 က အနိုင်ရမည်။ Tier အစီအစဉ်ကို မဖြစ်မနေလိုက်နာစေရန် combo strategy `priority` ကို အသုံးပြုပြီး provider များကို tier အလိုက် စီစဉ်ပါ။ Tier 1 (subscription) ကို ပြင်းပြင်းထန်ထန် ဦးစားပေးရန် `tierPriority` အလေးချိန်ကို တိုးမြှင့်ပါ- ```json { "strategy": "auto", "config": { "auto": { "weights": { "tierPriority": 0.3, "costInv": 0.05 } } } } ``` Tier သတ်မှတ်ချက်များနှင့် provider အမျိုးအစားခွဲခြားမှုအတွက် `docs/marketing/TIERS.md` ကို ကြည့်ပါ။ ## စမ်းသပ်ခြင်းနှင့် လွှမ်းခြုံမှု ### တစ်သမတ်တည်း ရလဒ်ထွက်သည့် routing ဆုံးဖြတ်ချက် matrix (`npm run test:combo:matrix`) `tests/integration/combo-matrix/*.test.ts` သည် အတုယူထားသော upstream နှင့် တကယ့် combo pipeline တစ်လျှောက် public strategy 19 ခုစလုံး၏ routing **ဆုံးဖြတ်ချက်** ကို အစမှအဆုံး အတည်ပြုသည်။ လွှမ်းခြုံမှုတွင် အောက်ပါတို့ ပါဝင်သည်- - `ROUTING_STRATEGY_VALUES` strategy 19 ခုစလုံး (ordered, weighted, cost, context, fusion, …)။ - `quota-share` (internal) အစမှအဆုံး- တကယ့် `selectQuotaShareTarget` seam (`registerQuotaFetcher` / `setLKGP` / `__setHeadroomSaturationFetcherForTests`) မှတစ်ဆင့် DRR မျှတမှု + ပြည့်ဝနေမှုကို ဦးစားပေးမှုလျှော့ချခြင်း။ - Target အရေအတွက်တိုင်းအတွက် `context-relay` universal-handoff လွှမ်းခြုံမှု။ ဤ test suite သည် တစ်သမတ်တည်း ရလဒ်ထွက်စေရန်နှင့် live credential များ မလိုအပ်စေရန် CI (`test:integration` job) တွင် `--test-concurrency=1` နှင့် `--test-force-exit` တို့ဖြင့် လုပ်ဆောင်သည်။ ### ကန့်သတ်ချက်ဖြင့် ဖွင့်ထားသော live smoke (CI တွင် မပါဝင်ပါ — တကယ့် provider များ) | Command | လုပ်ဆောင်ချက် | | :------------------------------------- | :----------------------------------------------------------------------------------------------------------------- | | `npm run test:combo:live` | `RUN_COMBO_LIVE=1` ဖြင့် process အတွင်း တကယ့် routing ကို လုပ်ဆောင်ပြီး live OmniRoute DB ၏ snapshot ကို ဖန်တီးသည် | | `npm run test:combo:live:vps` | Live OmniRoute server သို့ HTTP call များ ပြုလုပ်သည် (`COMBO_LIVE_BASE_URL` ကို သတ်မှတ်ပါ) | | `npm run test:combo:live:vps:failover` | တမင်ဖန်တီးထားသော failover scenario များဖြင့် အထက်ပါအတိုင်း လုပ်ဆောင်သည် | ဤ smoke test များသည် တကယ့် wire path (combo → provider → completion) ကို စမ်းသပ်သည်။ Live credential များနှင့် VPS access လိုအပ်သောကြောင့် ၎င်းတို့ကို CI မှ ရည်ရွယ်ချက်ရှိရှိ ဖယ်ထုတ်ထားသည်။ --- ## ဖိုင်များ | ဖိုင် | ရည်ရွယ်ချက် | | :-------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------- | | `open-sse/services/autoCombo/scoring.ts` | အချက် 16 ချက်ပါ အမှတ်ပေးလုပ်ဆောင်ချက်၊ `DEFAULT_WEIGHTS`၊ pool norm | | `open-sse/services/autoCombo/taskFitness.ts` | Model × task ကိုက်ညီမှု ရှာဖွေခြင်း | | `open-sse/services/autoCombo/engine.ts` | ရွေးချယ်မှု logic၊ bandit၊ budget cap | | `open-sse/services/autoCombo/selfHealing.ts` | ဖယ်ထုတ်ခြင်း၊ probes၊ incident mode | | `open-sse/services/autoCombo/modePacks.ts` | weight profile 6 ခု (ship-fast၊ cost-saver၊ quality-first၊ offline-friendly၊ reliability-first၊ chaos-mode) | | `open-sse/services/autoCombo/autoPrefix.ts` | `auto/` prefix parser + variant 6 ခု | | `open-sse/services/autoCombo/virtualFactory.ts` | လက်ရှိချိတ်ဆက်မှုများမှ in-memory `AutoComboConfig` ကို တည်ဆောက်သည် | | `open-sse/services/autoCombo/providerRegistryAccessor.ts` | provider registry ကို mock ပြုလုပ်ရန် test hook | | `src/shared/constants/routingStrategies.ts` | `ROUTING_STRATEGY_VALUES` (strategy 19 ခု) | | `src/sse/handlers/chat.ts` | ပေါင်းစည်းမှု—auto-prefix short-circuit |