# 🗜️ Prompt Compression Guide — OmniRoute (မြန်မာ)

🌐 **Languages:** 🇺🇸 [English](../../../../compression/COMPRESSION_GUIDE.md) · 🇪🇹 [am](../../../am/docs/compression/COMPRESSION_GUIDE.md) · 🇸🇦 [ar](../../../ar/docs/compression/COMPRESSION_GUIDE.md) · 🇦🇿 [az](../../../az/docs/compression/COMPRESSION_GUIDE.md) · 🇧🇬 [bg](../../../bg/docs/compression/COMPRESSION_GUIDE.md) · 🇧🇩 [bn](../../../bn/docs/compression/COMPRESSION_GUIDE.md) · 🇧🇦 [bs](../../../bs/docs/compression/COMPRESSION_GUIDE.md) · 🇨🇿 [cs](../../../cs/docs/compression/COMPRESSION_GUIDE.md) · 🇩🇰 [da](../../../da/docs/compression/COMPRESSION_GUIDE.md) · 🇩🇪 [de](../../../de/docs/compression/COMPRESSION_GUIDE.md) · 🇬🇷 [el](../../../el/docs/compression/COMPRESSION_GUIDE.md) · 🇪🇸 [es](../../../es/docs/compression/COMPRESSION_GUIDE.md) · 🇪🇪 [et](../../../et/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇷 [fa](../../../fa/docs/compression/COMPRESSION_GUIDE.md) · 🇫🇮 [fi](../../../fi/docs/compression/COMPRESSION_GUIDE.md) · 🇫🇷 [fr](../../../fr/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇪 [ga](../../../ga/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [gu](../../../gu/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇬 [ha](../../../ha/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇱 [he](../../../he/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [hi](../../../hi/docs/compression/COMPRESSION_GUIDE.md) · 🇭🇷 [hr](../../../hr/docs/compression/COMPRESSION_GUIDE.md) · 🇭🇺 [hu](../../../hu/docs/compression/COMPRESSION_GUIDE.md) · 🇦🇲 [hy](../../../hy/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇩 [id](../../../id/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇬 [ig](../../../ig/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇹 [it](../../../it/docs/compression/COMPRESSION_GUIDE.md) · 🇯🇵 [ja](../../../ja/docs/compression/COMPRESSION_GUIDE.md) · 🇬🇪 [ka](../../../ka/docs/compression/COMPRESSION_GUIDE.md) · 🇰🇭 [km](../../../km/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [kn](../../../kn/docs/compression/COMPRESSION_GUIDE.md) · 🇰🇷 [ko](../../../ko/docs/compression/COMPRESSION_GUIDE.md) · 🇱🇹 [lt](../../../lt/docs/compression/COMPRESSION_GUIDE.md) · 🇱🇻 [lv](../../../lv/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [ml](../../../ml/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [mr](../../../mr/docs/compression/COMPRESSION_GUIDE.md) · 🇲🇾 [ms](../../../ms/docs/compression/COMPRESSION_GUIDE.md) · 🇲🇹 [mt](../../../mt/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇵 [ne](../../../ne/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇱 [nl](../../../nl/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇴 [no](../../../no/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [or](../../../or/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [pa](../../../pa/docs/compression/COMPRESSION_GUIDE.md) · 🇵🇭 [phi](../../../phi/docs/compression/COMPRESSION_GUIDE.md) · 🇵🇱 [pl](../../../pl/docs/compression/COMPRESSION_GUIDE.md) · 🇵🇹 [pt](../../../pt/docs/compression/COMPRESSION_GUIDE.md) · 🇧🇷 [pt-BR](../../../pt-BR/docs/compression/COMPRESSION_GUIDE.md) · 🇷🇴 [ro](../../../ro/docs/compression/COMPRESSION_GUIDE.md) · 🇷🇺 [ru](../../../ru/docs/compression/COMPRESSION_GUIDE.md) · 🇱🇰 [si](../../../si/docs/compression/COMPRESSION_GUIDE.md) · 🇸🇰 [sk](../../../sk/docs/compression/COMPRESSION_GUIDE.md) · 🇸🇮 [sl](../../../sl/docs/compression/COMPRESSION_GUIDE.md) · 🇷🇸 [sr](../../../sr/docs/compression/COMPRESSION_GUIDE.md) · 🇸🇪 [sv](../../../sv/docs/compression/COMPRESSION_GUIDE.md) · 🇰🇪 [sw](../../../sw/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [ta](../../../ta/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [te](../../../te/docs/compression/COMPRESSION_GUIDE.md) · 🇹🇭 [th](../../../th/docs/compression/COMPRESSION_GUIDE.md) · 🇹🇷 [tr](../../../tr/docs/compression/COMPRESSION_GUIDE.md) · 🇺🇦 [uk-UA](../../../uk-UA/docs/compression/COMPRESSION_GUIDE.md) · 🇵🇰 [ur](../../../ur/docs/compression/COMPRESSION_GUIDE.md) · 🇺🇿 [uz](../../../uz/docs/compression/COMPRESSION_GUIDE.md) · 🇻🇳 [vi](../../../vi/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇬 [yo](../../../yo/docs/compression/COMPRESSION_GUIDE.md) · 🇨🇳 [zh-CN](../../../zh-CN/docs/compression/COMPRESSION_GUIDE.md) · 🇹🇼 [zh-TW](../../../zh-TW/docs/compression/COMPRESSION_GUIDE.md)

---

> သတ်မှတ်ချက်နှင့် ကိုက်ညီသော context အတွက် 15-95% ကို အလိုအလျောက် ချွေတာပါ။ အကျဉ်းချုပ်ကို အမြန်ကြည့်ရန် [README Compression အပိုင်း](../README.md#%EF%B8%8F-prompt-compression--save-15-95-eligible-tokens-automatically) ကို ကြည့်ပါ။

## ခြုံငုံသုံးသပ်ချက်

OmniRoute သည် request များ upstream provider များထံ မရောက်ရှိမီ **ကြိုတင်လုပ်ဆောင်သည့်** modular prompt compression pipeline တစ်ခုကို အကောင်အထည်ဖော်ထားသည်။ ဆိုလိုသည်မှာ token ချွေတာမှုကို မသိသာဘဲ အလိုအလျောက် ရရှိမည်ဖြစ်ပြီး သင်၏ workflow ကို ပြောင်းလဲရန် မလိုအပ်ပါ။

```
Client Request
  → Compression Strategy Selector
    → Combo override ရှိသလား? → combo setting ကို အသုံးပြုရန်
    → Auto-trigger threshold ပြည့်သလား? → auto mode ကို အသုံးပြုရန်
    → Default mode ရှိသလား? → global setting ကို အသုံးပြုရန်
    → Off ဖြစ်သလား? → compression ကို ကျော်ရန်
  → ရွေးချယ်ထားသော Compression Mode
    → Off: Compression မပြုလုပ်ပါ
    → Lite: ဘေးကင်းသော whitespace/formatting ရှင်းလင်းမှု (~15%)
    → Standard: Caveman ပုံစံ မလိုအပ်သည့် စကားလုံးများ ဖယ်ရှားမှု (~30%)
    → Aggressive: History aging + အကျဉ်းချုပ်ခြင်း (~50%)
    → Ultra: Heuristic pruning + code-block thinning (~75%)
    → RTK: Command ကို နားလည်သော terminal/tool-output စစ်ထုတ်မှု (upstream အပိုင်းအခြား 60-90%)
    → Stacked: အစီအစဉ်တကျ multi-engine pipeline၊ ပုံမှန်အားဖြင့် RTK ပြီးနောက် Caveman (သတ်မှတ်ချက်နှင့် ကိုက်ညီသော အပိုင်းအခြား 78-95%)
  → ချုံ့ထားသော Request → Provider
```

---

## Compression Mode များ

### Off

Compression မပြုလုပ်ပါ။ Message အားလုံးကို ပြောင်းလဲခြင်းမရှိဘဲ ဖြတ်သန်းစေသည်။

### Lite Mode (~15% ချွေတာမှု၊ latency <1ms)

အလုံခြုံဆုံး mode ဖြစ်ပြီး အဓိပ္ပာယ်ပိုင်းဆိုင်ရာ ပြောင်းလဲမှု လုံးဝမရှိဘဲ formatting ကိုသာ ရှင်းလင်းသည်-

| နည်းလမ်း                 | ဖော်ပြချက်                                                                        |
| ------------------------ | --------------------------------------------------------------------------------- |
| `collapseWhitespace`     | ဆက်တိုက်ဖြစ်နေသော စာကြောင်းလွတ်များနှင့် နောက်ဆုံးရှိ space များကို ပေါင်းစည်းသည် |
| `dedupSystemPrompt`      | ထပ်နေသော system message များကို ဖယ်ရှားသည်                                        |
| `compressToolResults`    | စာရှည်သော tool/function output များကို ချုံ့သည်                                   |
| `removeRedundantContent` | ထပ်ခါတလဲလဲပါသော ညွှန်ကြားချက်များကို ဖယ်ရှားသည်                                   |
| `replaceImageUrls`       | base64 image data URI များကို အတိုချုံ့သည်                                        |

**အသင့်တော်ဆုံး:** အမြဲဖွင့်ထားသော အသုံးပြုမှုနှင့် ဘေးကင်းလုံခြုံရေး အလွန်အရေးကြီးသော workflow များ။

### Standard Mode (~30% ချွေတာမှု)

[Caveman](https://github.com/JuliusBrussee/caveman) ကို အခြေခံထားပြီး အဓိပ္ပာယ်ကို ထိန်းသိမ်းလျက် မလိုအပ်သော စကားလုံးများနှင့် စကားရှည်အသုံးအနှုန်းများကို ဖယ်ရှားသည်-

- မလိုအပ်သော စကားလုံးများ ("please", "I think", "basically", "actually") ကို ဖယ်ရှားသည်
- စကားရှည်အသုံးအနှုန်းများကို တိုစေသည် ("in order to" → "to", "as a result of" → "because")
- ယဉ်ကျေးသိမ်မွေ့စွာ မရေမရာပြောဆိုမှုများ ("Would you mind...", "If you could possibly...") ကို ဖယ်ရှားသည်
- coding prompt များအတွက် ချိန်ညှိထားသော regex rule 30 ကျော် ပါဝင်သည်

**အသင့်တော်ဆုံး:** နေ့စဉ် coding workflow များနှင့် ကုန်ကျစရိတ်ကို အလေးထားသော အဖွဲ့များ။

### Aggressive Mode (~50% ချွေတာမှု)

ကြာရှည် session များအတွက် စမတ်ကျသော history စီမံခန့်ခွဲမှု-

- **Message Aging** — message အဟောင်းများကို တဖြည်းဖြည်း ပိုမိုချုံ့သည်
- **Tool Result Summarization** — ရှည်လျားသော tool output များကို အကျဉ်းချုပ်များဖြင့် အစားထိုးသည်
- **Structural Integrity Guards** — `tool_use` + `tool_result` အတွဲများ တစ်သမတ်တည်းရှိကြောင်း သေချာစေသည်
- **Context Window Awareness** — model တစ်ခုချင်းစီ၏ token ကန့်သတ်ချက်များကို လိုက်နာသည်

**အသင့်တော်ဆုံး:** ရက်ရှည် debugging session များနှင့် ကြီးမားသော codebase များ။

### Ultra Mode (~75% ချွေတာမှု)

Token အလွန်အရေးကြီးသော အခြေအနေများအတွက် အမြင့်ဆုံး compression-

- **Heuristic Pruning** — ဆက်စပ်မှု threshold အောက်ရှိ message များကို ဖယ်ရှားသည်
- **Code Block Thinning** — ထပ်တလဲလဲဖြစ်နေသော code ဥပမာများကို ချုံ့သည်
- **Binary Search Truncation** — context window အတွက် အကောင်းဆုံး ဖြတ်တောက်ရမည့်နေရာကို ရှာဖွေသည်
- Aggressive mode ၏ feature အားလုံး ပါဝင်သည်

**အသင့်တော်ဆုံး:** Context limit ကို ထပ်ခါတလဲလဲ ပြည့်သွားသည့်အခါ။

### RTK Mode (upstream အပိုင်းအခြား 60-90%)

RTK mode ကို coding-agent session များတွင် ပေါ်လာသည့် စာရှည်သော tool output များအတွက် အထူးပြုထားသည်-

- `git status`, `git diff`, `git log`, test runner များ၊
  TypeScript/Vite/Webpack build များ၊ ESLint/Biome/Prettier၊ npm audit/install များ၊ Docker log များ၊ infra
  output နှင့် ယေဘုယျ shell output ကဲ့သို့ command/output အမျိုးအစားများကို ရှာဖွေသိရှိသည်
- `open-sse/services/compression/engines/rtk/filters/` မှ JSON filter pack များကို အသုံးပြုသည်
- Project သို့မဟုတ် global `filters.toml` file များမှ RTK TOML schema v1 filter များကို inline-test
  validation နှင့် project file များအတွက် trust-gating တို့ဖြင့် import လုပ်သည်
- Inline verify sample များပါဝင်သော built-in filter 49 ခုကို ထည့်သွင်းပေးထားသည်
- ANSI control sequence များ၊ progress bar များ၊ ထပ်နေသော စာကြောင်းများနှင့် အရေးယူရန်မလိုသော noise များကို ဖယ်ရှားသည်
- Failure များ၊ error များ၊ warning များ၊ ပြောင်းလဲထားသော file များ၊ အကျဉ်းချုပ်များနှင့် ရှည်လျားသော output ၏ နောက်ဆုံးပိုင်းကို ထိန်းသိမ်းထားသည်
- Trust-gated project filter များ၊ global filter များနှင့် ရွေးချယ်နိုင်သော redacted raw-output recovery ကို ပံ့ပိုးသည်

**အသင့်တော်ဆုံး:** Shell၊ build၊ test၊ git၊ grep နှင့် file-output transcript များ ပါဝင်သော agent session များ။

### Stacked Mode (သတ်မှတ်ချက်နှင့် ကိုက်ညီသော အပိုင်းအခြား 78-95%)

Stacked mode သည် compression engine အများအပြားကို တိကျသတ်မှတ်ထားသော အစီအစဉ်အတိုင်း လုပ်ဆောင်သည်။ မူလ pipeline မှာ-

```txt
RTK -> Caveman
```

ထိုအစီအစဉ်သည် terminal/tool output ကို ဦးစွာ ကျစ်လျစ်စေပြီးနောက် ကျန်ရှိသော သဘာဝဘာသာစကား prompt အပေါ် Caveman semantic condensation ကို အသုံးပြုသည်။ Stacked pipeline များကို global အနေဖြင့်ဖြစ်စေ၊ routing combo များတွင် သတ်မှတ်ထားသော compression combo များမှတစ်ဆင့်ဖြစ်စေ ပြင်ဆင်သတ်မှတ်နိုင်သည်။

**အသင့်တော်ဆုံး:** ကြီးမားသော tool log များနှင့် လူသား၏ ညွှန်ကြားချက်များ သို့မဟုတ် assistant အကျဉ်းချုပ်များ ရောနှောပါဝင်သော context များ။

---

## Upstream ချွေတာမှု တွက်ချက်ပုံ

OmniRoute သည် ချုံ့ခြင်းကြောင့် ရရှိသည့် ချွေတာမှုများကို ရင်းမြစ်နှစ်ခုဖြစ်သော upstream ပရောဂျက် benchmark များနှင့်
OmniRoute ၏ ကိုယ်ပိုင် engine ပေါင်းစပ်မှုတို့မှ မှတ်တမ်းတင်ဖော်ပြထားသည်။

| ရင်းမြစ် | ဤနေရာတွင် အသုံးပြုထားသည့် Upstream README ကိန်းဂဏန်း                                                                                  |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Caveman  | output token `~75%` ပိုနည်းခြင်း၊ benchmark ပျမ်းမျှ output ချွေတာမှု `65%`၊ အပိုင်းအခြား `22-87%` နှင့် input ချုံ့ခြင်း tool `~46%` |
| RTK      | command output ချွေတာမှု `60-90%`၊ နမူနာ session တွင် token `~118,000 -> ~23,900` သို့မဟုတ် `79.7%` ချွေတာမှု (`~80%`)                |

ထပ်နေသော tool/context payload များအတွက် ပုံသေ OmniRoute ပေါင်းစပ်မှုသည် engine များကို အောက်ပါအတိုင်း အဆင့်ဆင့် အသုံးပြုသည်-

```txt
RTK -> Caveman
```

ပေါင်းစပ်ချွေတာမှုသည် ပေါင်းခြင်းမဟုတ်ဘဲ မြှောက်ခြင်းပုံစံဖြင့် တွက်ချက်သည်-

```txt
combined = 1 - (1 - RTK savings) * (1 - Caveman input savings)
average  = 1 - (1 - 0.80) * (1 - 0.46) = 89.2%
range    = 1 - (1 - 0.60..0.90) * (1 - 0.46) = 78.4-94.6%
```

ထို `78-95%` ကိန်းဂဏန်းသည် RTK နှင့် Caveman နှစ်ခုစလုံးက တူညီသော input/context payload ကို လျှော့ချနိုင်သည့်အခါတွင် အကျုံးဝင်သည်။
Caveman ၏ response output mode သည် သီးခြားဖြစ်သည်။ ၎င်းကို ဖွင့်ထားသည့်အခါ Caveman ၏ ကိုယ်ပိုင် output ချွေတာမှုများ (ပျမ်းမျှ `65%`၊
အဓိကဖော်ပြချက် `~75%`၊ အပိုင်းအခြား `22-87%`) ကို အသုံးပြုပါ။ စုစုပေါင်း billing ချွေတာမှုသည် သင်၏ prompt/output အချိုးအစားပေါ် မူတည်သည်။

### "eligible" ဟူသည် အမှန်တကယ် ဘာကို ဆိုလိုသနည်း

အဓိကဖော်ပြထားသော 15-95% အပိုင်းအခြားသည် အမှန်ဖြစ်သော်လည်း **ထပ်နေသော သို့မဟုတ် အလွန်ရှည်လျားသော** အကြောင်းအရာများအတွက်သာ အကျုံးဝင်သည် — ထပ်ခါတလဲလဲဖြစ်နေသော
error စာကြောင်းများ၊ တူညီသော warning ကို အလွန်အကျွံ ထုတ်ပြသည့် build log၊ အရွယ်အစားအလွန်ကြီးသော `grep`/file-read dump တို့ဖြစ်သည်။ ၎င်းသည်
request တိုင်းတွင် ထိုမျှလောက် ချွေတာနိုင်သည်ဟု **မ** ဆိုလိုပါ။

လက်တွေ့စမ်းသပ်ပြီး အတည်ပြုထားသည် (`tests/unit/compression/stacked-compression-tool-result-savings.test.ts`)။ တူညီသော
error စာကြောင်း 300 ပါဝင်သည့် Anthropic ပုံစံ `tool_result` block အပေါ် `stacked` (RTK + Caveman) run တစ်ခုက
**token ချွေတာမှု 95.93% / character ချွေတာမှု 96.26%** ကို ရရှိစေခဲ့ပြီး ကြော်ငြာထားသည့်
အပိုင်းအခြားအတွင်း အပြည့်အဝ ရှိနေသည်။ သို့သော် တူညီသော pipeline ကို ပုံမှန်၊ မထပ်နေသော tool output (ရှင်းလင်းသည့် `grep` ကိုက်ညီမှုစာရင်း၊
တိုတောင်းသော file read၊ ပုံမှန် စကားပြောစာသား) အပေါ် run သည့်အခါတွင် မှန်ကန်စွာ **သုညနီးပါး ချွေတာမှု** သာ ရရှိသည်။ အဘယ်ကြောင့်ဆိုသော်
ဖယ်ရှားရန် ထပ်နေသောအရာ မရှိသည့်အပြင် `validateCompression()` (`validation.ts`) သည် code block များ၊ URL များ၊ heading များ၊ version များ သို့မဟုတ် ALL-CAPS constant identifier များကို ဖယ်ရှားခြင်း သို့မဟုတ် ပြောင်းလဲခြင်းဖြစ်စေမည့်
ပြန်လည်ရေးသားမှုကို ပေးပို့ရန် ငြင်းပယ်သောကြောင့် ဖြစ်သည်။

၎င်းသည် မျှော်လင့်ထားသည့် ဘေးကင်းသော လုပ်ဆောင်ချက်ဖြစ်ပြီး bug မဟုတ်ပါ။ ရှင်းလင်းသော file များကို အဓိကအားဖြင့် ဖတ်ရှုခြင်း/grep လုပ်ခြင်းသာရှိသည့် coding session တစ်ခုတွင်
ချုံ့ခြင်းကို အပြည့်အဝ ဖွင့်ထားသော်လည်း စုစုပေါင်းချွေတာမှု အနည်းငယ်သာ တွေ့ရမည်ဖြစ်ပြီး၊ fail ဖြစ်နေသည့်
loop သို့မဟုတ် output အလွန်များသော linter နှင့် ကြုံတွေ့ရသည့် session တစ်ခုတွင်မူ ထို traffic အတွက် 78-95% အပိုင်းအခြားအပြည့်ကို ရရှိမည်ဖြစ်သည်။ Session တစ်ခုတည်း၏
စုစုပေါင်းချွေတာမှု ရာခိုင်နှုန်းနည်းခြင်းကို compression config မှားယွင်းနေကြောင်း သက်သေအဖြစ် မယူဆပါနှင့် — ပထမဦးစွာ
မူလ tool output သည် အမှန်တကယ် ထပ်နေခြင်းရှိမရှိ စစ်ဆေးပါ။

---

## Token ချွေတာမှု ပုံဖော်ပြသခြင်း

```
ချုံ့ခြင်းမရှိဘဲ:      LLM သို့ token 47K ပေးပို့သည်
Lite ဖြင့်:           token 40K ပေးပို့သည်          (15% ချွေတာ — ဘေးကင်းပြီး အမြဲဖွင့်ထားသည်)
Standard ဖြင့်:       token 33K ပေးပို့သည်          (30% ချွေတာ — caveman စကားပြောပုံ စည်းမျဉ်းများ)
Aggressive ဖြင့်:     token 24K ပေးပို့သည်          (50% ချွေတာ — အဟောင်းဖြစ်လာမှု + အနှစ်ချုပ်ခြင်း)
Ultra ဖြင့်:          token 12K ပေးပို့သည်          (75% ချွေတာ — heuristic ဖြတ်တောက်ခြင်း)
RTK ဖြင့်:            token 19K-5K ပေးပို့သည်       (command/tool output တွင် 60-90% ချွေတာ)
Stacked ဖြင့်:        token 10K-2.5K ပေးပို့သည်     (အကျုံးဝင်သည့် RTK+Caveman အပိုင်းအခြား 78-95%)
```

---

## စီစဉ်သတ်မှတ်ခြင်း

### ဒက်ရှ်ဘုတ်

`Dashboard → Context & Cache` သို့ သွားပါ-

- **Caveman** — မုဒ်ရွေးချယ်မှု၊ ဘာသာစကားပက်ကေ့ချ်များ၊ ကြိုတင်ကြည့်ရှုခြင်းနှင့် ကမ္ဘာလုံးဆိုင်ရာ မူရင်းများ
- **RTK** — ကွန်မန်း-ဖစ်လ်တာ ကြိုတင်ကြည့်ရှုခြင်း၊ RTK ဘေးကင်းရေး ဆက်တင်များနှင့် ဖစ်လ်တာ ကတ်တလောက်
- **Compression Combos** — ရောက်တာ ကွန်ဘိုများသို့ သတ်မှတ်ထားသော အမည်ရှိ အင်ဂျင် ပိုက်လိုင်းများ
- **Auto-Trigger Threshold** — တိုကင်အရေအတွက် သတ်မှတ်ထားသော ကန့်သတ်ချက်ထက် ကျော်လွန်ပါက အလိုအလျောက် ဖိသိပ်မှုကို စတင်လုပ်ဆောင်ခြင်း

### ကွန်ဘိုတစ်ခုချင်းစီအတွက် ထပ်ဆင့်သတ်မှတ်ခြင်း

`Dashboard → Context & Cache → Compression Combos` တွင်၊ ရောက်တာ ကွန်ဘိုတစ်ခုသို့ ဖိသိပ်မှု ကွန်ဘိုတစ်ခုကို သတ်မှတ်ပါ-

```txt
Combo: "free-tier-fallback"
  Compression Combo: "coding-agent-stack"
  Pipeline: RTK -> Caveman
  Targets:
    1. if/kimi-k2.7-code
    2. if/qwen3.8-max-preview
```

၎င်းသည် အခမဲ့/ကုဒ်ရေးသားခြင်း ပံ့ပိုးပေးသူများတွင် စုစည်းထားသော ဖိသိပ်မှုကို အသုံးပြုနိုင်ပြီး အခပေး စာရင်းသွင်းမှုများတွင် lite မုဒ်ကို ထားရှိနိုင်စေသည်။

ဤ "Per-Combo Override" သတ်မှတ်မှုသည် **routing-combo compression mode** override (Default/Off/Lite/Standard/Aggressive/Ultra) နှင့် ကွဲပြားသော ထိန်းချုပ်မှုတစ်ခုဖြစ်သည်။ ထို override သည် အမည်ရှိ ဖိသိပ်မှု-ကွန်ဘို ပိုက်လိုင်းကို ရွေးချယ်ခြင်းမဟုတ်ဘဲ `resolveCompressionPlan` မှ တိုင်ပင်သော `compressionMode` field ကိုသာ သတ်မှတ်သည်။ ၎င်းကို ကွန်ဘိုကတ် (`Dashboard → Combos`) တွင် သို့မဟုတ် #6760 မှစ၍ `Dashboard → Context & Cache → Compression Combos` ရှိ "Assign to routing" စာရင်းတွင် ရောက်တာ ကွန်ဘိုတစ်ခုချင်းစီအတွက်၊ အထက်တွင် မှတ်တမ်းတင်ထားသော ပိုက်လိုင်း-သတ်မှတ်မှု အမှန်ခြစ်ဘောက်စ်ဘေးတွင် သတ်မှတ်နိုင်သည်။ မျက်နှာပြင်နှစ်ခုလုံးသည် တူညီသော `PUT /api/combos/{id}` endpoint မှတစ်ဆင့် ဆက်လက်တည်ရှိနေသည်။

### တောင်းဆိုမှုတစ်ခုချင်းစီအတွက် ထပ်ဆင့်သတ်မှတ်ခြင်း

တောင်းဆိုမှုတစ်ခုတည်းအတွက် ဖိသိပ်မှု အစီအစဉ်ကို ထပ်ဆင့်သတ်မှတ်ရန် `x-omniroute-compression` တောင်းဆိုမှု ခေါင်းစီးကို ပေးပို့ပါ။ ၎င်းသည် အမြင့်ဆုံး ဦးစားပေးမှုရှိသည် — ၎င်းသည် routing-combo override၊ active profile၊ auto-trigger နှင့် panel Default တို့ကို ကျော်လွန်သည်။ မသိသော တန်ဖိုးများကို လျစ်လျူရှုသည် (တောင်းဆိုမှုကို ဘယ်တော့မှ ပယ်ချမည်မဟုတ်ပါ) နှင့် ကမ္ဘာလုံးဆိုင်ရာ မာစတာခလုတ်သည် အရာအားလုံးကို ဆက်လက်ထိန်းချုပ်သည်- ဖိသိပ်မှုကို ကမ္ဘာလုံးဆိုင်ရာ ပိတ်ထားသောအခါ၊ ခေါင်းစီးသည် ၎င်းကို ဖွင့်၍မရပါ။ တန်ဖိုးများ-

| တန်ဖိုး       | အကျိုးသက်ရောက်မှု                                                                                                              |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| `off`         | ဤတောင်းဆိုမှုအတွက် ဖိသိပ်မှုမရှိပါ။                                                                                            |
| `default`     | panel မှ ဆင်းသက်လာသော Default profile (active profile ကို လျစ်လျူရှုသည်)။ Lossy engines များကို ပိတ်ထားသည်။                    |
| `safe`        | ခေါင်းစီးကို ချန်လှပ်ထားခြင်းနှင့် တူညီသည်- dedup နှင့် whitespace folding သာ။                                                 |
| `allow-lossy` | ဤတောင်းဆိုမှု၏ operator plan ကို ထားရှိပါ၊ ၎င်းတွင် အကျဉ်းချုပ်များ၊ သက်ဆိုင်ရာ filter များနှင့် style rewrites များ ပါဝင်သည်။ |
| `engine:<id>` | ဖွင့်ထားသောအခါ အင်ဂျင်တစ်ခုတည်း၊ ဥပမာ `engine:rtk`။ ၎င်းသည် ထိုအင်ဂျင်အတွက် တောင်းဆိုမှုတစ်ခုချင်းစီ opt-in ဖြစ်သည်။           |
| `<combo>`     | အမည်ရှိ ကွန်ဘိုတစ်ခု၊ အမည်ဖြင့် (case-insensitive) ဦးစွာ ကိုက်ညီပြီးနောက် id ဖြင့် ကိုက်ညီသည်။                                 |

`allow-lossy`၊ `engine:<id>` သို့မဟုတ် အမည်ရှိ ကွန်ဘိုမပါဘဲ၊ lossy engines များကို အသုံးမပြုပါ။ ဖိသိပ်မှုကို ဖွင့်ထားသောအခါ တောင်းဆိုမှုသည် session dedup နှင့် whitespace folding ကို ဆက်လက်ရရှိသည်။

အသုံးပြုထားသော အစီအစဉ်ကို `X-OmniRoute-Compression: <mode>; source=<source>` တုံ့ပြန်မှု ခေါင်းစီးတွင် ပြန်လည်ပဲ့တင်ထပ်သည်၊ ၎င်းတွင် `<source>` သည် `request-header`၊ `routing-override`၊ `active-profile`၊ `auto-trigger`၊ `default` သို့မဟုတ် `off` တို့မှ တစ်ခုဖြစ်သည်။

### API

```bash
# ဖိသိပ်မှု ဆက်တင်များကို ရယူပါ
curl http://localhost:20128/api/settings/compression

# ဖိသိပ်မှု ဆက်တင်များကို အပ်ဒိတ်လုပ်ပါ
curl -X PUT http://localhost:20128/api/settings/compression \
  -H "Content-Type: application/json" \
  -d '{"defaultMode":"stacked","autoTriggerMode":"stacked","autoTriggerTokens":32000}'

# သီးခြား RTK/stacked payload ကို ကြိုတင်ကြည့်ရှုပါ
curl -X POST http://localhost:20128/api/compression/preview \
  -H "Content-Type: application/json" \
  -d '{"mode":"rtk","messages":[{"role":"tool","content":"npm test output here"}]}'

# RTK filter packs များကို စာရင်းပြုစုပါ
curl http://localhost:20128/api/context/rtk/filters

# RTK ကို ရွေးချယ်နိုင်သော ကွန်မန်း metadata ဖြင့် တိုက်ရိုက် စမ်းသပ်ပါ
curl -X POST http://localhost:20128/api/context/rtk/test \
  -H "Content-Type: application/json" \
  -d '{"command":"npm test","text":"FAIL tests/example.test.ts\nError: boom"}'
```

---

## ကာကွယ်ထားသည့် အရာများ

ချုံ့ခြင်းအင်ဂျင်သည် **အောက်ပါတို့ကို အမြဲထိန်းသိမ်းထားသည်-**

- ✅ ကုဒ်ဘလောက်များ (အကာအရံပါသောနှင့် လိုင်းအတွင်းရှိသော)
- ✅ URL များနှင့် ဖိုင်လမ်းကြောင်းများ
- ✅ JSON ဖွဲ့စည်းပုံများနှင့် ဖွဲ့စည်းထားသောဒေတာ
- ✅ သတ်မှတ်အမည်များနှင့် ကာကွယ်ထားသော နည်းပညာဆိုင်ရာ တိုကင်များ
- ✅ သင်္ချာဖော်ပြချက်များ
- ✅ ကိရိယာ/ဖန်ရှင်ခေါ်ဆိုမှု သတ်မှတ်ချက်များ
- ✅ စနစ်ညွှန်ကြားချက်များ (lite မုဒ်တွင်)

RTK ကုန်ကြမ်းအထွက် ပြန်လည်ရယူခြင်းသည် မည်သည့်အရာကိုမဆို သိမ်းဆည်းမထားမီ အသုံးများသော API key များ၊ bearer token များ၊ Slack token များ၊ AWS access key များ၊
စကားဝှက်များ၊ တိုကင်များနှင့် လျှို့ဝှက်ချက်များကို ဖုံးကွယ်ပေးသည်။

---

## ချုံ့ခြင်း ကိန်းဂဏန်းများ

ချုံ့ထားသော တောင်းဆိုမှုတိုင်းတွင် ဆာဗာမှတ်တမ်းများ၌ ကိန်းဂဏန်းများ ပါဝင်သည်-

```json
{
  "originalTokens": 47200,
  "compressedTokens": 40120,
  "savingsPercent": 15.0,
  "techniquesUsed": ["collapseWhitespace", "dedupSystemPrompt"],
  "mode": "lite",
  "engine": "caveman",
  "compressionComboId": "coding-agent-stack",
  "durationMs": 0.8,
  "rtkRawOutputPointers": []
}
```

---

## အဆင့်လမ်းပြမြေပုံ

| အဆင့်    | မုဒ်များ                                                                                                                                      | အခြေအနေ     |
| -------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
| အဆင့် ၁  | ပိတ်ထားသည်၊ Lite                                                                                                                              | ✅ ပို့ပြီး |
| အဆင့် ၂  | စံ၊ ပြင်းထန်၊ Ultra                                                                                                                           | ✅ ပို့ပြီး |
| အဆင့် ၃  | RTK၊ Stacked၊ Compression Combos                                                                                                              | ✅ ပို့ပြီး |
| အဆင့် ၄  | Output Styles၊ SLM-tier Ultra၊ eval harness                                                                                                   | ✅ ပို့ပြီး |
| အဆင့် ၄C | Adaptive context-budget ("dial") — compute engine + API (`contextBudget` on `PUT /api/settings/compression`) + dashboard mode/policy controls | ✅ ပို့ပြီး |

---

## အသိအမှတ်ပြုမှုများ

Standard မုဒ်၏ ချုံ့ခြင်းစည်းမျဉ်းများသည် **[JuliusBrussee](https://github.com/JuliusBrussee)** (⭐ 51K+) ဖန်တီးသော **[Caveman](https://github.com/JuliusBrussee/caveman)** — လူကြိုက်များပျံ့နှံ့ခဲ့သည့် "တိုကင်နည်းနည်းဖြင့် အလုပ်ဖြစ်လျှင် တိုကင်အများကြီးကို ဘာကြောင့်သုံးမလဲ" ပရောဂျက်မှ စိတ်ကူးရယူထားသည်။ Caveman ၏ အစီရင်ခံချက်အရ အထွက်တိုကင် `~75%` လျော့နည်းခြင်း၊ စံနှုန်းတိုင်းတာမှု ပျမ်းမျှအထွက် ချွေတာမှု `65%`၊ အထွက်အပိုင်းအခြား `22-87%` နှင့် အဝင်ချုံ့ခြင်းကိရိယာ `~46%` ရှိသည်။

RTK မုဒ်သည် **[RTK AI](https://github.com/rtk-ai)** ဖန်တီးသော **[RTK - Rust Token Killer](https://github.com/rtk-ai/rtk)** — terminal၊ build၊ test၊ git နှင့် tool-output စစ်ထုတ်ခြင်းတို့အတွက် စွမ်းဆောင်ရည်မြင့် command-output ချုံ့ခြင်းပရောဂျက်မှ စိတ်ကူးရယူထားသည်။ RTK ၏ အစီရင်ခံချက်အရ ချွေတာမှု `60-90%` ရှိပြီး ၎င်း၏ README နမူနာ session တွင် `~80%` ချွေတာထားကြောင်း ဖော်ပြထားသည်။

---

## အဆင့်မြင့် ဖိသိမ်းမှုစနစ်များ

စံမုဒ် ၇ ခုအပြင် OmniRoute တွင် အခြေအနေပေါ်မူတည်၍ အလိုအလျောက်အလုပ်လုပ်သော အဆင့်မြင့် ဖိသိမ်းမှုစနစ်များစွာ ပါဝင်သည်။

### Cache-Aware ဖိသိမ်းမှု

အချို့သော ပံ့ပိုးသူများ (Anthropic ကဲ့သို့ prompt caching ဖြင့်) သည် **prompt caching** ကို ပံ့ပိုးပေးသည်။ ၎င်းသည် prompt ၏ အစိတ်အပိုင်းများကို cache လုပ်ခြင်းဖြင့် ကုန်ကျစရိတ်နှင့် latency ကို လျှော့ချပေးသည်။ Caching ကို ဖွင့်ထားသောအခါတွင် ပြင်းထန်သော ဖိသိမ်းမှုသည် စွမ်းဆောင်ရည်ကို အမှန်တကယ် **ထိခိုက်စေနိုင်သည်** အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် cache လုပ်ထားသော tokens များကို ပြောင်းလဲစေပြီး cache ကို ပျက်ပြယ်စေသောကြောင့် ဖြစ်သည်။

`cachingAware.ts` module သည် ဤပြဿနာကို **caching context ကို ရှာဖွေခြင်း** နှင့် **ဖိသိမ်းမှုနည်းဗျူဟာကို ချိန်ညှိခြင်း** ဖြင့် ဖြေရှင်းသည်။

#### ၎င်းမည်သို့အလုပ်လုပ်သနည်း

1. **Caching context ကို ရှာဖွေပါ** — `cache_control` အမှတ်အသားများအတွက် request body ကို စစ်ဆေးသည်။
2. **Caching ပံ့ပိုးသူများကို ခွဲခြားသတ်မှတ်ပါ** — ပစ်မှတ်ပံ့ပိုးသူသည် caching ကို ပံ့ပိုးခြင်းရှိမရှိ စစ်ဆေးသည်။
3. **နည်းဗျူဟာကို ချိန်ညှိပါ** — `aggressive`/`ultra` ကို caching ပံ့ပိုးသူများအတွက် `standard` သို့ လျှော့ချသည်။
4. **System prompt ကို ကျော်သွားပါ** — System prompts များကို အများအားဖြင့် cache လုပ်ထားသောကြောင့် ၎င်းတို့ကို ဖိသိမ်းခြင်းမပြုပါ။
5. **Deterministic ပြောင်းလဲမှုများကို အသုံးပြုပါ** — တသမတ်တည်းသော output ကို ထုတ်လုပ်သည့် ပြောင်းလဲမှုများကိုသာ အသုံးပြုပါ။

#### Code ဥပမာ

```ts
import {
  detectCachingContext,
  getCacheAwareStrategy,
} from "@omniroute/open-sse/services/compression/cachingAware";

const body = {
  model: "anthropic/claude-sonnet-4.5",
  messages: [{ role: "user", content: "Hello" }],
  cache_control: { type: "ephemeral" }, // ← Cache marker
};

const ctx = detectCachingContext(body, { provider: "anthropic" });
// → { hasCacheControl: true, provider: "anthropic", isCachingProvider: true }

const strategy = getCacheAwareStrategy("aggressive", ctx);
// → { strategy: "standard", skipSystemPrompt: true, deterministicOnly: true }
```

#### မည်သည့်အချိန်တွင် အသုံးပြုရမည်နည်း။

Cache-aware ဖိသိမ်းမှုသည် **အမြဲတမ်း ဖွင့်ထားသည်** — မည်သည့် configuration မှ မလိုအပ်ပါ။ ၎င်းသည် အောက်ပါအခြေအနေများတွင်သာ အလုပ်လုပ်သည်။

- request တွင် `cache_control` အမှတ်အသားများ ပါရှိသည်။
- ပစ်မှတ်ပံ့ပိုးသူသည် prompt caching ကို ပံ့ပိုးသည် (Anthropic, OpenAI, စသည်ဖြင့်)။

### Progressive Aging

ကြာရှည်သော စကားဝိုင်းများသည် မက်ဆေ့ချ်အလှည့်များစွာကို စုဆောင်းမိသော်လည်း ပိုမိုဟောင်းနွမ်းသော အလှည့်များသည် အရေးပါမှု နည်းပါးလာသည်။ `progressiveAging.ts` module သည် **အလှည့်အကွာအဝေးအလိုက် မက်ဆေ့ချ်များကို လျှော့ချသည်**-

- **မကြာသေးမီက အလှည့်များ (၀-၃)**: စကားလုံးအတိုင်း ထားရှိသည် (အပြည့်အစုံ အသေးစိတ်)
- **အလယ်အလတ် အလှည့်များ (၄-၈)**: Lite ဖိသိမ်းမှု (နေရာလွတ်များ၊ ပုံစံချခြင်း သန့်ရှင်းရေး)
- **ဟောင်းနွမ်းသော အလှည့်များ (၉+)**: Caveman ဖိသိမ်းမှု (ဖြည့်စွက်စာများ ဖယ်ရှားခြင်း၊ အကျဉ်းချုပ်ခြင်း)
- **အလွန်ဟောင်းနွမ်းသော အလှည့်များ (၂၀+)**: အလွန်အကျဉ်းချုပ်ခြင်း သို့မဟုတ် ဖယ်ရှားခြင်း

#### Code ဥပမာ

```ts
import { applyAging } from "@omniroute/open-sse/services/compression/progressiveAging";

const messages = [
  { role: "system", content: "You are a helpful assistant" },
  { role: "user", content: "What is 2+2?" },
  { role: "assistant", content: "4" },
  // ... 50 more turns ...
];

const { messages: aged, saved } = applyAging(messages, {
  verbatim: 3, // ပထမ ၃ အလှည့်: စကားလုံးအတိုင်း
  light: 8, // အလှည့် ၄-၈: lite ဖိသိမ်းမှု
  moderate: 20, // အလှည့် ၉-၂၀: caveman ဖိသိမ်းမှု
  // အလှည့် ၂၁+: အလွန်အကျဉ်းချုပ်ခြင်း
});

// saved = သိမ်းဆည်းထားသော tokens အရေအတွက်
```

#### မည်သည့်အချိန်တွင် အသုံးပြုရမည်နည်း။

Progressive aging သည် `aggressive` နှင့် `ultra` မုဒ်များအတွက် **အမြဲတမ်း ဖွင့်ထားသည်**။ ၎င်းသည် အောက်ပါတို့အတွက် အထူးထိရောက်သည်။

- ကြာရှည်စွာ လုပ်ဆောင်နေသော coding sessions များ
- ရက်ပေါင်းများစွာ ကြာမြင့်သော စကားဝိုင်းများ
- ကိရိယာခေါ်ဆိုမှုများစွာပါရှိသော Agentic workflows များ

### Caveman Output မုဒ်

`outputMode.ts` module သည် မော်ဒယ်ကိုယ်တိုင် ဖိသိမ်းထားသော၊ တိုတောင်းသော output ( "caveman" ပုံစံ) ကို ထုတ်လုပ်ရန်အတွက် **system prompt ညွှန်ကြားချက်များ** ကို ထည့်သွင်းသည်။

#### ၎င်းမည်သို့အလုပ်လုပ်သနည်း

input ကို ဖိသိမ်းမည့်အစား ဤမုဒ်သည် အောက်ပါကဲ့သို့သော system prompt ကို ထည့်သွင်းသည်။

> "စကားလုံးအနည်းဆုံးဖြင့် ပြန်ဖြေပါ။ ချစ်ခင်စကားများကို ကျော်သွားပါ။ ဝါကျတိုများကို အသုံးပြုပါ။"

၎င်းသည် အောက်ပါတို့အတွက် အထူးကောင်းမွန်သည်။

- Code ထုတ်လုပ်ခြင်း (ပိုမိုတိုတောင်းသော output = tokens နည်းပါးခြင်း)
- အမြန် Q&A (အသေးစိတ်ရှင်းပြရန် မလိုအပ်ပါ)
- Batch processing (throughput ကို အမြင့်ဆုံးမြှင့်တင်ပါ)

#### မည်သည့်အချိန်တွင် အသုံးပြုရမည်နည်း။

Caveman output မုဒ်သည် **ရွေးချယ်နိုင်သည်** — ၎င်းကို combo config မှတဆင့် သတ်မှတ်ပါ။

```json
{
  "strategy": "auto",
  "config": {
    "auto": {
      "outputMode": "caveman"
    }
  }
}
```

### Output ပုံစံများ (catalog)

အထက်ပါ Caveman output မုဒ်သည် **အမွေအနှစ် တစ်ခုတည်းသော ပုံစံလမ်းကြောင်း** ဖြစ်သည်။ Phase 4 သည် ၎င်းကို ပေါင်းစပ်နိုင်သော output ပုံစံများ၏ catalog အဖြစ် အထွေထွေပြုလုပ်ခဲ့သည်- `open-sse/services/compression/outputStyles/catalog.ts` ရှိ `OUTPUT_STYLE_CATALOG`။ ပုံစံတစ်ခုစီသည် မော်ဒယ်ကိုယ်တိုင် ပိုမိုစျေးသက်သာသော output ကို ထုတ်လုပ်စေသည့် system-prompt ညွှန်ကြားချက်တစ်ခုဖြစ်သည်။ ပုံစံများကို အတူတကွ ဖွင့်နိုင်ပြီး catalog အစီအစဉ်အတိုင်း ထည့်သွင်းသည်။

| ပုံစံ                                             | `id`          | ၎င်းလုပ်ဆောင်သည်                                                                                                                                                                                                                                            | ညွှန်ကြားချက် ဘာသာစကားများ                                          |
| ------------------------------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| တိုတောင်းသော စကားပြေ                              | `terse-prose` | ဖြည့်စွက်စာများ/ဆောင်းပါးများ/ကာကွယ်မှုများကို ဖယ်ရှားပါ။ နည်းပညာဆိုင်ရာ အနှစ်သာရကို တိကျစွာ ထိန်းသိမ်းပါ။ အမွေအနှစ် caveman output mode (ကိုးကားထားသည်၊ ပြန်မရိုက်ပါ) နှင့် တူညီသော စာသား။                                                                 | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi                       |
| ကုဒ်နည်းပါးခြင်း                                  | `less-code`   | YAGNI လှေကား- အသေးငယ်ဆုံး လုပ်ဆောင်နိုင်သော ပြောင်းလဲမှု၊ တောင်းဆိုမထားသော abstraction များ မရှိပါ။                                                                                                                                                         | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi                       |
| မြင်းမြီး (ပျင်းရိသော အကြီးတန်း dev)              | `ponytail`    | "အကောင်းဆုံး ကုဒ်သည် ဘယ်တော့မှ မရေးထားသော ကုဒ်ဖြစ်သည်"- ပြန်လည်အသုံးပြုခြင်း > ပြန်လည်ရေးသားခြင်း၊ အရင်းခံအကြောင်းရင်း > ရောဂါလက္ခဏာ၊ အတိုဆုံး လုပ်ဆောင်နိုင်သော ကွာခြားချက်။                                                                               | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi                       |
| ကျွန်ုပ်တွင် ADHD ရှိသည် (လုပ်ဆောင်ချက်-ဦးစားပေး) | `i-have-adhd` | လုပ်ဆောင်ချက် ဦးစားပေး (command/path/snippet ကို စကားပြေမတိုင်မီ)၊ နံပါတ်တပ်ထားသော အဆင့်များ၊ တိကျသော နောက်တစ်ဆင့်၊ နိဒါန်း/ပြန်လည်သုံးသပ်ခြင်း/ပိတ်ခြင်းများ မရှိပါ။ [ayghri/i-have-adhd](https://github.com/ayghri/i-have-adhd) (MIT) မှ ပြောင်းလဲထားသည်။ | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi                       |
| တိုတောင်းသော CJK (文言)                           | `terse-cjk`   | ဂန္ထဝင်-တရုတ် အလွန်တိုတောင်းသော ပုံစံ။                                                                                                                                                                                                                      | zh (locale-gated: ဖြေရှင်းပြီးသော ဘာသာစကားသည် `zh` ဖြစ်မှသာ ပေးသည်) |

ပုံစံတိုင်းတွင် ပြင်းအားအဆင့်သုံးဆင့် — `lite`၊ `full`၊ `ultra` — ပါရှိပြီး အဆင့်တိုင်း
သည် မျှဝေထားသော နယ်နိမိတ်အပိုဒ်ဖြင့် အဆုံးသတ်သည်။ ၎င်းသည် ကုဒ်ဘလော့များ၊ ဖိုင်လမ်းကြောင်းများ၊
command များ၊ အမှား string များ၊ URL များနှင့် identifier များကို မူရင်းအတိုင်း ထိန်းသိမ်းထားသည်။

#### ထိုးသွင်းမှု မည်သို့လုပ်ဆောင်သနည်း

`applyOutputStyles()` (`open-sse/services/compression/outputStyles/apply.ts`) သည်
ရွေးချယ်မှုကို catalog နှင့် ဖြေရှင်းသည် (မသိသော id များနှင့် locale-မကိုက်ညီသော ပုံစံများကို
ဖယ်ရှားသည်၊ အမှားအယွင်းမရှိပါ)၊ ရွေးချယ်ထားသော ညွှန်ကြားချက်များကို catalog အစီအစဉ်အတိုင်း
ပေါင်းစပ်သည်၊ နယ်နိမိတ်အပိုဒ်ကို **တစ်ကြိမ်** ထည့်သွင်းသည်၊ ထို့နောက် ရလဒ်ကို system
prompt ၏ရှေ့တွင် တစ်ခုတည်းသော idempotency marker (`[OmniRoute Output Styles]`) နောက်တွင်
ထည့်သွင်းသည် — ပြန်လည်အသုံးပြုခြင်းသည် no-op ဖြစ်သည်။ ရှာဖွေတွေ့ရှိထားသော တောင်းဆိုမှုဘာသာစကားတွင်
ဘာသာပြန်တစ်ခုရှိပါက၊ ဒေသခံညွှန်ကြားချက်ကို အင်္ဂလိပ်အစား ထိုးသွင်းသည်။

#### မည်သို့ဖွင့်ရမည်နည်း

ဒက်ရှ်ဘုတ်တွင်- **Context → Settings → Compression** — ပုံစံတစ်ခုစီအတွက် on/off toggle နှင့်
level selector ပါသော တစ်တန်းစီ။ ပရိုဂရမ်အရ၊ compression config သည် ရွေးချယ်မှုကို
အောက်ပါအတိုင်း ထိန်းသိမ်းသည်-

```json
{
  "outputStyles": [
    { "id": "i-have-adhd", "level": "full" },
    { "id": "less-code", "level": "lite" }
  ]
}
```

Back-compat- အမွေအနှစ် `outputMode: "caveman"` combo setting သည် အလုပ်လုပ်နေဆဲဖြစ်ပြီး
`terse-prose` သို့ မြေပုံဆွဲသည်။ ၎င်းသည် အမွေအနှစ်ဘာသာစကားတိုင်းတွင် အဟောင်းထိုးသွင်းမှုနှင့်
byte-တူညီသည်။

ဘာသာစကားရွေးချယ်မှု- `languageConfig.enabled` ကို ဖွင့်ထားပါက၊ `autoDetect` သည်
နောက်ဆုံးအသုံးပြုသူမက်ဆေ့ဂျ်၏ ဘာသာစကားကို ရွေးချယ်သည် (input engine များနှင့် တူညီသော detector)၊
`autoDetect` ကို ပိတ်လိုက်ပါက `defaultLanguage` ကို သတ်မှတ်သည်။ ပိတ်ထားပါက → အင်္ဂလိပ်။

ပုံစံ × ဘာသာစကား matrix ကို
`tests/unit/compression/output-styles-i18n-matrix.test.ts` ဖြင့် သတ်မှတ်ထားသည်- ပုံစံအသစ်တစ်ခုသည်
အနည်းဆုံး pt-BR ဘာသာပြန် (သို့မဟုတ် ရှင်းလင်းစွာ ခြေရာခံထားသော ချွင်းချက်) မပါဘဲ ထုတ်လုပ်၍မရပါ၊
ရှိပြီးသားပုံစံတစ်ခုသည် locale တစ်ခုကို တိတ်တဆိတ် ဆုံးရှုံး၍မရပါ။ ပုံစံတစ်ခုထည့်ရန်၊
[EXTENDING_COMPRESSION.md](./EXTENDING_COMPRESSION.md#adding-an-output-style) ကို ကြည့်ပါ။

### Tool Result Compression

`toolResultCompressor.ts` module သည် tool result များ (function call များ၊ agent output များ၊
search result များ စသည်ဖြင့်) အတွက် **အထူးပြု compression strategy ၅ ခု** ကို ပံ့ပိုးပေးသည်-

1. **Search result compression** — ထပ်နေသော ရလဒ်များကို ဖယ်ရှားသည်၊ ထိပ်တန်း-N ကို ထိန်းသိမ်းသည်
2. **File read compression** — ဖိုင်ကြီးများကို ဖြတ်တောက်သည်၊ header/import များကို ထိန်းသိမ်းသည်
3. **Code execution compression** — မရှိမဖြစ်လိုအပ်သော stdout/stderr ကိုသာ ထိန်းသိမ်းသည်
4. **Database query compression** — တန်းများကို ကန့်သတ်သည်၊ အသေးစိတ် metadata များကို ဖယ်ရှားသည်
5. **API response compression** — null field များကို ဖယ်ရှားသည်၊ array များကို ကျစ်လျစ်စေသည်

#### မည်သည့်အချိန်တွင် အသုံးပြုရမည်နည်း

Tool call များရှိနေပါက Tool result compression သည် **အမြဲတမ်း ဖွင့်ထားသည်**။
configuration မလိုအပ်ပါ။

### Stacked Pipeline

stacked mode သည် **အင်ဂျင်များစွာကို အစီအစဉ်အတိုင်း** လုပ်ဆောင်သည် — များသောအားဖြင့် RTK ကို
ဦးစွာ (tool output တွင် 60-90% သက်သာသည်)၊ ထို့နောက် Caveman (ကျန်ရှိသော စာသားတွင် 30% ထပ်ဆောင်းသက်သာသည်)။
၎င်းသည် **စုစုပေါင်း 78-95% သက်သာမှု** ကို ရရှိစေသည်။

#### မည်သို့လုပ်ဆောင်သနည်း

```
Input (1000 tokens)
  → RTK (command-aware filter) → 200 tokens
    → Caveman (filler removal) → 140 tokens
  → Output (140 tokens, 86% savings)
```

#### မည်သည့်အချိန်တွင် အသုံးပြုရမည်နည်း

stacked mode ကို အောက်ပါတို့အတွက် အသုံးပြုပါ-

- Tool-heavy workflow များ (agentic coding, research)
- ကုန်ကျစရိတ်သက်သာသော batch processing
- အများဆုံး token သက်သာမှု လိုအပ်သည့်အခါ

combo မှတစ်ဆင့် configure လုပ်ပါ-

```json
{
  "strategy": "auto",
  "config": {
    "auto": {
      "modePack": "stacked"
    }
  }
}
```

---

## Compression Combo ကို အလိုက်သင့် အစားထိုးသတ်မှတ်ခြင်း

မတူညီသော အသုံးပြုမှုအခြေအနေများအတွက် လုပ်ဆောင်ပုံကို အသေးစိတ်ချိန်ညှိရန် ကမ္ဘာလုံးဆိုင်ရာ compression mode ကို **combo တစ်ခုချင်းစီအလိုက်** အစားထိုးသတ်မှတ်နိုင်သည်-

```json
{
  "id": "coding-combo",
  "strategy": "priority",
  "config": {
    "auto": {
      "weights": { "taskFit": 0.5 },
      "modePack": "quality-first"
    }
  },
  "compressionOverride": {
    "mode": "aggressive",
    "stackedPipelines": ["rtk", "caveman"],
    "preserveToolDefinitions": true
  }
}
```

ဤအရာသည် အောက်ပါအခြေအနေများတွင် အသုံးဝင်သည်-

- **Coding combo များ**: ကြာမြင့်သော session များအတွက် `aggressive` mode ကို အသုံးပြုပါ
- **အမြန် အမေးအဖြေ combo များ**: မြန်ဆန်သော တုံ့ပြန်ချက်များအတွက် `lite` mode ကို အသုံးပြုပါ
- **Tool အများအပြားသုံးသော combo များ**: ချွေတာမှုအများဆုံးရရှိရန် `stacked` mode ကို အသုံးပြုပါ
- **Production combo များ**: Caching provider များအတွက် `cache-aware` mode ကို အသုံးပြုပါ

---

## ထပ်မံကြည့်ရှုရန်

- [Environment Config](../reference/ENVIRONMENT.md) — Compression environment variable များ
- [Architecture Guide](../architecture/ARCHITECTURE.md) — Compression pipeline ၏ အတွင်းပိုင်းလုပ်ဆောင်ပုံ
- [User Guide](../guides/USER_GUIDE.md) — Compression ကို စတင်အသုံးပြုခြင်း
- [RTK Compression](./RTK_COMPRESSION.md) — RTK filter များ၊ ယုံကြည်မှု model၊ အတည်ပြုခြင်း gate နှင့် မူရင်း output ပြန်လည်ရယူခြင်း
- [Compression Engines](./COMPRESSION_ENGINES.md) — Caveman၊ RTK၊ stacked၊ API များ၊ MCP နှင့် dashboard
- [Compression Rules Format](./COMPRESSION_RULES_FORMAT.md) — JSON rule-pack format
- [Compression Language Packs](./COMPRESSION_LANGUAGE_PACKS.md) — ဘာသာစကားအလိုက် Caveman rule များ