OmniRoute/docs/i18n/my/docs/compression/COMPRESSION_GUIDE.md

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

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

---

သတ်မှတ်ချက်နှင့် ကိုက်ညီသော context အတွက် 15-95% ကို အလိုအလျောက် ချွေတာပါ။ အကျဉ်းချုပ်ကို အမြန်ကြည့်ရန် README Compression အပိုင်း ကို ကြည့်ပါ။

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

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 ကို အခြေခံထားပြီး အဓိပ္ပာယ်ကို ထိန်းသိမ်းလျက် မလိုအပ်သော စကားလုံးများနှင့် စကားရှည်အသုံးအနှုန်းများကို ဖယ်ရှားသည်-

• မလိုအပ်သော စကားလုံးများ ("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 မှာ-

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 များကို အောက်ပါအတိုင်း အဆင့်ဆင့် အသုံးပြုသည်-

RTK -> Caveman

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

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 — command-filter အစမ်းကြည့်ရှုခြင်း၊ RTK လုံခြုံရေးဆိုင်ရာ သတ်မှတ်ချက်များနှင့် filter catalog
• Compression Combos — routing combo များတွင် သတ်မှတ်ပေးထားသော အမည်ပါ engine pipeline များ
• Auto-Trigger Threshold — token အရေအတွက်သည် သတ်မှတ်ထားသည့် threshold ကို ကျော်လွန်သောအခါ compression ကို အလိုအလျောက် စတင်အသုံးပြုခြင်း

Combo တစ်ခုချင်းစီအလိုက် Override

Dashboard → Context & Cache → Compression Combos တွင် compression combo တစ်ခုကို routing combo တစ်ခုနှင့် သတ်မှတ်ချိတ်ဆက်ပါ-

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 mode ကို ဆက်လက်အသုံးပြုထားစဉ် free/coding provider များတွင် အဆင့်ဆင့်ဆက်ထားသော compression ကို အသုံးပြုနိုင်သည်။

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

Request တစ်ခုချင်းစီအလိုက် override

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

Value	အကျိုးသက်ရောက်မှု
off	ဤ request အတွက် compression မပြုလုပ်ပါ။
default	Panel မှ ဆုံးဖြတ်ထားသော Default profile (လက်ရှိအသုံးပြုနေသော profile ကို လျစ်လျူရှုသည်)။
engine:<id>	ဖွင့်ထားသည့်အခါ engine တစ်ခုတည်းကို အသုံးပြုသည်၊ ဥပမာ engine:rtk။
<combo>	အမည်ပါ combo တစ်ခု၊ ပထမဦးစွာ အမည်ဖြင့် (စာလုံးအကြီးအသေးမခွဲခြားဘဲ) တိုက်ဆိုင်စစ်ဆေးပြီးနောက် id ဖြင့် စစ်ဆေးသည်။

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

API

# 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"}'

---

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

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

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

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

---

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

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

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

---

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

အဆင့်	မုဒ်များ	အခြေအနေ
အဆင့် 1	ပိတ်ထားခြင်း၊ Lite	✅ ဖြန့်ချိပြီး
အဆင့် 2	Standard၊ Aggressive၊ Ultra	✅ ဖြန့်ချိပြီး
အဆင့် 3	RTK၊ Stacked၊ Compression Combos	✅ ဖြန့်ချိပြီး
အဆင့် 4	Output Styles၊ SLM-tier Ultra၊ eval harness	✅ ဖြန့်ချိပြီး
အဆင့် 4C	လိုက်လျောညီထွေဖြစ်သော context-budget ("dial") — တွက်ချက်မှုအင်ဂျင် + API (PUT /api/settings/compression ပေါ်ရှိ contextBudget) + ဒက်ရှ်ဘုတ် မုဒ်/မူဝါဒ ထိန်းချုပ်မှုများ	✅ ဖြန့်ချိပြီး

---

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

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

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

---

အဆင့်မြင့် ချုံ့ခြင်းစနစ်များ

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

Cache ကို ထည့်သွင်းစဉ်းစားသော ချုံ့ခြင်း

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

cachingAware.ts module သည် caching အခြေအနေကို စစ်ဆေးသိရှိခြင်း နှင့် ထိုအခြေအနေနှင့်အညီ ချုံ့ခြင်းနည်းဗျူဟာကို ချိန်ညှိခြင်း ဖြင့် ဤပြဿနာကို ဖြေရှင်းသည်။

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

1. caching အခြေအနေကို စစ်ဆေးခြင်း — တောင်းဆိုမှု body ထဲရှိ cache_control အမှတ်အသားများကို စစ်ဆေးသည်
2. caching provider များကို ခွဲခြားသတ်မှတ်ခြင်း — ဦးတည် provider သည် caching ကို ပံ့ပိုးပေးခြင်းရှိမရှိ စစ်ဆေးသည်
3. နည်းဗျူဟာကို ချိန်ညှိခြင်း — caching provider များအတွက် aggressive/ultra ကို standard သို့ လျှော့ချသည်
4. စနစ်ညွှန်ကြားချက်ကို ကျော်သွားခြင်း — စနစ်ညွှန်ကြားချက်များကို ပုံမှန်အားဖြင့် cache သိမ်းထားသောကြောင့် ၎င်းတို့ကို မချုံ့ပါ
5. သတ်မှတ်ထားသည့်အတိုင်း ထပ်တူရလဒ်ထုတ်ပေးသော ပြောင်းလဲမှုများကို အသုံးပြုခြင်း — တစ်သမတ်တည်း ရလဒ်ထွက်စေသော ပြောင်းလဲမှုများကိုသာ အသုံးပြုသည်

ကုဒ်နမူနာ

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 အမှတ်အသား
};

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

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

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

Cache ကို ထည့်သွင်းစဉ်းစားသော ချုံ့ခြင်းကို အမြဲဖွင့်ထားသည် — ဖွဲ့စည်းသတ်မှတ်ရန် မလိုအပ်ပါ။ အောက်ပါအခြေအနေများတွင်သာ စတင်အလုပ်လုပ်သည်-

• တောင်းဆိုမှုတွင် cache_control အမှတ်အသားများ ပါရှိခြင်း
• ဦးတည် provider သည် prompt caching ကို ပံ့ပိုးပေးခြင်း (Anthropic၊ OpenAI စသည်တို့)

အဆင့်ဆင့် အဟောင်းပြုလုပ်ခြင်း

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

• မကြာသေးမီ အလှည့်များ (0-3): မူရင်းအတိုင်း ထိန်းသိမ်းထားသည် (အသေးစိတ်အပြည့်အစုံ)
• အလယ်အလတ် အလှည့်များ (4-8): Lite ချုံ့ခြင်း (နေရာလွတ်များ၊ ဖော်မတ်ပြင်ဆင်မှု)
• အလှည့်ဟောင်းများ (9+): Caveman ချုံ့ခြင်း (မလိုအပ်သော စကားလုံးများ ဖယ်ရှားခြင်း၊ အကျဉ်းချုပ်ခြင်း)
• အလွန်ဟောင်းသော အလှည့်များ (20+): အလွန်အမင်း အကျဉ်းချုပ်ခြင်း သို့မဟုတ် ဖယ်ရှားခြင်း

ကုဒ်နမူနာ

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" },
  // ... နောက်ထပ် အလှည့် ၅၀ ...
];

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

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

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

တဖြည်းဖြည်း အဟောင်းပြောင်းခြင်းသည် aggressive နှင့် ultra မုဒ်များအတွက် အမြဲတမ်း ဖွင့်ထားသည်။ အောက်ပါအခြေအနေများတွင် အထူးထိရောက်သည်-

• အချိန်ကြာမြင့်စွာ လုပ်ဆောင်သည့် ကုဒ်ရေးသားမှု session များ
• ရက်ပေါင်းများစွာ ကြာမြင့်သည့် စကားဝိုင်းများ
• tool call များစွာပါဝင်သည့် agentic workflow များ

Caveman Output မုဒ်

outputMode.ts module သည် model ကိုယ်တိုင်က ချုံ့ထားပြီး တိုတောင်းသော output (“caveman” ပုံစံ) ထုတ်လုပ်စေရန် system prompt ညွှန်ကြားချက်များ ကို ထည့်သွင်းပေးသည်။

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

input ကို ချုံ့မည့်အစား ဤမုဒ်သည် အောက်ပါကဲ့သို့ system prompt တစ်ခုကို ထည့်သွင်းသည်-

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

၎င်းသည် အောက်ပါကိစ္စများတွင် အထူးကောင်းမွန်စွာ အလုပ်လုပ်သည်-

• ကုဒ်ထုတ်လုပ်ခြင်း (ပိုတိုသော output = token ပိုနည်းခြင်း)
• အမြန် အမေးအဖြေ (အသေးစိတ် ရှင်းလင်းချက်များ မလိုအပ်ခြင်း)
• Batch processing (throughput ကို အများဆုံးဖြစ်စေခြင်း)

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

Caveman output မုဒ်သည် opt-in ဖြစ်သည် — combo config မှတစ်ဆင့် သတ်မှတ်ပါ-

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

Output ပုံစံများ (ကတ်တလောက်)

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

ပုံစံ	id	လုပ်ဆောင်ချက်	ညွှန်ကြားချက် ဘာသာစကားများ
တိုတောင်းသော စကားပြေ	terse-prose	မလိုအပ်သော စကားလုံးများ/articles/မသေချာသလို ပြောဆိုမှုများကို ဖယ်ရှားပြီး နည်းပညာဆိုင်ရာ အနှစ်သာရကို တိကျစွာ ထိန်းသိမ်းသည်။ ယခင် caveman output မုဒ်နှင့် စာသားတူညီသည် (ပြန်ရိုက်မရေးဘဲ ရည်ညွှန်းထားသည်)။	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
Ponytail (အပျင်းထူသော ဝါရင့် developer)	ponytail	"အကောင်းဆုံးကုဒ်သည် ဘယ်တော့မှ မရေးခဲ့သောကုဒ်ဖြစ်သည်"- ပြန်ရေးခြင်းထက် ပြန်လည်အသုံးပြုခြင်း၊ လက္ခဏာထက် အရင်းခံအကြောင်းရင်း၊ အလုပ်လုပ်နိုင်သည့် အတိုဆုံး diff။	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
ကျွန်ုပ်တွင် ADHD ရှိသည် (လုပ်ဆောင်ချက်ကို ဦးစားပေး)	i-have-adhd	လုပ်ဆောင်ချက်ကို ဦးစွာပြခြင်း (စကားပြေမတိုင်မီ command/path/snippet)၊ နံပါတ်စဉ်တပ်ထားသော အကန့်အသတ်ရှိသည့် အဆင့်များ၊ တိကျသော နောက်အဆင့် တစ်ခုတည်း၊ နိဒါန်း/အကျဉ်းချုပ်/အပိတ်စကား မပါဝင်ခြင်း။ ayghri/i-have-adhd (MIT) မှ ပြုပြင်ယူထားသည်။	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
တိုတောင်းသော CJK (文言)	terse-cjk	ရှေးဟောင်းတရုတ်စာပေစတိုင် အလွန်တိုတောင်းသော ပုံစံ။	zh (locale အလိုက် ကန့်သတ်ထားသည်- ဖြေရှင်းသတ်မှတ်ထားသော ဘာသာစကားသည် zh ဖြစ်သည့်အခါမှသာ ပေးထားသည်)

ပုံစံတိုင်းတွင် lite၊ full၊ ultra ဟူသော ပြင်းအားအဆင့်သုံးခု ပါဝင်ပြီး အဆင့်တိုင်းသည် မျှဝေထားသော နယ်နိမိတ်ဆိုင်ရာ အပိုဒ်ဖြင့် အဆုံးသတ်သည်။ ၎င်းအပိုဒ်သည် code block များ၊ file path များ၊ command များ၊ error string များ၊ URL များနှင့် identifier များကို မူရင်းအတိုင်း ထိန်းသိမ်းပေးသည်။

ထည့်သွင်းပုံ

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

ဖွင့်နည်း

dashboard တွင်- Context → Settings → Compression — ပုံစံတစ်ခုစီအတွက် on/off toggle နှင့် level selector ပါဝင်သော row တစ်ခုစီရှိသည်။ Programmatic နည်းဖြင့် compression config သည် ရွေးချယ်မှုကို အောက်ပါအတိုင်း သိမ်းဆည်းသည်-

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

နောက်ပြန်လိုက်ဖက်ညီမှု- ယခင် outputMode: "caveman" combo setting သည် ဆက်လက်အလုပ်လုပ်ပြီး terse-prose သို့ ချိတ်ဆက်ပေးသည်။ ယခင်ဘာသာစကားတိုင်းရှိ အဟောင်း injection နှင့် byte အလိုက် တစ်ထပ်တည်းတူညီသည်။

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

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

Tool Result ချုံ့ခြင်း

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

1. ရှာဖွေမှုရလဒ် ချုံ့ခြင်း — ထပ်နေသောရလဒ်များကို ဖယ်ရှားပြီး ထိပ်ဆုံး N ခုကို ထိန်းသိမ်းသည်
2. ဖိုင်ဖတ်ရှုမှု ချုံ့ခြင်း — ကြီးမားသောဖိုင်များကို ဖြတ်တောက်ပြီး header/import များကို ထိန်းသိမ်းသည်
3. ကုဒ်လုပ်ဆောင်မှု ချုံ့ခြင်း — မရှိမဖြစ်လိုအပ်သော stdout/stderr ကိုသာ ထိန်းသိမ်းသည်
4. Database query ချုံ့ခြင်း — row အရေအတွက်ကို ကန့်သတ်ပြီး ရှည်လျားသော metadata ကို ဖယ်ရှားသည်
5. API response ချုံ့ခြင်း — null field များကို ဖယ်ရှားပြီး array များကို ကျစ်လျစ်စေသည်

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

tool call များ ပါဝင်သည့်အခါ Tool result compression ကို အမြဲတမ်း ဖွင့်ထားသည်။ Configuration ပြုလုပ်ရန် မလိုအပ်ပါ။

Stacked Pipeline

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

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

Input (1000 tokens)
  → RTK (command ကို နားလည်သည့် filter) → 200 tokens
    → Caveman (မလိုအပ်သော စကားလုံးများ ဖယ်ရှားခြင်း) → 140 tokens
  → Output (140 tokens၊ 86% ချွေတာမှု)

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

အောက်ပါကိစ္စများအတွက် stacked မုဒ်ကို အသုံးပြုပါ-

• Tool အသုံးပြုမှုများသော workflow များ (agentic coding၊ သုတေသန)
• ကုန်ကျစရိတ်အရေးကြီးသော batch processing
• token ချွေတာမှုကို အများဆုံးလိုအပ်သည့်အခါ

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

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

---

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

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

{
  "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 — Compression environment variable များ
• Architecture Guide — Compression pipeline ၏ အတွင်းပိုင်းလုပ်ဆောင်ပုံ
• User Guide — Compression ကို စတင်အသုံးပြုခြင်း
• RTK Compression — RTK filter များ၊ ယုံကြည်မှု model၊ အတည်ပြုခြင်း gate နှင့် မူရင်း output ပြန်လည်ရယူခြင်း
• Compression Engines — Caveman၊ RTK၊ stacked၊ API များ၊ MCP နှင့် dashboard
• Compression Rules Format — JSON rule-pack format
• Compression Language Packs — ဘာသာစကားအလိုက် Caveman rule များ