OmniRoute/docs/i18n/ur/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 · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

موزوں سیاق و سباق پر خودکار طور پر 15-95% بچت کریں۔ فوری جائزے کے لیے، README کا Compression سیکشن دیکھیں۔

جائزہ

OmniRoute ایک ماڈیولر پرامپٹ کمپریشن پائپ لائن نافذ کرتا ہے جو درخواستوں کے اپ اسٹریم فراہم کنندگان تک پہنچنے سے پیشگی چلتی ہے۔ اس کا مطلب ہے کہ آپ کے ٹوکنز کی بچت شفاف انداز میں ہوتی ہے — آپ کے ورک فلو میں کسی تبدیلی کی ضرورت نہیں۔

کلائنٹ کی درخواست
  → کمپریشن حکمتِ عملی کا انتخاب کنندہ
    → Combo اوور رائیڈ؟ → Combo کی ترتیب استعمال کریں
    → خودکار ٹرگر کی حد؟ → خودکار موڈ استعمال کریں
    → ڈیفالٹ موڈ؟ → عالمی ترتیب استعمال کریں
    → بند؟ → کمپریشن چھوڑ دیں
  → منتخب کردہ کمپریشن موڈ
    → بند: کوئی کمپریشن نہیں
    → ہلکا: محفوظ خالی جگہ/فارمیٹنگ کی صفائی (~15%)
    → معیاری: Caveman طرز میں اضافی الفاظ کا اخراج (~30%)
    → جارحانہ: ہسٹری ایجنگ + خلاصہ سازی (~50%)
    → الٹرا: ہیورسٹک چھانٹی + کوڈ بلاک کو مختصر کرنا (~75%)
    → RTK: کمانڈ سے آگاہ ٹرمینل/ٹول آؤٹ پٹ فلٹرنگ (اپ اسٹریم حد 60-90%)
    → اسٹیکڈ: ترتیب وار کثیر انجن پائپ لائن، عموماً پہلے RTK پھر Caveman (موزوں حد 78-95%)
  → کمپریس شدہ درخواست → فراہم کنندہ

---

کمپریشن موڈز

بند

کوئی کمپریشن لاگو نہیں کی جاتی۔ تمام پیغامات بغیر تبدیلی کے گزر جاتے ہیں۔

ہلکا موڈ (~15% بچت، <1ms تاخیر)

سب سے محفوظ موڈ — مفہوم میں کوئی تبدیلی نہیں، صرف فارمیٹنگ کی صفائی:

تکنیک	وضاحت
collapseWhitespace	مسلسل خالی سطروں اور آخری خالی جگہوں کو یکجا کرنا
dedupSystemPrompt	نقلی سسٹم پیغامات کو ہٹانا
compressToolResults	تفصیلی ٹول/فنکشن آؤٹ پٹس کو کمپریس کرنا
removeRedundantContent	دہرائی گئی ہدایات کو ہٹانا
replaceImageUrls	base64 امیج ڈیٹا URIs کو مختصر کرنا

بہترین برائے: ہمیشہ فعال استعمال، سلامتی کے لحاظ سے حساس ورک فلوز۔

معیاری موڈ (~30% بچت)

Caveman سے متاثر — معنی برقرار رکھتے ہوئے اضافی الفاظ اور غیر ضروری تفصیلی عبارت کو ہٹاتا ہے:

• اضافی الفاظ ہٹاتا ہے ("براہِ کرم"، "میرے خیال میں"، "بنیادی طور پر"، "دراصل")
• طویل فقروں کو مختصر کرتا ہے ("کرنے کے لیے" → "کو"، "کے نتیجے میں" → "کی وجہ سے")
• مؤدبانہ تذبذب والی عبارت ہٹاتا ہے ("کیا آپ کو اعتراض ہوگا..."، "اگر آپ ممکنہ طور پر کر سکیں...")
• کوڈنگ پرامپٹس کے لیے بہتر بنائے گئے 30+ regex قواعد

بہترین برائے: روزمرہ کوڈنگ ورک فلوز، لاگت کے بارے میں محتاط ٹیمیں۔

جارحانہ موڈ (~50% بچت)

طویل سیشنز کے لیے ذہین ہسٹری مینجمنٹ:

• پیغامات کی ایجنگ — پرانے پیغامات کو بتدریج زیادہ کمپریس کیا جاتا ہے
• ٹول نتائج کی خلاصہ سازی — طویل ٹول آؤٹ پٹس کو خلاصوں سے بدل دیا جاتا ہے
• ساختی سالمیت کے محافظ — یقینی بناتے ہیں کہ tool_use + tool_result جوڑے ہم آہنگ رہیں
• کانٹیکسٹ ونڈو سے آگاہی — ہر ماڈل کی ٹوکن حدود کا لحاظ رکھتی ہے

بہترین برائے: طویل ڈیبگنگ سیشنز، بڑے کوڈ بیسز۔

الٹرا موڈ (~75% بچت)

ٹوکن کے لحاظ سے حساس حالات کے لیے زیادہ سے زیادہ کمپریشن:

• ہیورسٹک چھانٹی — مطابقت کی حد سے نیچے موجود پیغامات ہٹاتی ہے
• کوڈ بلاک کو مختصر کرنا — دہرائی جانے والی کوڈ مثالوں کو کمپریس کرتا ہے
• بائنری سرچ ٹرنکیشن — کانٹیکسٹ ونڈو کے لیے بہترین قطع کا مقام تلاش کرتی ہے
• جارحانہ موڈ کی تمام خصوصیات شامل ہیں

بہترین برائے: جب آپ بار بار کانٹیکسٹ حدود تک پہنچ رہے ہوں۔

RTK موڈ (اپ اسٹریم حد 60-90%)

RTK موڈ کوڈنگ ایجنٹ سیشنز میں ظاہر ہونے والے تفصیلی ٹول آؤٹ پٹس کے لیے بہتر بنایا گیا ہے:

• git status، git diff، git log، ٹیسٹ رنرز، TypeScript/Vite/Webpack بلڈز، ESLint/Biome/Prettier، npm آڈٹ/انسٹالیشنز، Docker لاگز، انفرا آؤٹ پٹ، اور عمومی شیل آؤٹ پٹ جیسی کمانڈ/آؤٹ پٹ کلاسز کا پتا لگاتا ہے
• open-sse/services/compression/engines/rtk/filters/ سے JSON فلٹر پیکس لاگو کرتا ہے
• پروجیکٹ یا عالمی filters.toml فائلوں سے RTK TOML schema v1 فلٹرز درآمد کرتا ہے، جس میں ان لائن ٹیسٹ کی توثیق اور پروجیکٹ فائلوں کے لیے اعتماد پر مبنی پابندی شامل ہے
• ان لائن توثیقی نمونوں کے ساتھ 49 بلٹ اِن فلٹرز فراہم کرتا ہے
• ANSI کنٹرول سلسلے، پروگریس بارز، دہرائی گئی سطریں، اور ناقابلِ عمل شور ہٹاتا ہے
• ناکامیاں، خرابیاں، انتباہات، تبدیل شدہ فائلیں، خلاصے، اور طویل آؤٹ پٹ کا آخری حصہ محفوظ رکھتا ہے
• اعتماد پر مبنی پابندی والے پروجیکٹ فلٹرز، عالمی فلٹرز، اور اختیاری طور پر حذف شدہ حساس معلومات والے خام آؤٹ پٹ کی بازیابی کو سپورٹ کرتا ہے

بہترین برائے: شیل، بلڈ، ٹیسٹ، git، grep، اور فائل آؤٹ پٹ ٹرانسکرپٹس والے ایجنٹ سیشنز۔

اسٹیکڈ موڈ (موزوں حد 78-95%)

اسٹیکڈ موڈ متعدد کمپریشن انجنز کو ایک متعین ترتیب میں چلاتا ہے۔ ڈیفالٹ پائپ لائن یہ ہے:

RTK -> Caveman

یہ ترتیب پہلے ٹرمینل/ٹول آؤٹ پٹ کو مختصر رکھتی ہے، پھر باقی قدرتی زبان کے پرامپٹ پر Caveman کی معنوی اختصار کاری لاگو کرتی ہے۔ اسٹیکڈ پائپ لائنز کو عالمی طور پر یا روٹنگ combos کو تفویض کردہ کمپریشن combos کے ذریعے کنفیگر کیا جا سکتا ہے۔

بہترین برائے: بڑے ٹول لاگز کے ساتھ انسانی ہدایات یا اسسٹنٹ کے خلاصوں پر مشتمل مخلوط سیاق و سباق۔

---

اپ اسٹریم بچت کا حساب

OmniRoute کمپریشن کی بچت کو دو ذرائع سے دستاویزی شکل دیتا ہے: اپ اسٹریم پروجیکٹ بینچ مارکس اور OmniRoute کے اپنے انجنوں کی ترکیب۔

ماخذ	یہاں استعمال ہونے والا اپ اسٹریم README کا عدد
Caveman	~75% کم آؤٹ پٹ ٹوکنز، 65% بینچ مارک کی اوسط آؤٹ پٹ بچت، 22-87% حد، اور ~46% اِن پٹ کمپریشن ٹول
RTK	کمانڈ آؤٹ پٹ میں 60-90% بچت؛ نمونہ سیشن میں ~118,000 -> ~23,900 ٹوکنز، یا 79.7% بچت (~80%)

ایک دوسرے پر منطبق ہونے والے ٹول/کانٹیکسٹ پے لوڈز کے لیے، OmniRoute کا ڈیفالٹ امتزاج انجنوں کو یکے بعد دیگرے چلاتا ہے:

RTK -> Caveman

مشترکہ بچت ضربی ہوتی ہے، جمعی نہیں:

مشترکہ = 1 - (1 - RTK بچت) * (1 - Caveman اِن پٹ بچت)
اوسط   = 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 دونوں ایک ہی اِن پٹ/کانٹیکسٹ پے لوڈ کو کم کر سکیں۔ Caveman کا رسپانس آؤٹ پٹ موڈ الگ ہے: فعال ہونے پر، Caveman کی اپنی آؤٹ پٹ بچت (65% اوسط، ~75% نمایاں عدد، 22-87% حد) استعمال کریں۔ بلنگ کی کل بچت آپ کے پرامپٹ/آؤٹ پٹ کے تناسب پر منحصر ہے۔

"اہل" ہونے کا اصل مطلب

15-95% کی نمایاں حد حقیقی ہے، لیکن یہ صرف مکرر یا غیر ضروری طور پر طویل مواد پر لاگو ہوتی ہے — بار بار آنے والی خرابی کی سطریں، ایک بلڈ لاگ جو ایک ہی وارننگ بار بار دکھاتا ہو، یا ضرورت سے بڑا grep/فائل ریڈ ڈمپ۔ اس کا یہ مطلب نہیں کہ ہر درخواست میں اتنی بچت ہوتی ہے۔

تجرباتی طور پر تصدیق شدہ (tests/unit/compression/stacked-compression-tool-result-savings.test.ts): ایک stacked (RTK + Caveman) رن نے Anthropic ساخت کے tool_result بلاک میں موجود 300 یکساں خرابی کی سطروں پر 95.93% ٹوکن بچت / 96.26% کریکٹر بچت حاصل کی — جو تشہیر کردہ حد کے عین اندر ہے۔ لیکن یہی پائپ لائن جب عام، غیر مکرر ٹول آؤٹ پٹ (ایک صاف grep میچ فہرست، ایک مختصر فائل ریڈ، عام گفتگو کا متن) پر چلائی جاتی ہے تو درست طور پر تقریباً صفر بچت دیتی ہے، کیونکہ حذف کرنے کے لیے کوئی تکرار موجود نہیں ہوتی اور validateCompression() (validation.ts) ایسی دوبارہ تحریر بھیجنے سے انکار کرتا ہے جو کوڈ بلاکس، URLs، سرخیوں، ورژنز، یا ALL-CAPS مستقل شناخت کاروں کو حذف یا تبدیل کرے۔

یہ متوقع اور محفوظ رویہ ہے، بگ نہیں: ایک کوڈنگ سیشن جو زیادہ تر صاف فائلیں پڑھتا/grep کرتا ہے، اس میں کمپریشن مکمل طور پر فعال ہونے کے باوجود مجموعی بچت معمولی ہوگی، جبکہ ناکام ہونے والے لوپ یا بہت زیادہ آؤٹ پٹ دینے والے لنٹر والے سیشن میں اس ٹریفک پر مکمل 78-95% حد کی بچت ہوگی۔ کسی ایک سیشن کی کم مجموعی بچت کی شرح کو کمپریشن کی غلط کنفیگریشن کا ثبوت نہ سمجھیں — پہلے یہ جانچیں کہ آیا بنیادی ٹول آؤٹ پٹ واقعی مکرر تھا۔

---

ٹوکن بچت کی بصری نمائندگی

کمپریشن کے بغیر:       LLM کو 47K ٹوکنز بھیجے گئے
Lite کے ساتھ:          40K ٹوکنز بھیجے گئے          (15% بچت — محفوظ، ہمیشہ فعال)
Standard کے ساتھ:      33K ٹوکنز بھیجے گئے          (30% بچت — caveman-speak اصول)
Aggressive کے ساتھ:    24K ٹوکنز بھیجے گئے          (50% بچت — عمر بندی + خلاصہ سازی)
Ultra کے ساتھ:         12K ٹوکنز بھیجے گئے          (75% بچت — تخمینی چھانٹی)
RTK کے ساتھ:           19K-5K ٹوکنز بھیجے گئے       (کمانڈ/ٹول آؤٹ پٹ پر 60-90% بچت)
Stacked کے ساتھ:       10K-2.5K ٹوکنز بھیجے گئے     (اہل RTK+Caveman مواد پر 78-95% حد)

---

کنفیگریشن

ڈیش بورڈ

Dashboard → Context & Cache پر جائیں:

• Caveman — موڈ کا انتخاب، لینگویج پیکس، پیش منظر، اور عالمی ڈیفالٹس
• RTK — کمانڈ فلٹر کا پیش منظر، RTK حفاظتی ترتیبات، اور فلٹر کیٹلاگ
• کمپریشن کومبوز — نام زدہ انجن پائپ لائنز جو روٹنگ کومبوز کو تفویض کی گئی ہیں
• خودکار ٹرگر کی حد — ٹوکنز کی تعداد حد سے تجاوز کرنے پر کمپریشن کو خودکار طور پر فعال کریں

فی کومبو اوور رائیڈ

Dashboard → Context & Cache → Compression Combos میں، کسی روٹنگ کومبو کو ایک کمپریشن کومبو تفویض کریں:

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

اس سے آپ مفت/کوڈنگ فراہم کنندگان پر اسٹیکڈ کمپریشن استعمال کر سکتے ہیں، جبکہ بامعاوضہ سبسکرپشنز پر لائٹ موڈ برقرار رکھ سکتے ہیں۔

یہ "فی کومبو اوور رائیڈ" تفویض روٹنگ کومبو کمپریشن موڈ اوور رائیڈ (Default/Off/Lite/Standard/Aggressive/Ultra) سے ایک مختلف کنٹرول ہے — وہ اوور رائیڈ کسی نام زدہ کمپریشن کومبو پائپ لائن کا انتخاب نہیں کرتا؛ وہ صرف compressionMode فیلڈ متعین کرتا ہے جسے resolveCompressionPlan استعمال کرتا ہے۔ اسے یا تو کومبو کارڈ (Dashboard → Combos) پر، یا #6760 کے بعد سے، Dashboard → Context & Cache → Compression Combos میں "Assign to routing" فہرست کے اندر ہر روٹنگ کومبو کے لیے، اوپر درج پائپ لائن تفویض چیک باکس کے بالکل ساتھ متعین کیا جا سکتا ہے۔ دونوں جگہوں کی تبدیلیاں ایک ہی PUT /api/combos/{id} اینڈ پوائنٹ کے ذریعے محفوظ رہتی ہیں۔

فی درخواست اوور رائیڈ

کسی ایک درخواست کے لیے کمپریشن پلان کو اوور رائیڈ کرنے کی خاطر x-omniroute-compression درخواست ہیڈر بھیجیں۔ اس کی ترجیح سب سے زیادہ ہے — یہ روٹنگ کومبو اوور رائیڈ، فعال پروفائل، خودکار ٹرگر، اور پینل کے Default پر فوقیت رکھتا ہے۔ نامعلوم قدروں کو نظر انداز کیا جاتا ہے (درخواست کبھی مسترد نہیں کی جاتی)، اور عالمی ماسٹر سوئچ پھر بھی ہر چیز کو کنٹرول کرتا ہے: جب کمپریشن عالمی طور پر بند ہو تو ہیڈر اسے فعال نہیں کر سکتا۔ قدریں:

قدر	اثر
off	اس درخواست کے لیے کوئی کمپریشن نہیں۔
default	پینل سے اخذ کردہ Default پروفائل (فعال پروفائل کو نظر انداز کرتا ہے)۔
engine:<id>	فعال ہونے کی صورت میں ایک واحد انجن، مثلاً engine:rtk۔
<combo>	ایک نام زدہ کومبو، پہلے نام کے مطابق (حروف کی صورت سے قطع نظر)، پھر id کے مطابق ملایا جاتا ہے۔

لاگو شدہ پلان کو X-OmniRoute-Compression: <mode>; source=<source> جوابی ہیڈر میں واپس دکھایا جاتا ہے، جہاں <source>، request-header، routing-override، active-profile، auto-trigger، default، یا off میں سے ایک ہوتا ہے۔

API

# کمپریشن کی ترتیبات حاصل کریں
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 پے لوڈ کا پیش منظر دیکھیں
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 فلٹر پیکس کی فہرست حاصل کریں
curl http://localhost:20128/api/context/rtk/filters

# اختیاری کمانڈ میٹا ڈیٹا کے ساتھ براہ راست 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"}'

---

کیا محفوظ رکھا جاتا ہے

کمپریشن انجن ہمیشہ درج ذیل کو محفوظ رکھتا ہے:

• ✅ کوڈ بلاکس (فینس شدہ اور اِن لائن)
• ✅ URLs اور فائل پاتھس
• ✅ JSON ساختیں اور منظم ڈیٹا
• ✅ شناخت کنندگان اور محفوظ تکنیکی ٹوکنز
• ✅ ریاضیاتی اظہارات
• ✅ ٹول/فنکشن کال کی تعریفیں
• ✅ سسٹم پرامپٹس (لائٹ موڈ میں)

کسی بھی چیز کو محفوظ کیے جانے سے پہلے RTK خام آؤٹ پٹ ریکوری عام API کیز، بیئرر ٹوکنز، Slack ٹوکنز، AWS ایکسیس کیز، پاس ورڈز، ٹوکنز، اور رازدارانہ معلومات کو مخفی کر دیتی ہے۔

---

کمپریشن کے اعداد و شمار

ہر کمپریس شدہ درخواست کے اعداد و شمار سرور لاگز میں شامل ہوتے ہیں:

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

---

مراحل کا روڈ میپ

مرحلہ	موڈز	حیثیت
مرحلہ 1	بند، لائٹ	✅ جاری کر دیا گیا
مرحلہ 2	اسٹینڈرڈ، ایگریسیو، الٹرا	✅ جاری کر دیا گیا
مرحلہ 3	RTK، اسٹیکڈ، کمپریشن کومبوز	✅ جاری کر دیا گیا
مرحلہ 4	آؤٹ پٹ اسٹائلز، SLM-درجے کا الٹرا، جانچ کا نظام	✅ جاری کر دیا گیا
مرحلہ 4C	موافق کانٹیکسٹ بجٹ ("ڈائل") — کمپیوٹ انجن + API (PUT /api/settings/compression پر contextBudget) + ڈیش بورڈ موڈ/پالیسی کنٹرولز	✅ جاری کر دیا گیا

---

اعترافات

اسٹینڈرڈ موڈ کے کمپریشن قواعد JuliusBrussee (⭐ 51K+) کے Caveman سے متاثر ہیں — یہ وائرل "جب چند ٹوکن کام کر سکتے ہیں تو زیادہ ٹوکن کیوں استعمال کریں" پروجیکٹ ہے۔ Caveman آؤٹ پٹ ٹوکنز میں ~75% کمی، بینچ مارک پر اوسطاً 65% آؤٹ پٹ بچت، 22-87% آؤٹ پٹ رینج، اور ~46% اِن پٹ کمپریشن ٹول رپورٹ کرتا ہے۔

RTK موڈ RTK AI کے RTK - Rust Token Killer سے متاثر ہے — یہ ٹرمینل، بلڈ، ٹیسٹ، git، اور ٹول آؤٹ پٹ فلٹرنگ کے لیے اعلیٰ کارکردگی والا کمانڈ آؤٹ پٹ کمپریشن پروجیکٹ ہے۔ RTK 60-90% بچت رپورٹ کرتا ہے، جبکہ اس کے README کے نمونہ سیشن میں ~80% بچت دکھائی گئی ہے۔

---

جدید کمپریشن سسٹمز

7 معیاری موڈز کے علاوہ، OmniRoute میں کئی جدید کمپریشن سسٹمز شامل ہیں جو کانٹیکسٹ کی بنیاد پر خودکار طور پر کام کرتے ہیں۔

کیش سے آگاہ کمپریشن

کچھ فراہم کنندگان (جیسے پرامپٹ کیشنگ کے ساتھ Anthropic) پرامپٹ کیشنگ کی معاونت کرتے ہیں، جو انہیں لاگت اور تاخیر کم کرنے کے لیے پرامپٹ کے کچھ حصے کیش کرنے دیتی ہے۔ جب کیشنگ فعال ہو، تو ایگریسیو کمپریشن دراصل کارکردگی کو نقصان پہنچا سکتی ہے کیونکہ یہ کیش شدہ ٹوکنز کو تبدیل کرکے کیش کو غیر مؤثر کر دیتی ہے۔

cachingAware.ts ماڈیول کیشنگ کانٹیکسٹ کا پتہ لگا کر اور اس کے مطابق کمپریشن حکمت عملی کو ایڈجسٹ کرکے یہ مسئلہ حل کرتا ہے۔

یہ کیسے کام کرتا ہے

1. کیشنگ کانٹیکسٹ کا پتہ لگانا — cache_control مارکرز کے لیے درخواست کی باڈی اسکین کرتا ہے
2. کیشنگ فراہم کنندگان کی شناخت — جانچتا ہے کہ آیا ہدف فراہم کنندہ کیشنگ کی معاونت کرتا ہے
3. حکمت عملی کو ایڈجسٹ کرنا — کیشنگ فراہم کنندگان کے لیے aggressive/ultra کو standard میں ڈاؤن گریڈ کرتا ہے
4. سسٹم پرامپٹ کو چھوڑنا — سسٹم پرامپٹس عموماً کیش ہوتے ہیں، اس لیے انہیں کمپریس نہ کریں
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" }, // ← کیش مارکر
};

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

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

کب استعمال کریں

کیش سے آگاہ کمپریشن ہمیشہ فعال رہتی ہے — کسی کنفیگریشن کی ضرورت نہیں۔ یہ صرف اس وقت فعال ہوتی ہے جب:

• درخواست میں cache_control مارکرز موجود ہوں
• ہدف فراہم کنندہ پرامپٹ کیشنگ (Anthropic، OpenAI، وغیرہ) کی معاونت کرتا ہو

تدریجی فرسودگی

طویل گفتگوؤں میں پیغامات کے کئی ادوار جمع ہو جاتے ہیں، لیکن پرانے ادوار کی مطابقت کم ہوتی جاتی ہے۔ progressiveAging.ts ماڈیول دور کی بنیاد پر پیغامات کی تفصیل کم کرتا ہے:

• حالیہ ادوار (0-3): من و عن رکھے جاتے ہیں (مکمل تفصیل)
• درمیانی ادوار (4-8): لائٹ کمپریشن (خالی جگہ، فارمیٹنگ کی صفائی)
• پرانے ادوار (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" },
  // ... مزید 50 ادوار ...
];

const { messages: aged, saved } = applyAging(messages, {
  verbatim: 3, // پہلے 3 ادوار: من و عن
  light: 8, // ادوار 4-8: لائٹ کمپریشن
  moderate: 20, // ادوار 9-20: caveman کمپریشن
  // ادوار 21+: بھرپور خلاصہ کاری
});

// saved = محفوظ کیے گئے ٹوکنز کی تعداد

کب استعمال کریں

تدریجی فرسودگی aggressive اور ultra موڈز کے لیے ہمیشہ فعال رہتی ہے۔ یہ خصوصاً ان صورتوں میں مؤثر ہے:

• طویل دورانیے کے کوڈنگ سیشنز
• کئی دنوں پر محیط گفتگوئیں
• بہت سی ٹول کالز والے ایجنٹک ورک فلوز

کیو مین آؤٹ پٹ موڈ

outputMode.ts ماڈیول سسٹم پرامپٹ ہدایات شامل کرتا ہے تاکہ ماڈل خود مختصر اور جامع آؤٹ پٹ (ایک "کیو مین" انداز) تیار کرے۔

یہ کیسے کام کرتا ہے

ان پٹ کو کمپریس کرنے کے بجائے، یہ موڈ اس طرح کا سسٹم پرامپٹ شامل کرتا ہے:

"کم سے کم الفاظ میں جواب دیں۔ رسمی خوش کلامی چھوڑ دیں۔ مختصر جملے استعمال کریں۔"

یہ خصوصاً ان صورتوں میں اچھا کام کرتا ہے:

• کوڈ جنریشن (مختصر آؤٹ پٹ = کم ٹوکنز)
• فوری سوال و جواب (تفصیلی وضاحتوں کی ضرورت نہیں)
• بیچ پروسیسنگ (تھروپٹ کو زیادہ سے زیادہ کرنا)

کب استعمال کریں

کیو مین آؤٹ پٹ موڈ اختیاری ہے — اسے combo config کے ذریعے سیٹ کریں:

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

آؤٹ پٹ اسٹائلز (کیٹلاگ)

اوپر دیا گیا کیو مین آؤٹ پٹ موڈ پرانا واحد اسٹائل والا راستہ ہے۔ Phase 4 نے اسے مرکب آؤٹ پٹ اسٹائلز کے ایک کیٹلاگ میں عمومی بنا دیا: OUTPUT_STYLE_CATALOG، open-sse/services/compression/outputStyles/catalog.ts میں۔ ہر اسٹائل ایک سسٹم پرامپٹ ہدایت ہے جو ماڈل کو خود کم لاگت والا آؤٹ پٹ تیار کرنے پر آمادہ کرتی ہے؛ اسٹائلز کو بیک وقت فعال کیا جا سکتا ہے اور انہیں کیٹلاگ کی ترتیب کے مطابق شامل کیا جاتا ہے۔

اسٹائل	id	یہ کیا کرتا ہے	ہدایات کی زبانیں
مختصر نثر	terse-prose	غیر ضروری الفاظ/آرٹیکلز/مبہم محتاط عبارتیں حذف کرتا ہے؛ تکنیکی مواد کو بعینہٖ برقرار رکھتا ہے۔ متن وہی ہے جو پرانے کیو مین آؤٹ پٹ موڈ میں ہے (حوالہ دیا گیا ہے، دوبارہ تحریر نہیں کیا گیا)۔	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
کم کوڈ	less-code	YAGNI درجہ بندی: سب سے چھوٹی قابلِ عمل تبدیلی، بلا درخواست تجریدات نہیں۔	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
پونی ٹیل (سست سینئر ڈویلپر)	ponytail	"بہترین کوڈ وہ ہے جو کبھی لکھا ہی نہ جائے": دوبارہ استعمال > دوبارہ تحریر، بنیادی وجہ > علامت، مختصر ترین قابلِ عمل diff۔	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
مجھے ADHD ہے (عمل پہلے)	i-have-adhd	عمل پہلے (نثر سے پہلے کمانڈ/پاتھ/اسنیپٹ)، محدود تعداد میں نمبر وار مراحل، صرف ایک ٹھوس اگلا مرحلہ، کوئی تمہید/خلاصہ/اختتامی کلمات نہیں۔ ayghri/i-have-adhd (MIT) سے ماخوذ۔	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
مختصر CJK (文言)	terse-cjk	کلاسیکی چینی کا انتہائی مختصر انداز۔	zh (لوکیل سے محدود: صرف اس وقت پیش کیا جاتا ہے جب حل شدہ زبان zh ہو)

ہر اسٹائل کے ساتھ شدت کی تین سطحیں — lite، full، ultra — فراہم کی جاتی ہیں اور ہر سطح مشترکہ حدود کی شق پر ختم ہوتی ہے، جو کوڈ بلاکس، فائل پاتھز، کمانڈز، خرابی کے اسٹرنگز، URLs اور identifiers کو بعینہٖ برقرار رکھتی ہے۔

شمولیت کیسے کام کرتی ہے

applyOutputStyles() (open-sse/services/compression/outputStyles/apply.ts) انتخاب کو کیٹلاگ کے مطابق حل کرتا ہے (نامعلوم ids اور لوکیل سے غیر مطابق اسٹائلز حذف کر دیے جاتے ہیں، کبھی خرابی پیدا نہیں ہوتی)، منتخب ہدایات کو کیٹلاگ کی ترتیب میں جوڑتا ہے، حدود کی شق صرف ایک بار شامل کرتا ہے، اور نتیجے کو ایک واحد idempotency marker ([OmniRoute Output Styles]) کے بعد سسٹم پرامپٹ کے آغاز میں شامل کرتا ہے — دوبارہ اطلاق کوئی اثر نہیں رکھتا۔ جب شناخت شدہ درخواست کی زبان کا ترجمہ موجود ہو تو انگریزی کی بجائے مقامی زبان کی ہدایت شامل کی جاتی ہے۔

فعال کرنے کا طریقہ

ڈیش بورڈ میں: Context → Settings → Compression — ہر اسٹائل کے لیے ایک قطار، جس میں on/off ٹوگل اور سطح منتخب کرنے کا اختیار ہوتا ہے۔ پروگرام کے ذریعے، کمپریشن config انتخاب کو اس طرح محفوظ رکھتا ہے:

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

پسماندہ مطابقت: پرانی outputMode: "caveman" combo ترتیب اب بھی کام کرتی ہے اور terse-prose سے میپ ہوتی ہے، جو ہر پرانی زبان میں سابقہ شمولیت کے ساتھ بائٹ بہ بائٹ یکساں ہے۔

زبان کا انتخاب: languageConfig.enabled فعال ہونے پر، autoDetect تازہ ترین صارف پیغام کی زبان منتخب کرتا ہے (ان پٹ انجنز والا ہی detector)؛ autoDetect کو غیر فعال کرنے سے defaultLanguage مستقل ہو جاتی ہے۔ غیر فعال → انگریزی۔

اسٹائل × زبان matrix کو tests/unit/compression/output-styles-i18n-matrix.test.ts کے ذریعے مستقل کیا گیا ہے: کوئی نیا اسٹائل کم از کم pt-BR ترجمے (یا واضح طور پر ٹریک کی گئی استثنا) کے بغیر جاری نہیں کیا جا سکتا، اور کوئی موجودہ اسٹائل خاموشی سے کسی لوکیل سے محروم نہیں ہو سکتا۔ اسٹائل شامل کرنے کے لیے EXTENDING_COMPRESSION.md دیکھیں۔

ٹول نتائج کی کمپریشن

toolResultCompressor.ts ماڈیول ٹول نتائج (فنکشن کالز، ایجنٹ آؤٹ پٹس، تلاش کے نتائج وغیرہ) کے لیے 5 خصوصی کمپریشن حکمت عملیاں فراہم کرتا ہے:

1. تلاش کے نتائج کی کمپریشن — فالتو نتائج ہٹاتی ہے، سرفہرست N برقرار رکھتی ہے
2. فائل پڑھنے کی کمپریشن — بڑی فائلوں کو مختصر کرتی ہے، headers/imports محفوظ رکھتی ہے
3. کوڈ اجرا کی کمپریشن — صرف ضروری stdout/stderr برقرار رکھتی ہے
4. ڈیٹابیس کوئری کمپریشن — قطاریں محدود کرتی ہے، غیر ضروری تفصیلی metadata ہٹاتی ہے
5. API رسپانس کمپریشن — null فیلڈز ہٹاتی ہے، arrays کو مختصر کرتی ہے

کب استعمال کریں

ٹول کالز موجود ہونے پر ٹول نتائج کی کمپریشن ہمیشہ فعال رہتی ہے۔ کسی کنفیگریشن کی ضرورت نہیں۔

تہہ دار پائپ لائن

تہہ دار موڈ متعدد انجنز کو ترتیب وار چلاتا ہے — عموماً پہلے RTK (ٹول آؤٹ پٹ پر 60-90% بچت)، پھر Caveman (باقی متن پر مزید 30% بچت)۔ اس سے مجموعی طور پر 78-95% بچت حاصل ہوتی ہے۔

یہ کیسے کام کرتا ہے

ان پٹ (1000 ٹوکنز)
  → RTK (کمانڈ سے آگاہ فلٹر) → 200 ٹوکنز
    → Caveman (غیر ضروری الفاظ کا اخراج) → 140 ٹوکنز
  → آؤٹ پٹ (140 ٹوکنز، 86% بچت)

کب استعمال کریں

تہہ دار موڈ ان صورتوں میں استعمال کریں:

• ٹولز پر زیادہ انحصار والے ورک فلوز (ایجنٹک کوڈنگ، تحقیق)
• لاگت کے لحاظ سے حساس بیچ پروسیسنگ
• جب آپ کو ٹوکنز کی زیادہ سے زیادہ بچت درکار ہو

combo کے ذریعے کنفیگر کریں:

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

---

کمپریشن کومبو اوور رائیڈز

آپ مختلف استعمالی صورتوں کے لیے رویے کو بہتر بنانے کی خاطر عالمی کمپریشن موڈ کو ہر کومبو کے لیے اوور رائیڈ کر سکتے ہیں:

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

یہ درج ذیل کے لیے مفید ہے:

• کوڈنگ کومبوز: طویل سیشنز کے لیے aggressive موڈ استعمال کریں
• فوری سوال و جواب کے کومبوز: تیز جوابات کے لیے lite موڈ استعمال کریں
• ٹول پر مبنی کومبوز: زیادہ سے زیادہ بچت کے لیے stacked موڈ استعمال کریں
• پروڈکشن کومبوز: کیشنگ فراہم کنندگان کے لیے cache-aware موڈ استعمال کریں

---

مزید دیکھیں

• انوائرنمنٹ کنفیگ — کمپریشن کے انوائرنمنٹ ویری ایبلز
• آرکیٹیکچر گائیڈ — کمپریشن پائپ لائن کے اندرونی اجزا
• صارف گائیڈ — کمپریشن کے ساتھ شروعات
• RTK کمپریشن — RTK فلٹرز، ٹرسٹ ماڈل، ویریفائی گیٹ، خام آؤٹ پٹ کی بازیابی
• کمپریشن انجنز — Caveman، RTK، اسٹیکڈ، APIs، MCP، ڈیش بورڈ
• کمپریشن رولز فارمیٹ — JSON رول پیک فارمیٹ
• کمپریشن لینگویج پیکس — زبان کے لحاظ سے مخصوص Caveman قواعد