mirror of https://github.com/diegosouzapw/OmniRoute.git synced 2026-09-20 05:42: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

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

ਯੋਗ ਸੰਦਰਭ 'ਤੇ ਆਪਣੇ ਆਪ 15-95% ਬਚਾਓ। ਇੱਕ ਤੁਰੰਤ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਲਈ, README Compression ਭਾਗ ਵੇਖੋ।

ਸੰਖੇਪ ਜਾਣਕਾਰੀ

OmniRoute ਇੱਕ ਮੋਡੀਊਲਰ ਪ੍ਰੌਮਪਟ ਕੰਪ੍ਰੈਸ਼ਨ ਪਾਈਪਲਾਈਨ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਜੋ ਬੇਨਤੀਆਂ ਦੇ ਅੱਪਸਟ੍ਰੀਮ ਪ੍ਰਦਾਤਾਵਾਂ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸਰਗਰਮੀ ਨਾਲ ਚੱਲਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੇ ਟੋਕਨਾਂ ਦੀ ਬਚਤ ਪਾਰਦਰਸ਼ੀ ਢੰਗ ਨਾਲ ਹੁੰਦੀ ਹੈ — ਤੁਹਾਡੇ ਵਰਕਫਲੋ ਵਿੱਚ ਕਿਸੇ ਤਬਦੀਲੀ ਦੀ ਲੋੜ ਨਹੀਂ।

ਕਲਾਇੰਟ ਬੇਨਤੀ
  → ਕੰਪ੍ਰੈਸ਼ਨ ਰਣਨੀਤੀ ਚੋਣਕਾਰ
    → ਕੰਬੋ ਓਵਰਰਾਈਡ? → ਕੰਬੋ ਸੈਟਿੰਗ ਵਰਤੋ
    → ਸਵੈ-ਚਾਲੂ ਹੋਣ ਦੀ ਸੀਮਾ? → ਆਟੋ ਮੋਡ ਵਰਤੋ
    → ਡਿਫੌਲਟ ਮੋਡ? → ਗਲੋਬਲ ਸੈਟਿੰਗ ਵਰਤੋ
    → ਬੰਦ? → ਕੰਪ੍ਰੈਸ਼ਨ ਛੱਡੋ
  → ਚੁਣਿਆ ਗਿਆ ਕੰਪ੍ਰੈਸ਼ਨ ਮੋਡ
    → ਬੰਦ: ਕੋਈ ਕੰਪ੍ਰੈਸ਼ਨ ਨਹੀਂ
    → ਲਾਈਟ: ਸੁਰੱਖਿਅਤ ਖਾਲੀ ਥਾਂ/ਫਾਰਮੈਟਿੰਗ ਸਫ਼ਾਈ (~15%)
    → ਸਟੈਂਡਰਡ: ਆਦਿਮ-ਸ਼ੈਲੀ ਦੇ ਭਰਾਵੀਂ ਸ਼ਬਦਾਂ ਨੂੰ ਹਟਾਉਣਾ (~30%)
    → ਅਗਰੈਸਿਵ: ਹਿਸਟਰੀ ਏਜਿੰਗ + ਸੰਖੇਪੀਕਰਨ (~50%)
    → ਅਲਟਰਾ: ਹਿਊਰਿਸਟਿਕ ਛਾਂਟੀ + ਕੋਡ-ਬਲਾਕ ਪਤਲੇ ਕਰਨਾ (~75%)
    → RTK: ਕਮਾਂਡ-ਅਨੁਕੂਲ ਟਰਮੀਨਲ/ਟੂਲ-ਆਉਟਪੁੱਟ ਫਿਲਟਰਿੰਗ (60-90% ਅੱਪਸਟ੍ਰੀਮ ਰੇਂਜ)
    → ਸਟੈਕਡ: ਕ੍ਰਮਬੱਧ ਬਹੁ-ਇੰਜਣ ਪਾਈਪਲਾਈਨ, ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ RTK ਫਿਰ Caveman (78-95% ਯੋਗ ਰੇਂਜ)
  → ਕੰਪ੍ਰੈੱਸ ਕੀਤੀ ਬੇਨਤੀ → ਪ੍ਰਦਾਤਾ

ਕੰਪ੍ਰੈਸ਼ਨ ਮੋਡ

ਬੰਦ

ਕੋਈ ਕੰਪ੍ਰੈਸ਼ਨ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀ। ਸਾਰੇ ਸੁਨੇਹੇ ਬਿਨਾਂ ਕਿਸੇ ਤਬਦੀਲੀ ਦੇ ਅੱਗੇ ਭੇਜੇ ਜਾਂਦੇ ਹਨ।

ਲਾਈਟ ਮੋਡ (~15% ਬਚਤ, <1ms ਲੇਟੈਂਸੀ)

ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਮੋਡ — ਅਰਥ ਵਿੱਚ ਕੋਈ ਤਬਦੀਲੀ ਨਹੀਂ, ਸਿਰਫ਼ ਫਾਰਮੈਟਿੰਗ ਦੀ ਸਫ਼ਾਈ:

ਤਕਨੀਕ	ਵੇਰਵਾ
`collapseWhitespace`	ਲਗਾਤਾਰ ਖਾਲੀ ਲਾਈਨਾਂ ਅਤੇ ਅੰਤਲੀਆਂ ਖਾਲੀ ਥਾਵਾਂ ਨੂੰ ਮਿਲਾਓ
`dedupSystemPrompt`	ਡੁਪਲੀਕੇਟ ਸਿਸਟਮ ਸੁਨੇਹੇ ਹਟਾਓ
`compressToolResults`	ਵਿਸਤ੍ਰਿਤ ਟੂਲ/ਫੰਕਸ਼ਨ ਆਉਟਪੁੱਟਾਂ ਨੂੰ ਕੰਪ੍ਰੈੱਸ ਕਰੋ
`removeRedundantContent`	ਦੁਹਰਾਈਆਂ ਹਦਾਇਤਾਂ ਹਟਾਓ
`replaceImageUrls`	base64 ਚਿੱਤਰ ਡਾਟਾ URIs ਨੂੰ ਛੋਟਾ ਕਰੋ

ਇਸ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ: ਹਮੇਸ਼ਾ-ਚਾਲੂ ਵਰਤੋਂ, ਸੁਰੱਖਿਆ-ਨਾਜ਼ੁਕ ਵਰਕਫਲੋ।

ਸਟੈਂਡਰਡ ਮੋਡ (~30% ਬਚਤ)

Caveman ਤੋਂ ਪ੍ਰੇਰਿਤ — ਅਰਥ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋਏ ਭਰਾਵੀਂ ਸ਼ਬਦ ਅਤੇ ਬੇਲੋੜੀ ਵਿਸਤ੍ਰਿਤ ਵਾਕ-ਰਚਨਾ ਹਟਾਉਂਦਾ ਹੈ:

ਭਰਾਵੀਂ ਸ਼ਬਦਾਂ ("ਕਿਰਪਾ ਕਰਕੇ", "ਮੇਰੇ ਖ਼ਿਆਲ ਵਿੱਚ", "ਮੂਲ ਰੂਪ ਵਿੱਚ", "ਅਸਲ ਵਿੱਚ") ਨੂੰ ਹਟਾਉਂਦਾ ਹੈ
ਬੇਲੋੜੇ ਲੰਮੇ ਵਾਕਾਂਸ਼ਾਂ ਨੂੰ ਸੰਖੇਪ ਕਰਦਾ ਹੈ ("ਕਰਨ ਦੇ ਉਦੇਸ਼ ਨਾਲ" → "ਕਰਨ ਲਈ", "ਦੇ ਨਤੀਜੇ ਵਜੋਂ" → "ਕਿਉਂਕਿ")
ਨਿਮਰ ਹਿਚਕਚਾਹਟ ਵਾਲੇ ਵਾਕਾਂਸ਼ ਹਟਾਉਂਦਾ ਹੈ ("ਕੀ ਤੁਹਾਨੂੰ ਇਤਰਾਜ਼ ਹੋਵੇਗਾ...", "ਜੇ ਤੁਸੀਂ ਸੰਭਵ ਤੌਰ 'ਤੇ ਕਰ ਸਕੋ...")
ਕੋਡਿੰਗ ਪ੍ਰੌਮਪਟਾਂ ਲਈ ਅਨੁਕੂਲਿਤ 30+ regex ਨਿਯਮ

ਇਸ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ: ਰੋਜ਼ਾਨਾ ਕੋਡਿੰਗ ਵਰਕਫਲੋ, ਲਾਗਤ ਪ੍ਰਤੀ ਸੁਚੇਤ ਟੀਮਾਂ।

ਅਗਰੈਸਿਵ ਮੋਡ (~50% ਬਚਤ)

ਲੰਮੇ ਸੈਸ਼ਨਾਂ ਲਈ ਸਮਾਰਟ ਹਿਸਟਰੀ ਪ੍ਰਬੰਧਨ:

ਸੁਨੇਹਾ ਏਜਿੰਗ — ਪੁਰਾਣੇ ਸੁਨੇਹੇ ਹੌਲੀ-ਹੌਲੀ ਹੋਰ ਕੰਪ੍ਰੈੱਸ ਹੁੰਦੇ ਜਾਂਦੇ ਹਨ
ਟੂਲ ਨਤੀਜਾ ਸੰਖੇਪੀਕਰਨ — ਲੰਮੀਆਂ ਟੂਲ ਆਉਟਪੁੱਟਾਂ ਨੂੰ ਸੰਖੇਪਾਂ ਨਾਲ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ
ਸੰਰਚਨਾਤਮਕ ਅਖੰਡਤਾ ਸੁਰੱਖਿਆਵਾਂ — ਯਕੀਨੀ ਬਣਾਉਂਦੀਆਂ ਹਨ ਕਿ tool_use + tool_result ਜੋੜੇ ਇਕਸਾਰ ਰਹਿਣ
ਕਾਂਟੈਕਸਟ ਵਿੰਡੋ ਜਾਗਰੂਕਤਾ — ਹਰ ਮਾਡਲ ਦੀ ਟੋਕਨ ਸੀਮਾ ਦਾ ਧਿਆਨ ਰੱਖਦੀ ਹੈ

ਇਸ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ: ਲੰਮੇ ਡੀਬੱਗਿੰਗ ਸੈਸ਼ਨ, ਵੱਡੇ ਕੋਡਬੇਸ।

ਅਲਟਰਾ ਮੋਡ (~75% ਬਚਤ)

ਟੋਕਨ-ਨਾਜ਼ੁਕ ਸਥਿਤੀਆਂ ਲਈ ਅਧਿਕਤਮ ਕੰਪ੍ਰੈਸ਼ਨ:

ਹਿਊਰਿਸਟਿਕ ਛਾਂਟੀ — ਪ੍ਰਸੰਗਿਕਤਾ ਸੀਮਾ ਤੋਂ ਹੇਠਾਂ ਵਾਲੇ ਸੁਨੇਹੇ ਹਟਾਉਂਦੀ ਹੈ
ਕੋਡ ਬਲਾਕ ਪਤਲੇ ਕਰਨਾ — ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਕੋਡ ਉਦਾਹਰਨਾਂ ਨੂੰ ਕੰਪ੍ਰੈੱਸ ਕਰਦਾ ਹੈ
ਬਾਈਨਰੀ ਖੋਜ ਕਟੌਤੀ — ਕਾਂਟੈਕਸਟ ਵਿੰਡੋ ਲਈ ਸਰਵੋਤਮ ਕੱਟਣ ਬਿੰਦੂ ਲੱਭਦੀ ਹੈ
ਅਗਰੈਸਿਵ ਮੋਡ ਦੀਆਂ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ਾਮਲ ਹਨ

ਇਸ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ: ਜਦੋਂ ਤੁਸੀਂ ਵਾਰ-ਵਾਰ ਕਾਂਟੈਕਸਟ ਸੀਮਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਰਹੇ ਹੋਵੋ।

RTK ਮੋਡ (60-90% ਅੱਪਸਟ੍ਰੀਮ ਰੇਂਜ)

RTK ਮੋਡ ਕੋਡਿੰਗ-ਏਜੰਟ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀਆਂ ਵਿਸਤ੍ਰਿਤ ਟੂਲ ਆਉਟਪੁੱਟਾਂ ਲਈ ਅਨੁਕੂਲਿਤ ਹੈ:

git status, git diff, git log, ਟੈਸਟ ਰਨਰਾਂ, TypeScript/Vite/Webpack ਬਿਲਡਾਂ, ESLint/Biome/Prettier, npm ਆਡਿਟ/ਇੰਸਟਾਲਾਂ, Docker ਲੌਗਾਂ, ਇਨਫਰਾ ਆਉਟਪੁੱਟ ਅਤੇ ਆਮ ਸ਼ੈੱਲ ਆਉਟਪੁੱਟ ਵਰਗੀਆਂ ਕਮਾਂਡ/ਆਉਟਪੁੱਟ ਸ਼੍ਰੇਣੀਆਂ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ
open-sse/services/compression/engines/rtk/filters/ ਤੋਂ JSON ਫਿਲਟਰ ਪੈਕ ਲਾਗੂ ਕਰਦਾ ਹੈ
ਪ੍ਰੋਜੈਕਟ ਜਾਂ ਗਲੋਬਲ filters.toml ਫਾਈਲਾਂ ਤੋਂ RTK TOML schema v1 ਫਿਲਟਰ ਇੰਪੋਰਟ ਕਰਦਾ ਹੈ, ਇਨਲਾਈਨ-ਟੈਸਟ ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਫਾਈਲਾਂ ਲਈ ਭਰੋਸਾ-ਗੇਟਿੰਗ ਸਮੇਤ
ਇਨਲਾਈਨ ਪੁਸ਼ਟੀ ਨਮੂਨਿਆਂ ਸਮੇਤ 49 ਬਿਲਟ-ਇਨ ਫਿਲਟਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ
ANSI ਕੰਟਰੋਲ ਕ੍ਰਮ, ਪ੍ਰਗਤੀ ਪੱਟੀਆਂ, ਦੁਹਰਾਈਆਂ ਲਾਈਨਾਂ ਅਤੇ ਗੈਰ-ਕਾਰਵਾਈਯੋਗ ਸ਼ੋਰ ਹਟਾਉਂਦਾ ਹੈ
ਅਸਫਲਤਾਵਾਂ, ਗਲਤੀਆਂ, ਚੇਤਾਵਨੀਆਂ, ਬਦਲੀਆਂ ਫਾਈਲਾਂ, ਸੰਖੇਪਾਂ ਅਤੇ ਲੰਮੀ ਆਉਟਪੁੱਟ ਦੇ ਅੰਤਲੇ ਹਿੱਸੇ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ
ਭਰੋਸਾ-ਗੇਟਿਡ ਪ੍ਰੋਜੈਕਟ ਫਿਲਟਰਾਂ, ਗਲੋਬਲ ਫਿਲਟਰਾਂ ਅਤੇ ਵਿਕਲਪਿਕ ਸੰਪਾਦਿਤ ਕੱਚੀ-ਆਉਟਪੁੱਟ ਰਿਕਵਰੀ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ

ਇਸ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ: ਸ਼ੈੱਲ, ਬਿਲਡ, ਟੈਸਟ, git, grep ਅਤੇ ਫਾਈਲ-ਆਉਟਪੁੱਟ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟਾਂ ਵਾਲੇ ਏਜੰਟ ਸੈਸ਼ਨ।

ਸਟੈਕਡ ਮੋਡ (78-95% ਯੋਗ ਰੇਂਜ)

ਸਟੈਕਡ ਮੋਡ ਕਈ ਕੰਪ੍ਰੈਸ਼ਨ ਇੰਜਣਾਂ ਨੂੰ ਇੱਕ ਨਿਰਧਾਰਿਤ ਕ੍ਰਮ ਵਿੱਚ ਚਲਾਉਂਦਾ ਹੈ। ਡਿਫੌਲਟ ਪਾਈਪਲਾਈਨ ਇਹ ਹੈ:

RTK -> Caveman

ਇਹ ਕ੍ਰਮ ਪਹਿਲਾਂ ਟਰਮੀਨਲ/ਟੂਲ ਆਉਟਪੁੱਟ ਨੂੰ ਸੰਖੇਪ ਰੱਖਦਾ ਹੈ, ਫਿਰ ਬਾਕੀ ਕੁਦਰਤੀ-ਭਾਸ਼ਾ ਪ੍ਰੌਮਪਟ 'ਤੇ Caveman ਦਾ ਅਰਥਮੂਲਕ ਸੰਖੇਪੀਕਰਨ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਸਟੈਕਡ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਗਲੋਬਲ ਤੌਰ 'ਤੇ ਜਾਂ ਰਾਊਟਿੰਗ ਕੰਬੋਜ਼ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤੇ ਕੰਪ੍ਰੈਸ਼ਨ ਕੰਬੋਜ਼ ਰਾਹੀਂ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇਸ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ: ਵੱਡੇ ਟੂਲ ਲੌਗਾਂ ਦੇ ਨਾਲ ਮਨੁੱਖੀ ਹਦਾਇਤਾਂ ਜਾਂ ਸਹਾਇਕ ਸੰਖੇਪਾਂ ਵਾਲਾ ਮਿਲਿਆ-ਜੁਲਿਆ ਸੰਦਰਭ।

ਅੱਪਸਟ੍ਰੀਮ ਬੱਚਤ ਦਾ ਗਣਿਤ

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 ਬੱਚਤ) * (1 - Caveman ਇਨਪੁੱਟ ਬੱਚਤ)
average  = 1 - (1 - 0.80) * (1 - 0.46) = 89.2%
range    = 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, ਸਿਰਲੇਖਾਂ, ਵਰਜਨਾਂ, ਜਾਂ ALL-CAPS ਕੌਂਸਟੈਂਟ ਪਛਾਣਕਰਤਾਵਾਂ ਨੂੰ ਹਟਾ ਜਾਂ ਬਦਲ ਦੇਵੇ।

ਇਹ ਉਮੀਦ ਕੀਤੀ ਗਈ, ਸੁਰੱਖਿਅਤ ਕਾਰਗੁਜ਼ਾਰੀ ਹੈ, ਕੋਈ ਬੱਗ ਨਹੀਂ: ਇੱਕ ਕੋਡਿੰਗ ਸੈਸ਼ਨ ਜੋ ਮੁੱਖ ਤੌਰ 'ਤੇ ਸਾਫ਼ ਫ਼ਾਈਲਾਂ ਨੂੰ ਪੜ੍ਹਦਾ/grep ਕਰਦਾ ਹੈ, ਉਸ ਵਿੱਚ ਕੰਪ੍ਰੈਸ਼ਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਚਾਲੂ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਕੁੱਲ ਬੱਚਤ ਮਾਮੂਲੀ ਹੋਵੇਗੀ, ਜਦਕਿ ਇੱਕ ਸੈਸ਼ਨ ਜੋ ਕਿਸੇ ਅਸਫਲ ਲੂਪ ਜਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਆਉਟਪੁੱਟ ਦੇਣ ਵਾਲੇ ਲਿੰਟਰ ਦਾ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ, ਉਸ ਟ੍ਰੈਫ਼ਿਕ ਉੱਤੇ ਪੂਰਾ 78-95% ਦਾਇਰਾ ਵੇਖੇਗਾ। ਕਿਸੇ ਇੱਕ ਸੈਸ਼ਨ ਦੀ ਘੱਟ ਕੁੱਲ ਬੱਚਤ ਪ੍ਰਤੀਸ਼ਤ ਨੂੰ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਾ ਮੰਨੋ ਕਿ ਕੰਪ੍ਰੈਸ਼ਨ ਗਲਤ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ — ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਮੂਲ ਟੂਲ ਆਉਟਪੁੱਟ ਅਸਲ ਵਿੱਚ ਦੁਹਰਾਇਆ ਹੋਇਆ ਸੀ ਜਾਂ ਨਹੀਂ।

ਟੋਕਨ ਬੱਚਤ ਦਾ ਦ੍ਰਿਸ਼ੀਕਰਨ

ਕੰਪ੍ਰੈਸ਼ਨ ਤੋਂ ਬਿਨਾਂ: 47K ਟੋਕਨ LLM ਨੂੰ ਭੇਜੇ ਗਏ
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% ਬੱਚਤ)

ਸੰਰਚਨਾ

ਡੈਸ਼ਬੋਰਡ

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/ਸਟੈਕਡ ਪੇਲੋਡ ਦਾ ਪੂਰਵਦਰਸ਼ਨ ਕਰੋ
curl -X POST http://localhost:20128/api/compression/preview \
  -H "Content-Type: application/json" \
  -d '{"mode":"rtk","messages":[{"role":"tool","content":"npm test output here"}]}'

# RTK ਫਿਲਟਰ ਪੈਕਾਂ ਦੀ ਸੂਚੀ ਵੇਖੋ
curl http://localhost:20128/api/context/rtk/filters

# ਵਿਕਲਪਿਕ ਕਮਾਂਡ ਮੈਟਾਡੇਟਾ ਨਾਲ ਸਿੱਧੇ RTK ਦੀ ਜਾਂਚ ਕਰੋ
curl -X POST http://localhost:20128/api/context/rtk/test \
  -H "Content-Type: application/json" \
  -d '{"command":"npm test","text":"FAIL tests/example.test.ts\nError: boom"}'

ਕੀ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦਾ ਹੈ

ਕੰਪ੍ਰੈਸ਼ਨ ਇੰਜਣ ਹਮੇਸ਼ਾਂ ਇਹਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦਾ ਹੈ:

✅ ਕੋਡ ਬਲਾਕ (ਫੈਂਸਡ ਅਤੇ ਇਨਲਾਈਨ)
✅ URLs ਅਤੇ ਫ਼ਾਈਲ ਪਾਥ
✅ JSON ਸੰਰਚਨਾਵਾਂ ਅਤੇ ਸੰਰਚਿਤ ਡਾਟਾ
✅ ਆਈਡੈਂਟੀਫਾਇਰ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਕਨੀਕੀ ਟੋਕਨ
✅ ਗਣਿਤਕ ਸਮੀਕਰਨ
✅ ਟੂਲ/ਫੰਕਸ਼ਨ ਕਾਲ ਪਰਿਭਾਸ਼ਾਵਾਂ
✅ ਸਿਸਟਮ ਪ੍ਰੌਂਪਟ (lite ਮੋਡ ਵਿੱਚ)

RTK raw-output ਰਿਕਵਰੀ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਸਥਾਈ ਤੌਰ 'ਤੇ ਸੰਭਾਲਣ ਤੋਂ ਪਹਿਲਾਂ ਆਮ API keys, bearer tokens, Slack tokens, AWS access keys, ਪਾਸਵਰਡਾਂ, ਟੋਕਨਾਂ ਅਤੇ ਸੀਕ੍ਰੇਟਾਂ ਨੂੰ ਰੀਡੈਕਟ ਕਰਦੀ ਹੈ।

ਕੰਪ੍ਰੈਸ਼ਨ ਅੰਕੜੇ

ਹਰ ਕੰਪ੍ਰੈੱਸ ਕੀਤੀ ਬੇਨਤੀ ਵਿੱਚ ਸਰਵਰ ਲੌਗਾਂ ਅੰਦਰ ਅੰਕੜੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ:

{
  "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 (`contextBudget` on `PUT /api/settings/compression`) + ਡੈਸ਼ਬੋਰਡ ਮੋਡ/ਨੀਤੀ ਕੰਟਰੋਲ	✅ ਜਾਰੀ ਕੀਤਾ ਗਿਆ

ਧੰਨਵਾਦ

Standard ਮੋਡ ਦੇ ਕੰਪ੍ਰੈਸ਼ਨ ਨਿਯਮ JuliusBrussee (⭐ 51K+) ਦੇ Caveman ਤੋਂ ਪ੍ਰੇਰਿਤ ਹਨ — ਵਾਇਰਲ "ਜਦੋਂ ਥੋੜ੍ਹੇ ਟੋਕਨਾਂ ਨਾਲ ਕੰਮ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਬਹੁਤ ਸਾਰੇ ਟੋਕਨ ਕਿਉਂ ਵਰਤਣੇ" ਪ੍ਰੋਜੈਕਟ। Caveman ~75% ਘੱਟ ਆਉਟਪੁੱਟ ਟੋਕਨਾਂ, ਬੈਂਚਮਾਰਕ ਵਿੱਚ ਔਸਤ 65% ਆਉਟਪੁੱਟ ਬਚਤ, 22-87% ਆਉਟਪੁੱਟ ਰੇਂਜ ਅਤੇ ਇੱਕ ~46% ਇਨਪੁੱਟ-ਕੰਪ੍ਰੈਸ਼ਨ ਟੂਲ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ।

RTK ਮੋਡ RTK AI ਦੇ RTK - Rust Token Killer ਤੋਂ ਪ੍ਰੇਰਿਤ ਹੈ — ਟਰਮੀਨਲ, ਬਿਲਡ, ਟੈਸਟ, git ਅਤੇ ਟੂਲ-ਆਉਟਪੁੱਟ ਫਿਲਟਰਿੰਗ ਲਈ ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਵਾਲਾ ਕਮਾਂਡ-ਆਉਟਪੁੱਟ ਕੰਪ੍ਰੈਸ਼ਨ ਪ੍ਰੋਜੈਕਟ। RTK 60-90% ਬਚਤ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਇਸਦੇ README ਦੇ ਨਮੂਨਾ ਸੈਸ਼ਨ ਵਿੱਚ ~80% ਬਚਤ ਦਿਖਾਈ ਗਈ ਹੈ।

ਉੱਨਤ ਕੰਪ੍ਰੈਸ਼ਨ ਸਿਸਟਮ

7 ਮਿਆਰੀ ਮੋਡਾਂ ਤੋਂ ਇਲਾਵਾ, OmniRoute ਵਿੱਚ ਕਈ ਉੱਨਤ ਕੰਪ੍ਰੈਸ਼ਨ ਸਿਸਟਮ ਸ਼ਾਮਲ ਹਨ ਜੋ ਸੰਦਰਭ ਦੇ ਆਧਾਰ 'ਤੇ ਆਪਣੇ ਆਪ ਕੰਮ ਕਰਦੇ ਹਨ।

ਕੈਸ਼-ਅਵੇਅਰ ਕੰਪ੍ਰੈਸ਼ਨ

ਕੁਝ ਪ੍ਰਦਾਤਾ (ਜਿਵੇਂ ਕਿ ਪ੍ਰੌਂਪਟ ਕੈਸ਼ਿੰਗ ਵਾਲਾ Anthropic) ਪ੍ਰੌਂਪਟ ਕੈਸ਼ਿੰਗ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਉਹ ਲਾਗਤ ਅਤੇ ਲੇਟੈਂਸੀ ਘਟਾਉਣ ਲਈ ਪ੍ਰੌਂਪਟ ਦੇ ਕੁਝ ਹਿੱਸਿਆਂ ਨੂੰ ਕੈਸ਼ ਕਰ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਕੈਸ਼ਿੰਗ ਸਮਰੱਥ ਹੁੰਦੀ ਹੈ, ਤਾਂ 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"
    }
  }
}

ਆਉਟਪੁੱਟ ਸ਼ੈਲੀਆਂ (ਕੈਟਾਲੌਗ)

ਉੱਪਰ ਦਿੱਤਾ ਕੇਵਮੈਨ ਆਉਟਪੁੱਟ ਮੋਡ ਪੁਰਾਣਾ ਸਿੰਗਲ-ਸਟਾਈਲ ਪਾਥ ਹੈ। ਫੇਜ਼ 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, stacked, APIs, MCP, ਡੈਸ਼ਬੋਰਡ
ਕੰਪ੍ਰੈਸ਼ਨ ਨਿਯਮਾਂ ਦਾ ਫਾਰਮੈਟ — JSON ਰੂਲ-ਪੈਕ ਫਾਰਮੈਟ
ਕੰਪ੍ਰੈਸ਼ਨ ਭਾਸ਼ਾ ਪੈਕ — ਭਾਸ਼ਾ-ਵਿਸ਼ੇਸ਼ Caveman ਨਿਯਮ

55 KiB Raw Blame History Unescape Escape

🗜️ Prompt Compression Guide — OmniRoute (ਪੰਜਾਬੀ)

ਸੰਖੇਪ ਜਾਣਕਾਰੀ

ਕੰਪ੍ਰੈਸ਼ਨ ਮੋਡ

ਬੰਦ

ਲਾਈਟ ਮੋਡ (~15% ਬਚਤ, <1ms ਲੇਟੈਂਸੀ)

ਸਟੈਂਡਰਡ ਮੋਡ (~30% ਬਚਤ)

ਅਗਰੈਸਿਵ ਮੋਡ (~50% ਬਚਤ)

ਅਲਟਰਾ ਮੋਡ (~75% ਬਚਤ)

RTK ਮੋਡ (60-90% ਅੱਪਸਟ੍ਰੀਮ ਰੇਂਜ)

ਸਟੈਕਡ ਮੋਡ (78-95% ਯੋਗ ਰੇਂਜ)

ਅੱਪਸਟ੍ਰੀਮ ਬੱਚਤ ਦਾ ਗਣਿਤ

"ਯੋਗ" ਹੋਣ ਦਾ ਅਸਲ ਅਰਥ

ਟੋਕਨ ਬੱਚਤ ਦਾ ਦ੍ਰਿਸ਼ੀਕਰਨ

ਸੰਰਚਨਾ

ਡੈਸ਼ਬੋਰਡ

ਪ੍ਰਤੀ-ਕੰਬੋ ਓਵਰਰਾਈਡ

ਪ੍ਰਤੀ-ਬੇਨਤੀ ਓਵਰਰਾਈਡ

API

ਕੀ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦਾ ਹੈ

ਕੰਪ੍ਰੈਸ਼ਨ ਅੰਕੜੇ

ਪੜਾਅ ਰੋਡਮੈਪ

ਧੰਨਵਾਦ

ਉੱਨਤ ਕੰਪ੍ਰੈਸ਼ਨ ਸਿਸਟਮ

ਕੈਸ਼-ਅਵੇਅਰ ਕੰਪ੍ਰੈਸ਼ਨ

ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਕੋਡ ਉਦਾਹਰਨ

ਕਦੋਂ ਵਰਤਣਾ ਹੈ

ਪ੍ਰਗਤੀਸ਼ੀਲ ਏਜਿੰਗ

ਕੋਡ ਉਦਾਹਰਨ

ਕਦੋਂ ਵਰਤਣਾ ਹੈ

ਕੇਵਮੈਨ ਆਉਟਪੁੱਟ ਮੋਡ

ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਕਦੋਂ ਵਰਤਣਾ ਹੈ

ਆਉਟਪੁੱਟ ਸ਼ੈਲੀਆਂ (ਕੈਟਾਲੌਗ)

ਇੰਜੈਕਸ਼ਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਸਮਰੱਥ ਕਿਵੇਂ ਕਰਨਾ ਹੈ

ਟੂਲ ਨਤੀਜਾ ਕੰਪ੍ਰੈਸ਼ਨ

ਕਦੋਂ ਵਰਤਣਾ ਹੈ

ਸਟੈਕਡ ਪਾਈਪਲਾਈਨ

ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਕਦੋਂ ਵਰਤਣਾ ਹੈ

ਕੰਪ੍ਰੈਸ਼ਨ ਕੌਂਬੋ ਓਵਰਰਾਈਡ

ਇਹ ਵੀ ਵੇਖੋ

55 KiB

Raw Blame History