OmniRoute/docs/i18n/mr/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 · 🇲🇾 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 · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

पात्र संदर्भावर स्वयंचलितपणे 15-95% बचत करा. झटपट आढाव्यासाठी, README मधील Compression विभाग पहा.

आढावा

OmniRoute एक मॉड्यूलर प्रॉम्प्ट कॉम्प्रेशन पाइपलाइन कार्यान्वित करते, जी विनंत्या अपस्ट्रीम प्रदात्यांपर्यंत पोहोचण्यापूर्वी सक्रियपणे चालते. याचा अर्थ तुमची टोकन बचत पारदर्शकपणे होते — तुमच्या कार्यप्रवाहात कोणतेही बदल करण्याची आवश्यकता नाही.

क्लायंट विनंती
  → कॉम्प्रेशन धोरण निवडक
    → कॉम्बो ओव्हरराइड? → कॉम्बो सेटिंग वापरा
    → स्वयंचलित-ट्रिगर मर्यादा? → स्वयंचलित मोड वापरा
    → डीफॉल्ट मोड? → जागतिक सेटिंग वापरा
    → बंद? → कॉम्प्रेशन वगळा
  → निवडलेला कॉम्प्रेशन मोड
    → बंद: कॉम्प्रेशन नाही
    → लाइट: सुरक्षित व्हाइटस्पेस/फॉरमॅटिंग स्वच्छता (~15%)
    → स्टँडर्ड: कॅव्हमॅन-शैलीतील अनावश्यक शब्द काढणे (~30%)
    → अॅग्रेसिव्ह: इतिहासाचे कालबाह्यीकरण + सारांशीकरण (~50%)
    → अल्ट्रा: ह्युरिस्टिक छाटणी + कोड-ब्लॉक विरळ करणे (~75%)
    → RTK: कमांड-जागरूक टर्मिनल/टूल-आउटपुट फिल्टरिंग (अपस्ट्रीम श्रेणी 60-90%)
    → स्टॅक्ड: क्रमबद्ध मल्टी-इंजिन पाइपलाइन, सामान्यतः RTK नंतर Caveman (पात्र श्रेणी 78-95%)
  → कॉम्प्रेस केलेली विनंती → प्रदाता

---

कॉम्प्रेशन मोड

बंद

कोणतेही कॉम्प्रेशन लागू केले जात नाही. सर्व संदेश कोणताही बदल न होता पुढे पाठवले जातात.

लाइट मोड (~15% बचत, <1ms विलंब)

सर्वांत सुरक्षित मोड — अर्थामध्ये शून्य बदल, केवळ फॉरमॅटिंगची स्वच्छता:

तंत्र	वर्णन
collapseWhitespace	सलग रिकाम्या ओळी आणि ओळींच्या शेवटची स्पेस एकत्र करणे
dedupSystemPrompt	डुप्लिकेट सिस्टम संदेश काढून टाकणे
compressToolResults	शब्दबंबाळ टूल/फंक्शन आउटपुट कॉम्प्रेस करणे
removeRedundantContent	पुनरावृत्त सूचना काढून टाकणे
replaceImageUrls	base64 इमेज डेटा URI लहान करणे

यासाठी सर्वोत्तम: नेहमी-सक्रिय वापर, सुरक्षितता-महत्त्वपूर्ण कार्यप्रवाह.

स्टँडर्ड मोड (~30% बचत)

Caveman पासून प्रेरित — अर्थ जतन करत अनावश्यक शब्द आणि शब्दबंबाळ वाक्यरचना काढून टाकतो:

• अनावश्यक शब्द काढतो ("please", "I think", "basically", "actually")
• शब्दबंबाळ वाक्यरचना संक्षिप्त करतो ("in order to" → "to", "as a result of" → "because")
• विनम्र संदिग्ध भाषा काढतो ("Would you mind...", "If you could possibly...")
• कोडिंग प्रॉम्प्टसाठी अनुकूल केलेले 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 चे अर्थपूर्ण संक्षिप्तीकरण लागू करतो. स्टॅक्ड पाइपलाइन जागतिक स्तरावर किंवा राउटिंग कॉम्बोंना नियुक्त केलेल्या कॉम्प्रेशन कॉम्बोंद्वारे कॉन्फिगर करता येतात.

यासाठी सर्वोत्तम: मोठे टूल लॉग तसेच मानवी सूचना किंवा असिस्टंट सारांश असलेला मिश्र संदर्भ.

---

अपस्ट्रीम बचतीचे गणित

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): एकसारख्या 300 एरर ओळी असलेल्या Anthropic-स्वरूपातील tool_result ब्लॉकवर केलेल्या stacked (RTK + Caveman) रनमध्ये 95.93% टोकन बचत / 96.26% अक्षर बचत झाली — ही जाहिरात केलेल्या श्रेणीत पूर्णपणे बसते. परंतु सामान्य, पुनरावृत्ती नसलेल्या टूल आउटपुटवर (स्वच्छ grep जुळणाऱ्यांची यादी, लहान फाइल रीड, सामान्य संभाषणात्मक मजकूर) तीच पाइपलाइन योग्यरीत्या जवळपास शून्य बचत देते, कारण काढून टाकण्यासारखी कोणतीही पुनरावृत्ती नसते आणि कोड ब्लॉक, URLs, शीर्षके, आवृत्त्या किंवा ALL-CAPS स्थिरांक आयडेंटिफायर वगळणारे किंवा बदलणारे पुनर्लेखन पाठवण्यास validateCompression() (validation.ts) नकार देते.

हे अपेक्षित आणि सुरक्षित वर्तन आहे; बग नाही: प्रामुख्याने स्वच्छ फाइल्स रीड/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 सुरक्षा सेटिंग्ज आणि फिल्टर कॅटलॉग
• Compression Combos — राउटिंग कॉम्बोजना नियुक्त केलेल्या नामांकित इंजिन पाइपलाइन्स
• Auto-Trigger Threshold — टोकन संख्या मर्यादेपेक्षा जास्त झाल्यावर कम्प्रेशन स्वयंचलितपणे सक्रिय करा

प्रति-कॉम्बो ओव्हरराइड

Dashboard → Context & Cache → Compression Combos मध्ये, राउटिंग कॉम्बोला कम्प्रेशन कॉम्बो नियुक्त करा:

कॉम्बो: "free-tier-fallback"
  कम्प्रेशन कॉम्बो: "coding-agent-stack"
  पाइपलाइन: RTK -> Caveman
  लक्ष्ये:
    1. if/kimi-k2.7-code
    2. if/qwen3.8-max-preview

यामुळे सशुल्क सबस्क्रिप्शन्सवर लाइट मोड कायम ठेवताना मोफत/कोडिंग प्रोव्हायडर्सवर स्टॅक केलेले कम्प्रेशन वापरता येते.

ही "Per-Combo Override" नियुक्ती राउटिंग-कॉम्बो कम्प्रेशन मोड ओव्हरराइडपेक्षा (Default/Off/Lite/Standard/Aggressive/Ultra) वेगळे नियंत्रण आहे — ते ओव्हरराइड नामांकित कम्प्रेशन-कॉम्बो पाइपलाइन निवडत नाही; ते फक्त resolveCompressionPlan द्वारे तपासले जाणारे compressionMode फील्ड सेट करते. ते कॉम्बो कार्डवर (Dashboard → Combos) किंवा #6760 पासून, वर दस्तऐवजीकरण केलेल्या पाइपलाइन-नियुक्ती चेकबॉक्सच्या अगदी शेजारी Dashboard → Context & Cache → Compression Combos मधील "Assign to routing" सूचीमध्ये प्रत्येक राउटिंग कॉम्बोसाठी सेट करता येते. दोन्ही इंटरफेस समान PUT /api/combos/{id} एंडपॉइंटद्वारे कायमस्वरूपी जतन केले जातात.

प्रति-विनंती ओव्हरराइड

एका विनंतीसाठी कम्प्रेशन प्लॅन ओव्हरराइड करण्याकरिता x-omniroute-compression विनंती हेडर पाठवा. त्याला सर्वोच्च प्राधान्य आहे — तो राउटिंग-कॉम्बो ओव्हरराइड, सक्रिय प्रोफाइल, ऑटो-ट्रिगर आणि पॅनेल डीफॉल्टपेक्षा प्राधान्य घेतो. अज्ञात मूल्यांकडे दुर्लक्ष केले जाते (विनंती कधीही नाकारली जात नाही) आणि जागतिक मास्टर स्विच अजूनही सर्वकाही नियंत्रित करतो: कम्प्रेशन जागतिक स्तरावर बंद असताना, हेडर ते सुरू करू शकत नाही. मूल्ये:

मूल्य	परिणाम
off	या विनंतीसाठी कम्प्रेशन नाही.
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/स्टॅक केलेल्या पेलोडचे पूर्वावलोकन करा
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 मॉड्यूल, मॉडेलनेच संक्षिप्त आणि मोजका आउटपुट ("केव्हमॅन" शैली) तयार करावा यासाठी सिस्टम प्रॉम्प्ट सूचना इंजेक्ट करते.

हे कसे कार्य करते

इनपुट संक्षिप्त करण्याऐवजी, हा मोड पुढीलप्रमाणे सिस्टम प्रॉम्प्ट जोडतो:

"कमीत कमी शब्दांत उत्तर द्या. औपचारिक शिष्टाचार टाळा. लहान वाक्ये वापरा."

हे विशेषतः पुढील बाबींसाठी चांगले कार्य करते:

• कोड निर्मिती (अधिक संक्षिप्त आउटपुट = कमी टोकन्स)
• झटपट प्रश्नोत्तरे (तपशीलवार स्पष्टीकरणांची आवश्यकता नाही)
• बॅच प्रक्रिया (थ्रूपुट कमाल करा)

कधी वापरावे

केव्हमॅन आउटपुट मोड ऐच्छिक आहे — कॉम्बो कॉन्फिगद्वारे तो सेट करा:

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

आउटपुट शैली (कॅटलॉग)

वरील केव्हमॅन आउटपुट मोड हा लेगसी एकल-शैली मार्ग आहे. फेज 4 ने त्याचे संयोज्य आउटपुट शैलींच्या कॅटलॉगमध्ये सामान्यीकरण केले: open-sse/services/compression/outputStyles/catalog.ts मधील OUTPUT_STYLE_CATALOG. प्रत्येक शैली ही सिस्टम-प्रॉम्प्ट सूचना असते, जी मॉडेललाच कमी खर्चिक आउटपुट तयार करण्यास प्रवृत्त करते; शैली एकत्र सक्षम करता येतात आणि त्या कॅटलॉगच्या क्रमाने इंजेक्ट केल्या जातात.

शैली	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	"सर्वोत्तम कोड म्हणजे कधीही न लिहिलेला कोड": पुनर्वापर > पुनर्लेखन, मूळ कारण > लक्षण, सर्वात लहान कार्यरत डिफ.	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 आणि आयडेंटिफायर्स जसेच्या तसे ठेवते.

इंजेक्शन कसे कार्य करते

applyOutputStyles() (open-sse/services/compression/outputStyles/apply.ts) निवडीचे कॅटलॉगशी निराकरण करते (अज्ञात ids आणि लोकेलशी न जुळणाऱ्या शैली वगळल्या जातात, त्यामुळे कधीही त्रुटी येत नाही), निवडलेल्या सूचना कॅटलॉगच्या क्रमाने जोडते, सीमा कलम एकदाच जोडते आणि एका आयडेम्पोटन्सी मार्करच्या ([OmniRoute Output Styles]) मागे परिणाम सिस्टम प्रॉम्प्टच्या सुरुवातीला ठेवते — पुन्हा लागू केल्यास काहीही होत नाही. शोधलेल्या विनंतीच्या भाषेसाठी भाषांतर उपलब्ध असल्यास, इंग्रजीऐवजी स्थानिकीकरण केलेली सूचना इंजेक्ट केली जाते.

सक्षम कसे करावे

डॅशबोर्डमध्ये: Context → Settings → Compression — प्रत्येक शैलीसाठी एक रांग, ज्यात सुरू/बंद टॉगल आणि पातळी निवडक असतो. प्रोग्रामद्वारे, कॉम्प्रेशन कॉन्फिग निवड पुढीलप्रमाणे कायम ठेवते:

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

मागील आवृत्त्यांशी सुसंगतता: लेगसी outputMode: "caveman" कॉम्बो सेटिंग अजूनही कार्य करते आणि terse-prose शी मॅप होते; प्रत्येक लेगसी भाषेतील जुन्या इंजेक्शनशी ते बाइट-दर-बाइट एकसमान असते.

भाषा निवड: languageConfig.enabled सुरू असताना, autoDetect नवीनतम वापरकर्ता संदेशाची भाषा निवडते (इनपुट इंजिन्ससारखाच डिटेक्टर); autoDetect बंद केल्यास defaultLanguage निश्चित होते. बंद → इंग्रजी.

शैली × भाषा मॅट्रिक्स tests/unit/compression/output-styles-i18n-matrix.test.ts द्वारे निश्चित केलेले आहे: किमान pt-BR भाषांतराशिवाय (किंवा स्पष्टपणे ट्रॅक केलेल्या अपवादाशिवाय) नवीन शैली रिलीज करता येत नाही आणि विद्यमान शैलीमधून एखादे लोकेल गुपचूप काढता येत नाही. शैली जोडण्यासाठी, EXTENDING_COMPRESSION.md पहा.

टूल परिणाम कॉम्प्रेशन

toolResultCompressor.ts मॉड्यूल टूल परिणामांसाठी (फंक्शन कॉल्स, एजंट आउटपुट्स, शोध परिणाम इत्यादी) 5 विशेष कॉम्प्रेशन धोरणे पुरवते:

1. शोध परिणाम कॉम्प्रेशन — अनावश्यक पुनरावृत्तीचे परिणाम काढते, सर्वोच्च-N ठेवते
2. फाइल वाचन कॉम्प्रेशन — मोठ्या फाइल्स छाटते, हेडर्स/इम्पोर्ट्स जतन करते
3. कोड अंमलबजावणी कॉम्प्रेशन — केवळ आवश्यक stdout/stderr ठेवते
4. डेटाबेस क्वेरी कॉम्प्रेशन — ओळी मर्यादित करते, शब्दबंबाळ मेटाडेटा काढते
5. API प्रतिसाद कॉम्प्रेशन — null फील्ड्स काढते, अॅरे संक्षिप्त करते

कधी वापरावे

टूल कॉल्स उपस्थित असताना टूल परिणाम कॉम्प्रेशन नेहमी सुरू असते. कोणत्याही कॉन्फिगरेशनची आवश्यकता नाही.

स्टॅक्ड पाइपलाइन

स्टॅक्ड मोडमध्ये अनेक इंजिन्स क्रमाने चालतात — सामान्यतः प्रथम RTK (टूल आउटपुटवर 60-90% बचत), त्यानंतर केव्हमॅन (उर्वरित मजकुरावर अतिरिक्त 30% बचत). यामुळे एकूण 78-95% बचत होते.

हे कसे कार्य करते

इनपुट (1000 टोकन्स)
  → RTK (कमांड-जागरूक फिल्टर) → 200 टोकन्स
    → केव्हमॅन (भरतीचे शब्द काढणे) → 140 टोकन्स
  → आउटपुट (140 टोकन्स, 86% बचत)

कधी वापरावे

पुढील बाबींसाठी स्टॅक्ड मोड वापरा:

• टूल-प्रधान वर्कफ्लो (एजंटिक कोडिंग, संशोधन)
• खर्च-संवेदनशील बॅच प्रक्रिया
• तुम्हाला कमाल टोकन बचत आवश्यक असेल तेव्हा

कॉम्बोद्वारे कॉन्फिगर करा:

{
  "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 नियम