# 🗜️ Prompt Compression Guide — OmniRoute (తెలుగు) 🌐 **Languages:** 🇺🇸 [English](../../../../compression/COMPRESSION_GUIDE.md) · 🇪🇹 [am](../../../am/docs/compression/COMPRESSION_GUIDE.md) · 🇸🇦 [ar](../../../ar/docs/compression/COMPRESSION_GUIDE.md) · 🇦🇿 [az](../../../az/docs/compression/COMPRESSION_GUIDE.md) · 🇧🇬 [bg](../../../bg/docs/compression/COMPRESSION_GUIDE.md) · 🇧🇩 [bn](../../../bn/docs/compression/COMPRESSION_GUIDE.md) · 🇧🇦 [bs](../../../bs/docs/compression/COMPRESSION_GUIDE.md) · 🇨🇿 [cs](../../../cs/docs/compression/COMPRESSION_GUIDE.md) · 🇩🇰 [da](../../../da/docs/compression/COMPRESSION_GUIDE.md) · 🇩🇪 [de](../../../de/docs/compression/COMPRESSION_GUIDE.md) · 🇬🇷 [el](../../../el/docs/compression/COMPRESSION_GUIDE.md) · 🇪🇸 [es](../../../es/docs/compression/COMPRESSION_GUIDE.md) · 🇪🇪 [et](../../../et/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇷 [fa](../../../fa/docs/compression/COMPRESSION_GUIDE.md) · 🇫🇮 [fi](../../../fi/docs/compression/COMPRESSION_GUIDE.md) · 🇫🇷 [fr](../../../fr/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇪 [ga](../../../ga/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [gu](../../../gu/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇬 [ha](../../../ha/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇱 [he](../../../he/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [hi](../../../hi/docs/compression/COMPRESSION_GUIDE.md) · 🇭🇷 [hr](../../../hr/docs/compression/COMPRESSION_GUIDE.md) · 🇭🇺 [hu](../../../hu/docs/compression/COMPRESSION_GUIDE.md) · 🇦🇲 [hy](../../../hy/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇩 [id](../../../id/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇬 [ig](../../../ig/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇹 [it](../../../it/docs/compression/COMPRESSION_GUIDE.md) · 🇯🇵 [ja](../../../ja/docs/compression/COMPRESSION_GUIDE.md) · 🇬🇪 [ka](../../../ka/docs/compression/COMPRESSION_GUIDE.md) · 🇰🇭 [km](../../../km/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [kn](../../../kn/docs/compression/COMPRESSION_GUIDE.md) · 🇰🇷 [ko](../../../ko/docs/compression/COMPRESSION_GUIDE.md) · 🇱🇹 [lt](../../../lt/docs/compression/COMPRESSION_GUIDE.md) · 🇱🇻 [lv](../../../lv/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [ml](../../../ml/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [mr](../../../mr/docs/compression/COMPRESSION_GUIDE.md) · 🇲🇾 [ms](../../../ms/docs/compression/COMPRESSION_GUIDE.md) · 🇲🇹 [mt](../../../mt/docs/compression/COMPRESSION_GUIDE.md) · 🇲🇲 [my](../../../my/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇵 [ne](../../../ne/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇱 [nl](../../../nl/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇴 [no](../../../no/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [or](../../../or/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [pa](../../../pa/docs/compression/COMPRESSION_GUIDE.md) · 🇵🇭 [phi](../../../phi/docs/compression/COMPRESSION_GUIDE.md) · 🇵🇱 [pl](../../../pl/docs/compression/COMPRESSION_GUIDE.md) · 🇵🇹 [pt](../../../pt/docs/compression/COMPRESSION_GUIDE.md) · 🇧🇷 [pt-BR](../../../pt-BR/docs/compression/COMPRESSION_GUIDE.md) · 🇷🇴 [ro](../../../ro/docs/compression/COMPRESSION_GUIDE.md) · 🇷🇺 [ru](../../../ru/docs/compression/COMPRESSION_GUIDE.md) · 🇱🇰 [si](../../../si/docs/compression/COMPRESSION_GUIDE.md) · 🇸🇰 [sk](../../../sk/docs/compression/COMPRESSION_GUIDE.md) · 🇸🇮 [sl](../../../sl/docs/compression/COMPRESSION_GUIDE.md) · 🇷🇸 [sr](../../../sr/docs/compression/COMPRESSION_GUIDE.md) · 🇸🇪 [sv](../../../sv/docs/compression/COMPRESSION_GUIDE.md) · 🇰🇪 [sw](../../../sw/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [ta](../../../ta/docs/compression/COMPRESSION_GUIDE.md) · 🇹🇭 [th](../../../th/docs/compression/COMPRESSION_GUIDE.md) · 🇹🇷 [tr](../../../tr/docs/compression/COMPRESSION_GUIDE.md) · 🇺🇦 [uk-UA](../../../uk-UA/docs/compression/COMPRESSION_GUIDE.md) · 🇵🇰 [ur](../../../ur/docs/compression/COMPRESSION_GUIDE.md) · 🇺🇿 [uz](../../../uz/docs/compression/COMPRESSION_GUIDE.md) · 🇻🇳 [vi](../../../vi/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇬 [yo](../../../yo/docs/compression/COMPRESSION_GUIDE.md) · 🇨🇳 [zh-CN](../../../zh-CN/docs/compression/COMPRESSION_GUIDE.md) · 🇹🇼 [zh-TW](../../../zh-TW/docs/compression/COMPRESSION_GUIDE.md) --- > అర్హమైన సందర్భంపై స్వయంచాలకంగా 15-95% ఆదా చేయండి. త్వరిత అవలోకనం కోసం, [README Compression విభాగం](../README.md#%EF%B8%8F-prompt-compression--save-15-95-eligible-tokens-automatically) చూడండి. ## అవలోకనం OmniRoute, అభ్యర్థనలు అప్స్ట్రీమ్ ప్రొవైడర్లకు చేరకముందే **ముందస్తుగా** అమలయ్యే మాడ్యులర్ ప్రాంప్ట్ కంప్రెషన్ పైప్లైన్ను అమలు చేస్తుంది. అంటే మీ టోకెన్ ఆదా పారదర్శకంగా జరుగుతుంది — మీ వర్క్ఫ్లోలో ఎలాంటి మార్పులు అవసరం లేదు. ``` క్లయింట్ అభ్యర్థన → కంప్రెషన్ వ్యూహ ఎంపిక సాధనం → కాంబో ఓవర్రైడ్ ఉందా? → కాంబో సెట్టింగ్ను ఉపయోగించండి → ఆటో-ట్రిగ్గర్ థ్రెషోల్డ్ చేరిందా? → ఆటో మోడ్ను ఉపయోగించండి → డిఫాల్ట్ మోడ్ ఉందా? → గ్లోబల్ సెట్టింగ్ను ఉపయోగించండి → Offలో ఉందా? → కంప్రెషన్ను దాటవేయండి → ఎంచుకున్న కంప్రెషన్ మోడ్ → Off: కంప్రెషన్ లేదు → Lite: సురక్షితమైన వైట్స్పేస్/ఫార్మాటింగ్ శుభ్రపరచడం (~15%) → Standard: Caveman-శైలి అనవసర పదాల తొలగింపు (~30%) → Aggressive: హిస్టరీ ఏజింగ్ + సారాంశీకరణ (~50%) → Ultra: హ్యూరిస్టిక్ ప్రూనింగ్ + కోడ్-బ్లాక్ సన్నబరచడం (~75%) → RTK: కమాండ్ను గుర్తించే టెర్మినల్/టూల్-అవుట్పుట్ ఫిల్టరింగ్ (60-90% అప్స్ట్రీమ్ పరిధి) → Stacked: క్రమబద్ధమైన బహుళ-ఇంజిన్ పైప్లైన్, సాధారణంగా RTK తర్వాత Caveman (78-95% అర్హమైన పరిధి) → కంప్రెస్ చేసిన అభ్యర్థన → ప్రొవైడర్ ``` --- ## కంప్రెషన్ మోడ్లు ### Off ఎలాంటి కంప్రెషన్ వర్తించదు. అన్ని సందేశాలు మార్పు లేకుండా పంపబడతాయి. ### Lite మోడ్ (~15% ఆదా, <1ms లేటెన్సీ) అత్యంత సురక్షితమైన మోడ్ — అర్థపరమైన మార్పు శూన్యం, ఫార్మాటింగ్ శుభ్రపరచడం మాత్రమే: | సాంకేతికత | వివరణ | | ------------------------ | ---------------------------------------------------------------- | | `collapseWhitespace` | వరుస ఖాళీ పంక్తులను విలీనం చేసి, చివరలోని స్పేస్లను తొలగిస్తుంది | | `dedupSystemPrompt` | నకిలీ సిస్టమ్ సందేశాలను తొలగిస్తుంది | | `compressToolResults` | సుదీర్ఘమైన టూల్/ఫంక్షన్ అవుట్పుట్లను కంప్రెస్ చేస్తుంది | | `removeRedundantContent` | పునరావృత సూచనలను తొలగిస్తుంది | | `replaceImageUrls` | base64 ఇమేజ్ డేటా URIలను సంక్షిప్తం చేస్తుంది | **దీనికి ఉత్తమం:** ఎల్లప్పుడూ ఆన్లో ఉండే వినియోగం, భద్రత అత్యంత కీలకమైన వర్క్ఫ్లోలు. ### Standard మోడ్ (~30% ఆదా) [Caveman](https://github.com/JuliusBrussee/caveman) స్ఫూర్తితో రూపొందించబడింది — అర్థాన్ని కాపాడుతూ అనవసర పదాలు మరియు సుదీర్ఘ పదబంధాలను తొలగిస్తుంది: - అనవసర పదాలను తొలగిస్తుంది ("please", "I think", "basically", "actually") - సుదీర్ఘ పదబంధాలను సంక్షిప్తం చేస్తుంది ("in order to" → "to", "as a result of" → "because") - మర్యాదపూర్వక సందిగ్ధ పదబంధాలను తొలగిస్తుంది ("Would you mind...", "If you could possibly...") - కోడింగ్ ప్రాంప్ట్ల కోసం సర్దుబాటు చేసిన 30+ regex నియమాలు **దీనికి ఉత్తమం:** రోజువారీ కోడింగ్ వర్క్ఫ్లోలు, ఖర్చుపై శ్రద్ధగల బృందాలు. ### Aggressive మోడ్ (~50% ఆదా) సుదీర్ఘ సెషన్ల కోసం తెలివైన హిస్టరీ నిర్వహణ: - **సందేశాల ఏజింగ్** — పాత సందేశాలు క్రమంగా మరింత కంప్రెస్ అవుతాయి - **టూల్ ఫలితాల కంప్రెషన్** — సుదీర్ఘమైన టూల్ అవుట్పుట్లు కత్తిరించబడతాయి లేదా తొలగించబడతాయి (మొదటి/చివరి పంక్తులు, సరిపోలే పంక్తుల ఫిల్టరింగ్, JSON కీ కంపాక్షన్) - **నిర్మాణ సమగ్రత రక్షణలు** — `tool_use` + `tool_result` జతలు స్థిరంగా ఉండేలా నిర్ధారిస్తాయి - **కాంటెక్స్ట్ విండో అవగాహన** — ప్రతి మోడల్కు సంబంధించిన టోకెన్ పరిమితులను గౌరవిస్తుంది **దీనికి ఉత్తమం:** సుదీర్ఘ డీబగ్గింగ్ సెషన్లు, పెద్ద కోడ్బేస్లు. ### Ultra మోడ్ (~75% ఆదా) టోకెన్లు అత్యంత కీలకమైన సందర్భాల కోసం గరిష్ఠ కంప్రెషన్: - **హ్యూరిస్టిక్ ప్రూనింగ్** — గద్యాన్ని స్కోర్ ఆధారంగా టోకెన్ ప్రూనింగ్ చేయడం - **నిర్మాణ పరిరక్షణ** — ఫెన్స్ చేసిన కోడ్ బ్లాక్లు, ఇన్లైన్ కోడ్, URLలు మరియు ఐడెంటిఫైయర్లు టూంబ్స్టోన్ చేసి, యథాతథంగా తిరిగి జోడించబడతాయి; వాటిని ఎన్నడూ ప్రూన్ చేయరు - **ఐచ్ఛిక SLM స్థాయి** — కాన్ఫిగర్ చేసినప్పుడు చిన్న లోకల్ మోడల్ ప్రూనింగ్ను మెరుగుపరచగలదు - Aggressive మోడ్తో సంబంధం లేకుండా పనిచేస్తుంది: ఇది సందేశాల ఏజింగ్, టూల్-ఫలితాల కంప్రెషన్ లేదా ఫాల్బ్యాక్ సారాంశీకరణను అమలు చేయదు (SLM-స్థాయి వైఫల్యం మాత్రమే ఫాల్బ్యాక్ పాస్ను aggressive ద్వారా రూట్ చేయగలదు) **దీనికి ఉత్తమం:** మీరు పదేపదే కాంటెక్స్ట్ పరిమితులను చేరుకుంటున్నప్పుడు. ### 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 ఫిల్టర్లను ఇంపోర్ట్ చేస్తుంది; ప్రాజెక్ట్ ఫైల్ల కోసం ఇన్లైన్-టెస్ట్ ధ్రువీకరణ మరియు ట్రస్ట్-గేటింగ్ను ఉపయోగిస్తుంది - ఇన్లైన్ ధ్రువీకరణ నమూనాలతో 55 అంతర్నిర్మిత ఫిల్టర్లను అందిస్తుంది - ANSI నియంత్రణ క్రమాలు, ప్రోగ్రెస్ బార్లు, పునరావృత పంక్తులు మరియు చర్య అవసరం లేని అనవసర సమాచారాన్ని తొలగిస్తుంది - వైఫల్యాలు, ఎర్రర్లు, హెచ్చరికలు, మారిన ఫైల్లు, సారాంశాలు మరియు సుదీర్ఘ అవుట్పుట్ చివరి భాగాన్ని సంరక్షిస్తుంది - ట్రస్ట్-గేటెడ్ ప్రాజెక్ట్ ఫిల్టర్లు, గ్లోబల్ ఫిల్టర్లు మరియు ఐచ్ఛికంగా సవరించిన ముడి అవుట్పుట్ రికవరీకి మద్దతు ఇస్తుంది **దీనికి ఉత్తమం:** షెల్, బిల్డ్, టెస్ట్, git, grep మరియు ఫైల్-అవుట్పుట్ ట్రాన్స్క్రిప్ట్లు ఉన్న ఏజెంట్ సెషన్లు. ### Stacked మోడ్ (78-95% అర్హమైన పరిధి) Stacked మోడ్ బహుళ కంప్రెషన్ ఇంజిన్లను నిర్ణీత క్రమంలో అమలు చేస్తుంది. డిఫాల్ట్ పైప్లైన్: ```txt RTK -> Caveman ``` ఈ క్రమం ముందుగా టెర్మినల్/టూల్ అవుట్పుట్ను సంక్షిప్తంగా ఉంచి, ఆపై మిగిలిన సహజ-భాష ప్రాంప్ట్పై Caveman అర్థపరమైన సంక్షేపణను వర్తింపజేస్తుంది. Stacked పైప్లైన్లను గ్లోబల్గా లేదా రూటింగ్ కాంబోలకు కేటాయించిన కంప్రెషన్ కాంబోల ద్వారా కాన్ఫిగర్ చేయవచ్చు. **దీనికి ఉత్తమం:** భారీ టూల్ లాగ్లతో పాటు మానవ సూచనలు లేదా అసిస్టెంట్ సారాంశాలు కలిగిన మిశ్రమ కాంటెక్స్ట్. --- ## అప్స్ట్రీమ్ పొదుపుల గణితం OmniRoute రెండు మూలాల నుండి కంప్రెషన్ పొదుపులను డాక్యుమెంట్ చేస్తుంది: అప్స్ట్రీమ్ ప్రాజెక్ట్ బెంచ్మార్క్లు మరియు OmniRoute స్వంత ఇంజిన్ కూర్పు. | మూలం | ఇక్కడ ఉపయోగించిన అప్స్ట్రీమ్ README సంఖ్య | | ------- | -------------------------------------------------------------------------------------------------------------------------------- | | Caveman | `~75%` తక్కువ అవుట్పుట్ టోకెన్లు, `65%` బెంచ్మార్క్ సగటు అవుట్పుట్ పొదుపులు, `22-87%` పరిధి మరియు `~46%` ఇన్పుట్ కంప్రెషన్ సాధనం | | RTK | `60-90%` కమాండ్-అవుట్పుట్ పొదుపులు; నమూనా సెషన్లో `~118,000 -> ~23,900` టోకెన్లు లేదా `79.7%` పొదుపు (`~80%`) | ఒకదానితో ఒకటి అతివ్యాప్తి చెందే సాధనం/కాంటెక్స్ట్ పేలోడ్ల కోసం, డిఫాల్ట్ OmniRoute కాంబో ఇంజిన్లను ఇలా వరుసగా అమర్చుతుంది: ```txt RTK -> Caveman ``` సంయుక్త పొదుపులు సంకలనాత్మకమైనవి కావు, గుణకారాత్మకమైనవి: ```txt సంయుక్తం = 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% ``` RTK మరియు Caveman రెండూ ఒకే ఇన్పుట్/కాంటెక్స్ట్ పేలోడ్ను తగ్గించగలిగినప్పుడు ఆ `78-95%` సంఖ్య వర్తిస్తుంది. 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` మ్యాచ్ జాబితా, చిన్న ఫైల్ రీడ్, సాధారణ సంభాషణ టెక్స్ట్) అదే పైప్లైన్ను రన్ చేసినప్పుడు సరిగ్గా **దాదాపు సున్నా పొదుపులు** వస్తాయి, ఎందుకంటే తొలగించడానికి పునరావృతమైనది ఏమీ ఉండదు మరియు కోడ్ బ్లాక్లు, URLలు, హెడ్డింగ్లు, వెర్షన్లు లేదా ALL-CAPS కాన్స్టంట్ ఐడెంటిఫైయర్లను తొలగించే లేదా మార్చే రీరైట్ను పంపడానికి `validateCompression()` (`validation.ts`) నిరాకరిస్తుంది. ఇది ఆశించిన, సురక్షితమైన ప్రవర్తనే, బగ్ కాదు: ప్రధానంగా శుభ్రమైన ఫైళ్లను రీడ్/grep చేసే కోడింగ్ సెషన్లో కంప్రెషన్ పూర్తిగా ప్రారంభించబడినప్పటికీ మొత్తం పొదుపులు పరిమితంగానే ఉంటాయి, అయితే విఫలమవుతున్న లూప్ లేదా అతిగా అవుట్పుట్ ఇచ్చే లింటర్ను ఎదుర్కొనే సెషన్లో ఆ ట్రాఫిక్పై పూర్తి 78-95% పరిధి కనిపిస్తుంది. ఒకే సెషన్లోని తక్కువ సమగ్ర పొదుపు శాతాన్ని కంప్రెషన్ తప్పుగా కాన్ఫిగర్ చేయబడిందనే ఆధారంగా ఉపయోగించవద్దు — ముందుగా అంతర్లీన టూల్ అవుట్పుట్ నిజంగా పునరావృతమైందో లేదో తనిఖీ చేయండి. --- ## టోకెన్ పొదుపుల దృశ్యీకరణ ``` కంప్రెషన్ లేకుండా: 47K టోకెన్లు LLMకు పంపబడ్డాయి 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`లో, ఒక రూటింగ్ కాంబోకు కంప్రెషన్ కాంబోను కేటాయించండి: ```txt కాంబో: "free-tier-fallback" కంప్రెషన్ కాంబో: "coding-agent-stack" పైప్లైన్: RTK -> Caveman లక్ష్యాలు: 1. if/kimi-k2.7-code 2. if/qwen3.8-max-preview ``` దీని ద్వారా చెల్లింపు సబ్స్క్రిప్షన్లపై లైట్ మోడ్ను కొనసాగిస్తూనే, ఉచిత/కోడింగ్ ప్రొవైడర్లపై స్టాక్డ్ కంప్రెషన్ను ఉపయోగించవచ్చు. ఈ "Per-Combo Override" కేటాయింపు, **routing-combo compression mode** ఓవర్రైడ్కు (Default/Off/Lite/Standard/Aggressive/Ultra/Codex Responses — ఈ ఫీల్డ్ స్కీమా `rtk`, `stacked` మరియు `omniglyph`లను కూడా అంగీకరిస్తుంది) భిన్నమైన నియంత్రణ — ఆ ఓవర్రైడ్ పేరుగల కంప్రెషన్-కాంబో పైప్లైన్ను ఎంచుకోదు; అది కేవలం `resolveCompressionPlan` పరిశీలించే `compressionMode` ఫీల్డ్ను సెట్ చేస్తుంది. దీన్ని కాంబో కార్డ్లో (`Dashboard → Combos`) లేదా #6760 నుంచి, పైన డాక్యుమెంట్ చేసిన పైప్లైన్-కేటాయింపు చెక్బాక్స్ పక్కనే ఉన్న `Dashboard → Context & Cache → Compression Combos`లోని "Assign to routing" జాబితాలో ఒక్కో రూటింగ్ కాంబోకు సెట్ చేయవచ్చు. రెండు ఇంటర్ఫేస్లలో చేసిన మార్పులూ ఒకే `PUT /api/combos/{id}` ఎండ్పాయింట్ ద్వారా నిల్వ చేయబడతాయి. ### ఒక్కో రిక్వెస్ట్కు ఓవర్రైడ్ ఒకే రిక్వెస్ట్కు కంప్రెషన్ ప్లాన్ను ఓవర్రైడ్ చేయడానికి `x-omniroute-compression` రిక్వెస్ట్ హెడర్ను పంపండి. దీనికే అత్యధిక ప్రాధాన్యత ఉంటుంది — ఇది రూటింగ్-కాంబో ఓవర్రైడ్, యాక్టివ్ ప్రొఫైల్, ఆటో-ట్రిగ్గర్ మరియు ప్యానెల్ Default కంటే ప్రాధాన్యత పొందుతుంది. తెలియని విలువలు విస్మరించబడతాయి (రిక్వెస్ట్ను ఎప్పుడూ తిరస్కరించరు), అలాగే గ్లోబల్ మాస్టర్ స్విచ్ ఇప్పటికీ అన్నింటినీ నియంత్రిస్తుంది: కంప్రెషన్ గ్లోబల్గా ఆఫ్లో ఉన్నప్పుడు, హెడర్ దాన్ని ఆన్ చేయలేదు. విలువలు: | విలువ | ప్రభావం | | ------------- | --------------------------------------------------------------------------------------------------------- | | `off` | ఈ రిక్వెస్ట్కు కంప్రెషన్ ఉండదు. | | `default` | ప్యానెల్-ఉత్పన్న Default ప్రొఫైల్ (యాక్టివ్ ప్రొఫైల్ను విస్మరిస్తుంది). లాసీ ఇంజిన్లు ఆఫ్లోనే ఉంటాయి. | | `safe` | హెడర్ను ఇవ్వకపోవడంతో సమానం: డీడప్ మరియు వైట్స్పేస్ ఫోల్డింగ్ మాత్రమే. | | `allow-lossy` | సమరీలు, ప్రాసంగికత ఫిల్టర్లు మరియు శైలి రీరైట్లతో సహా ఈ రిక్వెస్ట్ యొక్క ఆపరేటర్ ప్లాన్ను కొనసాగిస్తుంది. | | `engine:` | ప్రారంభించబడి ఉన్నప్పుడు ఒకే ఇంజిన్, ఉదా. `engine:rtk`. ఇది ఆ ఇంజిన్ కోసం ఒక్కో రిక్వెస్ట్కు ఆప్ట్-ఇన్. | | `` | పేరుగల కాంబో; ముందుగా పేరు ఆధారంగా (కేస్ను పట్టించుకోకుండా), ఆపై id ఆధారంగా సరిపోల్చబడుతుంది. | `allow-lossy`, `engine:` లేదా పేరుగల కాంబో లేకుండా, లాసీ ఇంజిన్లు వర్తింపజేయబడవు. కంప్రెషన్ ఆన్లో ఉన్నప్పుడు రిక్వెస్ట్కు ఇప్పటికీ సెషన్ డీడప్ మరియు వైట్స్పేస్ ఫోల్డింగ్ వర్తిస్తాయి. వర్తింపజేసిన ప్లాన్ `X-OmniRoute-Compression: ; source=` రెస్పాన్స్ హెడర్లో తిరిగి అందించబడుతుంది, ఇందులో `` అనేది `request-header`, `routing-override`, `active-profile`, `auto-trigger`, `default` లేదా `off`లో ఒకటి. ### API ```bash # కంప్రెషన్ సెట్టింగ్లను పొందండి 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"}' ``` --- ## ఏవి రక్షించబడతాయి కంప్రెషన్ ఇంజిన్ **ఎల్లప్పుడూ వీటిని యథాతథంగా ఉంచుతుంది:** - ✅ కోడ్ బ్లాక్లు (ఫెన్స్డ్ మరియు ఇన్లైన్) - ✅ URLలు మరియు ఫైల్ పాత్లు - ✅ JSON నిర్మాణాలు మరియు నిర్మిత డేటా - ✅ ఐడెంటిఫైయర్లు మరియు రక్షిత సాంకేతిక టోకెన్లు - ✅ గణిత వ్యక్తీకరణలు - ✅ టూల్/ఫంక్షన్ కాల్ నిర్వచనాలు - ✅ సిస్టమ్ ప్రాంప్ట్లు (lite మోడ్లో) ఏదైనా నిల్వ చేయడానికి ముందే, RTK ముడి-అవుట్పుట్ రికవరీ సాధారణ API కీలు, bearer టోకెన్లు, Slack టోకెన్లు, AWS యాక్సెస్ కీలు, పాస్వర్డ్లు, టోకెన్లు మరియు సీక్రెట్లను తొలగించి దాచుతుంది. --- ## కంప్రెషన్ గణాంకాలు కంప్రెస్ చేసిన ప్రతి అభ్యర్థనకు సంబంధించిన గణాంకాలు సర్వర్ లాగ్లలో ఉంటాయి: ```json { "originalTokens": 47200, "compressedTokens": 40120, "savingsPercent": 15.0, "techniquesUsed": ["collapseWhitespace", "dedupSystemPrompt"], "mode": "lite", "engine": "caveman", "compressionComboId": "coding-agent-stack", "durationMs": 0.8, "rtkRawOutputPointers": [] } ``` --- ## దశల రోడ్మ్యాప్ | దశ | మోడ్లు | స్థితి | | ----- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | | దశ 1 | Off, 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](https://github.com/JuliusBrussee)** రూపొందించిన **[Caveman](https://github.com/JuliusBrussee/caveman)** (⭐ 51K+) నుంచి ప్రేరణ పొందాయి — వైరల్ అయిన "చాలా టోకెన్లు ఎందుకు వాడాలి, కొన్ని టోకెన్లతోనే పని పూర్తయినప్పుడు" ప్రాజెక్ట్. Caveman ప్రకారం, అవుట్పుట్ టోకెన్లు `~75%` తక్కువగా ఉంటాయి, బెంచ్మార్క్లో సగటు అవుట్పుట్ ఆదా `65%`, అవుట్పుట్ పరిధి `22-87%`, అలాగే ఇన్పుట్-కంప్రెషన్ టూల్తో `~46%` ఆదా ఉంటుంది. RTK మోడ్ **[RTK AI](https://github.com/rtk-ai)** రూపొందించిన **[RTK - Rust Token Killer](https://github.com/rtk-ai/rtk)** నుంచి ప్రేరణ పొందింది — ఇది టెర్మినల్, బిల్డ్, టెస్ట్, git మరియు టూల్-అవుట్పుట్ ఫిల్టరింగ్ కోసం రూపొందించిన అధిక-పనితీరు గల కమాండ్-అవుట్పుట్ కంప్రెషన్ ప్రాజెక్ట్. RTK ప్రకారం `60-90%` ఆదా ఉంటుంది, దాని README నమూనా సెషన్లో `~80%` ఆదా చూపబడింది. --- ## అధునాతన కంప్రెషన్ సిస్టమ్లు పైన వివరించిన 7 మోడ్లకు అదనంగా (సోర్స్ `codex-responses` మరియు `omniglyph` మోడ్లను కూడా అంగీకరిస్తుంది, కానీ ఈ గైడ్ వాటిని కవర్ చేయదు), దిగువ విభాగాలు ఆ మోడ్లలో లేదా వాటితో పాటు పనిచేసే ఫీచర్లను వివరిస్తాయి: టూల్ రిజల్ట్ కంప్రెషన్ మరియు ప్రోగ్రెసివ్ ఏజింగ్ అగ్రెసివ్ ఇంజిన్లోని 1 మరియు 2 దశలు (Aggressive మోడ్ మరియు స్టాక్డ్ పైప్లైన్లోని ఒక `aggressive` దశ), స్టాక్డ్ మోడ్ అమలయ్యే విధానమే స్టాక్డ్ పైప్లైన్, కంప్రెషన్ ఆన్లో ఉన్నప్పుడు క్యాషింగ్ ప్రొవైడర్ల కోసం క్యాష్-అవేర్ కంప్రెషన్ `aggressive` మరియు `ultra`ను `standard`కు డౌన్గ్రేడ్ చేస్తుంది, అలాగే కేవ్మ్యాన్ అవుట్పుట్ మోడ్ మరియు అవుట్పుట్ స్టైల్స్ అనేవి ఐచ్ఛికంగా ప్రారంభించగల సిస్టమ్-ప్రాంప్ట్ సూచనలు; ఇవి డిఫాల్ట్గా ఆఫ్లో ఉంటాయి మరియు రిక్వెస్ట్ను కంప్రెస్ చేయడానికి బదులుగా మోడల్ అవుట్పుట్ను రూపొందిస్తాయి. ### క్యాష్-అవేర్ కంప్రెషన్ కొన్ని ప్రొవైడర్లు (ప్రాంప్ట్ క్యాషింగ్తో Anthropic వంటివి) **ప్రాంప్ట్ క్యాషింగ్**కు మద్దతిస్తాయి, ఇది ఖర్చులు మరియు లేటెన్సీని తగ్గించడానికి ప్రాంప్ట్లోని భాగాలను క్యాష్ చేయడానికి వీలు కల్పిస్తుంది. క్యాషింగ్ ప్రారంభించబడినప్పుడు, అగ్రెసివ్ కంప్రెషన్ క్యాష్ చేసిన టోకెన్లను మార్చి, క్యాష్ను చెల్లనిదిగా చేస్తుంది కాబట్టి వాస్తవానికి పనితీరును **దెబ్బతీయవచ్చు**. `cachingAware.ts` మాడ్యూల్ **క్యాషింగ్ సందర్భాన్ని గుర్తించి**, దానికి అనుగుణంగా **కంప్రెషన్ వ్యూహాన్ని సర్దుబాటు చేయడం** ద్వారా ఈ సమస్యను పరిష్కరిస్తుంది. #### ఇది ఎలా పనిచేస్తుంది 1. **క్యాషింగ్ సందర్భాన్ని గుర్తించడం** — `cache_control` మార్కర్ల కోసం రిక్వెస్ట్ బాడీని స్కాన్ చేస్తుంది 2. **క్యాషింగ్ ప్రొవైడర్లను గుర్తించడం** — లక్ష్య ప్రొవైడర్ క్యాషింగ్కు మద్దతిస్తుందో లేదో తనిఖీ చేస్తుంది 3. **వ్యూహాన్ని సర్దుబాటు చేయడం** — క్యాషింగ్ ప్రొవైడర్ల కోసం `aggressive`/`ultra`ను `standard`కు డౌన్గ్రేడ్ చేస్తుంది 4. **సిస్టమ్ ప్రాంప్ట్ను దాటవేయడం** — సిస్టమ్ ప్రాంప్ట్లు సాధారణంగా క్యాష్ చేయబడతాయి, కాబట్టి వాటిని కంప్రెస్ చేయదు వ్యూహ సహాయకం `deterministicOnly` ఫ్లాగ్ను కూడా అందిస్తుంది, కానీ ప్లాన్ బిల్డర్ వ్యూహాన్ని మాత్రమే ఉపయోగిస్తుంది — ప్రస్తుతం తదుపరి దశల్లో ఏదీ ఆ ఫ్లాగ్ను చదవదు. #### కోడ్ ఉదాహరణ ```ts import { detectCachingContext, getCacheAwareStrategy, } from "@omniroute/open-sse/services/compression/cachingAware"; const body = { model: "anthropic/claude-sonnet-4.5", messages: [{ role: "user", content: "Hello" }], cache_control: { type: "ephemeral" }, // ← క్యాష్ మార్కర్ }; const ctx = detectCachingContext(body, { provider: "anthropic" }); // → { hasCacheControl: true, provider: "anthropic", targetFormat: null, isCachingProvider: true } const strategy = getCacheAwareStrategy("aggressive", ctx); // → { strategy: "standard", skipSystemPrompt: true, deterministicOnly: true } ``` #### ఎప్పుడు ఉపయోగించాలి క్యాష్-అవేర్ కంప్రెషన్ **ఎల్లప్పుడూ ఆన్లో ఉంటుంది** — ఎలాంటి కాన్ఫిగరేషన్ అవసరం లేదు. కంప్రెషన్ ఆన్లో ఉండి, లక్ష్య ప్రొవైడర్ ప్రాంప్ట్ క్యాషింగ్కు (Anthropic, OpenAI మొదలైనవి) మద్దతిచ్చినప్పుడల్లా ఇది అమలవుతుంది; స్పష్టమైన `cache_control` మార్కర్లు అవసరం లేదు — క్యాషింగ్ ప్రొవైడర్ ఒక్కటే డౌన్గ్రేడ్ను ట్రిగ్గర్ చేస్తుంది, కానీ మార్కర్లు మాత్రమే ఎప్పటికీ అలా చేయవు (మార్కర్ గుర్తింపు క్యాష్ టెలిమెట్రీకి సమాచారాన్ని అందిస్తుంది, వ్యూహ నిర్ణయానికి కాదు). ### ప్రోగ్రెసివ్ ఏజింగ్ సుదీర్ఘ సంభాషణల్లో అనేక మెసేజ్ టర్న్లు పేరుకుపోతాయి, కానీ పాత టర్న్లు తక్కువ సంబంధితంగా మారతాయి. `progressiveAging.ts` మాడ్యూల్ **టర్న్ దూరం ఆధారంగా మెసేజ్లను సరళీకరిస్తుంది** (సంభాషణ ముగింపు నుంచి దూరాన్ని కొలుస్తారు). అందించబడిన డిఫాల్ట్లతో (`verbatim: 2, light: 2, moderate: 3`): - **చివరి 2 టర్న్లు (దూరం ≤ 2)**: యథాతథంగా ఉంచబడతాయి - **దూరం 3**: కేవ్మ్యాన్ కంప్రెషన్ (అనవసర పదాల తొలగింపు) - **దూరం 4+**: అసిస్టెంట్ మెసేజ్లు సంగ్రహించబడతాయి; యూజర్ మెసేజ్లు వాటి మొదటి లైన్కు కుదించబడి, 120 అక్షరాలకు పరిమితం చేయబడతాయి; ఇతర రోల్స్ మార్చబడవు. సిస్టమ్ ప్రాంప్ట్లు, ఇప్పటికే ఏజ్ చేయబడిన మెసేజ్లు మరియు తాజా యూజర్ మెసేజ్ దూరంతో సంబంధం లేకుండా ఎల్లప్పుడూ యథాతథంగా ఉంచబడతాయి. ఏదీ పూర్తిగా తొలగించబడదు, అలాగే అందించబడిన డిఫాల్ట్లతో (`light` అనేది `verbatim`కు సమానం) `light` బ్యాండ్ను చేరుకోవడం సాధ్యం కాదు. #### కోడ్ ఉదాహరణ ```ts import { applyAging } from "@omniroute/open-sse/services/compression/progressiveAging"; const messages = [ { role: "system", content: "You are a helpful assistant" }, { role: "user", content: "What is 2+2?" }, { role: "assistant", content: "4" }, // ... మరో 50 టర్న్లు ... ]; const { messages: aged, saved } = applyAging(messages, { verbatim: 3, // చివరి 3 టర్న్లు: యథాతథంగా light: 8, // దూరం <= 8: లైట్ కంప్రెషన్ moderate: 20, // దూరం <= 20: కేవ్మ్యాన్ కంప్రెషన్ fullSummary: 5, // టైప్కు అవసరం, బ్యాండింగ్ కోడ్ దీన్ని చదవదు // దూరం > 20: సంగ్రహించబడుతుంది (అసిస్టెంట్) / మొదటి లైన్ ఉంచబడుతుంది (యూజర్) }); // saved = సేవ్ చేసిన టోకెన్ల సంఖ్య ``` #### ఎప్పుడు ఉపయోగించాలి `aggressive` మోడ్లో ప్రోగ్రెసివ్ ఏజింగ్ **ఎల్లప్పుడూ ఆన్లో ఉంటుంది** — ఇది `compressAggressive()`లోని 2వ దశ. Ultra మోడ్ దీన్ని అమలు చేయదు. ఇది ముఖ్యంగా కింది వాటికి ప్రభావవంతంగా ఉంటుంది: - ఎక్కువసేపు కొనసాగే కోడింగ్ సెషన్లు - అనేక రోజుల సంభాషణలు - అనేక టూల్ కాల్స్తో కూడిన ఏజెంటిక్ వర్క్ఫ్లోలు ### కేవ్మ్యాన్ అవుట్పుట్ మోడ్ కేవ్మ్యాన్ అవుట్పుట్ మోడ్, సంక్షిప్త అవుట్పుట్ ఇవ్వమని మోడల్నే కోరే **సిస్టమ్ ప్రాంప్ట్ సూచనలను** జోడిస్తుంది — `lite` స్థాయి పూర్తి వాక్యాలను ఉంచుతూ సంక్షిప్త సమాధానాలను అడుగుతుంది, `full` "తెలివైన కేవ్మ్యాన్లా క్లుప్తంగా స్పందించమని" అడుగుతుంది, అలాగే `ultra` టెలిగ్రాఫిక్ అవుట్పుట్ను అడుగుతుంది; సూచనలు కేవలం అభ్యర్థించగలవు, దానికి హామీ ఇవ్వలేవు. రిక్వెస్ట్లు ఈ సూచనలను `applyOutputStyles()` (`open-sse/services/compression/outputStyles/apply.ts`) ద్వారా పొందుతాయి: `open-sse/handlers/chatCore.ts` మొదట బ్యాక్వర్డ్-కంపాటిబిలిటీ షిమ్తో ఎంపికను పరిష్కరిస్తుంది (`open-sse/services/compression/outputStyles/backCompat.ts`లోని `resolveOutputStyleSelection()`), ఇది `outputStyles` ఖాళీగా ఉన్నప్పుడు, ప్రారంభించబడిన `cavemanOutputMode`ను `cavemanOutputMode.intensity` వద్ద `terse-prose` అవుట్పుట్ స్టైల్కు మ్యాప్ చేస్తుంది (దిగువ బ్యాక్వర్డ్-కంపాటిబిలిటీని చూడండి); ఖాళీ కాని `outputStyles` ఎంపిక యథాతథంగా ఉపయోగించబడుతుంది, ఆ తర్వాత `cavemanOutputMode.enabled` మరియు `intensity` ఎలాంటి ప్రభావం చూపవు, అయితే దాని `autoClarity` టాగుల్ మాత్రం ఇప్పటికీ వర్తిస్తుంది. `outputMode.ts`లో సూచన టెక్స్ట్లు (`CAVEMAN_INSTRUCTION_BY_LANGUAGE`), కంటెంట్ బైపాస్ మరియు ఇంజెక్షన్ ఉపయోగించే ప్లేస్మెంట్ సహాయకం ఉంటాయి; దాని స్వంత `applyCavemanOutputMode()` ఇంజెక్టర్కు ప్రొడక్షన్ కాలర్ ఏదీ లేదు. #### ఇది ఎలా పనిచేస్తుంది ఈ మోడ్ ఇన్పుట్ను కుదించదు. ఇది సిస్టమ్ ప్రాంప్ట్కు ఒక సూచన బ్లాక్ను జోడిస్తుంది (క్రింద ఇంజెక్షన్ ఎలా పనిచేస్తుందో చూడండి), అలాగే అభ్యర్థన కోసం ఎంచుకున్న ఏ ఇన్పుట్ కంప్రెషన్ మోడ్ అయినా ఆ బ్లాక్ను ఇప్పుడు కలిగి ఉన్న బాడీపై తర్వాత కూడా అమలవుతుంది. ప్రతి స్థాయి చివర ఉండే ఉమ్మడి పరిమితుల క్లాజ్కు ముందు, ఆంగ్ల `full` స్థాయి ఇలా ఉంటుంది: > "తెలివైన ఆదిమానవుడిలా క్లుప్తంగా స్పందించండి. ఆర్టికల్స్ (a/an/the), అనవసర పదాలు (just/really/basically/actually/simply), మర్యాదపూర్వక పలుకులు, సందిగ్ధత వ్యక్తీకరణలను తొలగించండి. వాక్య ఖండాలు సరే. చిన్న పర్యాయపదాలు వాడండి (extensive బదులు big, implement బదులు fix). అన్ని సాంకేతిక విషయాలు, కోడ్, లోపాలు, URLs, ఐడెంటిఫైయర్లను యథాతథంగా ఉంచండి." ఇది ముఖ్యంగా వీటికి బాగా పనిచేస్తుంది: - కోడ్ ఉత్పత్తి (మరింత క్లుప్తమైన అవుట్పుట్ = తక్కువ టోకెన్లు) - త్వరిత ప్రశ్నోత్తరాలు (విస్తృతమైన వివరణలు అవసరం లేదు) - బ్యాచ్ ప్రాసెసింగ్ (నిర్వహణ సామర్థ్యాన్ని గరిష్ఠం చేయండి) #### ఎప్పుడు ఉపయోగించాలి కేవ్మ్యాన్ అవుట్పుట్ మోడ్ **ఐచ్ఛికం**. కంప్రెషన్ ఆన్లో ఉన్నప్పుడు (`enabled: true`, Compression Settings పేజీలోని ప్రధాన టాగుల్ ఆన్లో ఉన్నప్పుడు), దీన్ని `cavemanOutputMode.enabled`తో ఆన్ చేయండి; `intensity` `lite`, `full` లేదా `ultra`ను ఎంచుకుంటుంది: ```json { "enabled": true, "cavemanOutputMode": { "enabled": true, "intensity": "full" } } ``` కంప్రెషన్ కాంబో యొక్క **అవుట్పుట్ మోడ్** టాగుల్ (`outputMode`, స్థాయి `outputModeIntensity`లో) ఆ కాంబో వర్తించే అభ్యర్థనలకు అదే స్విచ్ను సెట్ చేస్తుంది, అలాగే `omniroute_set_compression_engine` MCP సాధనం తన బూలియన్ `outputMode` ఆర్గ్యుమెంట్ ద్వారా దాన్ని రాస్తుంది. ఖాళీగా లేని `outputStyles` ఎంపిక ఈ స్విచ్ కంటే ప్రాధాన్యం పొందుతుంది. డాష్బోర్డ్లో, **క్లుప్త గద్యం** అవుట్పుట్ శైలిని ప్రారంభించడం అదే బ్లాక్ను ఇంజెక్ట్ చేస్తుంది (క్రింద అవుట్పుట్ శైలులు చూడండి). ### అవుట్పుట్ శైలులు (కేటలాగ్) పైన ఉన్న కేవ్మ్యాన్ అవుట్పుట్ మోడ్ **లెగసీ ఏక-శైలి మార్గం**. దశ 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](https://github.com/ayghri/i-have-adhd) (MIT) నుండి అనుసరించబడింది. | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi | | యాంటీస్లాప్ UI ఫిల్టర్ | `antislop-ui` | ప్రతి దృశ్య పద్ధతి తప్పనిసరిగా ప్రయోజన పరీక్షలో ఉత్తీర్ణం కావాలి (హైరార్కీ, గుర్తింపు, చదవగల సామర్థ్యం); డిఫాల్ట్ గ్రేడియెంట్లు/గ్లాస్/గ్లో ఉండవు, పరిమిత ప్యాలెట్, టెంప్లేట్ లేఅవుట్లు ఉండవు. రెండు యాంటీస్లాప్ శైలులూ పనిచేయని నియంత్రణలు / కల్పిత క్లెయిమ్లు ఉండకూడదనే పరిమితిని జోడిస్తాయి. | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi | | యాంటీస్లాప్ కాపీ మరియు మానవ ఫిల్టర్ | `antislop-copy` | నిర్దిష్ట కాపీ (ఎమ్ డాష్లు, సాధారణ CTAలు, బజ్వర్డ్లు, చాట్బాట్ ముగింపులు, కల్పిత వాస్తవాలు ఉండవు), అలాగే వ్యక్తులకు సంబంధించిన నియమాలు: WCAG AA కాంట్రాస్ట్, కనిపించే ఫోకస్, కీబోర్డ్ యాక్సెస్, ఖాళీ/లోడింగ్/లోప స్థితులు, మొబైల్ రీఫ్లో. | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi | | క్లుప్త CJK (文言) | `terse-cjk` | `full`/`ultra` సమాధానం సాంప్రదాయ చైనీస్లో (文言); `lite` మాత్రం ఫంక్షన్ పదాలు, మర్యాదపూర్వక పలుకులు లేదా అలంకరణలు లేని సంక్షిప్త సమాధానాలను అడుగుతుంది. | zh (లోకేల్-గేటెడ్, క్రింద చూడండి) | ప్రతి శైలిలో మూడు తీవ్రత స్థాయిలు ఉంటాయి — `lite`, `full`, `ultra` — మరియు ప్రతి స్థాయి ఉమ్మడి పరిమితుల క్లాజ్తో ముగుస్తుంది (`outputMode.ts`లోని `SHARED_BOUNDARIES`), ఇది కోడ్ బ్లాక్లు, ఫైల్ పాత్లు, కమాండ్లు, లోపాలు మరియు URLsను యథాతథంగా ఉంచుతుంది. `terse-prose` మరియు `terse-cjk` స్థాయి టెక్స్ట్లు ఆ జాబితాకు ఐడెంటిఫైయర్లను జోడిస్తాయి. `terse-cjk` రెండు చోట్ల `zh`కు లోకేల్-గేటెడ్గా ఉంటుంది. డాష్బోర్డ్ UI భాష చైనీస్గా (`zh-CN` లేదా `zh-TW`) ఉన్నప్పుడు మాత్రమే Compression Settings పేజీ దాని వరుసను చూపుతుంది, అలాగే అభ్యర్థనకు నిర్ణయించబడిన భాష (క్రింద భాష ఎంపిక చూడండి) `zh` అయినప్పుడు మాత్రమే `applyOutputStyles()` దాన్ని ఇంజెక్ట్ చేస్తుంది. వరుసను దాచడం వల్ల సేవ్ చేసిన `terse-cjk` ఎంపిక తొలగించబడదు: సెట్టింగ్ల API ఏ శైలి idనైనా అంగీకరిస్తుంది, అలాగే పేజీలో ఇతర శైలులను సేవ్ చేయడం దాన్ని అలాగే ఉంచుతుంది. అభ్యర్థన సమయంలో, `applyOutputStyles()` భాష తనిఖీ మాత్రమే లోకేల్ గేట్. #### ఇంజెక్షన్ ఎలా పనిచేస్తుంది `applyOutputStyles()` (`open-sse/services/compression/outputStyles/apply.ts`) ఎంపికను కాటలాగ్తో సరిపోల్చి పరిష్కరిస్తుంది (తెలియని ids మరియు locale సరిపోలని styles తొలగించబడతాయి, ఎప్పుడూ error కాదు; ఏ styleకూ పరిష్కారం కాని ఎంపిక bodyని మార్చకుండా ఉంచి, `no_styles`గా దాటవేయబడుతుంది), ఎంచుకున్న instructionsను catalog క్రమంలో కలుపుతుంది, boundaries clauseను **ఒక్కసారి** జోడిస్తుంది (అదనంగా, `less-code` లేదా `ponytail` ఎంచుకున్నప్పుడు safety clause, `SAFETY_BOUNDARIES` లేదా దాని అనువాదాన్ని జోడిస్తుంది), మరియు blockను ఒకే idempotency marker (`[OmniRoute Output Styles]`)తో ప్రారంభిస్తుంది, కాబట్టి మళ్లీ వర్తింపజేయడం no-op అవుతుంది. పరిష్కరించిన languageకు (క్రింద Language selection చూడండి) అనువాదం ఉన్నప్పుడు, Englishకు బదులుగా localized instruction చొప్పించబడుతుంది. ఖాళీ కాని `messages` array ఉన్న bodyలో, idempotency check content bypassకు ముందు నడుస్తుంది: `[OmniRoute Output Styles]` marker ఇప్పటికే top-level `system` fieldలో (string లేదా content-block arrayలో) లేదా string content ఉన్న system messageలో ఉంటే, body `already_applied`గా మార్పు లేకుండా ఉంచబడుతుంది మరియు keyword check నడవదు. లేకపోతే, content bypass (`open-sse/services/compression/outputMode.ts`లోని `shouldBypassCavemanOutputMode()`) చివరి మూడు messages యొక్క textను, వాటి role ఏదైనా సరే, తనిఖీ చేస్తుంది; ఆ text దాని security, irreversible-action లేదా clarification keywordsతో సరిపోలినప్పుడు, లేదా ఈ order-sensitive sequenceతో సరిపోలినప్పుడు, మొత్తం turn కోసం stylesను దాటవేస్తుంది: `first`, `then`, `after that`, `before`, `rollback` లేదా `backup` తర్వాత 240 charactersలోపు `delete`, `drop`, `migrate`, `deploy` లేదా `release` రావడం. **Auto-Clarity Bypass** toggle (`cavemanOutputMode.autoClarity`, defaultగా on) onలో ఉన్నప్పుడు bypass నడుస్తుంది; toggleను off చేయడం keyword checkను దాటవేస్తుంది. Bypass turnను అనుమతించినప్పుడు, ఎప్పుడూ కొత్త `messages[0]`ను సృష్టించని `placeSystemInstruction()` (అదే file), తాను మొదట కనుగొన్న క్రింది స్థానంలో blockను ఉంచుతుంది: 1. String content ఉన్న ప్రారంభ system message: దాని text తర్వాత block జోడించబడుతుంది. 2. Top-level `system` field: string యొక్క text తర్వాత block జోడించబడుతుంది, లేదా content-block arrayకు కొత్త text blockగా చేర్చబడుతుంది. 3. తర్వాత వచ్చే, string content ఉన్న మొదటి system message: దాని text తర్వాత block జోడించబడుతుంది. 4. పైవేవీ లేకపోతే: `messages` చివరలో కొత్త system messageలో block ఉంచబడుతుంది. `messages` array లేని (లేదా ఖాళీగా ఉన్న) bodyలో content bypass నడవదు మరియు top-level `system` fieldను పరిగణనలోకి తీసుకోరు. String `instructions` field యొక్క text తర్వాత block జోడించబడుతుంది; అయితే ఆ fieldలో ఇప్పటికే `[OmniRoute Output Styles]` marker ఉంటే, body `already_applied`గా మార్పు లేకుండా ఉంచబడుతుంది. Bodyలో string `instructions` field లేకపోయినా `input` (string లేదా array) ఉంటే, ఆ fieldలో ఉన్న string కాని valueను భర్తీ చేస్తూ block `instructions` అవుతుంది. String `instructions` field లేదా string లేదా array `input` రెండూ లేని body మార్పు లేకుండా ఉంచబడి, `no_messages`గా దాటవేయబడుతుంది. #### ఎలా ప్రారంభించాలి Dashboardలో: **Compression Context → Compression Settings** (`/dashboard/context/settings`), Output styles section: ప్రతి styleకు on/off toggle మరియు level selectorతో ఒక row ఉంటుంది. Compression స్వయంగా onలో ఉన్నప్పుడు (page master toggle, `enabled`) styles చొప్పించబడతాయి. **Auto-Clarity Bypass** toggle **Caveman** pageలో (`/dashboard/context/caveman`), దాని **Output Mode** cardలో ఉంటుంది. Programmatically, compression config ఎంపికను ఇలా నిల్వ చేస్తుంది: ```json { "outputStyles": [ { "id": "i-have-adhd", "level": "full" }, { "id": "less-code", "level": "lite" } ] } ``` Back-compat: `outputStyles` ఖాళీగా ఉన్నంతవరకు, legacy `cavemanOutputMode.enabled` setting `cavemanOutputMode.intensity` వద్ద `terse-prose`కు map అవుతుంది. అప్పుడు block `[OmniRoute Output Styles]` markerతో ప్రారంభమవుతుంది; legacy `applyCavemanOutputMode()` injector `[OmniRoute Caveman Output Mode]`ను చొప్పించేది. Marker క్రింద, text en, pt-BR, es, de, fr, it, ru, id మరియు viలో legacy injectionతో సరిపోలుతుంది; ja మరియు zhలో boundaries clauseకు ముందు ఒక అదనపు space ఉంటుంది. `terse-prose` pt-BR, es, de, fr, it, ru, zh, ja, id మరియు viలోకి అనువదించబడుతుంది, కాబట్టి resolved language `hu` అయిన requestకు legacy injector తన Hungarian textను ఉపయోగించిన చోట English text లభిస్తుంది. Output-style language selection (`outputStyles/apply.ts`లోని `resolveOutputStyleLanguage()`): `languageConfig.enabled` onలో ఉన్నప్పుడు, `autoDetect` request యొక్క `messages` arrayలో text ఉన్న తాజా user messageను (string content లేదా దాని content partsలోని `text`) sample చేసి, దానిపై Caveman engine detector (`detectCompressionLanguage()`)ను నడుపుతుంది. Kana లేని Han characters గల textకు detector `zh`ను return చేస్తుంది; లేకపోతే `it`, `pt-BR`, `es`, `de`, `fr`, `ru`, `ja`, `hu` మరియు `id`లో అత్యధిక hint matches ఉన్నదాన్ని return చేస్తుంది, ఏదీ match కాకపోతే `en`ను return చేస్తుంది — అది classify చేయలేని textకు English లభిస్తుంది, `defaultLanguage` ఎప్పుడూ కాదు; stylesలో `vi` text ఉన్నప్పటికీ `vi` ఎప్పుడూ detect చేయబడదు. Responses API body తన turnsను `input`లో ఉంచుతుంది, దాన్ని sample చేయరు, కాబట్టి దానికి మొదట `defaultLanguage`, ఆపై English లభిస్తుంది. `messages`లోని ఏ user messageలోనూ text లేనప్పుడు, లేదా `autoDetect` offలో ఉన్నప్పుడు, మొదట `defaultLanguage`, ఆపై English వర్తిస్తాయి. `languageConfig.enabled` offలో ఉన్నప్పుడు language English అవుతుంది — requestకు compression combo వర్తిస్తే తప్ప (request యొక్క routing comboకు assign చేసిన combo, లేదా built-in stacked pipeline కోసం chatCore fallback అయ్యే default compression combo): comboను వర్తింపజేయడం ఆ request కోసం `languageConfig.enabled`ను on చేసి, combo యొక్క language packs నుండి `defaultLanguage`ను set చేస్తుంది (saved value combo packsలో ఒకటైతే అదే, లేకపోతే combo యొక్క మొదటి pack, ఇది defaultగా `en`), అలాగే saved `autoDetect` (defaultగా on) ఇప్పటికీ వర్తిస్తుంది. Caveman input engine తన rule-pack languageను వేరుగా ఎంచుకుంటుంది — ప్రతి text partకు విడిగా మరియు auto-detect offలో ఉన్నప్పుడు, `enabledPacks` ఆధారంగా నియంత్రించబడుతుంది. స్టైల్ × భాష మ్యాట్రిక్స్ను `tests/unit/compression/output-styles-i18n-matrix.test.ts` పిన్ చేస్తుంది: ప్రతి కేటలాగ్ స్టైల్కు పరీక్షలోని `BASELINE_LANGUAGES`లో ఒక ఎంట్రీ అవసరం; లోకేల్కు పరిమితం కాని స్టైల్ తప్పనిసరిగా pt-BR అనువాదంతో అందించబడాలి (లోకేల్కు పరిమితమైన `terse-cjk`కు ఈ నియమం నుంచి మినహాయింపు ఉంది), లేదా అది `KNOWN_ENGLISH_ONLY`లో జాబితా చేయబడి ఉండాలి. అయితే ఇందులో అసలు అనువాదాలే లేని స్టైల్లు మాత్రమే ఉండవచ్చు — జాబితాలో ఉన్న స్టైల్కు ఏదైనా అనువాదం ఉంటే పరీక్ష విఫలమవుతుంది; అలాగే ఒక స్టైల్ తన `BASELINE_LANGUAGES` ఎంట్రీలో జాబితా చేసిన భాషను కోల్పోతే పరీక్షలో విఫలమవుతుంది. స్టైల్ను జోడించడానికి, [EXTENDING_COMPRESSION.md](./EXTENDING_COMPRESSION.md#adding-an-output-style) చూడండి. ### టూల్ ఫలిత కంప్రెషన్ `open-sse/services/compression/toolResultCompressor.ts`లోని `compressToolResult()` టూల్-ఫలిత టెక్స్ట్ను **5 వ్యూహాలతో** కంప్రెస్ చేస్తుంది. ఇది వాటిని ఈ క్రమంలో ప్రయత్నిస్తుంది, అలాగే కంటెంట్తో తన తనిఖీ సరిపోలిన మొదటి ప్రారంభించబడిన వ్యూహమే ఫలితాన్ని నిర్ణయిస్తుంది: 1. **`fileContent`**: 3 లేదా అంతకంటే ఎక్కువ లైన్ల కంటెంట్లో కనీసం ఒక లైన్, ప్రారంభ ఇండెంటేషన్ను విస్మరిస్తే, `import `, `export `, `function `, `class `, `const `, `let `, `var ` లేదా `return `తో (కీవర్డ్తో పాటు ఒక స్పేస్), లేదా `if`, `for` లేదా `while` తర్వాత `(` లేదా ` (`తో ప్రారంభమైతే, మొదటి 20 మరియు చివరి 5 లైన్లను ఉంచి, తొలగించిన మధ్య భాగాన్ని గుర్తిస్తుంది. 2. **`grepSearch`**: `::` రూపంలో కనీసం ఒక లైన్ ఉన్న కంటెంట్లో, మొదటి కోలన్కు ముందున్న టెక్స్ట్లో వైట్స్పేస్ లేకుంటే, అలాంటి లైన్లను మాత్రమే, గరిష్ఠంగా 30 వరకు ఉంచి, ఆ తర్వాత అదనపు సరిపోలికల సంఖ్యను మరియు సరిపోలిన ఫైళ్ల జాబితాను ఉంచుతుంది; మిగతా ప్రతి లైన్ తొలగించబడుతుంది. వ్యూహాన్ని ట్రిగ్గర్ చేయడానికి అలాంటి ఒక్క లైన్ సరిపోతుంది, కాబట్టి `12:30:45` వంటి టైమ్స్టాంప్తో ప్రారంభమయ్యే లాగ్ లైన్ కూడా లెక్కించబడుతుంది. 3. **`shellOutput`**: ANSI CSI సీక్వెన్స్ను (`ESC[` తర్వాత అంకెలు లేదా సెమీకోలన్లు, ఆపై కలర్ కోడ్లలో ఉన్నట్లుగా ఒక అక్షరం) లేదా టెక్స్ట్లో ఎక్కడైనా వైట్స్పేస్ను అనుసరించే `$`ను కలిగి ఉన్న అవుట్పుట్ ఆ సీక్వెన్స్లను కోల్పోతుంది (`ESC[?25l` లేదా OSC విండో-టైటిల్ సీక్వెన్స్ వంటి ఇతర ఎస్కేప్లు ఉంచబడతాయి), అలాగే వరుసగా పునరావృతమైన లైన్లను ఒకటిగా కుదిస్తూ చివరి 50 లైన్లను ఉంచుతుంది. ఈ తనిఖీ `json` మరియు `errorMessage` కంటే ముందు నడుస్తుంది కాబట్టి, అలాంటి `$`ను కలిగి ఉన్న JSON లేదా ఎరర్ అవుట్పుట్, `shellOutput` ఆన్లో ఉన్నప్పుడు వాటి వరకు ఎప్పటికీ చేరదు. 4. **`json`**: ఐచ్ఛిక వైట్స్పేస్ తర్వాత `{` లేదా `[`తో ప్రారంభమై, పార్స్ చేయగలిగే 2,000 అక్షరాలకంటే ఎక్కువ పొడవున్న JSON పేలోడ్ సారాంశీకరించబడుతుంది: 7 కంటే ఎక్కువ ఐటమ్లు ఉన్న అర్రేలో మొదటి 5, చివరి 2 ఐటమ్లు మరియు మొత్తం సంఖ్య ఉంచబడతాయి; ఆబ్జెక్ట్లో మొదటి 20 కీలు ఉంచబడతాయి, ప్రతి నెస్టెడ్ ఆబ్జెక్ట్ లేదా అర్రే విలువ `{…N keys}` ప్లేస్హోల్డర్తో భర్తీ చేయబడుతుంది (అర్రేకు N అనేది దాని పొడవు), అలాగే మొదటి 20 తర్వాత తొలగించబడిన కీలను లెక్కించే `_remaining__keys` మార్కర్ ఉంచబడుతుంది. స్కేలర్ విలువలు పూర్తిగా కాపీ చేయబడతాయి, కాబట్టి నెస్టెడ్ విలువలు లేని 20 లేదా అంతకంటే తక్కువ కీల ఆబ్జెక్ట్ కేవలం మళ్లీ ఇండెంట్ చేయబడుతుంది — మినిఫై చేసిన ఆబ్జెక్ట్కు అక్షరాలు పెరిగి, అది మారకుండా ఉంటుంది. 5. **`errorMessage`**: ఎక్కడైనా, అక్షరాల కేసుతో సంబంధం లేకుండా, `error:`, `error ` (పదం తర్వాత స్పేస్, `no error found`లో ఉన్నట్లుగా), `[error]`, `exception:`, `exception `, `[exception]` లేదా `traceback`ను కలిగి ఉన్న అవుట్పుట్ తన మొదటి లైన్ను, తదుపరి 10 లైన్లను మరియు చివరి 3 లైన్లను ఉంచి, వాటి మధ్య లైన్ల స్థానంలో `… [N frames elided] …` మార్కర్ను ఉంచుతుంది. మొదటి లైన్ తర్వాత 13 కంటే ఎక్కువ లైన్లు ఉన్నప్పుడు మాత్రమే మార్కర్ కనిపిస్తుంది, కాబట్టి 14 లేదా అంతకంటే తక్కువ లైన్ల ఎరర్ అవుట్పుట్ సంక్షిప్తం చేయబడదు (12 లేదా 13 లైన్ల వద్ద చివరి 3 లైన్లు ఇప్పటికే ఉంచిన లైన్లనే పునరావృతం చేస్తాయి). ఒక వ్యూహం సరిపోలిన తర్వాత, అది ఏమీ ఆదా చేయకపోయినా, తదుపరి వ్యూహాలు ప్రయత్నించబడవు. సరిపోలిన వ్యూహం అంచనా వేసిన టోకెన్లను (పొడవు ÷ 4, పైకి రౌండ్ చేయబడినది) ఏమీ ఆదా చేయనప్పుడు — ఉదాహరణకు 25 లేదా అంతకంటే తక్కువ లైన్ల కోడ్-లాంటి ఫైల్, లేదా 7 లేదా అంతకంటే తక్కువ ఐటమ్లతో 2,000 అక్షరాలకు మించిన JSON అర్రే — అగ్రెసివ్ ఇంజిన్ అసలు టూల్ ఫలితాన్ని ఉంచుతుంది: `saved` 0 లేదా అంతకంటే తక్కువగా ఉన్నప్పుడు కాలర్లు రెండూ (`compressAggressive()` మరియు `compressAnthropicToolResultBlock()`) అసలుదానినే ఉంచుతాయి, అయితే `compressToolResult()` మాత్రం ఆ వ్యూహపు అవుట్పుట్ను తిరిగి ఇస్తుంది. టూల్-ఫలిత దశే తుది నిర్ణయం కాదు: ఇంజిన్ ఫాల్బ్యాక్ సమరైజర్ ఇప్పటికీ 8,192 అక్షరాలకంటే ఎక్కువ పొడవున్న `tool` లేదా `function` సందేశాన్ని (`maxTokensPerMessage`, 2,048, గుణించబడిన 4) సంక్షిప్తం చేయగలదు. #### ఎప్పుడు ఉపయోగించాలి టూల్ ఫలిత కంప్రెషన్ అగ్రెసివ్ ఇంజిన్లోని 1వ దశ (`open-sse/services/compression/aggressive.ts`లోని `compressAggressive()`), కాబట్టి ఇది Aggressive మోడ్లో మరియు స్టాక్ చేసిన పైప్లైన్లోని `aggressive` దశలో నడుస్తుంది. ఇది OpenAI ఆకృతిలోని `tool` మరియు `function` సందేశాలను, అలాగే Anthropic `tool_result` బ్లాక్లలోని టెక్స్ట్ను కంప్రెస్ చేస్తుంది. ప్రతి వ్యూహానికి `aggressive.toolStrategies` కింద దాని స్వంత స్విచ్ ఉంటుంది; అన్నీ డిఫాల్ట్గా ఆన్లో ఉంటాయి. డ్యాష్బోర్డ్లో, కంప్రెషన్ ఆన్లో ఉండి, డిఫాల్ట్ మోడ్ Aggressiveగా ఉన్నప్పుడు, స్విచ్లు Caveman పేజీలోని **Advanced** వీక్షణలో ఉంటాయి. ### స్టాక్ చేసిన పైప్లైన్ స్టాక్ చేసిన మోడ్ **అనేక ఇంజిన్లను క్రమంగా** నడుపుతుంది — సాధారణంగా మొదట RTK (టూల్ అవుట్పుట్పై 60-90% ఆదా), ఆపై మిగిలిన టెక్స్ట్పై Caveman (~46% ఇన్పుట్ ఆదా). కలిపితే, అది **78-95% అర్హ పరిధి** (పైన ఉన్న Upstream Savings Math చూడండి): `1 - (1 - 0.60..0.90) × (1 - 0.46)` సగటు ≈89%. #### ఇది ఎలా పనిచేస్తుంది ``` ఇన్పుట్ (1000 టోకెన్లు) → RTK (కమాండ్-అవేర్ ఫిల్టర్) → 200 టోకెన్లు → Caveman (అనవసర పదాల తొలగింపు) → 108 టోకెన్లు → అవుట్పుట్ (108 టోకెన్లు, ~89% ఆదా) ``` #### ఎప్పుడు ఉపయోగించాలి స్టాక్ చేసిన మోడ్ను వీటి కోసం ఉపయోగించండి: - టూల్లు ఎక్కువగా ఉండే వర్క్ఫ్లోలు (ఏజెంటిక్ కోడింగ్, పరిశోధన) - ఖర్చుపై దృష్టి పెట్టే బ్యాచ్ ప్రాసెసింగ్ - మీకు గరిష్ఠ టోకెన్ ఆదా అవసరమైనప్పుడు స్టాక్ చేసిన పైప్లైన్లు గ్లోబల్ `stackedPipeline` కంప్రెషన్ సెట్టింగ్ ద్వారా లేదా రూటింగ్ కాంబోకు కేటాయించిన పేరు గల కంప్రెషన్ కాంబో ద్వారా కాన్ఫిగర్ చేయబడతాయి (పైన ఉన్న Per-Combo Override చూడండి) — auto-combo `modePack` ద్వారా కాదు (ఆ ఫీల్డ్ auto-combo మోడల్ ఎంపిక బరువులను మాత్రమే మార్చుతుంది, అలాగే `stacked` చెల్లుబాటు అయ్యే ప్యాక్ పేరు కాదు). --- ## కాంబోకు ప్రత్యేకమైన కంప్రెషన్ ఓవర్రైడ్లు వివిధ వినియోగ సందర్భాల కోసం ప్రవర్తనను సూక్ష్మంగా సర్దుబాటు చేయడానికి, గ్లోబల్ కంప్రెషన్ మోడ్ను **ప్రతి కాంబోకు** ఓవర్రైడ్ చేయవచ్చు: ```json { "id": "coding-combo", "strategy": "priority", "config": { "weights": { "taskFit": 0.5 }, "modePack": "quality-first" }, "compressionOverride": "aggressive" } ``` ఇది వీటికి ఉపయోగకరంగా ఉంటుంది: - **కోడింగ్ కాంబోలు**: సుదీర్ఘ సెషన్ల కోసం `aggressive` మోడ్ను ఉపయోగించండి - **త్వరిత ప్రశ్నోత్తర కాంబోలు**: వేగవంతమైన ప్రతిస్పందనల కోసం `lite` మోడ్ను ఉపయోగించండి - **టూల్స్ను ఎక్కువగా ఉపయోగించే కాంబోలు**: గరిష్ఠ ఆదా కోసం `stacked` మోడ్ను ఉపయోగించండి - **ప్రొడక్షన్ కాంబోలు**: క్యాషింగ్ ప్రొవైడర్ల కోసం ఓవర్రైడ్ను ఆఫ్లోనే ఉంచండి — ఎల్లప్పుడూ ఆన్లో ఉండే క్యాష్-అవేర్ సర్దుబాటు `aggressive`/`ultra`ను స్వయంచాలకంగా `standard`కు డౌన్గ్రేడ్ చేస్తుంది (`cache-aware` మోడ్ను ఎంచుకునే అవకాశం లేదు) --- ## ఇవి కూడా చూడండి - [ఎన్విరాన్మెంట్ కాన్ఫిగ్](../reference/ENVIRONMENT.md) — కంప్రెషన్ ఎన్విరాన్మెంట్ వేరియబుల్స్ - [ఆర్కిటెక్చర్ గైడ్](../architecture/ARCHITECTURE.md) — కంప్రెషన్ పైప్లైన్ అంతర్గత అంశాలు - [వినియోగదారు గైడ్](../guides/USER_GUIDE.md) — కంప్రెషన్తో ప్రారంభించడం - [RTK కంప్రెషన్](./RTK_COMPRESSION.md) — RTK ఫిల్టర్లు, ట్రస్ట్ మోడల్, వెరిఫై గేట్, ముడి అవుట్పుట్ రికవరీ - [కంప్రెషన్ ఇంజిన్లు](./COMPRESSION_ENGINES.md) — Caveman, RTK, stacked, APIలు, MCP, డ్యాష్బోర్డ్ - [కంప్రెషన్ నియమాల ఫార్మాట్](./COMPRESSION_RULES_FORMAT.md) — JSON రూల్-ప్యాక్ ఫార్మాట్ - [కంప్రెషన్ లాంగ్వేజ్ ప్యాక్లు](./COMPRESSION_LANGUAGE_PACKS.md) — భాష-నిర్దిష్ట Caveman నియమాలు