mirror of https://github.com/diegosouzapw/OmniRoute.git synced 2026-09-20 22:02:19 +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

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

ଯୋଗ୍ୟ context ଉପରେ ସ୍ୱୟଂଚାଳିତ ଭାବେ 15-95% ସଞ୍ଚୟ କରନ୍ତୁ। ଏକ ଦ୍ରୁତ ସମୀକ୍ଷା ପାଇଁ, README Compression ବିଭାଗ ଦେଖନ୍ତୁ।

ସାରାଂଶ

OmniRoute ଏକ ମଡ୍ୟୁଲାର୍ prompt compression pipeline କାର୍ଯ୍ୟକାରୀ କରେ, ଯାହା ଅନୁରୋଧଗୁଡ଼ିକ upstream providerଙ୍କ ପାଖରେ ପହଞ୍ଚିବା ପୂର୍ବରୁ ସକ୍ରିୟ ଭାବେ ଚାଲେ। ଏହାର ଅର୍ଥ ଆପଣଙ୍କ token ସଞ୍ଚୟ ସ୍ୱଚ୍ଛ ଭାବେ ହୁଏ — ଆପଣଙ୍କ workflowରେ କୌଣସି ପରିବର୍ତ୍ତନ ଦରକାର ନାହିଁ।

କ୍ଲାଏଣ୍ଟ ଅନୁରୋଧ
  → Compression କୌଶଳ ଚୟନକାରୀ
    → Combo override? → Combo ସେଟିଂ ବ୍ୟବହାର କରନ୍ତୁ
    → ସ୍ୱୟଂଚାଳିତ-ଟ୍ରିଗର୍ ସୀମା? → Auto mode ବ୍ୟବହାର କରନ୍ତୁ
    → ଡିଫଲ୍ଟ mode? → Global ସେଟିଂ ବ୍ୟବହାର କରନ୍ତୁ
    → ବନ୍ଦ? → Compression ଏଡ଼ାଇ ଯାଆନ୍ତୁ
  → ଚୟନିତ Compression Mode
    → ବନ୍ଦ: କୌଣସି compression ନାହିଁ
    → Lite: ସୁରକ୍ଷିତ whitespace/formatting ସଫେଇ (~15%)
    → Standard: Caveman-ଶୈଳୀର filler ଅପସାରଣ (~30%)
    → Aggressive: History aging + ସାରାଂଶକରଣ (~50%)
    → Ultra: Heuristic pruning + code-block thinning (~75%)
    → RTK: Command-aware terminal/tool-output filtering (60-90% upstream ପରିସର)
    → Stacked: କ୍ରମବଦ୍ଧ multi-engine pipeline, ସାଧାରଣତଃ ପ୍ରଥମେ RTK ଏବଂ ପରେ Caveman (78-95% ଯୋଗ୍ୟ ପରିସର)
  → ସଂକୁଚିତ ଅନୁରୋଧ → Provider

Compression Modeଗୁଡ଼ିକ

ବନ୍ଦ

କୌଣସି compression ପ୍ରୟୋଗ କରାଯାଏ ନାହିଁ। ସମସ୍ତ message ଅପରିବର୍ତ୍ତିତ ଭାବେ ପାର ହୁଏ।

Lite Mode (~15% ସଞ୍ଚୟ, <1ms ବିଳମ୍ବ)

ସବୁଠାରୁ ସୁରକ୍ଷିତ mode — କୌଣସି ଅର୍ଥଗତ ପରିବର୍ତ୍ତନ ନାହିଁ, କେବଳ formatting ସଫେଇ:

ପ୍ରକ୍ରିୟା	ବର୍ଣ୍ଣନା
`collapseWhitespace`	କ୍ରମାଗତ ଖାଲି ଧାଡ଼ି ଏବଂ ଶେଷରେ ଥିବା spaceଗୁଡ଼ିକୁ ମିଶାନ୍ତୁ
`dedupSystemPrompt`	ନକଲ system messageଗୁଡ଼ିକୁ ଅପସାରଣ କରନ୍ତୁ
`compressToolResults`	ବିସ୍ତୃତ tool/function outputକୁ ସଂକୁଚିତ କରନ୍ତୁ
`removeRedundantContent`	ପୁନରାବୃତ୍ତ ନିର୍ଦ୍ଦେଶଗୁଡ଼ିକୁ ହଟାନ୍ତୁ
`replaceImageUrls`	base64 image data URIଗୁଡ଼ିକୁ ସଂକ୍ଷିପ୍ତ କରନ୍ତୁ

ଏହା ପାଇଁ ସର୍ବୋତ୍ତମ: ସର୍ବଦା-ସକ୍ରିୟ ବ୍ୟବହାର, ସୁରକ୍ଷା-ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ workflow।

Standard Mode (~30% ସଞ୍ଚୟ)

Caveman ଦ୍ୱାରା ଅନୁପ୍ରାଣିତ — ଅର୍ଥ ସଂରକ୍ଷଣ କରି filler ଶବ୍ଦ ଏବଂ ଅତି-ବିସ୍ତୃତ ବାକ୍ୟାଂଶକୁ ଅପସାରଣ କରେ:

filler ଶବ୍ଦଗୁଡ଼ିକୁ ଅପସାରଣ କରେ ("ଦୟାକରି", "ମୁଁ ଭାବୁଛି", "ମୂଳତଃ", "ବାସ୍ତବରେ")
ଅତି-ବିସ୍ତୃତ ବାକ୍ୟାଂଶକୁ ସଂକ୍ଷିପ୍ତ କରେ ("କରିବା ଉଦ୍ଦେଶ୍ୟରେ" → "କରିବାକୁ", "ର ଫଳସ୍ୱରୂପ" → "କାରଣ")
ବିନମ୍ର ଦ୍ୱିଧାସୂଚକ ବାକ୍ୟାଂଶକୁ ହଟାଏ ("ଆପଣ କ’ଣ...", "ଯଦି ଆପଣ ସମ୍ଭବତଃ...")
coding prompt ପାଇଁ ସମନ୍ୱୟ କରାଯାଇଥିବା 30+ regex rule

ଏହା ପାଇଁ ସର୍ବୋତ୍ତମ: ଦୈନନ୍ଦିନ coding workflow, ଖର୍ଚ୍ଚ-ସଚେତନ team।

Aggressive Mode (~50% ସଞ୍ଚୟ)

ଦୀର୍ଘ session ପାଇଁ ବୁଦ୍ଧିମାନ history ପରିଚାଳନା:

Message Aging — ପୁରୁଣା messageଗୁଡ଼ିକ କ୍ରମଶଃ ଅଧିକ ସଂକୁଚିତ ହୁଏ
Tool Result Summarization — ଦୀର୍ଘ tool outputକୁ ସାରାଂଶ ସହ ବଦଳାଯାଏ
Structural Integrity Guards — tool_use + tool_result ଯୋଡ଼ିଗୁଡ଼ିକ ସୁସଙ୍ଗତ ରହିବା ସୁନିଶ୍ଚିତ କରେ
Context Window Awareness — ପ୍ରତ୍ୟେକ modelର token ସୀମାକୁ ସମ୍ମାନ କରେ

ଏହା ପାଇଁ ସର୍ବୋତ୍ତମ: ବିସ୍ତୃତ debugging session, ବଡ଼ codebase।

Ultra Mode (~75% ସଞ୍ଚୟ)

Token-ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ ପରିସ୍ଥିତି ପାଇଁ ସର୍ବାଧିକ compression:

Heuristic Pruning — ପ୍ରାସଙ୍ଗିକତା ସୀମାଠାରୁ ନିମ୍ନରେ ଥିବା messageଗୁଡ଼ିକୁ ଅପସାରଣ କରେ
Code Block Thinning — ପୁନରାବୃତ୍ତ code ଉଦାହରଣଗୁଡ଼ିକୁ ସଂକୁଚିତ କରେ
Binary Search Truncation — context window ପାଇଁ ସର୍ବୋତ୍ତମ cut point ଖୋଜେ
Aggressive modeର ସମସ୍ତ ବୈଶିଷ୍ଟ୍ୟ ଅନ୍ତର୍ଭୁକ୍ତ

ଏହା ପାଇଁ ସର୍ବୋତ୍ତମ: ଯେତେବେଳେ ଆପଣ ବାରମ୍ବାର context ସୀମାରେ ପହଞ୍ଚୁଛନ୍ତି।

RTK Mode (60-90% upstream ପରିସର)

RTK modeକୁ coding-agent sessionରେ ଦେଖାଯାଉଥିବା ବିସ୍ତୃତ tool output ପାଇଁ ଅନୁକୂଳିତ କରାଯାଇଛି:

git status, git diff, git log, test runner, TypeScript/Vite/Webpack build, ESLint/Biome/Prettier, npm audit/install, Docker log, infra output ଏବଂ generic shell output ଭଳି command/output class ଚିହ୍ନଟ କରେ
open-sse/services/compression/engines/rtk/filters/ରୁ JSON filter pack ପ୍ରୟୋଗ କରେ
inline-test validation ଏବଂ project file ପାଇଁ trust-gating ସହିତ project କିମ୍ବା global filters.toml fileରୁ RTK TOML schema v1 filter import କରେ
inline verify sample ସହ 49ଟି built-in filter ପ୍ରଦାନ କରେ
ANSI control sequence, progress bar, ପୁନରାବୃତ୍ତ ଧାଡ଼ି ଏବଂ କାର୍ଯ୍ୟଯୋଗ୍ୟ ନଥିବା noiseକୁ ଅପସାରଣ କରେ
failure, error, warning, ପରିବର୍ତ୍ତିତ file, ସାରାଂଶ ଏବଂ ଦୀର୍ଘ outputର ଶେଷ ଭାଗକୁ ସଂରକ୍ଷଣ କରେ
trust-gated project filter, global filter ଏବଂ ଇଚ୍ଛାଧୀନ ଭାବେ redacted raw-output recoveryକୁ ସମର୍ଥନ କରେ

ଏହା ପାଇଁ ସର୍ବୋତ୍ତମ: shell, build, test, git, grep ଏବଂ file-output transcript ସହିତ agent session।

Stacked Mode (78-95% ଯୋଗ୍ୟ ପରିସର)

Stacked mode ଏକ ନିର୍ଦ୍ଧାରିତ କ୍ରମରେ ଏକାଧିକ compression engine ଚଲାଏ। ଡିଫଲ୍ଟ pipeline ହେଉଛି:

RTK -> Caveman

ସେହି କ୍ରମ ପ୍ରଥମେ terminal/tool outputକୁ ସଂକ୍ଷିପ୍ତ ରଖେ, ତା’ପରେ ଅବଶିଷ୍ଟ natural-language promptରେ Caveman semantic condensation ପ୍ରୟୋଗ କରେ। Stacked pipelineକୁ global ଭାବେ କିମ୍ବା routing comboକୁ ନ୍ୟସ୍ତ compression combo ମାଧ୍ୟମରେ configure କରାଯାଇପାରେ।

ଏହା ପାଇଁ ସର୍ବୋତ୍ତମ: ବଡ଼ tool log ସହିତ ମାନବୀୟ ନିର୍ଦ୍ଦେଶ କିମ୍ବା assistant ସାରାଂଶ ଥିବା ମିଶ୍ରିତ context।

ଅପ୍ଷ୍ଟ୍ରିମ୍ ସଞ୍ଚୟ ଗଣନା

OmniRoute ଦୁଇଟି ଉତ୍ସରୁ ମିଳୁଥିବା କମ୍ପ୍ରେସନ୍ ସଞ୍ଚୟକୁ ଡକ୍ୟୁମେଣ୍ଟ କରେ: ଅପ୍ଷ୍ଟ୍ରିମ୍ ପ୍ରକଳ୍ପ ବେଞ୍ଚମାର୍କ ଏବଂ OmniRoute ର ନିଜସ୍ୱ ଇଞ୍ଜିନ୍ ସଂଯୋଜନ।

ଉତ୍ସ	ଏଠାରେ ବ୍ୟବହୃତ ଅପ୍ଷ୍ଟ୍ରିମ୍ README ସଂଖ୍ୟା
Caveman	`~75%` କମ୍ ଆଉଟ୍ପୁଟ୍ ଟୋକନ୍, `65%` ବେଞ୍ଚମାର୍କ ହାରାହାରି ଆଉଟ୍ପୁଟ୍ ସଞ୍ଚୟ, `22-87%` ପରିସର, ଏବଂ `~46%` ଇନ୍ପୁଟ୍ କମ୍ପ୍ରେସନ୍ ଟୁଲ୍
RTK	କମାଣ୍ଡ ଆଉଟ୍ପୁଟ୍ରେ `60-90%` ସଞ୍ଚୟ; ନମୁନା ସେସନ୍ରେ `~118,000 -> ~23,900` ଟୋକନ୍, କିମ୍ବା `79.7%` ସଞ୍ଚିତ (`~80%`)

ପରସ୍ପର ଆଚ୍ଛାଦିତ ଟୁଲ୍/କନ୍ଟେକ୍ସ୍ଟ ପେଲୋଡ୍ଗୁଡ଼ିକ ପାଇଁ, ଡିଫଲ୍ଟ OmniRoute କମ୍ବୋ ଇଞ୍ଜିନ୍ଗୁଡ଼ିକୁ ଷ୍ଟାକ୍ କରେ:

RTK -> Caveman

ମିଳିତ ସଞ୍ଚୟ ଯୋଗାତ୍ମକ ନୁହେଁ, ଗୁଣାତ୍ମକ ଅଟେ:

combined = 1 - (1 - RTK savings) * (1 - Caveman input savings)
average  = 1 - (1 - 0.80) * (1 - 0.46) = 89.2%
range    = 1 - (1 - 0.60..0.90) * (1 - 0.46) = 78.4-94.6%

ଯେତେବେଳେ 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 ମ୍ୟାଚ୍ ତାଲିକା, ଏକ ଛୋଟ ଫାଇଲ୍ ରିଡ୍, ସାଧାରଣ ବାର୍ତ୍ତାଳାପମୂଳକ ପାଠ୍ୟ) ବିପକ୍ଷରେ ସମାନ ପାଇପ୍ଲାଇନ୍ ରନ୍ ସଠିକ୍ ଭାବରେ ପ୍ରାୟ-ଶୂନ୍ୟ ସଞ୍ଚୟ ପ୍ରଦାନ କରେ, କାରଣ ଅପସାରଣ କରିବାକୁ କୌଣସି ପୁନରାବୃତ୍ତି ନାହିଁ ଏବଂ validateCompression() (validation.ts) ଏପରି କୌଣସି ପୁନର୍ଲିଖନକୁ ପଠାଇବାକୁ ମନା କରେ, ଯାହା କୋଡ୍ ବ୍ଲକ୍, URL, ହେଡିଂ, ଭର୍ସନ୍ କିମ୍ବା ALL-CAPS କନ୍ଷ୍ଟାଣ୍ଟ ଆଇଡେଣ୍ଟିଫାୟର୍ଗୁଡ଼ିକୁ ବାଦ ଦେବ କିମ୍ବା ପରିବର୍ତ୍ତନ କରିବ।

ଏହା ଆଶାକରାଯାଇଥିବା ସୁରକ୍ଷିତ ଆଚରଣ, କୌଣସି ବଗ୍ ନୁହେଁ: ମୁଖ୍ୟତଃ ସ୍ୱଚ୍ଛ ଫାଇଲ୍ଗୁଡ଼ିକୁ ପଢ଼ୁଥିବା/grep କରୁଥିବା ଏକ କୋଡିଂ ସେସନ୍ରେ କମ୍ପ୍ରେସନ୍ ସମ୍ପୂର୍ଣ୍ଣ ସକ୍ଷମ ଥିଲେ ମଧ୍ୟ ସାମାନ୍ୟ ସମୁଦାୟ ସଞ୍ଚୟ ଦେଖାଯିବ, ଯେତେବେଳେ ଏକ ବିଫଳ ଲୁପ୍ କିମ୍ବା ଅତ୍ୟଧିକ ଆଉଟ୍ପୁଟ୍ ଦେଉଥିବା ଲିଣ୍ଟର୍ର ସମ୍ମୁଖୀନ ହେଉଥିବା ସେସନ୍ରେ ସେହି ଟ୍ରାଫିକ୍ ଉପରେ ସମ୍ପୂର୍ଣ୍ଣ 78-95% ପରିସର ଦେଖାଯିବ। କମ୍ ସମଗ୍ର ସଞ୍ଚୟ ପ୍ରତିଶତ ଥିବା ଗୋଟିଏ ସେସନ୍କୁ କମ୍ପ୍ରେସନ୍ ଭୁଲ ଭାବେ କନ୍ଫିଗର୍ ହୋଇଥିବାର ପ୍ରମାଣ ଭାବେ ବ୍ୟବହାର କରନ୍ତୁ ନାହିଁ — ପ୍ରଥମେ ଯାଞ୍ଚ କରନ୍ତୁ ଯେ ଅନ୍ତର୍ନିହିତ ଟୁଲ୍ ଆଉଟ୍ପୁଟ୍ ପ୍ରକୃତରେ ପୁନରାବୃତ୍ତ ଥିଲା କି ନାହିଁ।

ଟୋକନ୍ ସଞ୍ଚୟ ଭିଜୁଆଲାଇଜେସନ୍

କମ୍ପ୍ରେସନ୍ ବିନା:      LLMକୁ 47K ଟୋକନ୍ ପଠାଗଲା
Lite ସହିତ:             40K ଟୋକନ୍ ପଠାଗଲା          (15% ସଞ୍ଚିତ — ସୁରକ୍ଷିତ, ସର୍ବଦା-ସକ୍ଷମ)
Standard ସହିତ:         33K ଟୋକନ୍ ପଠାଗଲା          (30% ସଞ୍ଚିତ — caveman-speak ନିୟମ)
Aggressive ସହିତ:       24K ଟୋକନ୍ ପଠାଗଲା          (50% ସଞ୍ଚିତ — ଏଜିଂ + ସାରାଂଶୀକରଣ)
Ultra ସହିତ:            12K ଟୋକନ୍ ପଠାଗଲା          (75% ସଞ୍ଚିତ — ହ୍ୟୁରିଷ୍ଟିକ୍ ପ୍ରୁନିଂ)
RTK ସହିତ:              19K-5K ଟୋକନ୍ ପଠାଗଲା       (କମାଣ୍ଡ/ଟୁଲ୍ ଆଉଟ୍ପୁଟ୍ରେ 60-90% ସଞ୍ଚିତ)
Stacked ସହିତ:          10K-2.5K ଟୋକନ୍ ପଠାଗଲା     (ଯୋଗ୍ୟ RTK+Caveman ପରିସରରେ 78-95% ସଞ୍ଚିତ)

ବିନ୍ୟାସ

ଡ୍ୟାଶବୋର୍ଡ

Dashboard → Context & Cacheକୁ ଯାଆନ୍ତୁ:

Caveman — ମୋଡ୍ ଚୟନ, ଭାଷା ପ୍ୟାକ୍, ପୂର୍ବାବଲୋକନ ଏବଂ ବୈଶ୍ୱିକ ଡିଫଲ୍ଟ
RTK — କମାଣ୍ଡ-ଫିଲ୍ଟର୍ ପୂର୍ବାବଲୋକନ, RTK ସୁରକ୍ଷା ସେଟିଂସ୍ ଏବଂ ଫିଲ୍ଟର୍ କ୍ୟାଟାଲଗ୍
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

ଏହା ଆପଣଙ୍କୁ ପେଡ୍ ସବ୍ସ୍କ୍ରିପ୍ସନ୍ଗୁଡ଼ିକରେ ଲାଇଟ୍ ମୋଡ୍ ରଖିବା ସହିତ ମାଗଣା/କୋଡିଂ ପ୍ରଦାତାଙ୍କ ପାଇଁ ସ୍ତରୀକୃତ ସଙ୍କୋଚନ ବ୍ୟବହାର କରିବାକୁ ଦିଏ।

ଏହି "ପ୍ରତି-କମ୍ବୋ ଓଭରରାଇଡ୍" ଆସାଇନ୍ମେଣ୍ଟଟି ରାଉଟିଂ-କମ୍ବୋ ସଙ୍କୋଚନ ମୋଡ୍ ଓଭରରାଇଡ୍ (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 ଅନୁରୋଧ ହେଡର୍ ପଠାନ୍ତୁ। ଏହାର ସର୍ବୋଚ୍ଚ ପ୍ରାଥମିକତା ରହିଛି — ଏହା ରାଉଟିଂ-କମ୍ବୋ ଓଭରରାଇଡ୍, ସକ୍ରିୟ ପ୍ରୋଫାଇଲ୍, ଅଟୋ-ଟ୍ରିଗର୍ ଏବଂ ପ୍ୟାନେଲ୍ର Defaultକୁ ଅଗ୍ରାଧିକାର ଦିଏ। ଅଜଣା ମୂଲ୍ୟଗୁଡ଼ିକୁ ଅଣଦେଖା କରାଯାଏ (ଅନୁରୋଧ କେବେବି ପ୍ରତ୍ୟାଖ୍ୟାନ ହୁଏ ନାହିଁ) ଏବଂ ବୈଶ୍ୱିକ ମାଷ୍ଟର୍ ସ୍ୱିଚ୍ ତଥାପି ସବୁକିଛିକୁ ନିୟନ୍ତ୍ରଣ କରେ: ବୈଶ୍ୱିକ ଭାବେ ସଙ୍କୋଚନ ବନ୍ଦ ଥିଲେ, ହେଡର୍ ଏହାକୁ ଚାଲୁ କରିପାରିବ ନାହିଁ। ମୂଲ୍ୟଗୁଡ଼ିକ:

ମୂଲ୍ୟ	ପ୍ରଭାବ
`off`	ଏହି ଅନୁରୋଧ ପାଇଁ କୌଣସି ସଙ୍କୋଚନ ନାହିଁ।
`default`	ପ୍ୟାନେଲ୍ରୁ ଉତ୍ପନ୍ନ Default ପ୍ରୋଫାଇଲ୍ (ସକ୍ରିୟ ପ୍ରୋଫାଇଲ୍କୁ ଅଣଦେଖା କରେ)।
`engine:<id>`	ସକ୍ରିୟ ଥିବାବେଳେ ଗୋଟିଏ ଇଞ୍ଜିନ୍, ଉଦାହରଣ ସ୍ୱରୂପ `engine:rtk`।
`<combo>`	ଏକ ନାମିତ କମ୍ବୋ, ପ୍ରଥମେ ନାମ ଅନୁଯାୟୀ (କେସ୍-ଅସମ୍ବେଦନଶୀଳ), ତା’ପରେ id ଅନୁଯାୟୀ ମେଳ କରାଯାଏ।

ପ୍ରୟୋଗ କରାଯାଇଥିବା ଯୋଜନାଟି X-OmniRoute-Compression: <mode>; source=<source> ପ୍ରତିକ୍ରିୟା ହେଡର୍ରେ ପୁନର୍ବାର ଫେରାଯାଏ, ଯେଉଁଠାରେ <source> ହେଉଛି request-header, routing-override, active-profile, auto-trigger, default, କିମ୍ବା off ମଧ୍ୟରୁ ଗୋଟିଏ।

API

# ସଙ୍କୋଚନ ସେଟିଂସ୍ ପ୍ରାପ୍ତ କରନ୍ତୁ
curl http://localhost:20128/api/settings/compression

# ସଙ୍କୋଚନ ସେଟିଂସ୍ ଅପଡେଟ୍ କରନ୍ତୁ
curl -X PUT http://localhost:20128/api/settings/compression \
  -H "Content-Type: application/json" \
  -d '{"defaultMode":"stacked","autoTriggerMode":"stacked","autoTriggerTokens":32000}'

# ଏକ ନିର୍ଦ୍ଦିଷ୍ଟ RTK/stacked ପେଲୋଡ୍ର ପୂର୍ବାବଲୋକନ କରନ୍ତୁ
curl -X POST http://localhost:20128/api/compression/preview \
  -H "Content-Type: application/json" \
  -d '{"mode":"rtk","messages":[{"role":"tool","content":"npm test output here"}]}'

# RTK ଫିଲ୍ଟର୍ ପ୍ୟାକ୍ଗୁଡ଼ିକର ତାଲିକା ପାଆନ୍ତୁ
curl http://localhost:20128/api/context/rtk/filters

# ଇଚ୍ଛାଧୀନ କମାଣ୍ଡ ମେଟାଡାଟା ସହିତ RTKକୁ ସିଧାସଳଖ ପରୀକ୍ଷା କରନ୍ତୁ
curl -X POST http://localhost:20128/api/context/rtk/test \
  -H "Content-Type: application/json" \
  -d '{"command":"npm test","text":"FAIL tests/example.test.ts\nError: boom"}'

କ’ଣ ସୁରକ୍ଷିତ ରହେ

କମ୍ପ୍ରେସନ୍ ଇଞ୍ଜିନ୍ ସର୍ବଦା ଏଗୁଡ଼ିକୁ ସଂରକ୍ଷିତ ରଖେ:

✅ କୋଡ୍ ବ୍ଲକ୍ଗୁଡ଼ିକ (ଫେନ୍ସ୍ଡ ଏବଂ ଇନ୍ଲାଇନ୍)
✅ URL ଏବଂ ଫାଇଲ୍ ପାଥ୍ଗୁଡ଼ିକ
✅ JSON ଗଠନ ଏବଂ ସଂରଚିତ ଡାଟା
✅ ଆଇଡେଣ୍ଟିଫାୟର୍ ଏବଂ ସୁରକ୍ଷିତ ବୈଷୟିକ ଟୋକନ୍ଗୁଡ଼ିକ
✅ ଗାଣିତିକ ଏକ୍ସପ୍ରେସନ୍ଗୁଡ଼ିକ
✅ ଟୁଲ୍/ଫଙ୍କସନ୍ କଲ୍ ପରିଭାଷାଗୁଡ଼ିକ
✅ ସିଷ୍ଟମ୍ ପ୍ରମ୍ପ୍ଟଗୁଡ଼ିକ (lite ମୋଡ୍ରେ)

କୌଣସି ବିଷୟ ସ୍ଥାୟୀ ଭାବେ ସଂରକ୍ଷିତ ହେବା ପୂର୍ବରୁ RTK raw-output recovery ସାଧାରଣ API କୀ, bearer ଟୋକନ୍, 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	Off, Lite	✅ ପ୍ରକାଶିତ
ପର୍ଯ୍ୟାୟ 2	Standard, Aggressive, Ultra	✅ ପ୍ରକାଶିତ
ପର୍ଯ୍ୟାୟ 3	RTK, Stacked, Compression Combos	✅ ପ୍ରକାଶିତ
ପର୍ଯ୍ୟାୟ 4	Output Styles, SLM-tier Ultra, eval harness	✅ ପ୍ରକାଶିତ
ପର୍ଯ୍ୟାୟ 4C	ଆଡାପ୍ଟିଭ୍ କଣ୍ଟେକ୍ସ୍ଟ-ବଜେଟ୍ ("dial") — କମ୍ପ୍ୟୁଟ୍ ଇଞ୍ଜିନ୍ + API (`PUT /api/settings/compression` ରେ `contextBudget`) + ଡ୍ୟାଶ୍ବୋର୍ଡ ମୋଡ୍/ପଲିସି କଣ୍ଟ୍ରୋଲ୍ଗୁଡ଼ିକ	✅ ପ୍ରକାଶିତ

ସ୍ୱୀକୃତି

Standard ମୋଡ୍ କମ୍ପ୍ରେସନ୍ ନିୟମଗୁଡ଼ିକ **JuliusBrussee**ଙ୍କ Caveman (⭐ 51K+) — ଭାଇରାଲ୍ "ଅଳ୍ପ ଟୋକନ୍ରେ କାମ ହେଉଥିବାବେଳେ ଅଧିକ ଟୋକନ୍ କାହିଁକି ବ୍ୟବହାର କରିବେ" ପ୍ରକଳ୍ପ — ଦ୍ୱାରା ଅନୁପ୍ରାଣିତ। Caveman ~75% କମ୍ ଆଉଟ୍ପୁଟ୍ ଟୋକନ୍, ବେଞ୍ଚମାର୍କରେ ହାରାହାରି 65% ଆଉଟ୍ପୁଟ୍ ସଞ୍ଚୟ, 22-87% ଆଉଟ୍ପୁଟ୍ ପରିସର ଏବଂ ଏକ ~46% ଇନ୍ପୁଟ୍-କମ୍ପ୍ରେସନ୍ ଟୁଲ୍ ରିପୋର୍ଟ କରେ।

RTK ମୋଡ୍ **RTK AI**ଙ୍କ RTK - Rust Token Killer — ଟର୍ମିନାଲ୍, ବିଲ୍ଡ, ଟେଷ୍ଟ, git ଏବଂ ଟୁଲ୍-ଆଉଟ୍ପୁଟ୍ ଫିଲ୍ଟରିଂ ପାଇଁ ଉଚ୍ଚ-କାର୍ଯ୍ୟଦକ୍ଷତାସମ୍ପନ୍ନ କମାଣ୍ଡ-ଆଉଟ୍ପୁଟ୍ କମ୍ପ୍ରେସନ୍ ପ୍ରକଳ୍ପ — ଦ୍ୱାରା ଅନୁପ୍ରାଣିତ। RTK 60-90% ସଞ୍ଚୟ ରିପୋର୍ଟ କରେ, ଏବଂ ଏହାର README ନମୁନା ସେସନ୍ରେ ~80% ସଞ୍ଚୟ ଦେଖାଯାଇଛି।

ଉନ୍ନତ କମ୍ପ୍ରେସନ୍ ସିଷ୍ଟମ୍ଗୁଡ଼ିକ

7ଟି ମାନକ ମୋଡ୍ ବ୍ୟତୀତ, OmniRoute ରେ ଅନେକ ଉନ୍ନତ କମ୍ପ୍ରେସନ୍ ସିଷ୍ଟମ୍ ଅନ୍ତର୍ଭୁକ୍ତ ଅଛି, ଯାହା କଣ୍ଟେକ୍ସ୍ଟ ଆଧାରରେ ସ୍ୱୟଂଚାଳିତ ଭାବେ କାମ କରେ।

କ୍ୟାଶ୍-ସଚେତନ କମ୍ପ୍ରେସନ୍

କିଛି ପ୍ରଦାନକାରୀ (ଯେପରିକି ପ୍ରମ୍ପ୍ଟ କ୍ୟାଶିଂ ସହିତ Anthropic) ପ୍ରମ୍ପ୍ଟ କ୍ୟାଶିଂ ସମର୍ଥନ କରନ୍ତି, ଯାହା ସେମାନଙ୍କୁ ଖର୍ଚ୍ଚ ଏବଂ ବିଳମ୍ବତା କମାଇବା ପାଇଁ ପ୍ରମ୍ପ୍ଟର କିଛି ଅଂଶ କ୍ୟାଶ୍ କରିବାକୁ ଦିଏ। ଯେତେବେଳେ କ୍ୟାଶିଂ ସକ୍ଷମ ଥାଏ, aggressive କମ୍ପ୍ରେସନ୍ ପ୍ରକୃତରେ କାର୍ଯ୍ୟଦକ୍ଷତାକୁ କ୍ଷତି ପହଞ୍ଚାଇପାରେ, କାରଣ ଏହା କ୍ୟାଶ୍ ହୋଇଥିବା ଟୋକନ୍ଗୁଡ଼ିକୁ ପରିବର୍ତ୍ତନ କରି କ୍ୟାଶ୍କୁ ଅବୈଧ କରିଦିଏ।

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): Lite କମ୍ପ୍ରେସନ୍ (ହ୍ୱାଇଟ୍ସ୍ପେସ୍, ଫର୍ମାଟିଂ ସଫାକରଣ)
ପୁରୁଣା ପର୍ଯ୍ୟାୟ (9+): Caveman କମ୍ପ୍ରେସନ୍ (ଅନାବଶ୍ୟକ ବିଷୟବସ୍ତୁ ଅପସାରଣ, ସାରାଂଶକରଣ)
ଅତ୍ୟନ୍ତ ପୁରୁଣା ପର୍ଯ୍ୟାୟ (20+): ବ୍ୟାପକ ଭାବେ ସାରାଂଶିତ କିମ୍ବା ବାଦ ଦିଆଯାଏ

କୋଡ୍ ଉଦାହରଣ

import { applyAging } from "@omniroute/open-sse/services/compression/progressiveAging";

const messages = [
  { role: "system", content: "You are a helpful assistant" },
  { role: "user", content: "What is 2+2?" },
  { role: "assistant", content: "4" },
  // ... ଆହୁରି 50ଟି ପର୍ଯ୍ୟାୟ ...
];

const { messages: aged, saved } = applyAging(messages, {
  verbatim: 3, // ପ୍ରଥମ 3ଟି ପର୍ଯ୍ୟାୟ: ଅବିକଳ
  light: 8, // ପର୍ଯ୍ୟାୟ 4-8: lite କମ୍ପ୍ରେସନ୍
  moderate: 20, // ପର୍ଯ୍ୟାୟ 9-20: caveman କମ୍ପ୍ରେସନ୍
  // ପର୍ଯ୍ୟାୟ 21+: ବ୍ୟାପକ ସାରାଂଶକରଣ
});

// 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 — ରହିଛି ଏବଂ ପ୍ରତ୍ୟେକ ସ୍ତର ସାଧାରଣ ସୀମା ଧାରା ସହିତ ଶେଷ ହୁଏ, ଯାହା କୋଡ୍ ବ୍ଲକ୍, ଫାଇଲ୍ ପାଥ୍, କମାଣ୍ଡ, ତ୍ରୁଟି ଷ୍ଟ୍ରିଙ୍ଗ୍, URL ଏବଂ ଆଇଡେଣ୍ଟିଫାୟର୍ଗୁଡ଼ିକୁ ଅବିକଳ ରଖେ।

ଇଞ୍ଜେକ୍ସନ୍ କିପରି କାମ କରେ

applyOutputStyles() (open-sse/services/compression/outputStyles/apply.ts) ଚୟନକୁ କ୍ୟାଟାଲଗ୍ ସହିତ ମେଳାଇ ସମାଧାନ କରେ (ଅଜଣା id ଏବଂ ଲୋକେଲ୍ ସହିତ ମେଳ ନହେଉଥିବା ଶୈଳୀଗୁଡ଼ିକୁ ବାଦ ଦିଆଯାଏ, କେବେ ମଧ୍ୟ ତ୍ରୁଟି ହୁଏ ନାହିଁ), ଚୟନିତ ନିର୍ଦ୍ଦେଶଗୁଡ଼ିକୁ କ୍ୟାଟାଲଗ୍ କ୍ରମରେ ଯୋଡ଼େ, ସୀମା ଧାରାକୁ ଥରେ ମାତ୍ର ଯୋଡ଼େ ଏବଂ ଫଳାଫଳକୁ ଏକକ ଆଇଡେମ୍ପୋଟେନ୍ସି ମାର୍କର୍ ([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% ସଞ୍ଚୟ), ତା’ପରେ କେଭ୍ମ୍ୟାନ୍ (ଅବଶିଷ୍ଟ ପାଠ୍ୟରେ ଅତିରିକ୍ତ 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 ନିୟମଗୁଡ଼ିକ

57 KiB Raw Blame History Unescape Escape

🗜️ Prompt Compression Guide — OmniRoute (ଓଡ଼ିଆ)

ସାରାଂଶ

Compression Modeଗୁଡ଼ିକ

ବନ୍ଦ

Lite Mode (~15% ସଞ୍ଚୟ, <1ms ବିଳମ୍ବ)

Standard Mode (~30% ସଞ୍ଚୟ)

Aggressive Mode (~50% ସଞ୍ଚୟ)

Ultra Mode (~75% ସଞ୍ଚୟ)

RTK Mode (60-90% upstream ପରିସର)

Stacked Mode (78-95% ଯୋଗ୍ୟ ପରିସର)

ଅପ୍ଷ୍ଟ୍ରିମ୍ ସଞ୍ଚୟ ଗଣନା

"ଯୋଗ୍ୟ"ର ପ୍ରକୃତ ଅର୍ଥ କ’ଣ

ଟୋକନ୍ ସଞ୍ଚୟ ଭିଜୁଆଲାଇଜେସନ୍

ବିନ୍ୟାସ

ଡ୍ୟାଶବୋର୍ଡ

ପ୍ରତି-କମ୍ବୋ ଓଭରରାଇଡ୍

ପ୍ରତି-ଅନୁରୋଧ ଓଭରରାଇଡ୍

API

କ’ଣ ସୁରକ୍ଷିତ ରହେ

କମ୍ପ୍ରେସନ୍ ପରିସଂଖ୍ୟାନ

ପର୍ଯ୍ୟାୟ ରୋଡ୍ମ୍ୟାପ୍

ସ୍ୱୀକୃତି

ଉନ୍ନତ କମ୍ପ୍ରେସନ୍ ସିଷ୍ଟମ୍ଗୁଡ଼ିକ

କ୍ୟାଶ୍-ସଚେତନ କମ୍ପ୍ରେସନ୍

ଏହା କିପରି କାମ କରେ

କୋଡ୍ ଉଦାହରଣ

କେବେ ବ୍ୟବହାର କରିବେ

ପ୍ରଗତିଶୀଳ ପୁରୁଣାକରଣ

କୋଡ୍ ଉଦାହରଣ

କେବେ ବ୍ୟବହାର କରିବେ

କେଭ୍ମ୍ୟାନ୍ ଆଉଟପୁଟ୍ ମୋଡ୍

ଏହା କିପରି କାମ କରେ

କେବେ ବ୍ୟବହାର କରିବେ

ଆଉଟପୁଟ୍ ଶୈଳୀଗୁଡ଼ିକ (କ୍ୟାଟାଲଗ୍)

ଇଞ୍ଜେକ୍ସନ୍ କିପରି କାମ କରେ

କିପରି ସକ୍ରିୟ କରିବେ

ଟୁଲ୍ ଫଳାଫଳ କମ୍ପ୍ରେସନ୍

କେବେ ବ୍ୟବହାର କରିବେ

ଷ୍ଟାକ୍ଡ୍ ପାଇପଲାଇନ୍

ଏହା କିପରି କାମ କରେ

କେବେ ବ୍ୟବହାର କରିବେ

କମ୍ପ୍ରେସନ୍ କମ୍ବୋ ଓଭରରାଇଡ୍ଗୁଡ଼ିକ

ଏହା ମଧ୍ୟ ଦେଖନ୍ତୁ

57 KiB

Raw Blame History