mirror of https://github.com/diegosouzapw/OmniRoute.git synced 2026-09-21 06:12:17 +03:00

Files

Diego Rodrigues de Sa e Souza 8feea123bb feat(docs): mirror every docs/ page in all 65 locales (#14106 )

* feat(docs): mirror every docs/ page in all 65 locales

Extends the documentation mirrors from the 22-page core set (#13940) to
every Markdown page under docs/: 152 sources x 65 locales = 9,880 mirrors
(6,208 new), language bars rewritten for the full locale list, state
adopted so the blocking drift gate now covers all 152 pages.

run-translation.mjs: an oversized block made only of table rows or list
items (PROVIDER_REFERENCE.md 244-row table, FREE_TIERS.md 71-item list) is
cut at item boundaries and rejoined without a blank line — the single
16-40 KB request outlived the backend socket for verbose scripts. 48
older mirrors whose tables had lost rows were retranslated with --force.

* docs(i18n): refresh mirrors for the sources the base changed since the branch cut

Section-level retranslation of the 29 docs (and README.md) whose source
or mirrors moved on release/v3.8.51 during the run, then state adoption;
the drift gate is green again on the merged tree.

2026-09-18 13:16:46 -03:00

58 KiB

Raw Blame History

🗜️ 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 · 🇳🇱 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 को सङ्कुचन खण्ड हेर्नुहोस्।

अवलोकन

OmniRoute ले मोड्युलर प्रम्प्ट सङ्कुचन पाइपलाइन कार्यान्वयन गर्छ, जुन अनुरोधहरू अपस्ट्रिम प्रदायकहरूमा पुग्नुअघि नै सक्रिय रूपमा चल्छ। यसको अर्थ तपाईंको टोकन बचत पारदर्शी रूपमा हुन्छ — तपाईंको कार्यप्रवाहमा कुनै परिवर्तन आवश्यक पर्दैन।

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

सङ्कुचन मोडहरू

बन्द

कुनै सङ्कुचन लागू हुँदैन। सबै सन्देशहरू अपरिवर्तित रूपमा पठाइन्छन्।

हल्का मोड (~15% बचत, <1ms विलम्बता)

सबैभन्दा सुरक्षित मोड — अर्थमा कुनै परिवर्तन नगरी, ढाँचा मात्र सफा गर्छ:

प्रविधि	विवरण
`collapseWhitespace`	लगातारका खाली पङ्क्ति र अन्त्यका स्पेसहरू मर्ज गर्छ
`dedupSystemPrompt`	दोहोरिएका सिस्टम सन्देशहरू हटाउँछ
`compressToolResults`	विस्तृत उपकरण/फङ्क्सन आउटपुटहरू सङ्कुचित गर्छ
`removeRedundantContent`	दोहोरिएका निर्देशनहरू हटाउँछ
`replaceImageUrls`	base64 छवि डेटा URI हरू छोट्याउँछ

यसका लागि उत्तम: सधैँ सक्रिय रहने प्रयोग, सुरक्षा-महत्त्वपूर्ण कार्यप्रवाहहरू।

मानक मोड (~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 को अर्थगत सङ्क्षेपीकरण लागू गर्छ। स्ट्याक्ड पाइपलाइनहरूलाई ग्लोबल रूपमा वा राउटिङ कम्बोहरूमा तोकिएका सङ्कुचन कम्बोहरूमार्फत कन्फिगर गर्न सकिन्छ।

यसका लागि उत्तम: ठूला उपकरण लगहरूका साथै मानवीय निर्देशन वा सहायकका सारांशहरू भएको मिश्रित सन्दर्भ।

अपस्ट्रिम बचतको गणना

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 मिलान सूची, छोटो फाइल रिड, सामान्य संवादात्मक पाठ) माथि चलाइएको उही पाइपलाइनले सही रूपमा लगभग-शून्य बचत दिन्छ, किनभने हटाउनुपर्ने कुनै दोहोरिएको सामग्री हुँदैन र validateCompression() (validation.ts) ले कोड ब्लकहरू, URLs, शीर्षकहरू, संस्करणहरू, वा सबै-अक्षर-ठूला स्थिर पहिचानकर्ताहरू हटाउने वा परिवर्तन गर्ने पुनर्लेखन पठाउन अस्वीकार गर्छ।

यो अपेक्षित, सुरक्षित व्यवहार हो, बग होइन: प्रायः सफा फाइलहरू पढ्ने/grep गर्ने कोडिङ सत्रले कम्प्रेसन पूर्ण रूपमा सक्षम हुँदा पनि सामान्य कुल बचत देख्नेछ, जबकि असफल भइरहने लुप वा अत्यधिक आउटपुट दिने लिन्टर सामना गर्ने सत्रले त्यस्तो ट्राफिकमा पूर्ण 78-95% दायरा देख्नेछ। कम्प्रेसन गलत कन्फिगर गरिएको प्रमाणका रूपमा कुनै एक सत्रको न्यून समग्र बचत प्रतिशत प्रयोग नगर्नुहोस् — पहिले अन्तर्निहित उपकरण आउटपुट वास्तवमै दोहोरिएको थियो कि थिएन जाँच गर्नुहोस्।

टोकन बचतको दृश्याङ्कन

कम्प्रेसन बिना:         LLM लाई 47K टोकन पठाइयो
Lite सँग:               40K टोकन पठाइयो          (15% बचत — सुरक्षित, सधैँ सक्रिय)
Standard सँग:           33K टोकन पठाइयो          (30% बचत — caveman-बोलीका नियमहरू)
Aggressive सँग:         24K टोकन पठाइयो          (50% बचत — एजिङ + सारांशकरण)
Ultra सँग:              12K टोकन पठाइयो          (75% बचत — ह्युरिस्टिक छाँटकाँट)
RTK सँग:                19K-5K टोकन पठाइयो       (कमाण्ड/उपकरण आउटपुटमा 60-90% बचत)
Stacked सँग:            10K-2.5K टोकन पठाइयो     (योग्य RTK+Caveman सामग्रीमा 78-95% दायरा)

कन्फिगरेसन

ड्यासबोर्ड

ड्यासबोर्ड → कन्टेक्स्ट र क्यास मा जानुहोस्:

Caveman — मोड चयन, भाषा प्याकहरू, पूर्वावलोकन र ग्लोबल पूर्वनिर्धारितहरू
RTK — कमान्ड-फिल्टर पूर्वावलोकन, RTK सुरक्षा सेटिङहरू र फिल्टर सूची
कम्प्रेसन कम्बोहरू — राउटिङ कम्बोहरूलाई तोकिएका नामयुक्त इन्जिन पाइपलाइनहरू
स्वतः-ट्रिगर थ्रेसहोल्ड — टोकन सङ्ख्याले थ्रेसहोल्ड नाघेपछि स्वतः कम्प्रेसन सक्रिय गर्ने

प्रति-कम्बो ओभरराइड

ड्यासबोर्ड → कन्टेक्स्ट र क्यास → कम्प्रेसन कम्बोहरू मा, एउटा राउटिङ कम्बोलाई कम्प्रेसन कम्बो तोक्नुहोस्:

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

यसले सशुल्क सदस्यताहरूमा लाइट मोड कायम राख्दै निःशुल्क/कोडिङ प्रदायकहरूमा स्ट्याक गरिएको कम्प्रेसन प्रयोग गर्न दिन्छ।

यो "प्रति-कम्बो ओभरराइड" तोकाइ राउटिङ-कम्बो कम्प्रेसन मोड ओभरराइड (पूर्वनिर्धारित/बन्द/लाइट/मानक/आक्रामक/अल्ट्रा) भन्दा फरक नियन्त्रण हो — उक्त ओभरराइडले नामयुक्त कम्प्रेसन-कम्बो पाइपलाइन चयन गर्दैन; यसले resolveCompressionPlan द्वारा हेरिने compressionMode फिल्ड मात्र सेट गर्छ। यसलाई कम्बो कार्ड (ड्यासबोर्ड → कम्बोहरू) मा वा #6760 देखि, माथि दस्तावेजीकरण गरिएको पाइपलाइन-तोकाइ चेकबक्सको ठीक छेउमा रहेको ड्यासबोर्ड → कन्टेक्स्ट र क्यास → कम्प्रेसन कम्बोहरू को "राउटिङमा तोक्नुहोस्" सूचीमा प्रति राउटिङ कम्बो सेट गर्न सकिन्छ। दुवै सतहले एउटै 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"}'

के सुरक्षित रहन्छ

कम्प्रेसन इन्जिनले सधैं सुरक्षित राख्छ:

✅ कोड ब्लकहरू (फेन्स्ड र इनलाइन)
✅ URL हरू र फाइल पथहरू
✅ 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 को Caveman (⭐ 51K+) बाट प्रेरित छन् — भाइरल "धेरै टोकन किन प्रयोग गर्ने, जब थोरै टोकनले काम गर्छ" परियोजना। Caveman ले ~75% कम आउटपुट टोकन, बेन्चमार्कमा औसत 65% आउटपुट बचत, 22-87% को आउटपुट दायरा र ~46% इनपुट-कम्प्रेसन टुल रिपोर्ट गर्छ।

RTK मोड RTK AI को RTK - Rust Token Killer बाट प्रेरित छ — टर्मिनल, बिल्ड, टेस्ट, git र टुल-आउटपुट फिल्टरिङका लागि उच्च-प्रदर्शन कमान्ड-आउटपुट कम्प्रेसन परियोजना। RTK ले 60-90% बचत रिपोर्ट गर्छ, र यसको README नमुना सत्रले ~80% बचत भएको देखाउँछ।

उन्नत कम्प्रेसन प्रणालीहरू

७ मानक मोडहरूबाहेक, OmniRoute ले कन्टेक्स्टका आधारमा स्वचालित रूपमा काम गर्ने धेरै उन्नत कम्प्रेसन प्रणालीहरू समावेश गर्छ।

क्यास-सचेत कम्प्रेसन

केही प्रदायकहरूले (जस्तै प्रम्प्ट क्यासिङसहितको Anthropic) प्रम्प्ट क्यासिङ समर्थन गर्छन्, जसले लागत र विलम्बता घटाउन प्रम्प्टका केही भागहरू क्यास गर्न दिन्छ। क्यासिङ सक्षम हुँदा, आक्रामक कम्प्रेसनले वास्तवमा कार्यसम्पादनलाई हानि पुर्याउन सक्छ किनकि यसले क्यास गरिएका टोकनहरू परिवर्तन गरेर क्यास अमान्य बनाउँछ।

cachingAware.ts मोड्युलले क्यासिङ कन्टेक्स्ट पत्ता लगाएर र त्यसअनुसार कम्प्रेसन रणनीति समायोजन गरेर यो समस्या समाधान गर्छ।

यसले कसरी काम गर्छ

क्यासिङ कन्टेक्स्ट पत्ता लगाउने — अनुरोध बडीमा cache_control मार्करहरू खोज्छ
क्यासिङ प्रदायकहरू पहिचान गर्ने — लक्षित प्रदायकले क्यासिङ समर्थन गर्छ कि गर्दैन जाँच्छ
रणनीति समायोजन गर्ने — क्यासिङ प्रदायकहरूका लागि aggressive/ultra लाई standard मा डाउनग्रेड गर्छ
सिस्टम प्रम्प्ट छाड्ने — सिस्टम प्रम्प्टहरू सामान्यतया क्यास गरिएका हुन्छन्, त्यसैले तिनलाई कम्प्रेस गर्दैन
निर्धारित रूपान्तरणहरू प्रयोग गर्ने — एकरूप आउटपुट उत्पादन गर्ने रूपान्तरणहरू मात्र प्रयोग गर्छ

कोड उदाहरण

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" },
  // ... थप ५० टर्नहरू ...
];

const { messages: aged, saved } = applyAging(messages, {
  verbatim: 3, // पहिलो ३ टर्नहरू: जस्ताको तस्तै
  light: 8, // टर्न ४-८: लाइट कम्प्रेसन
  moderate: 20, // टर्न ९-२०: caveman कम्प्रेसन
  // टर्न २१+: व्यापक सारांशीकरण
});

// saved = बचत भएका टोकनहरूको सङ्ख्या

कहिले प्रयोग गर्ने

प्रगतिशील एजिङ aggressive र ultra मोडहरूका लागि सधैँ सक्रिय हुन्छ। यो विशेष रूपमा निम्नका लागि प्रभावकारी छ:

लामो समयसम्म चल्ने कोडिङ सत्रहरू
धेरै दिनसम्म चल्ने कुराकानीहरू
धेरै टुल कलहरू भएका एजेन्टिक कार्यप्रवाहहरू

केभम्यान आउटपुट मोड

outputMode.ts मोड्युलले मोडेललाई नै सङ्कुचित, छोटो आउटपुट ("केभम्यान" शैली) उत्पादन गर्न लगाउन सिस्टम प्रम्प्ट निर्देशनहरू इन्जेक्ट गर्छ।

यसले कसरी काम गर्छ

इनपुट सङ्कुचित गर्नुको सट्टा, यो मोडले यस्तो सिस्टम प्रम्प्ट थप्छ:

"न्यूनतम शब्दहरूमा जवाफ दिनुहोस्। शिष्टाचारका वाक्यांशहरू छोड्नुहोस्। छोटा वाक्यहरू प्रयोग गर्नुहोस्।"

यसले विशेष रूपमा निम्नका लागि राम्रोसँग काम गर्छ:

कोड उत्पादन (छोटो आउटपुट = कम टोकनहरू)
द्रुत प्रश्नोत्तर (विस्तृत व्याख्या आवश्यक पर्दैन)
ब्याच प्रशोधन (थ्रुपुट अधिकतम बनाउने)

कहिले प्रयोग गर्ने

केभम्यान आउटपुट मोड अप्ट-इन हो — यसलाई कम्बो कन्फिगमार्फत सेट गर्नुहोस्:

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

आउटपुट शैलीहरू (क्याटलग)

माथिको केभम्यान आउटपुट मोड पुरानो एकल-शैली मार्ग हो। Phase 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 विशेषीकृत कम्प्रेसन रणनीतिहरू प्रदान गर्छ:

खोज परिणाम कम्प्रेसन — दोहोरिएका परिणामहरू हटाउँछ, शीर्ष-N कायम राख्छ
फाइल रिड कम्प्रेसन — ठूला फाइलहरू छोट्याउँछ, हेडरहरू/इम्पोर्टहरू जोगाउँछ
कोड कार्यान्वयन कम्प्रेसन — आवश्यक stdout/stderr मात्र राख्छ
डेटाबेस क्वेरी कम्प्रेसन — पङ्क्तिहरू सीमित गर्छ, विस्तृत मेटाडेटा हटाउँछ
API प्रतिक्रिया कम्प्रेसन — null फिल्डहरू हटाउँछ, एरेहरू सङ्क्षिप्त बनाउँछ

कहिले प्रयोग गर्ने

टुल कलहरू उपस्थित हुँदा टुल परिणाम कम्प्रेसन सधैँ सक्रिय हुन्छ। कुनै कन्फिगरेसन आवश्यक पर्दैन।

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

स्ट्याक्ड मोडले धेरै इन्जिनहरू क्रमिक रूपमा चलाउँछ — सामान्यतया पहिले RTK (टुल आउटपुटमा 60-90% बचत), त्यसपछि Caveman (बाँकी पाठमा थप 30% बचत)। यसले कुल 78-95% बचत हासिल गर्छ।

यसले कसरी काम गर्छ

इनपुट (1000 टोकनहरू)
  → RTK (कमान्ड-सचेत फिल्टर) → 200 टोकनहरू
    → Caveman (अनावश्यक शब्द हटाउने) → 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 नियमहरू

58 KiB Raw Blame History Unescape Escape

🗜️ Prompt Compression Guide — OmniRoute (नेपाली)

अवलोकन

सङ्कुचन मोडहरू

बन्द

हल्का मोड (~15% बचत, <1ms विलम्बता)

मानक मोड (~30% बचत)

आक्रामक मोड (~50% बचत)

अल्ट्रा मोड (~75% बचत)

RTK मोड (60-90% अपस्ट्रिम दायरा)

स्ट्याक्ड मोड (78-95% योग्य दायरा)

अपस्ट्रिम बचतको गणना

वास्तवमा "योग्य" भन्नाले के बुझिन्छ

टोकन बचतको दृश्याङ्कन

कन्फिगरेसन

ड्यासबोर्ड

प्रति-कम्बो ओभरराइड

प्रति-अनुरोध ओभरराइड

API

के सुरक्षित रहन्छ

कम्प्रेसन तथ्याङ्क

चरणगत मार्गचित्र

आभार

उन्नत कम्प्रेसन प्रणालीहरू

क्यास-सचेत कम्प्रेसन

यसले कसरी काम गर्छ

कोड उदाहरण

कहिले प्रयोग गर्ने

क्रमिक एजिङ

कोड उदाहरण

कहिले प्रयोग गर्ने

केभम्यान आउटपुट मोड

यसले कसरी काम गर्छ

कहिले प्रयोग गर्ने

आउटपुट शैलीहरू (क्याटलग)

इन्जेक्सनले कसरी काम गर्छ

कसरी सक्षम गर्ने

टुल परिणाम कम्प्रेसन

कहिले प्रयोग गर्ने

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

यसले कसरी काम गर्छ

कहिले प्रयोग गर्ने

कम्प्रेसन कम्बो ओभरराइडहरू

यो पनि हेर्नुहोस्

58 KiB

Raw Blame History