# 🗜️ 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 ကို အသုံးပြုမည်
    → ပိတ်ထားသလား? → compression ကို ကျော်သွားမည်
  → ရွေးချယ်ထားသော Compression Mode
    → Off: Compression မလုပ်ပါ
    → Lite: ဘေးကင်းသော whitespace/formatting ရှင်းလင်းမှု (~15%)
    → Standard: Caveman ပုံစံ အပိုစကားလုံးများ ဖယ်ရှားမှု (~30%)
    → Aggressive: History အဟောင်းပြောင်းခြင်း + အကျဉ်းချုပ်ခြင်း (~50%)
    → Ultra: Heuristic pruning + code-block ပါးလွှာစေခြင်း (~75%)
    → RTK: Command ကိုသိရှိသော terminal/tool-output filtering (upstream အပိုင်းအခြား 60-90%)
    → Stacked: အစဉ်လိုက် multi-engine pipeline၊ ပုံမှန်အားဖြင့် RTK ပြီးနောက် Caveman (သတ်မှတ်ချက်နှင့်ကိုက်ညီသော အပိုင်းအခြား 78-95%)
  → ချုံ့ထားသော Request → Provider
```

---

## Compression Mode များ

### Off

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

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

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

| နည်းစနစ်                 | ဖော်ပြချက်                                                                           |
| ------------------------ | ------------------------------------------------------------------------------------ |
| `collapseWhitespace`     | ဆက်တိုက်ဖြစ်နေသော blank line များနှင့် စာကြောင်းအဆုံးရှိ 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 Compression** — ရှည်လျားသော tool output များကို ဖြတ်တောက်ခြင်း သို့မဟုတ် ချန်လှပ်ခြင်း ပြုလုပ်သည် (ပထမ/နောက်ဆုံးစာကြောင်းများ၊
  ကိုက်ညီသောစာကြောင်း filtering၊ JSON key ချုံ့ခြင်း)
- **Structural Integrity Guards** — `tool_use` + `tool_result` အတွဲများ တစ်သမတ်တည်း ရှိနေစေရန် သေချာစေသည်
- **Context Window Awareness** — model တစ်ခုချင်းစီ၏ token ကန့်သတ်ချက်များကို လိုက်နာသည်

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

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

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

- **Heuristic Pruning** — ရမှတ်အခြေခံသည့် prose token pruning
- **Structure Preservation** — fenced code block များ၊ inline code၊ URL နှင့် identifier များကို
  tombstone အဖြစ် အစားထိုးပြီး မူရင်းအတိုင်း ပြန်လည်ဆက်စပ်ပေးသောကြောင့် မည်သည့်အခါမျှ pruning မလုပ်ပါ
- **ရွေးချယ်နိုင်သော SLM tier** — configure လုပ်ထားပါက local model အသေးစားတစ်ခုသည် prune ရလဒ်ကို ထပ်မံကောင်းမွန်အောင် ပြင်ဆင်နိုင်သည်
- Aggressive mode နှင့် သီးခြားလွတ်လပ်သည်။ Message aging၊ tool-result compression
  သို့မဟုတ် fallback summarizer ကို မလုပ်ဆောင်ပါ (SLM-tier ချို့ယွင်းမှုဖြစ်မှသာ fallback pass ကို
  aggressive မှတစ်ဆင့် လမ်းကြောင်းပြောင်းနိုင်သည်)

**အသင့်တော်ဆုံးအခြေအနေ:** Context ကန့်သတ်ချက်များကို ထပ်ခါတလဲလဲ ရောက်ရှိနေသောအခါ။

### 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 များကို import လုပ်ပြီး inline-test
  validation နှင့် project file များအတွက် trust-gating ကို အသုံးပြုသည်
- Inline verify sample များနှင့်အတူ built-in filter 55 ခု ပါဝင်သည်
- ANSI control sequence များ၊ progress bar များ၊ ထပ်နေသောစာကြောင်းများနှင့် လက်တွေ့လုပ်ဆောင်ရန်မလိုသည့် noise များကို ဖယ်ရှားသည်
- Failure များ၊ error များ၊ warning များ၊ ပြောင်းလဲထားသော file များ၊ အကျဉ်းချုပ်များနှင့် ရှည်လျားသော output ၏ အဆုံးပိုင်းကို ထိန်းသိမ်းထားသည်
- Trust-gated project filter များ၊ global filter များနှင့် ရွေးချယ်နိုင်သော ဖုံးကွယ်ပြင်ဆင်ထားသည့် raw-output recovery ကို ပံ့ပိုးသည်

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

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

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

```txt
RTK -> Caveman
```

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

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

---

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

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

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

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

```txt
RTK -> Caveman
```

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

```txt
ပေါင်းစပ်မှု = 1 - (1 - RTK ချွေတာမှု) * (1 - Caveman input ချွေတာမှု)
ပျမ်းမျှ    = 1 - (1 - 0.80) * (1 - 0.46) = 89.2%
အတိုင်းအတာ = 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 — အတွက်သာ သက်ဆိုင်သည်။ တောင်းဆိုမှုတိုင်းတွင်
ထိုမျှချွေတာနိုင်သည်ဟု **မဆိုလိုပါ**။

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

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

---

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

```
ဖိသိပ်မှုမပါဘဲ:       LLM သို့ token 47K ပို့သည်
Lite ဖြင့်:            token 40K ပို့သည်          (15% ချွေတာ — ဘေးကင်းပြီး အမြဲဖွင့်ထားသည်)
Standard ဖြင့်:        token 33K ပို့သည်          (30% ချွေတာ — caveman-speak စည်းမျဉ်းများ)
Aggressive ဖြင့်:      token 24K ပို့သည်          (50% ချွေတာ — aging + အနှစ်ချုပ်ခြင်း)
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** — လမ်းကြောင်းသတ်မှတ်ရေး combo များထံ သတ်မှတ်ပေးထားသော အမည်တပ် engine pipeline များ
- **Auto-Trigger Threshold** — token အရေအတွက်သည် သတ်မှတ်အဆင့်ကို ကျော်လွန်သောအခါ compression ကို အလိုအလျောက် စတင်အသုံးပြုခြင်း

### Combo အလိုက် အစားထိုးသတ်မှတ်မှု

`Dashboard → Context & Cache → Compression Combos` တွင် compression combo တစ်ခုကို routing
combo တစ်ခုထံ သတ်မှတ်ပေးပါ-

```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
```

၎င်းက အခပေး subscription များတွင် lite မုဒ်ကို ဆက်လက်အသုံးပြုထားစဉ် အခမဲ့/coding provider များတွင်
အဆင့်ဆင့်ဆက်ထားသော compression ကို အသုံးပြုနိုင်စေသည်။

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

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

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

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

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

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

### API

```bash
# Compression ဆက်တင်များကို ရယူရန်
curl http://localhost:20128/api/settings/compression

# 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 pack များကို စာရင်းပြုစုရန်
curl http://localhost:20128/api/context/rtk/filters

# ရွေးချယ်ထည့်သွင်းနိုင်သော command metadata ဖြင့် RTK ကို တိုက်ရိုက်စမ်းသပ်ရန်
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"}'
```

---

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

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

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

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

---

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

ချုံ့ထားသော request တိုင်းတွင် server log များအတွင်း ကိန်းဂဏန်းများ ပါဝင်သည်-

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

---

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

| အဆင့်    | Mode များ                                                                                                                                                   | အခြေအနေ         |
| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| Phase 1  | Off, Lite                                                                                                                                                   | ✅ ဖြန့်ချိပြီး |
| Phase 2  | Standard, Aggressive, Ultra                                                                                                                                 | ✅ ဖြန့်ချိပြီး |
| Phase 3  | RTK, Stacked, Compression Combos                                                                                                                            | ✅ ဖြန့်ချိပြီး |
| Phase 4  | Output Styles, SLM-tier Ultra, eval harness                                                                                                                 | ✅ ဖြန့်ချိပြီး |
| Phase 4C | Adaptive context-budget ("dial") — တွက်ချက်မှုအင်ဂျင် + API (`PUT /api/settings/compression` ရှိ `contextBudget`) + dashboard mode/policy ထိန်းချုပ်မှုများ | ✅ ဖြန့်ချိပြီး |

---

## အသိအမှတ်ပြုခြင်း

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

RTK mode ကို **[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%` ချွေတာထားသည်ကို ပြသထားသည်။

---

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

အထက်တွင် ဖော်ပြထားသော mode 7 ခုအပြင် (source သည် `codex-responses` နှင့်
`omniglyph` mode များကိုလည်း လက်ခံသော်လည်း ဤလမ်းညွှန်တွင် ၎င်းတို့ကို မဖော်ပြထားပါ)၊ အောက်ပါအပိုင်းများတွင်
အဆိုပါ mode များအတွင်း သို့မဟုတ် ၎င်းတို့နှင့်အတူ အလုပ်လုပ်သည့် feature များကို ဖော်ပြထားသည်- Tool Result Compression နှင့် Progressive Aging
တို့သည် aggressive engine ၏ အဆင့် 1 နှင့် 2 ဖြစ်သည် (Aggressive mode နှင့် stacked pipeline တစ်ခု၏ `aggressive` အဆင့်)၊ Stacked Pipeline သည် Stacked mode အလုပ်လုပ်ပုံဖြစ်သည်၊ Cache-Aware Compression သည် compression
ဖွင့်ထားစဉ် caching provider များအတွက် `aggressive` နှင့် `ultra` ကို `standard` သို့
အဆင့်လျှော့ပေးပြီး Caveman Output Mode နှင့် Output Styles တို့သည် ပုံမှန်အားဖြင့် ပိတ်ထားသော၊ အသုံးပြုရန် ရွေးချယ်ဖွင့်ရသည့် system-prompt ညွှန်ကြားချက်များဖြစ်ကာ request ကို ဖိသိပ်မည့်အစား model ၏ output ပုံစံကို သတ်မှတ်ပေးသည်။

### Cache-Aware Compression

အချို့ provider များ (ဥပမာ prompt caching ပါဝင်သည့် Anthropic) သည် **prompt caching** ကို ပံ့ပိုးပြီး၊
၎င်းက ကုန်ကျစရိတ်နှင့် ကြာချိန်ကို လျှော့ချရန် prompt ၏ အစိတ်အပိုင်းများကို cache လုပ်နိုင်စေသည်။ Caching
ဖွင့်ထားသောအခါ aggressive compression သည် cache ထားသည့် token များကို ပြောင်းလဲပြီး cache ကို ပျက်ပြယ်စေသောကြောင့် စွမ်းဆောင်ရည်ကို အမှန်တကယ် **ထိခိုက်စေနိုင်သည်**။

`cachingAware.ts` module သည် **caching context ကို ရှာဖွေခြင်း** နှင့်
**compression strategy ကို သင့်လျော်စွာ ချိန်ညှိခြင်း** ဖြင့် ဤပြဿနာကို ဖြေရှင်းပေးသည်။

#### အလုပ်လုပ်ပုံ

1. **Caching context ကို ရှာဖွေခြင်း** — Request body အတွင်းရှိ `cache_control` marker များကို ရှာဖွေစစ်ဆေးသည်
2. **Caching provider များကို သတ်မှတ်ခြင်း** — ပစ်မှတ် provider က caching ကို ပံ့ပိုးခြင်း ရှိ၊ မရှိ စစ်ဆေးသည်
3. **Strategy ကို ချိန်ညှိခြင်း** — Caching provider များအတွက် `aggressive`/`ultra` ကို `standard` သို့ အဆင့်လျှော့ပေးသည်
4. **System prompt ကို ကျော်ခြင်း** — System prompt များကို ပုံမှန်အားဖြင့် cache လုပ်ထားသောကြောင့် ၎င်းတို့ကို မဖိသိပ်ပါ

Strategy helper သည် `deterministicOnly` flag ကိုလည်း ပြန်ပေးသော်လည်း plan builder က
strategy ကိုသာ အသုံးပြုသည် — လက်ရှိတွင် downstream ရှိ မည်သည့်အရာကမျှ ထို flag ကို မဖတ်ပါ။

#### ကုဒ်နမူနာ

```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", targetFormat: null, isCachingProvider: true }

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

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

Cache-aware compression သည် **အမြဲဖွင့်ထားသည်** — configuration မလိုအပ်ပါ။ Compression
ဖွင့်ထားပြီး ပစ်မှတ် provider က prompt caching ကို ပံ့ပိုးသည့်အခါတိုင်း (Anthropic, OpenAI
စသည်တို့) ၎င်းသည် စတင်အလုပ်လုပ်သည်။ `cache_control` marker များကို တိတိကျကျ ထည့်ပေးရန် မလိုအပ်ပါ — caching provider ဖြစ်ရုံဖြင့်
အဆင့်လျှော့မှုကို စတင်စေပြီး marker များသက်သက်ဖြင့် မည်သည့်အခါမျှ မစတင်စေပါ (marker ရှာဖွေမှုကို cache
telemetry အတွက် အသုံးပြုခြင်းဖြစ်ပြီး strategy ဆုံးဖြတ်ချက်အတွက် မဟုတ်ပါ)။

### Progressive Aging

ရှည်လျားသော စကားဝိုင်းများတွင် message turn များစွာ စုပုံလာသော်လည်း ပိုဟောင်းသော turn များသည်
ဆက်စပ်မှု ပိုနည်းလာသည်။ `progressiveAging.ts` module သည် **turn အကွာအဝေးအလိုက် message များ၏ အသေးစိတ်အဆင့်ကို လျှော့ချပေးသည်**
(အကွာအဝေးကို စကားဝိုင်း၏ အဆုံးမှ စတင်တိုင်းတာသည်)။ ဖြန့်ချိထားသည့် ပုံသေတန်ဖိုးများ
(`verbatim: 2, light: 2, moderate: 3`) အရ-

- **နောက်ဆုံး turn 2 ခု (အကွာအဝေး ≤ 2)**: မူရင်းအတိုင်း ထားရှိသည်
- **အကွာအဝေး 3**: Caveman compression (မလိုအပ်သော ဖြည့်စွက်စကားလုံးများ ဖယ်ရှားခြင်း)
- **အကွာအဝေး 4+**: Assistant message များကို အနှစ်ချုပ်ပြီး user message များကို ၎င်းတို့၏ ပထမ
  စာကြောင်းအထိ လျှော့ချကာ အများဆုံး စာလုံး 120 ဖြင့် ကန့်သတ်သည်။ အခြား role များကို မပြောင်းလဲပါ။ System prompt များ၊ aging လုပ်ပြီးသား
  message များနှင့် နောက်ဆုံး user message ကို အကွာအဝေး မည်မျှရှိသည်ဖြစ်စေ မူရင်းအတိုင်း အမြဲထားရှိသည်။
  မည်သည့်အရာကိုမျှ လုံးဝဖယ်ရှားခြင်း မရှိဘဲ ဖြန့်ချိထားသည့် ပုံသေတန်ဖိုးများအရ `light`
  band ကို ရောက်ရှိနိုင်ခြင်း မရှိပါ (`light` သည် `verbatim` နှင့် တူညီသည်)။

#### ကုဒ်နမူနာ

```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" },
  // ... နောက်ထပ် turn 50 ...
];

const { messages: aged, saved } = applyAging(messages, {
  verbatim: 3, // နောက်ဆုံး turn 3 ခု- မူရင်းအတိုင်း
  light: 8, // အကွာအဝေး <= 8- lite compression
  moderate: 20, // အကွာအဝေး <= 20- caveman compression
  fullSummary: 5, // type အရ လိုအပ်သော်လည်း banding code က မဖတ်ပါ
  // အကွာအဝေး > 20- အနှစ်ချုပ်ထားသည် (assistant) / ပထမစာကြောင်းကို ထားရှိသည် (user)
});

// saved = ချွေတာနိုင်ခဲ့သည့် token အရေအတွက်
```

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

Progressive aging သည် `aggressive` mode အတွက် **အမြဲဖွင့်ထားသည်** — ၎င်းသည်
`compressAggressive()` ၏ အဆင့် 2 ဖြစ်သည်။ Ultra mode တွင် ၎င်းကို မလုပ်ဆောင်ပါ။ အထူးသဖြင့် အောက်ပါတို့အတွက်
ထိရောက်သည်-

- ကာလရှည် coding session များ
- ရက်ပေါင်းများစွာ ကြာမြင့်သည့် စကားဝိုင်းများ
- Tool call များစွာပါဝင်သည့် agentic workflow များ

### Caveman Output Mode

Caveman output mode သည် model ကိုယ်တိုင် အတိုချုံး output ပေးရန် တောင်းဆိုသည့် **system prompt ညွှန်ကြားချက်များ** ကို ထည့်သွင်းသည် — `lite` အဆင့်က ဝါကျအပြည့်အစုံကို ဆက်လက်အသုံးပြုသည့် တိုတောင်းရှင်းလင်းသော အဖြေများကို တောင်းဆိုပြီး၊ `full`
က "ထက်မြက်သော ရှေးခေတ်လူသားကဲ့သို့ တိုတိုတုတ်တုတ် ဖြေဆိုရန်" တောင်းဆိုကာ `ultra` က ကြေးနန်းစာပုံစံ output ကို တောင်းဆိုသည်။
ညွှန်ကြားချက်များသည် တောင်းဆိုရုံသာဖြစ်ပြီး အာမခံနိုင်ခြင်း မရှိပါ။ Request များသည် ၎င်းတို့ကို
`applyOutputStyles()` (`open-sse/services/compression/outputStyles/apply.ts`) မှတစ်ဆင့် ရရှိသည်-
`open-sse/handlers/chatCore.ts` သည် back-compat shim
(`open-sse/services/compression/outputStyles/backCompat.ts` ရှိ `resolveOutputStyleSelection()`) ဖြင့် ရွေးချယ်မှုကို ဦးစွာ ဖြေရှင်းသည်။ `outputStyles`
ဗလာဖြစ်နေစဉ် ၎င်းသည် ဖွင့်ထားသော `cavemanOutputMode` ကို
`cavemanOutputMode.intensity` ရှိ `terse-prose` output style နှင့် ချိတ်ဆက်ပေးသည် (အောက်ရှိ Back-compat ကို ကြည့်ပါ)။ ဗလာမဟုတ်သော `outputStyles`
ရွေးချယ်မှုကို မူလအတိုင်း အသုံးပြုပြီးနောက် `cavemanOutputMode.enabled` နှင့် `intensity` သည် အကျိုးသက်ရောက်မှု မရှိတော့သော်လည်း
၎င်း၏ `autoClarity` toggle က ဆက်လက်သက်ရောက်သည်။ `outputMode.ts` တွင်
ညွှန်ကြားချက်စာသားများ (`CAVEMAN_INSTRUCTION_BY_LANGUAGE`)၊ content bypass နှင့်
ထည့်သွင်းမှုက အသုံးပြုသည့် နေရာချထားရေး helper တို့ ပါဝင်သည်။ ၎င်း၏ကိုယ်ပိုင် `applyCavemanOutputMode()` injector ကို production caller တစ်ခုမျှ အသုံးမပြုပါ။

#### အလုပ်လုပ်ပုံ

ဤမုဒ်သည် input ကို compress မလုပ်ပါ။ ၎င်းသည် system prompt ထဲသို့ instruction block တစ်ခု ထည့်သည်
(အောက်ရှိ How injection works ကိုကြည့်ပါ)၊ ထို့နောက် request အတွက် ရွေးချယ်ထားသော input compression mode တစ်ခုခုသည်
ထို block ပါဝင်လာသော body ပေါ်တွင် ဆက်လက် run သည်။ Level တိုင်း၏အဆုံးတွင် ပါရှိသည့် shared
boundaries clause မတိုင်မီ English `full` level တွင် အောက်ပါအတိုင်း ရေးထားသည်-

> "ဉာဏ်ကောင်းသော ဂူလူသားကဲ့သို့ တိုတိုတုတ်တုတ် ဖြေပါ။ Articles (a/an/the)၊ ဖြည့်စွက်စကားလုံးများ (just/really/basically/actually/simply)၊ ယဉ်ကျေးစကားများနှင့် မသေချာသည့်သဘောထားများကို ဖယ်ပါ။ ဝါကျအပိုင်းအစများ သုံးနိုင်သည်။ တိုသော အဓိပ္ပာယ်တူစကားလုံးများကို သုံးပါ (extensive မဟုတ်ဘဲ big၊ implement မဟုတ်ဘဲ fix)။ နည်းပညာဆိုင်ရာ အကြောင်းအရာအားလုံး၊ code၊ errors၊ URLs နှင့် identifiers များကို အတိအကျ ထိန်းသိမ်းပါ။"

ဤအရာသည် အောက်ပါတို့အတွက် အထူးကောင်းမွန်စွာ အလုပ်လုပ်သည်-

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

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

Caveman output mode သည် **opt-in** ဖြစ်သည်။ Compression ကို ဖွင့်ထားပါက (`enabled: true`၊ Compression Settings page ရှိ master toggle
ကို ဖွင့်ထားခြင်း)၊ `cavemanOutputMode.enabled` ဖြင့် ၎င်းကို ဖွင့်ပါ။ `intensity` က
`lite`၊ `full` သို့မဟုတ် `ultra` ကို ရွေးချယ်သည်-

```json
{
  "enabled": true,
  "cavemanOutputMode": {
    "enabled": true,
    "intensity": "full"
  }
}
```

Compression combo တစ်ခု၏ **Output Mode** toggle (`outputMode`၊ level ကို `outputModeIntensity` တွင်)
သည် ထို combo သက်ရောက်သော requests များအတွက် တူညီသည့် switch ကို သတ်မှတ်ပြီး၊
`omniroute_set_compression_engine` MCP tool က ၎င်း၏ boolean `outputMode`
argument မှတစ်ဆင့် ရေးသားသည်။ ဗလာမဟုတ်သော `outputStyles` ရွေးချယ်မှုသည် ဤ switch ထက် ဦးစားပေးသည်။ Dashboard တွင် **Terse prose** output style ကို ဖွင့်ခြင်းက တူညီသော block ကို inject လုပ်သည် (အောက်ရှိ Output
Styles ကိုကြည့်ပါ)။

### Output Styles (catalog)

အထက်ပါ Caveman output mode သည် **legacy single-style path** ဖြစ်သည်။ Phase 4 တွင် ၎င်းကို
ပေါင်းစပ်အသုံးပြုနိုင်သော output styles catalog တစ်ခုအဖြစ် ယေဘုယျပြုခဲ့သည်- `open-sse/services/compression/outputStyles/catalog.ts` ရှိ
`OUTPUT_STYLE_CATALOG`။ Style တစ်ခုစီသည် စရိတ်ပိုသက်သာသော output ထုတ်ရန် model ကိုယ်တိုင်အား တောင်းဆိုသည့် system-prompt
instruction တစ်ခုဖြစ်သည်။ Styles များကို အတူတကွ ဖွင့်နိုင်ပြီး catalog အစဉ်အတိုင်း inject လုပ်သည်။

| Style                                            | `id`            | လုပ်ဆောင်ပုံ                                                                                                                                                                                                                                                                                                                    | Instruction ဘာသာစကားများ                           |
| ------------------------------------------------ | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
| တိုတောင်းသော စကားပြေ                             | `terse-prose`   | ဖြည့်စွက်စကားလုံးများ/articles/မသေချာသည့်အသုံးအနှုန်းများကို ဖယ်ရှားပြီး နည်းပညာဆိုင်ရာ အကြောင်းအရာကို အတိအကျ ထိန်းသိမ်းသည်။ Legacy caveman output mode နှင့် တူညီသောစာသားဖြစ်သည် (ပြန်ရိုက်မထားဘဲ reference လုပ်ထားသည်)။                                                                                                       | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi      |
| Code ပိုနည်းခြင်း                                | `less-code`     | YAGNI အဆင့်ဆင့်နည်းလမ်း- အလုပ်လုပ်နိုင်သည့် အနည်းဆုံးပြောင်းလဲမှု၊ မတောင်းဆိုထားသော abstractions မပါဝင်ခြင်း။                                                                                                                                                                                                                   | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi      |
| Ponytail (ပျင်းရိသော senior dev)                 | `ponytail`      | "အကောင်းဆုံး code သည် လုံးဝမရေးထားသော code ဖြစ်သည်"- ပြန်လည်အသုံးပြုခြင်း > ပြန်ရေးခြင်း၊ အရင်းခံအကြောင်းရင်း > လက္ခဏာ၊ အလုပ်လုပ်နိုင်သည့် အတိုဆုံး diff။                                                                                                                                                                       | 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      |
| Antislop UI filter                               | `antislop-ui`   | Visual technique တိုင်းသည် ရည်ရွယ်ချက်စမ်းသပ်ချက် (အဆင့်ဆင့်အရေးပါမှု၊ identity၊ ဖတ်ရှုနိုင်မှု) ကို ကျော်ဖြတ်ရမည်။ မူလ gradients/glass/glow မပါဝင်စေဘဲ palette ကို ကန့်သတ်ပြီး template layouts မသုံးရ။ Antislop styles နှစ်ခုစလုံးသည် အသုံးမဝင်သော controls မရှိစေရန် / ဖန်တီးထားသော claims မရှိစေရန် boundary တစ်ခု ထည့်သည်။ | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi      |
| Antislop စာသားနှင့် လူသား filter                 | `antislop-copy` | တိကျသော copy (em dash၊ ယေဘုယျ CTAs၊ buzzwords၊ chatbot နိဂုံးချုပ်များ၊ တီထွင်ထားသော အချက်အလက်များ မပါဝင်ခြင်း) နှင့် လူများအတွက် စည်းမျဉ်းများ- WCAG AA contrast၊ မြင်နိုင်သော focus၊ keyboard ဖြင့် ရောက်ရှိနိုင်မှု၊ empty/loading/error states၊ mobile reflow။                                                              | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi      |
| တိုတောင်းသော CJK (文言)                          | `terse-cjk`     | `full`/`ultra` အဖြေကို Classical Chinese (文言) ဖြင့် ဖြေသည်။ `lite` သည် function words၊ ယဉ်ကျေးစကားများ သို့မဟုတ် အလှဆင်စကားများ မပါဘဲ အကျဉ်းချုပ်အဖြေများကိုသာ တောင်းဆိုသည်။                                                                                                                                                  | zh (locale အလိုက် ကန့်သတ်ထားသည်၊ အောက်တွင်ကြည့်ပါ) |

Style တိုင်းတွင် intensity level သုံးခု — `lite`၊ `full`၊ `ultra` — ပါဝင်ပြီး level တိုင်းသည်
shared boundaries clause (`outputMode.ts` ရှိ `SHARED_BOUNDARIES`) ဖြင့် အဆုံးသတ်သည်။ ၎င်းက
code blocks၊ file paths၊ commands၊ errors နှင့် URLs များကို အတိအကျ ထိန်းသိမ်းသည်။ `terse-prose` နှင့်
`terse-cjk` level စာသားများသည် ထိုစာရင်းထဲသို့ identifiers များကိုပါ ထည့်သည်။

`terse-cjk` ကို နေရာနှစ်ခုတွင် locale အလိုက် `zh` သို့ ကန့်သတ်ထားသည်။ Dashboard UI ဘာသာစကားသည် Chinese (`zh-CN` သို့မဟုတ် `zh-TW`) ဖြစ်သည့်အခါမှသာ Compression Settings page က
၎င်း၏ row ကို ပြသပြီး၊ request ၏ ဖြေရှင်းသတ်မှတ်ထားသော ဘာသာစကား (အောက်ရှိ Language
selection ကိုကြည့်ပါ) သည် `zh` ဖြစ်သည့်အခါမှသာ `applyOutputStyles()` က ၎င်းကို inject လုပ်သည်။ Row ကို ဖျောက်ထားခြင်းသည် သိမ်းဆည်းထားသော `terse-cjk` ရွေးချယ်မှုကို မရှင်းလင်းပါ-
settings API သည် မည်သည့် style id ကိုမဆို လက်ခံပြီး page ပေါ်တွင် အခြား styles များကို သိမ်းဆည်းသည့်အခါ ၎င်းကို ဆက်လက်ထိန်းသိမ်းထားသည်။ Request ပြုလုပ်ချိန်တွင် `applyOutputStyles()` ဘာသာစကားစစ်ဆေးမှုသည် တစ်ခုတည်းသော locale gate ဖြစ်သည်။

#### Injection အလုပ်လုပ်ပုံ

`applyOutputStyles()` (`open-sse/services/compression/outputStyles/apply.ts`) သည်
ရွေးချယ်မှုကို catalog နှင့် တိုက်ဆိုင်စစ်ဆေးဆုံးဖြတ်သည် (မသိသော id များနှင့် locale မကိုက်ညီသော style များကို
ဖယ်ရှားပြီး error အဖြစ် မသတ်မှတ်ပါ။ ဖြေရှင်းပြီးနောက် style တစ်ခုမျှမရှိသော ရွေးချယ်မှုသည် body ကို
မပြောင်းလဲဘဲ `no_styles` အဖြစ် ကျော်သွားသည်)၊ ရွေးထားသော instruction များကို catalog
အစီအစဉ်အတိုင်း ဆက်စပ်ပေါင်းစည်းကာ
boundaries clause ကို **တစ်ကြိမ်သာ** ထပ်ဖြည့်သည် (`less-code` သို့မဟုတ် `ponytail` ကို
ရွေးထားလျှင် safety clause ဖြစ်သည့် `SAFETY_BOUNDARIES` သို့မဟုတ် ၎င်း၏
ဘာသာပြန်ကိုပါ ထည့်သည်)၊ ထို့နောက် block ကို idempotency marker တစ်ခုတည်းဖြစ်သော
(`[OmniRoute Output Styles]`) ဖြင့် စတင်သဖြင့် ပြန်လည် apply လုပ်ခြင်းသည် မည်သည့်ပြောင်းလဲမှုမျှ မဖြစ်စေပါ။
ဖြေရှင်းဆုံးဖြတ်ထားသော ဘာသာစကားအတွက် (အောက်ရှိ Language selection ကို ကြည့်ပါ)
ဘာသာပြန်ရှိပါက English instruction အစား localized instruction ကို ထည့်သွင်းသည်။

ဗလာမဟုတ်သော `messages` array ပါသည့် body တစ်ခုတွင် idempotency စစ်ဆေးမှုကို
content bypass မတိုင်မီ လုပ်ဆောင်သည်။ `[OmniRoute Output Styles]` marker သည် top-level
`system` field (string သို့မဟုတ် content-block array) အတွင်း သို့မဟုတ် string
content ပါသည့် system message အတွင်း ရှိပြီးသားဖြစ်လျှင် body ကို `already_applied` အဖြစ်
မပြောင်းလဲဘဲထားပြီး keyword စစ်ဆေးမှုကို မလုပ်ဆောင်ပါ။
ထိုသို့မဟုတ်ပါက content bypass (`open-sse/services/compression/outputMode.ts` ရှိ
`shouldBypassCavemanOutputMode()`) သည် role မည်သို့ပင်ဖြစ်စေ နောက်ဆုံး message သုံးခု၏
စာသားကို စစ်ဆေးပြီး ထိုစာသားသည် security၊ irreversible-action သို့မဟုတ် clarification
keyword များနှင့် ကိုက်ညီလျှင်ဖြစ်စေ၊ အစီအစဉ်အလိုက် အဓိပ္ပာယ်သက်ရောက်သည့် sequence ဖြစ်သော
`first`, `then`, `after that`, `before`, `rollback` သို့မဟုတ် `backup` နောက်တွင်
အက္ခရာ 240 အတွင်း `delete`, `drop`, `migrate`, `deploy` သို့မဟုတ် `release`
ပါလာလျှင်ဖြစ်စေ turn တစ်ခုလုံးအတွက် style များကို ကျော်သွားသည်။ Bypass ကို
**Auto-Clarity Bypass** toggle (`cavemanOutputMode.autoClarity`၊ မူလအတိုင်း ဖွင့်ထားသည်)
ဖွင့်ထားစဉ် လုပ်ဆောင်သည်။ Toggle ကို ပိတ်လိုက်ပါက keyword စစ်ဆေးမှုကို ကျော်သွားသည်။

Bypass က turn ကို ဖြတ်သန်းခွင့်ပေးသောအခါ `messages[0]` အသစ်ကို မည်သည့်အခါမျှ
မဖန်တီးသည့် `placeSystemInstruction()` (တူညီသော file) သည် block ကို အောက်ပါတို့အနက်
ပထမဆုံးတွေ့ရှိသည့် နေရာတွင် ထည့်သည်-

1. အစတွင်ရှိသော string content ပါသည့် system message: ၎င်း၏စာသားနောက်တွင် block ကို ထပ်ဖြည့်သည်။
2. Top-level `system` field: string ဖြစ်ပါက ၎င်း၏စာသားနောက်တွင် block ကို ထပ်ဖြည့်သည်၊ သို့မဟုတ်
   content-block array ဖြစ်ပါက text block အသစ်အဖြစ် ထည့်သည်။
3. နောက်ပိုင်းတွင် ပထမဆုံးတွေ့ရသော string content ပါသည့် system message: ၎င်း၏
   စာသားနောက်တွင် block ကို ထပ်ဖြည့်သည်။
4. အထက်ပါတစ်ခုမျှမရှိပါက block ကို `messages` ၏အဆုံးရှိ system message အသစ်အတွင်း ထည့်သည်။

`messages` array မပါသော body (သို့မဟုတ် array အလွတ်ပါသော body) တွင် content bypass
မလုပ်ဆောင်ဘဲ top-level `system` field ကိုလည်း မစစ်ဆေးပါ။ String အမျိုးအစား
`instructions` field ၏ စာသားနောက်တွင် block ကို ထပ်ဖြည့်သည်။ သို့သော် ထို field တွင်
`[OmniRoute Output Styles]` marker ပါပြီးသားဖြစ်ပါက body ကို `already_applied` အဖြစ်
မပြောင်းလဲဘဲထားသည်။ Body တွင် string `instructions` field မရှိသော်လည်း `input`
(string သို့မဟုတ် array) ပါရှိပါက block သည် `instructions` ဖြစ်လာပြီး ထို field တွင်ရှိခဲ့သည့်
string မဟုတ်သော value ကို အစားထိုးသည်။ String `instructions` field လည်းမရှိ၊ string
သို့မဟုတ် array အမျိုးအစား `input` လည်းမရှိသော body ကို မပြောင်းလဲဘဲထားပြီး
`no_messages` အဖြစ် ကျော်သွားသည်။

#### ဖွင့်နည်း

Dashboard တွင်- **Compression Context → Compression Settings**
(`/dashboard/context/settings`)၊ Output styles ကဏ္ဍ၌ style တစ်ခုစီအတွက် on/off
toggle နှင့် level selector တစ်ခုစီရှိသည်။ Compression ကိုယ်တိုင် ဖွင့်ထားစဉ် (စာမျက်နှာ၏
master toggle ဖြစ်သော `enabled`) style များကို ထည့်သွင်းသည်။ **Auto-Clarity Bypass**
toggle သည် **Caveman** စာမျက်နှာ (`/dashboard/context/caveman`) ရှိ ၎င်း၏
**Output Mode** card အတွင်းတွင်ရှိသည်။ Programmatic နည်းဖြင့် compression config သည်
ရွေးချယ်မှုကို အောက်ပါအတိုင်း သိမ်းဆည်းထားသည်-

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

နောက်ကြောင်းပြန်လိုက်ဖက်မှု- `outputStyles` အလွတ်ဖြစ်နေစဉ် legacy
`cavemanOutputMode.enabled` setting သည် `cavemanOutputMode.intensity` ရှိ
`terse-prose` သို့ mapping လုပ်သည်။ ထို့နောက် block သည် `[OmniRoute Output Styles]`
marker ဖြင့် စတင်ပြီး legacy `applyCavemanOutputMode()` injector ကမူ
`[OmniRoute Caveman Output Mode]` ကို ထည့်သွင်းခဲ့သည်။ Marker အောက်ရှိ စာသားသည်
en, pt-BR, es, de, fr, it, ru, id နှင့် vi တို့တွင် legacy injection နှင့် တူညီသည်။
ja နှင့် zh တို့တွင် boundaries clause မတိုင်မီ space တစ်ခု ပိုပါသည်။
`terse-prose` ကို pt-BR, es, de, fr, it, ru, zh, ja, id နှင့် vi သို့ ဘာသာပြန်ပေးထားသဖြင့်
ဖြေရှင်းဆုံးဖြတ်ထားသော ဘာသာစကား `hu` ဖြစ်သည့် request သည် legacy injector က ၎င်း၏
Hungarian စာသားကို အသုံးပြုခဲ့သည့်နေရာတွင် English စာသားကို ရရှိသည်။

Output-style ဘာသာစကားရွေးချယ်မှု (`outputStyles/apply.ts` ရှိ
`resolveOutputStyleLanguage()`)- `languageConfig.enabled` ကို ဖွင့်ထားပြီး
`autoDetect` ကို အသုံးပြုသောအခါ request ၏ `messages` array ထဲမှ စာသားပါသည့်
နောက်ဆုံး user message (string content သို့မဟုတ် ၎င်း၏ content part များထဲရှိ `text`)
ကို နမူနာယူကာ Caveman engine ၏ detector (`detectCompressionLanguage()`) ကို
၎င်းအပေါ် run သည်။ Detector သည် kana မပါဘဲ Han character များပါသော စာသားအတွက်
`zh` ကို ပြန်ပေးသည်။ ထိုသို့မဟုတ်ပါက `it`, `pt-BR`, `es`, `de`, `fr`, `ru`, `ja`,
`hu` နှင့် `id` တို့အနက် hint အများဆုံး ကိုက်ညီသည့် ဘာသာစကားကို ပြန်ပေးပြီး
တစ်ခုမျှမကိုက်ညီလျှင် `en` ကို ပြန်ပေးသည် — အမျိုးအစားမခွဲခြားနိုင်သော စာသားသည်
`defaultLanguage` ကို မည်သည့်အခါမျှ မသုံးဘဲ English ကို ရရှိပြီး style များတွင် `vi`
စာသားပါရှိသော်လည်း `vi` ကို မည်သည့်အခါမျှ detect မလုပ်ပါ။ Responses API body သည်
၎င်း၏ turn များကို `input` ထဲတွင် ထားရှိပြီး ထိုနေရာမှ နမူနာမယူသောကြောင့်
`defaultLanguage` ကို ရရှိကာ ထို့နောက် English ကို ရရှိသည်။ `messages` ထဲတွင်
စာသားပါသည့် user message မရှိသောအခါ သို့မဟုတ် `autoDetect` ကို ပိတ်ထားသောအခါ
`defaultLanguage` ကို အသုံးပြုပြီး ထို့နောက် English ကို အသုံးပြုသည်။
`languageConfig.enabled` ကို ပိတ်ထားပါက ဘာသာစကားသည် English ဖြစ်သည် — request တွင်
compression combo သက်ရောက်နေသည့်အခါမှလွဲ၍ ဖြစ်သည် (request ၏ routing combo အတွက်
သတ်မှတ်ထားသော combo သို့မဟုတ် built-in stacked pipeline အတွက် chatCore က fallback
လုပ်သည့် default compression combo)။ Combo တစ်ခုကို apply လုပ်ခြင်းသည် ထို request
အတွက် `languageConfig.enabled` ကို ဖွင့်ပြီး combo ၏ language pack များမှ
`defaultLanguage` ကို သတ်မှတ်သည် (သိမ်းဆည်းထားသော value သည် combo ၏ pack များထဲမှ
တစ်ခုဖြစ်ပါက ထို value ကို အသုံးပြုပြီး မဟုတ်ပါက ပုံသေအားဖြင့် `en` ဖြစ်သော combo ၏
ပထမဆုံး pack ကို အသုံးပြုသည်)။ တစ်ချိန်တည်းတွင် မူလအတိုင်း ဖွင့်ထားသည့် သိမ်းဆည်းထားသော
`autoDetect` သည် ဆက်လက်သက်ရောက်သည်။ Caveman input engine သည် ၎င်း၏ rule-pack
ဘာသာစကားကို မတူညီသောနည်းဖြင့် ရွေးချယ်သည် — text part တစ်ခုချင်းစီအလိုက် ရွေးချယ်ပြီး
auto-detect ပိတ်ထားသည့်အခါ `enabledPacks` အပေါ်မူတည်၍ ကန့်သတ်ထားသည်။

စတိုင် × ဘာသာစကား မက်ထရစ်ကို
`tests/unit/compression/output-styles-i18n-matrix.test.ts` က သတ်မှတ်ထားသည်။ catalog စတိုင်တိုင်းတွင် စမ်းသပ်မှု၏ `BASELINE_LANGUAGES` ထဲ၌ entry တစ်ခု ရှိရမည်။ locale ဖြင့် ကန့်သတ်မထားသော စတိုင်တစ်ခုသည် pt-BR ဘာသာပြန်ကို ထည့်သွင်းပေးရမည် (locale ဖြင့် ကန့်သတ်ထားသော `terse-cjk` သည် ဤစည်းမျဉ်းမှ ကင်းလွတ်သည်)။ သို့မဟုတ်ပါက ၎င်းကို `KNOWN_ENGLISH_ONLY` ထဲ၌ စာရင်းသွင်းထားရမည်။ သို့သော် ထိုစာရင်းတွင် ဘာသာပြန်ချက် လုံးဝမရှိသည့် စတိုင်များကိုသာ ထည့်ထားနိုင်သည် — စာရင်းသွင်းထားသော စတိုင်တစ်ခုတွင် မည်သည့်ဘာသာပြန်ချက်မဆို ရှိနေပါက စမ်းသပ်မှု မအောင်မြင်ပါ။ ထို့အပြင် စတိုင်တစ်ခုသည် ၎င်း၏ `BASELINE_LANGUAGES` entry ထဲတွင် စာရင်းပြုထားသော ဘာသာစကားတစ်ခု ဆုံးရှုံးသွားလျှင်လည်း စမ်းသပ်မှု မအောင်မြင်ပါ။ စတိုင်တစ်ခု ထည့်သွင်းရန်
[EXTENDING_COMPRESSION.md](./EXTENDING_COMPRESSION.md#adding-an-output-style) ကို ကြည့်ပါ။

### ကိရိယာရလဒ် ချုံ့ခြင်း

`open-sse/services/compression/toolResultCompressor.ts` ထဲရှိ `compressToolResult()` သည်
ကိရိယာရလဒ် စာသားကို **နည်းဗျူဟာ ၅ မျိုး** ဖြင့် ချုံ့သည်။ ၎င်းတို့ကို အောက်ပါအစဉ်အတိုင်း စမ်းသပ်ပြီး ဖွင့်ထားသည့် နည်းဗျူဟာများထဲမှ အကြောင်းအရာနှင့် စစ်ဆေးချက် ပထမဆုံး ကိုက်ညီသော နည်းဗျူဟာက ရလဒ်ကို ဆုံးဖြတ်သည်။

1. **`fileContent`**: စာကြောင်း ၃ ကြောင်းနှင့်အထက် ပါဝင်ပြီး အနည်းဆုံး စာကြောင်းတစ်ကြောင်းသည် ရှေ့မှ indentation ကို လျစ်လျူရှုလိုက်သည့်အခါ `import `, `export `, `function `, `class `,
   `const `, `let `, `var ` သို့မဟုတ် `return ` (keyword နှင့် space တစ်ခု) ဖြင့် စတင်ခြင်း၊ သို့မဟုတ် `if`,
   `for` သို့မဟုတ် `while` နောက်တွင် `(` သို့မဟုတ် ` (` လိုက်ခြင်းရှိသည့် အကြောင်းအရာအတွက် ပထမ စာကြောင်း ၂၀ နှင့် နောက်ဆုံး စာကြောင်း ၅ ကြောင်းကို ထိန်းသိမ်းပြီး ဖြုတ်ထားသော အလယ်ပိုင်းကို အမှတ်အသားပြုသည်။
2. **`grepSearch`**: `<path>:<digits>:` ပုံစံရှိသည့် စာကြောင်း အနည်းဆုံးတစ်ကြောင်း ပါသော အကြောင်းအရာဖြစ်ပြီး ပထမ colon မတိုင်မီ စာသား၌ whitespace မပါရပါ။ ထိုစာကြောင်းများကိုသာ အများဆုံး ၃၀ ကြောင်းအထိ ထိန်းသိမ်းပြီး နောက်ထပ် ကိုက်ညီမှုများ၏ အရေအတွက်နှင့် ကိုက်ညီသည့် ဖိုင်စာရင်းကို နောက်တွင် ထည့်ပေးသည်။ အခြားစာကြောင်းအားလုံးကို ဖယ်ရှားသည်။ ထိုသို့သော စာကြောင်းတစ်ကြောင်းတည်းဖြင့်ပင် နည်းဗျူဟာကို စတင်အသုံးပြုစေရန် လုံလောက်သောကြောင့် `12:30:45` ကဲ့သို့ timestamp ဖြင့် စတင်သည့် log စာကြောင်းကိုလည်း ထည့်တွက်သည်။
3. **`shellOutput`**: ANSI CSI sequence (`ESC[` နောက်တွင် ဂဏန်းများ သို့မဟုတ် semicolon များ၊ ထို့နောက် color code များကဲ့သို့ စာလုံးတစ်လုံး) ပါဝင်သည့် output သို့မဟုတ် စာသားအတွင်း မည်သည့်နေရာ၌မဆို whitespace နောက်လိုက်သော `$` ပါဝင်သည့် output မှ ထို sequence များကို ဖယ်ရှားသည် (`ESC[?25l` သို့မဟုတ် OSC window-title sequence ကဲ့သို့ အခြား escape များကို ထိန်းသိမ်းသည်)။ ဆက်တိုက် ထပ်နေသော စာကြောင်းများကို တစ်ကြောင်းတည်းအဖြစ် ပေါင်းပြီး နောက်ဆုံး စာကြောင်း ၅၀ ကို ထိန်းသိမ်းသည်။ ဤစစ်ဆေးချက်ကို `json` နှင့် `errorMessage` မတိုင်မီ လုပ်ဆောင်သောကြောင့် ထိုကဲ့သို့ `$` ပါဝင်သည့် JSON သို့မဟုတ် error output သည် `shellOutput` ဖွင့်ထားစဉ် ၎င်းတို့ထံ လုံးဝ မရောက်ပါ။
4. **`json`**: optional whitespace ပြီးနောက် `{` သို့မဟုတ် `[` ဖြင့် စတင်ကာ parse လုပ်နိုင်သည့် စာလုံးရေ ၂,၀၀၀ ကျော် JSON payload ကို အကျဉ်းချုပ်သည်။ item ၇ ခုထက်ပိုသော array သည် ပထမ item ၅ ခု၊ နောက်ဆုံး item ၂ ခုနှင့် စုစုပေါင်းအရေအတွက်ကို ထိန်းသိမ်းသည်။ object တစ်ခုသည် ၎င်း၏ ပထမ key ၂၀ ကို ထိန်းသိမ်းပြီး nested object သို့မဟုတ် array value တစ်ခုစီကို `{…N keys}` placeholder ဖြင့် အစားထိုးသည် (array အတွက် N သည် ၎င်း၏ အရှည်ဖြစ်သည်)။ ထို့အပြင် ပထမ key ၂၀ ကျော်လွန်၍ ဖယ်ရှားလိုက်သော key အရေအတွက်ကို ရေတွက်သည့် `_remaining_<N>_keys` အမှတ်အသားကို ထည့်ပေးသည်။ Scalar value များကို အပြည့်အစုံ ကူးယူသောကြောင့် nested value မပါသည့် key ၂၀ သို့မဟုတ် ထိုထက်နည်းသော object ကို indentation ပြန်စီရုံသာဖြစ်သည် — minified object ဆိုလျှင် စာလုံးရေ တိုးလာသဖြင့် မူလအတိုင်း ဆက်ထားသည်။
5. **`errorMessage`**: မည်သည့်နေရာ၌မဆို စာလုံးအကြီးအသေး မရွေးဘဲ `error:`,
   `error ` (`no error found` ကဲ့သို့ စကားလုံးနောက်တွင် space တစ်ခု), `[error]`,
   `exception:`, `exception `, `[exception]` သို့မဟုတ် `traceback` ပါဝင်သည့် output သည် ၎င်း၏ ပထမစာကြောင်း၊ နောက်ထပ် စာကြောင်း ၁၀ ကြောင်းနှင့် နောက်ဆုံး စာကြောင်း ၃ ကြောင်းကို ထိန်းသိမ်းပြီး ၎င်းတို့ကြားရှိ စာကြောင်းများနေရာတွင် `… [N frames elided] …` အမှတ်အသားကို ထည့်ပေးသည်။ ပထမစာကြောင်းနောက်တွင် စာကြောင်း ၁၃ ကြောင်းထက်ပိုမှသာ အမှတ်အသား ပေါ်လာသောကြောင့် ၁၄ ကြောင်း သို့မဟုတ် ထိုထက်နည်းသော error output ကို မတိုချုံ့ပါ (စာကြောင်း ၁၂ သို့မဟုတ် ၁၃ ကြောင်းတွင် နောက်ဆုံး ၃ ကြောင်းသည် ထိန်းသိမ်းထားပြီးသော စာကြောင်းများကို ထပ်မံပြသသည်)။

နည်းဗျူဟာတစ်ခု ကိုက်ညီသွားသည်နှင့် မည်သည့်ပမာဏမျှ မသက်သာစေသည့် နည်းဗျူဟာဖြစ်သည့်တိုင် နောက်ပိုင်း နည်းဗျူဟာများကို မစမ်းသပ်တော့ပါ။ ကိုက်ညီသော နည်းဗျူဟာသည် ခန့်မှန်း token အရေအတွက် (အရှည် ÷ ၄ ကို အပေါ်သို့ အနီးဆုံး ကိန်းပြည့်ယူခြင်း) လုံးဝ မသက်သာစေသည့်အခါ — ဥပမာ စာကြောင်း ၂၅ ကြောင်း သို့မဟုတ် ထိုထက်နည်းသော code နှင့်တူသည့် ဖိုင်၊ သို့မဟုတ် စာလုံးရေ ၂,၀၀၀ ကျော်ပြီး item ၇ ခု သို့မဟုတ် ထိုထက်နည်းသော JSON array — aggressive engine သည် မူလကိရိယာရလဒ်ကို ထိန်းသိမ်းသည်။ caller နှစ်ခုလုံး (`compressAggressive()` နှင့် `compressAnthropicToolResultBlock()`) သည် `saved` က 0 သို့မဟုတ် ထိုထက်နည်းလျှင် မူလရလဒ်ကို ထိန်းသိမ်းသော်လည်း `compressToolResult()` ကိုယ်တိုင်ကတော့ ထိုနည်းဗျူဟာ၏ output ကို ပြန်ပေးနေဆဲဖြစ်သည်။ ကိရိယာရလဒ် အဆင့်သည် နောက်ဆုံးဆုံးဖြတ်ချက် မဟုတ်ပါ။ engine ၏ fallback summarizer သည် စာလုံးရေ ၈,၁၉၂ ထက်ပိုရှည်သော `tool` သို့မဟုတ် `function` message (`maxTokensPerMessage`, 2,048, times 4) ကို ဆက်လက် တိုချုံ့နိုင်သည်။

#### အသုံးပြုရန် သင့်လျော်သည့်အချိန်

ကိရိယာရလဒ် ချုံ့ခြင်းသည် aggressive engine (`open-sse/services/compression/aggressive.ts` ထဲရှိ `compressAggressive()`) ၏ အဆင့် ၁ ဖြစ်သောကြောင့် Aggressive mode နှင့် stacked pipeline ၏ `aggressive` အဆင့်တို့တွင် လုပ်ဆောင်သည်။ ၎င်းသည် OpenAI ပုံစံ `tool` နှင့် `function` message များအပြင် Anthropic `tool_result` block များအတွင်းရှိ စာသားကို ချုံ့သည်။ နည်းဗျူဟာတစ်ခုစီတွင် `aggressive.toolStrategies` အောက်၌ ကိုယ်ပိုင် switch ရှိပြီး အားလုံးကို ပုံသေ ဖွင့်ထားသည်။ dashboard တွင် compression ဖွင့်ထားပြီး ပုံသေ mode သည် Aggressive ဖြစ်နေစဉ် switch များကို Caveman စာမျက်နှာ၏ **Advanced** view ထဲတွင် တွေ့နိုင်သည်။

### အဆင့်ဆင့် ပေါင်းစပ်ထားသော Pipeline

stacked mode သည် **engine များစွာကို အစဉ်လိုက်** လုပ်ဆောင်သည် — ပုံမှန်အားဖြင့် RTK ကို အရင်လုပ်ဆောင်ပြီး (ကိရိယာ output တွင် 60-90% သက်သာမှု) ကျန်ရှိသော စာသားကို Caveman ဖြင့် ဆက်လက်လုပ်ဆောင်သည် (~46% input သက်သာမှု)။ ပေါင်းစပ်လိုက်ပါက ၎င်းသည် **အကျုံးဝင်သော 78-95% အပိုင်းအခြား** ဖြစ်သည် (အထက်ရှိ Upstream Savings Math ကို ကြည့်ပါ)။ `1 - (1 - 0.60..0.90) × (1 - 0.46)` သည် ပျမ်းမျှ ≈89% ဖြစ်သည်။

#### အလုပ်လုပ်ပုံ

```
Input (1000 tokens)
  → RTK (command ကို သိရှိနားလည်သော filter) → 200 tokens
    → Caveman (မလိုအပ်သော စာသားများ ဖယ်ရှားခြင်း) → 108 tokens
  → Output (108 tokens, ~89% သက်သာမှု)
```

#### အသုံးပြုရန် သင့်လျော်သည့်အချိန်

အောက်ပါအခြေအနေများတွင် stacked mode ကို အသုံးပြုပါ။

- ကိရိယာအများအပြား အသုံးပြုသည့် workflow များ (agentic coding၊ research)
- ကုန်ကျစရိတ် အထူးဂရုပြုရသော batch processing
- token သက်သာမှု အများဆုံး လိုအပ်သည့်အခါ

Stacked pipeline များကို global `stackedPipeline` compression setting မှတစ်ဆင့် သို့မဟုတ် routing combo တစ်ခုသို့ သတ်မှတ်ထားသော အမည်ပေးထားသည့် compression combo မှတစ်ဆင့် စီစဉ်သတ်မှတ်သည် (အထက်ရှိ Per-Combo Override ကို ကြည့်ပါ) — auto-combo `modePack` မှတစ်ဆင့် မဟုတ်ပါ (ထို field သည် auto-combo model ရွေးချယ်မှု၏ weight များကိုသာ ပြန်လည်ချိန်ညှိပေးပြီး `stacked` သည် မှန်ကန်သော pack အမည် မဟုတ်ပါ)။

---

## Combo တစ်ခုချင်းအလိုက် Compression Override ပြုလုပ်ခြင်း

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

```json
{
  "id": "coding-combo",
  "strategy": "priority",
  "config": {
    "weights": { "taskFit": 0.5 },
    "modePack": "quality-first"
  },
  "compressionOverride": "aggressive"
}
```

၎င်းသည် အောက်ပါတို့အတွက် အသုံးဝင်သည်-

- **Coding combo များ**: ကြာရှည်သော session များအတွက် `aggressive` mode ကို အသုံးပြုပါ
- **အမြန် အမေးအဖြေ combo များ**: မြန်ဆန်သော တုံ့ပြန်ချက်များအတွက် `lite` mode ကို အသုံးပြုပါ
- **Tool အများအပြားသုံးသော combo များ**: အများဆုံး ချွေတာနိုင်ရန် `stacked` mode ကို အသုံးပြုပါ
- **Production combo များ**: caching provider များအတွက် override ကို ပိတ်ထားပါ — အမြဲဖွင့်ထားသော
  cache-aware adjustment သည် `aggressive`/`ultra` ကို `standard` သို့ အလိုအလျောက် လျှော့ချပေးသည်
  (ရွေးချယ်နိုင်သော `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 များ၊ ယုံကြည်မှုပုံစံ၊ အတည်ပြု 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 များ