# 🗜️ 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) · 🇵🇭 [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) · 🇮🇳 [te](../../../te/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 ਕੰਪ੍ਰੈਸ਼ਨ ਭਾਗ](../README.md#%EF%B8%8F-prompt-compression--save-15-95-eligible-tokens-automatically) ਵੇਖੋ।

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

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

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

---

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

### ਬੰਦ

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

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

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

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

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

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

[Caveman](https://github.com/JuliusBrussee/caveman) ਤੋਂ ਪ੍ਰੇਰਿਤ — ਅਰਥ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋਏ ਫ਼ਾਲਤੂ ਸ਼ਬਦ ਅਤੇ ਬੇਲੋੜੀ ਵਿਸਤ੍ਰਿਤ ਵਾਕ-ਰਚਨਾ ਹਟਾਉਂਦਾ ਹੈ:

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

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

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

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

- **ਸੁਨੇਹਾ ਏਜਿੰਗ** — ਪੁਰਾਣੇ ਸੁਨੇਹੇ ਕ੍ਰਮਵਾਰ ਵੱਧ ਕੰਪ੍ਰੈੱਸ ਹੁੰਦੇ ਜਾਂਦੇ ਹਨ
- **ਟੂਲ ਨਤੀਜਾ ਕੰਪ੍ਰੈਸ਼ਨ** — ਲੰਮੇ ਟੂਲ ਆਉਟਪੁੱਟ ਨੂੰ ਕੱਟਿਆ ਜਾਂ ਹਟਾਇਆ ਜਾਂਦਾ ਹੈ (ਪਹਿਲੀਆਂ/ਆਖ਼ਰੀ ਲਾਈਨਾਂ,
  ਮੇਲ ਖਾਂਦੀਆਂ ਲਾਈਨਾਂ ਦੀ ਫਿਲਟਰਿੰਗ, JSON ਕੁੰਜੀਆਂ ਦਾ ਸੰਕੁਚਨ)
- **ਸੰਰਚਨਾਤਮਕ ਅਖੰਡਤਾ ਸੁਰੱਖਿਆ** — ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ `tool_use` + `tool_result` ਜੋੜੇ ਇਕਸਾਰ ਰਹਿਣ
- **ਸੰਦਰਭ ਵਿੰਡੋ ਜਾਗਰੂਕਤਾ** — ਹਰ ਮਾਡਲ ਦੀ ਟੋਕਨ ਸੀਮਾ ਦਾ ਆਦਰ ਕਰਦੀ ਹੈ

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

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

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

- **ਹਿਊਰਿਸਟਿਕ ਛਾਂਟੀ** — ਗੱਦ ਦੀ ਸਕੋਰ-ਅਧਾਰਿਤ ਟੋਕਨ ਛਾਂਟੀ
- **ਸੰਰਚਨਾ ਦੀ ਸੰਭਾਲ** — ਫੈਂਸ ਕੀਤੇ ਕੋਡ ਬਲਾਕ, ਇਨਲਾਈਨ ਕੋਡ, URLs ਅਤੇ ਪਛਾਣਕਰਤਾਵਾਂ ਨੂੰ
  ਟੌਮਸਟੋਨ ਕਰਕੇ ਮੁੜ ਸ਼ਬਦ-ਬ-ਸ਼ਬਦ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਕਦੇ ਵੀ ਛਾਂਟਿਆ ਨਹੀਂ ਜਾਂਦਾ
- **ਵਿਕਲਪਿਕ SLM ਟੀਅਰ** — ਸੰਰਚਿਤ ਹੋਣ 'ਤੇ ਇੱਕ ਛੋਟਾ ਲੋਕਲ ਮਾਡਲ ਛਾਂਟੀ ਨੂੰ ਹੋਰ ਸੁਧਾਰ ਸਕਦਾ ਹੈ
- ਅਗਰੈਸਿਵ ਮੋਡ ਤੋਂ ਸੁਤੰਤਰ: ਇਹ ਸੁਨੇਹਾ ਏਜਿੰਗ, ਟੂਲ-ਨਤੀਜਾ ਕੰਪ੍ਰੈਸ਼ਨ
  ਜਾਂ ਫਾਲਬੈਕ ਸੰਖੇਪੀਕਰਨ ਨਹੀਂ ਚਲਾਉਂਦਾ (ਸਿਰਫ਼ SLM-ਟੀਅਰ ਦੀ ਅਸਫਲਤਾ ਹੀ ਫਾਲਬੈਕ ਪਾਸ ਨੂੰ
  ਅਗਰੈਸਿਵ ਰਾਹੀਂ ਭੇਜ ਸਕਦੀ ਹੈ)

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

### 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 ਅਤੇ ਫਾਈਲ-ਆਉਟਪੁੱਟ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟਾਂ ਵਾਲੇ ਏਜੰਟ ਸੈਸ਼ਨ।

### ਸਟੈਕਡ ਮੋਡ (78-95% ਯੋਗ ਸੀਮਾ)

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

```txt
RTK -> Caveman
```

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

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

---

## ਅੱਪਸਟ੍ਰੀਮ ਬੱਚਤ ਦਾ ਹਿਸਾਬ

OmniRoute ਦੋ ਸਰੋਤਾਂ ਤੋਂ ਹੋਣ ਵਾਲੀ ਕੰਪ੍ਰੈਸ਼ਨ ਬੱਚਤ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ: ਅੱਪਸਟ੍ਰੀਮ ਪ੍ਰੋਜੈਕਟ ਬੈਂਚਮਾਰਕ ਅਤੇ
OmniRoute ਦੀ ਆਪਣੀ ਇੰਜਣ ਰਚਨਾ।

| ਸਰੋਤ    | ਇੱਥੇ ਵਰਤਿਆ ਗਿਆ ਅੱਪਸਟ੍ਰੀਮ README ਅੰਕ                                                                      |
| ------- | -------------------------------------------------------------------------------------------------------- |
| Caveman | `~75%` ਘੱਟ ਆਉਟਪੁੱਟ ਟੋਕਨ, `65%` ਬੈਂਚਮਾਰਕ ਔਸਤ ਆਉਟਪੁੱਟ ਬੱਚਤ, `22-87%` ਰੇਂਜ, ਅਤੇ `~46%` ਇਨਪੁੱਟ ਕੰਪ੍ਰੈਸ਼ਨ ਟੂਲ |
| RTK     | ਕਮਾਂਡ ਆਉਟਪੁੱਟ ਵਿੱਚ `60-90%` ਬੱਚਤ; ਨਮੂਨਾ ਸੈਸ਼ਨ `~118,000 -> ~23,900` ਟੋਕਨ, ਜਾਂ `79.7%` ਬਚਾਏ (`~80%`)      |

ਓਵਰਲੈਪ ਹੋਣ ਵਾਲੇ ਟੂਲ/ਕਾਂਟੈਕਸਟ ਪੇਲੋਡਾਂ ਲਈ, ਮੂਲ OmniRoute ਕੌਂਬੋ ਇੰਜਣਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸਟੈਕ ਕਰਦਾ ਹੈ:

```txt
RTK -> Caveman
```

ਸੰਯੁਕਤ ਬੱਚਤ ਗੁਣਾਤਮਕ ਹੈ, ਜੋੜਾਤਮਕ ਨਹੀਂ:

```txt
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%
```

ਇਹ `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 ਕਰਦਾ ਹੈ,
ਕੰਪ੍ਰੈਸ਼ਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਰੱਥ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਕੁੱਲ ਬੱਚਤ ਘੱਟ ਦੇਖੇਗਾ, ਜਦਕਿ ਇੱਕ ਅਜਿਹਾ ਸੈਸ਼ਨ ਜੋ ਅਸਫਲ ਹੋ ਰਹੇ
ਲੂਪ ਜਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਆਉਟਪੁੱਟ ਦੇਣ ਵਾਲੇ linter ਨਾਲ ਟਕਰਾਉਂਦਾ ਹੈ, ਉਸ ਟ੍ਰੈਫਿਕ ਉੱਤੇ ਪੂਰੀ 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 ਸੁਰੱਖਿਆ ਸੈਟਿੰਗਾਂ ਅਤੇ ਫਿਲਟਰ ਕੈਟਾਲਾਗ
- **ਕੰਪ੍ਰੈਸ਼ਨ ਕੰਬੋ** — ਰਾਊਟਿੰਗ ਕੰਬੋਜ਼ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤੀਆਂ ਨਾਮਿਤ ਇੰਜਣ ਪਾਈਪਲਾਈਨਾਂ
- **ਆਟੋ-ਟ੍ਰਿਗਰ ਥ੍ਰੈਸ਼ਹੋਲਡ** — ਟੋਕਨ ਗਿਣਤੀ ਦੇ ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੋਂ ਵੱਧ ਜਾਣ 'ਤੇ ਆਪਣੇ-ਆਪ ਕੰਪ੍ਰੈਸ਼ਨ ਚਾਲੂ ਕਰੋ

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

`Dashboard → Context & Cache → Compression Combos` ਵਿੱਚ, ਕਿਸੇ ਰਾਊਟਿੰਗ ਕੰਬੋ ਨੂੰ ਇੱਕ ਕੰਪ੍ਰੈਸ਼ਨ ਕੰਬੋ ਨਿਰਧਾਰਤ ਕਰੋ:

```txt
Combo: "free-tier-fallback"
  Compression Combo: "coding-agent-stack"
  Pipeline: RTK -> Caveman
  Targets:
    1. if/kimi-k2.7-code
    2. if/qwen3.8-max-preview
```

ਇਸ ਨਾਲ ਤੁਸੀਂ ਭੁਗਤਾਨਸ਼ੁਦਾ ਸਬਸਕ੍ਰਿਪਸ਼ਨਾਂ 'ਤੇ ਲਾਈਟ ਮੋਡ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋਏ ਮੁਫ਼ਤ/ਕੋਡਿੰਗ ਪ੍ਰਦਾਤਾਵਾਂ 'ਤੇ ਸਟੈਕਡ ਕੰਪ੍ਰੈਸ਼ਨ ਵਰਤ ਸਕਦੇ ਹੋ।

ਇਹ "ਪ੍ਰਤੀ-ਕੰਬੋ ਓਵਰਰਾਈਡ" ਅਸਾਈਨਮੈਂਟ **ਰਾਊਟਿੰਗ-ਕੰਬੋ ਕੰਪ੍ਰੈਸ਼ਨ ਮੋਡ** ਓਵਰਰਾਈਡ (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` ਬੇਨਤੀ ਹੈਡਰ ਭੇਜੋ। ਇਸ ਦੀ ਤਰਜੀਹ ਸਭ ਤੋਂ ਉੱਚੀ ਹੈ — ਇਹ ਰਾਊਟਿੰਗ-ਕੰਬੋ ਓਵਰਰਾਈਡ, ਸਰਗਰਮ ਪ੍ਰੋਫਾਈਲ, ਆਟੋ-ਟ੍ਰਿਗਰ ਅਤੇ ਪੈਨਲ ਡਿਫਾਲਟ ਤੋਂ ਉੱਪਰ ਹੈ। ਅਣਜਾਣ ਮੁੱਲਾਂ ਨੂੰ ਅਣਡਿੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਬੇਨਤੀ ਕਦੇ ਵੀ ਰੱਦ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ) ਅਤੇ ਗਲੋਬਲ ਮਾਸਟਰ ਸਵਿੱਚ ਫਿਰ ਵੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ: ਜਦੋਂ ਕੰਪ੍ਰੈਸ਼ਨ ਗਲੋਬਲ ਤੌਰ 'ਤੇ ਬੰਦ ਹੋਵੇ, ਤਾਂ ਹੈਡਰ ਇਸ ਨੂੰ ਚਾਲੂ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਮੁੱਲ:

| ਮੁੱਲ          | ਪ੍ਰਭਾਵ                                                                                                      |
| ------------- | ----------------------------------------------------------------------------------------------------------- |
| `off`         | ਇਸ ਬੇਨਤੀ ਲਈ ਕੋਈ ਕੰਪ੍ਰੈਸ਼ਨ ਨਹੀਂ।                                                                             |
| `default`     | ਪੈਨਲ ਤੋਂ ਪ੍ਰਾਪਤ ਡਿਫਾਲਟ ਪ੍ਰੋਫਾਈਲ (ਸਰਗਰਮ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਅਣਡਿੱਠਾ ਕਰਦਾ ਹੈ)। ਲੌਸੀ ਇੰਜਣ ਬੰਦ ਰਹਿੰਦੇ ਹਨ।              |
| `safe`        | ਹੈਡਰ ਨੂੰ ਛੱਡਣ ਦੇ ਸਮਾਨ: ਕੇਵਲ ਡੀਡੁਪ ਅਤੇ ਵ੍ਹਾਈਟਸਪੇਸ ਫੋਲਡਿੰਗ।                                                   |
| `allow-lossy` | ਇਸ ਬੇਨਤੀ ਦੀ ਓਪਰੇਟਰ ਯੋਜਨਾ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖੋ, ਜਿਸ ਵਿੱਚ ਸਾਰਾਂਸ਼, ਪ੍ਰਸੰਗਿਕਤਾ ਫਿਲਟਰ ਅਤੇ ਸ਼ੈਲੀ ਮੁੜ-ਲਿਖਤਾਂ ਸ਼ਾਮਲ ਹਨ। |
| `engine:<id>` | ਸਮਰੱਥ ਹੋਣ 'ਤੇ ਇੱਕ ਇੰਜਣ, ਜਿਵੇਂ `engine:rtk`। ਇਹ ਉਸ ਇੰਜਣ ਲਈ ਪ੍ਰਤੀ-ਬੇਨਤੀ ਔਪਟ-ਇਨ ਹੈ।                            |
| `<combo>`     | ਇੱਕ ਨਾਮਿਤ ਕੰਬੋ, ਜਿਸ ਦਾ ਪਹਿਲਾਂ ਨਾਮ (ਅੱਖਰਾਂ ਦੇ ਕੇਸ ਤੋਂ ਬੇਪਰਵਾਹ), ਫਿਰ id ਰਾਹੀਂ ਮਿਲਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।            |

`allow-lossy`, `engine:<id>`, ਜਾਂ ਕਿਸੇ ਨਾਮਿਤ ਕੰਬੋ ਤੋਂ ਬਿਨਾਂ, ਲੌਸੀ ਇੰਜਣ ਲਾਗੂ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ। ਕੰਪ੍ਰੈਸ਼ਨ ਚਾਲੂ ਹੋਣ 'ਤੇ ਬੇਨਤੀ ਨੂੰ ਫਿਰ ਵੀ ਸੈਸ਼ਨ ਡੀਡੁਪ ਅਤੇ ਵ੍ਹਾਈਟਸਪੇਸ ਫੋਲਡਿੰਗ ਮਿਲਦੀ ਹੈ।

ਲਾਗੂ ਕੀਤੀ ਯੋਜਨਾ ਨੂੰ `X-OmniRoute-Compression: <mode>; source=<source>` ਜਵਾਬ ਹੈਡਰ ਵਿੱਚ ਵਾਪਸ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ, ਜਿੱਥੇ `<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"}'
```

---

## ਕੀ ਸੁਰੱਖਿਅਤ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ

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

- ✅ ਕੋਡ ਬਲਾਕ (ਫੈਂਸਡ ਅਤੇ ਇਨਲਾਈਨ)
- ✅ URLs ਅਤੇ ਫ਼ਾਈਲ ਪਾਥ
- ✅ 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 | ਅਨੁਕੂਲੀ ਕਾਂਟੈਕਸਟ-ਬਜਟ ("dial") — ਕੰਪਿਊਟ ਇੰਜਣ + API (`contextBudget` on `PUT /api/settings/compression`) + ਡੈਸ਼ਬੋਰਡ ਮੋਡ/ਨੀਤੀ ਕੰਟਰੋਲ | ✅ ਜਾਰੀ ਕੀਤਾ |

---

## ਧੰਨਵਾਦ

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` ਅਤੇ `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`
  ਬੈਂਡ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਹੁੰਦੀ (`light`, `verbatim` ਦੇ ਬਰਾਬਰ ਹੈ)।

#### ਕੋਡ ਉਦਾਹਰਨ

```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` ਪਹਿਲਾਂ ਬੈਕਵਰਡ-ਕੰਪੈਟੀਬਿਲਟੀ ਸ਼ਿਮ
(`resolveOutputStyleSelection()` ਜੋ
`open-sse/services/compression/outputStyles/backCompat.ts` ਵਿੱਚ ਹੈ) ਨਾਲ ਚੋਣ ਦਾ ਨਿਰਧਾਰਨ ਕਰਦਾ ਹੈ, ਜੋ `outputStyles`
ਖਾਲੀ ਹੋਣ ਵੇਲੇ ਸਮਰੱਥ `cavemanOutputMode` ਨੂੰ
`cavemanOutputMode.intensity` 'ਤੇ `terse-prose` ਆਉਟਪੁੱਟ ਸਟਾਈਲ ਨਾਲ ਮੈਪ ਕਰਦਾ ਹੈ (ਹੇਠਾਂ ਬੈਕਵਰਡ-ਕੰਪੈਟੀਬਿਲਟੀ ਵੇਖੋ); ਇੱਕ ਗੈਰ-ਖਾਲੀ `outputStyles`
ਚੋਣ ਜਿਵੇਂ ਹੈ ਤਿਵੇਂ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਫਿਰ `cavemanOutputMode.enabled` ਅਤੇ `intensity` ਦਾ ਕੋਈ
ਪ੍ਰਭਾਵ ਨਹੀਂ ਹੁੰਦਾ, ਜਦਕਿ ਇਸਦਾ `autoClarity` ਟੌਗਲ ਫਿਰ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। `outputMode.ts` ਵਿੱਚ
ਹਦਾਇਤ ਟੈਕਸਟ (`CAVEMAN_INSTRUCTION_BY_LANGUAGE`), ਸਮੱਗਰੀ ਬਾਈਪਾਸ ਅਤੇ
ਉਹ ਪਲੇਸਮੈਂਟ ਹੈਲਪਰ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇੰਜੈਕਸ਼ਨ ਵਰਤਦਾ ਹੈ; ਇਸਦੇ ਆਪਣੇ `applyCavemanOutputMode()` ਇੰਜੈਕਟਰ ਦਾ ਕੋਈ
ਪ੍ਰੋਡਕਸ਼ਨ ਕਾਲਰ ਨਹੀਂ ਹੈ।

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

ਇਹ ਮੋਡ ਇਨਪੁੱਟ ਨੂੰ ਸੰਕੁਚਿਤ ਨਹੀਂ ਕਰਦਾ। ਇਹ system prompt ਵਿੱਚ ਇੱਕ ਹਦਾਇਤ ਬਲਾਕ ਜੋੜਦਾ ਹੈ
(ਹੇਠਾਂ ਇੰਜੈਕਸ਼ਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਵੇਖੋ), ਅਤੇ ਬੇਨਤੀ ਲਈ ਚੁਣਿਆ ਗਿਆ ਕੋਈ ਵੀ ਇਨਪੁੱਟ ਕੰਪ੍ਰੈਸ਼ਨ ਮੋਡ
ਫਿਰ ਵੀ ਉਸ body ਉੱਤੇ ਬਾਅਦ ਵਿੱਚ ਚੱਲਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਹੁਣ ਇਹ ਬਲਾਕ ਸ਼ਾਮਲ ਹੈ। ਹਰ ਪੱਧਰ ਦੇ ਅੰਤ ਵਿੱਚ ਆਉਣ ਵਾਲੀ ਸਾਂਝੀ
boundaries clause ਤੋਂ ਪਹਿਲਾਂ, ਅੰਗਰੇਜ਼ੀ `full` ਪੱਧਰ ਇਹ ਕਹਿੰਦਾ ਹੈ:

> "ਸਿਆਣੇ ਗੁਫ਼ਾਵਾਸੀ ਵਾਂਗ ਸੰਖੇਪ ਜਵਾਬ ਦਿਓ। articles (a/an/the), filler (just/really/basically/actually/simply), ਸ਼ਿਸ਼ਟਾਚਾਰਕ ਸ਼ਬਦ ਅਤੇ ਅਨਿਸ਼ਚਿਤਤਾ ਦਰਸਾਉਣ ਵਾਲੇ ਸ਼ਬਦ ਹਟਾਓ। ਵਾਕਾਂਸ਼ ਠੀਕ ਹਨ। ਛੋਟੇ ਸਮਾਨਾਰਥਕ ਸ਼ਬਦ ਵਰਤੋ (extensive ਦੀ ਥਾਂ big, implement ਦੀ ਥਾਂ fix)। ਸਾਰਾ ਤਕਨੀਕੀ ਤੱਤ, code, errors, URLs, identifiers ਬਿਲਕੁਲ ਸਹੀ ਰੱਖੋ।"

ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਇਨ੍ਹਾਂ ਲਈ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ:

- Code generation (ਵਧੇਰੇ ਸੰਖੇਪ ਆਉਟਪੁੱਟ = ਘੱਟ tokens)
- ਤੁਰੰਤ Q&A (ਵਿਸਤ੍ਰਿਤ ਵਿਆਖਿਆਵਾਂ ਦੀ ਲੋੜ ਨਹੀਂ)
- Batch processing (throughput ਵੱਧ ਤੋਂ ਵੱਧ ਕਰੋ)

#### ਕਦੋਂ ਵਰਤਣਾ ਹੈ

Caveman output mode **opt-in** ਹੈ। ਕੰਪ੍ਰੈਸ਼ਨ ਚਾਲੂ ਹੋਣ 'ਤੇ (`enabled: true`, Compression Settings ਪੰਨੇ ਉੱਤੇ master toggle
ਚਾਲੂ), ਇਸਨੂੰ `cavemanOutputMode.enabled` ਨਾਲ ਚਾਲੂ ਕਰੋ; `intensity`
`lite`, `full` ਜਾਂ `ultra` ਚੁਣਦਾ ਹੈ:

```json
{
  "enabled": true,
  "cavemanOutputMode": {
    "enabled": true,
    "intensity": "full"
  }
}
```

ਕਿਸੇ compression combo ਦਾ **Output Mode** toggle (`outputMode`, `outputModeIntensity` ਵਿੱਚ ਪੱਧਰ)
ਉਨ੍ਹਾਂ ਬੇਨਤੀਆਂ ਲਈ ਇਹੀ switch ਸੈੱਟ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਉੱਤੇ ਉਹ combo ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ
`omniroute_set_compression_engine` MCP tool ਆਪਣੇ boolean `outputMode`
argument ਰਾਹੀਂ ਇਸਨੂੰ ਲਿਖਦਾ ਹੈ। ਇੱਕ ਗੈਰ-ਖਾਲੀ `outputStyles` ਚੋਣ ਨੂੰ ਇਸ switch ਉੱਤੇ ਤਰਜੀਹ ਮਿਲਦੀ ਹੈ। Dashboard ਵਿੱਚ, **Terse prose** output style ਨੂੰ ਚਾਲੂ ਕਰਨ ਨਾਲ ਉਹੀ ਬਲਾਕ inject ਹੁੰਦਾ ਹੈ (ਹੇਠਾਂ Output
Styles ਵੇਖੋ)।

### Output Styles (ਕੈਟਾਲੌਗ)

ਉੱਪਰ ਦਿੱਤਾ Caveman output mode **legacy single-style path** ਹੈ। Phase 4 ਨੇ ਇਸਨੂੰ
composable output styles ਦੇ ਇੱਕ ਕੈਟਾਲੌਗ ਵਿੱਚ ਆਮ ਕੀਤਾ: `OUTPUT_STYLE_CATALOG`,
`open-sse/services/compression/outputStyles/catalog.ts` ਵਿੱਚ। ਹਰ style ਇੱਕ system-prompt
ਹਦਾਇਤ ਹੈ ਜੋ ਮਾਡਲ ਨੂੰ ਖੁਦ ਘੱਟ ਮਹਿੰਗਾ ਆਉਟਪੁੱਟ ਦੇਣ ਲਈ ਕਹਿੰਦੀ ਹੈ; styles ਨੂੰ
ਇਕੱਠੇ ਚਾਲੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹ catalog ਕ੍ਰਮ ਵਿੱਚ inject ਹੁੰਦੇ ਹਨ।

| Style                          | `id`            | ਇਹ ਕੀ ਕਰਦਾ ਹੈ                                                                                                                                                                                                                                                 | ਹਦਾਇਤ ਦੀਆਂ ਭਾਸ਼ਾਵਾਂ                           |
| ------------------------------ | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- |
| ਸੰਖੇਪ ਗੱਦ                      | `terse-prose`   | Filler/articles/hedging ਹਟਾਓ; ਤਕਨੀਕੀ ਤੱਤ ਬਿਲਕੁਲ ਸਹੀ ਰੱਖੋ। legacy caveman output mode ਵਾਲਾ ਹੀ ਪਾਠ (ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਮੁੜ ਲਿਖਿਆ ਨਹੀਂ)।                                                                                                                        | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi |
| ਘੱਟ code                       | `less-code`     | YAGNI ਪੌੜੀ: ਸਭ ਤੋਂ ਛੋਟਾ ਕਾਰਗਰ ਬਦਲਾਅ, ਬਿਨਾਂ ਮੰਗੀਆਂ abstractions ਨਹੀਂ।                                                                                                                                                                                          | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi |
| Ponytail (ਆਲਸੀ senior dev)     | `ponytail`      | "ਸਭ ਤੋਂ ਵਧੀਆ code ਉਹ ਹੈ ਜੋ ਕਦੇ ਲਿਖਿਆ ਹੀ ਨਾ ਗਿਆ ਹੋਵੇ": reuse > rewrite, root cause > symptom, ਸਭ ਤੋਂ ਛੋਟਾ ਕਾਰਗਰ diff।                                                                                                                                          | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi |
| ਮੈਨੂੰ ADHD ਹੈ (action-first)   | `i-have-adhd`   | ਪਹਿਲਾਂ ਕਾਰਵਾਈ (ਗੱਦ ਤੋਂ ਪਹਿਲਾਂ command/path/snippet), ਨੰਬਰਬੱਧ ਸੀਮਿਤ ਕਦਮ, ਸਿਰਫ਼ ਇੱਕ ਠੋਸ ਅਗਲਾ ਕਦਮ, ਕੋਈ preamble/recap/closers ਨਹੀਂ। [ayghri/i-have-adhd](https://github.com/ayghri/i-have-adhd) (MIT) ਤੋਂ ਅਨੁਕੂਲਿਤ।                                              | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi |
| Antislop UI filter             | `antislop-ui`   | ਹਰ visual technique ਨੂੰ ਮਕਸਦ ਦੀ ਜਾਂਚ ਪਾਸ ਕਰਨੀ ਲਾਜ਼ਮੀ ਹੈ (hierarchy, identity, readability); ਕੋਈ default gradients/glass/glow ਨਹੀਂ, ਸੀਮਿਤ palette, ਕੋਈ template layouts ਨਹੀਂ। ਦੋਵੇਂ antislop styles no-dead-controls / no-fabricated-claims boundary ਜੋੜਦੇ ਹਨ। | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi |
| Antislop copy ਅਤੇ human filter | `antislop-copy` | ਖਾਸ copy (ਕੋਈ em dash, generic CTAs, buzzwords, chatbot closers ਜਾਂ ਘੜੇ ਹੋਏ ਤੱਥ ਨਹੀਂ), ਨਾਲ ਹੀ ਲੋਕਾਂ ਲਈ ਨਿਯਮ: WCAG AA contrast, ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ focus, keyboard reach, empty/loading/error states, mobile reflow।                                               | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi |
| ਸੰਖੇਪ CJK (文言)               | `terse-cjk`     | `full`/`ultra` ਜਵਾਬ Classical Chinese (文言) ਵਿੱਚ; `lite` ਸਿਰਫ਼ function words, ਸ਼ਿਸ਼ਟਾਚਾਰਕ ਸ਼ਬਦਾਂ ਜਾਂ ਸਜਾਵਟ ਤੋਂ ਬਿਨਾਂ ਸੰਖੇਪ ਜਵਾਬ ਮੰਗਦਾ ਹੈ।                                                                                                                   | zh (locale-gated, ਹੇਠਾਂ ਵੇਖੋ)                 |

ਹਰ style ਤਿੰਨ intensity levels — `lite`, `full`, `ultra` — ਨਾਲ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਹਰ level
ਸਾਂਝੀ boundaries clause (`outputMode.ts` ਵਿੱਚ `SHARED_BOUNDARIES`) ਨਾਲ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਜੋ
code blocks, file paths, commands, errors ਅਤੇ URLs ਨੂੰ ਬਿਲਕੁਲ ਸਹੀ ਰੱਖਦਾ ਹੈ। `terse-prose` ਅਤੇ
`terse-cjk` level texts ਉਸ ਸੂਚੀ ਵਿੱਚ identifiers ਵੀ ਜੋੜਦੇ ਹਨ।

`terse-cjk` ਦੋ ਥਾਵਾਂ ਉੱਤੇ `zh` ਲਈ locale-gated ਹੈ। Compression Settings ਪੰਨਾ
ਇਸ ਦੀ row ਸਿਰਫ਼ ਉਦੋਂ ਦਿਖਾਉਂਦਾ ਹੈ ਜਦੋਂ dashboard UI language ਚੀਨੀ (`zh-CN` ਜਾਂ `zh-TW`) ਹੋਵੇ, ਅਤੇ
`applyOutputStyles()` ਇਸਨੂੰ ਸਿਰਫ਼ ਉਦੋਂ inject ਕਰਦਾ ਹੈ ਜਦੋਂ ਬੇਨਤੀ ਦੀ resolved language (ਹੇਠਾਂ Language
selection ਵੇਖੋ) `zh` ਹੋਵੇ। Row ਨੂੰ ਲੁਕਾਉਣ ਨਾਲ saved `terse-cjk` selection ਸਾਫ਼ ਨਹੀਂ ਹੁੰਦੀ:
settings API ਕਿਸੇ ਵੀ style id ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਪੰਨੇ ਉੱਤੇ ਹੋਰ styles ਨੂੰ save ਕਰਨ ਨਾਲ ਇਹ ਬਣੀ ਰਹਿੰਦੀ ਹੈ। ਬੇਨਤੀ ਦੇ
ਸਮੇਂ, `applyOutputStyles()` language check ਹੀ ਇਕੱਲਾ locale gate ਹੈ।

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

`applyOutputStyles()` (`open-sse/services/compression/outputStyles/apply.ts`) ਚੋਣ ਨੂੰ
ਕੈਟਾਲਾਗ ਦੇ ਮੁਕਾਬਲੇ ਹੱਲ ਕਰਦਾ ਹੈ (ਅਣਜਾਣ ids ਅਤੇ locale ਨਾਲ ਮੇਲ ਨਾ ਖਾਣ ਵਾਲੀਆਂ styles ਨੂੰ
ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਇਹ ਕਦੇ ਵੀ ਗਲਤੀ ਨਹੀਂ ਹੁੰਦੀ; ਅਜਿਹੀ ਚੋਣ ਜੋ ਕਿਸੇ style ਤੱਕ ਹੱਲ ਨਹੀਂ ਹੁੰਦੀ,
body ਨੂੰ ਬਿਨਾਂ ਬਦਲੇ ਛੱਡ ਦਿੰਦੀ ਹੈ ਅਤੇ `no_styles` ਵਜੋਂ ਛੱਡੀ ਜਾਂਦੀ ਹੈ), ਚੁਣੀਆਂ ਹੋਈਆਂ ਹਦਾਇਤਾਂ ਨੂੰ
ਕੈਟਾਲਾਗ ਕ੍ਰਮ ਵਿੱਚ ਜੋੜਦਾ ਹੈ,
boundaries clause ਨੂੰ **ਇੱਕ ਵਾਰ** ਜੋੜਦਾ ਹੈ (ਨਾਲ ਹੀ safety clause, `SAFETY_BOUNDARIES` ਜਾਂ ਇਸਦਾ
ਅਨੁਵਾਦ, ਜਦੋਂ `less-code` ਜਾਂ `ponytail` ਚੁਣਿਆ ਗਿਆ ਹੋਵੇ), ਅਤੇ block ਨੂੰ ਇੱਕੋ
idempotency marker (`[OmniRoute Output Styles]`) ਨਾਲ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਮੁੜ ਲਾਗੂ ਕਰਨਾ
ਕੋਈ ਤਬਦੀਲੀ ਨਹੀਂ ਕਰਦਾ। ਜਦੋਂ ਹੱਲ ਕੀਤੀ ਗਈ ਭਾਸ਼ਾ (ਹੇਠਾਂ Language selection ਵੇਖੋ) ਦਾ ਅਨੁਵਾਦ
ਉਪਲਬਧ ਹੋਵੇ, ਤਾਂ ਅੰਗਰੇਜ਼ੀ ਦੀ ਥਾਂ ਸਥਾਨਕ ਬਣਾਈ ਹਦਾਇਤ ਸ਼ਾਮਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਗੈਰ-ਖਾਲੀ `messages` array ਵਾਲੀ body ਉੱਤੇ, idempotency ਜਾਂਚ content bypass ਤੋਂ ਪਹਿਲਾਂ
ਚੱਲਦੀ ਹੈ: ਜਦੋਂ `[OmniRoute Output Styles]` marker ਪਹਿਲਾਂ ਹੀ top-level
`system` field (ਇੱਕ string ਜਾਂ content-block array) ਵਿੱਚ, ਜਾਂ string content ਵਾਲੇ system
message ਵਿੱਚ ਮੌਜੂਦ ਹੋਵੇ, ਤਾਂ body ਨੂੰ `already_applied` ਵਜੋਂ ਬਿਨਾਂ ਬਦਲੇ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ
ਅਤੇ ਕੋਈ keyword ਜਾਂਚ ਨਹੀਂ ਚੱਲਦੀ। ਨਹੀਂ ਤਾਂ content bypass
(`open-sse/services/compression/outputMode.ts` ਵਿੱਚ `shouldBypassCavemanOutputMode()`)
ਆਖਰੀ ਤਿੰਨ messages ਦੇ text ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਭਾਵੇਂ ਉਨ੍ਹਾਂ ਦੀ role ਕੋਈ ਵੀ ਹੋਵੇ, ਅਤੇ ਜਦੋਂ ਉਹ
text ਇਸਦੇ security, irreversible-action ਜਾਂ clarification keywords ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ,
ਜਾਂ ਕ੍ਰਮ-ਸੰਵੇਦਨਸ਼ੀਲ sequence ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ ਤਾਂ ਪੂਰੇ turn ਲਈ styles ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ:
`first`, `then`, `after that`, `before`, `rollback` ਜਾਂ `backup`, ਜਿਸ ਤੋਂ ਬਾਅਦ 240
characters ਦੇ ਅੰਦਰ `delete`, `drop`, `migrate`, `deploy` ਜਾਂ `release` ਆਵੇ। bypass ਉਦੋਂ
ਚੱਲਦਾ ਹੈ ਜਦੋਂ **Auto-Clarity Bypass** toggle
(`cavemanOutputMode.autoClarity`, ਮੂਲ ਰੂਪ ਵਿੱਚ ਚਾਲੂ) ਚਾਲੂ ਹੋਵੇ; toggle ਨੂੰ ਬੰਦ ਕਰਨ ਨਾਲ
keyword ਜਾਂਚ ਛੱਡ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

ਜਦੋਂ bypass turn ਨੂੰ ਅੱਗੇ ਜਾਣ ਦਿੰਦਾ ਹੈ, ਤਾਂ `placeSystemInstruction()` (ਉਸੇ file ਵਿੱਚ),
ਜੋ ਕਦੇ ਵੀ ਨਵਾਂ `messages[0]` ਨਹੀਂ ਬਣਾਉਂਦਾ, block ਨੂੰ ਹੇਠਾਂ ਦਿੱਤਿਆਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ
ਮਿਲਣ ਵਾਲੀ ਥਾਂ ਉੱਤੇ ਰੱਖਦਾ ਹੈ:

1. string content ਵਾਲਾ ਸ਼ੁਰੂਆਤੀ system message: block ਨੂੰ ਇਸਦੇ text ਤੋਂ ਬਾਅਦ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ।
2. top-level `system` field: block ਨੂੰ string ਦੇ text ਤੋਂ ਬਾਅਦ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਜਾਂ
   content-block array ਵਿੱਚ ਨਵੇਂ text block ਵਜੋਂ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
3. string content ਵਾਲਾ ਬਾਅਦ ਵਿੱਚ ਆਉਣ ਵਾਲਾ ਪਹਿਲਾ system message: block ਨੂੰ ਇਸਦੇ
   text ਤੋਂ ਬਾਅਦ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ।
4. ਉਪਰੋਕਤ ਵਿੱਚੋਂ ਕੋਈ ਨਹੀਂ: block ਨੂੰ `messages` ਦੇ ਅੰਤ ਵਿੱਚ ਇੱਕ ਨਵੇਂ system message ਵਿੱਚ
   ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ।

`messages` array ਤੋਂ ਬਿਨਾਂ body ਉੱਤੇ (ਜਾਂ ਖਾਲੀ array ਵਾਲੀ body ਉੱਤੇ), ਕੋਈ content bypass
ਨਹੀਂ ਚੱਲਦਾ ਅਤੇ top-level `system` field ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। block ਨੂੰ string
`instructions` field ਦੇ text ਤੋਂ ਬਾਅਦ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਜਦ ਤੱਕ ਉਸ field ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ
`[OmniRoute Output Styles]` marker ਨਾ ਹੋਵੇ; ਉਸ ਸਥਿਤੀ ਵਿੱਚ body ਨੂੰ
`already_applied` ਵਜੋਂ ਬਿਨਾਂ ਬਦਲੇ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ body ਵਿੱਚ string
`instructions` field ਨਹੀਂ ਹੁੰਦਾ ਪਰ `input` (ਇੱਕ string ਜਾਂ array) ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ,
ਤਾਂ block `instructions` ਬਣ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਸ field ਵਿੱਚ ਮੌਜੂਦ ਕਿਸੇ ਵੀ non-string value
ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਅਜਿਹੀ body ਜਿਸ ਵਿੱਚ ਨਾ string `instructions` field ਹੋਵੇ ਅਤੇ ਨਾ ਹੀ
string ਜਾਂ array `input`, ਉਸਨੂੰ ਬਿਨਾਂ ਬਦਲੇ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ `no_messages` ਵਜੋਂ
skip ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

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

dashboard ਵਿੱਚ: **Compression Context → Compression Settings**
(`/dashboard/context/settings`), Output styles ਭਾਗ: ਹਰ style ਲਈ ਇੱਕ row, ਜਿਸ ਵਿੱਚ on/off
toggle ਅਤੇ level selector ਹੁੰਦਾ ਹੈ। styles ਉਦੋਂ inject ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ compression ਖੁਦ
ਚਾਲੂ ਹੋਵੇ (page ਦਾ master toggle, `enabled`)। **Auto-Clarity Bypass** toggle
**Caveman** page (`/dashboard/context/caveman`) ਦੇ **Output Mode** card ਵਿੱਚ ਹੈ।
Programmatically, compression config ਚੋਣ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ persist ਕਰਦੀ ਹੈ:

```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 ਵਿੱਚ ਅਨੁਵਾਦ ਹੁੰਦਾ ਹੈ,
ਇਸ ਲਈ ਜਿਸ request ਦੀ resolved language `hu` ਹੋਵੇ, ਉਸਨੂੰ ਉੱਥੇ ਅੰਗਰੇਜ਼ੀ text ਮਿਲਦਾ ਹੈ
ਜਿੱਥੇ legacy injector ਇਸਦਾ Hungarian text ਵਰਤਦਾ ਸੀ।

Output-style language selection (`outputStyles/apply.ts` ਵਿੱਚ
`resolveOutputStyleLanguage()`): `languageConfig.enabled` ਚਾਲੂ ਹੋਣ ਉੱਤੇ, `autoDetect`
request ਦੀ `messages` array ਵਿੱਚ text ਵਾਲੇ ਸਭ ਤੋਂ ਨਵੇਂ user message ਦਾ sample ਲੈਂਦਾ ਹੈ
(string content, ਜਾਂ ਇਸਦੇ content parts ਦਾ `text`) ਅਤੇ ਇਸ ਉੱਤੇ Caveman engine ਦਾ detector
(`detectCompressionLanguage()`) ਚਲਾਉਂਦਾ ਹੈ। Han characters ਅਤੇ ਕੋਈ kana ਨਾ ਰੱਖਣ ਵਾਲੇ
text ਲਈ detector `zh` ਵਾਪਸ ਕਰਦਾ ਹੈ; ਨਹੀਂ ਤਾਂ ਇਹ `it`, `pt-BR`, `es`, `de`,
`fr`, `ru`, `ja`, `hu` ਅਤੇ `id` ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਵੱਧ hint matches ਵਾਲੀ language ਵਾਪਸ ਕਰਦਾ
ਹੈ, ਅਤੇ ਜਦੋਂ ਕੋਈ match ਨਾ ਹੋਵੇ ਤਾਂ `en` ਵਾਪਸ ਕਰਦਾ ਹੈ — ਜਿਸ text ਨੂੰ ਇਹ classify ਨਹੀਂ
ਕਰ ਸਕਦਾ, ਉਸ ਲਈ English ਵਰਤੀ ਜਾਂਦੀ ਹੈ, `defaultLanguage` ਕਦੇ ਨਹੀਂ, ਅਤੇ styles ਦੇ ਨਾਲ
`vi` text ਦਿੱਤਾ ਹੋਣ ਦੇ ਬਾਵਜੂਦ `vi` ਕਦੇ detect ਨਹੀਂ ਹੁੰਦੀ। Responses API body ਆਪਣੇ turns
ਨੂੰ `input` ਵਿੱਚ ਰੱਖਦੀ ਹੈ, ਜਿਸਦਾ sample ਨਹੀਂ ਲਿਆ ਜਾਂਦਾ, ਇਸ ਲਈ ਇਸਨੂੰ ਪਹਿਲਾਂ
`defaultLanguage`, ਫਿਰ English ਮਿਲਦੀ ਹੈ। ਜਦੋਂ `messages` ਵਿੱਚ ਕਿਸੇ user message ਕੋਲ text
ਨਾ ਹੋਵੇ, ਜਾਂ `autoDetect` ਬੰਦ ਹੋਵੇ, ਤਾਂ `defaultLanguage` ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਫਿਰ English।
`languageConfig.enabled` ਬੰਦ ਹੋਣ ਉੱਤੇ language English ਹੁੰਦੀ ਹੈ — ਜਦ ਤੱਕ request ਉੱਤੇ
ਕੋਈ compression combo ਲਾਗੂ ਨਾ ਹੋਵੇ (request ਦੇ routing combo ਨੂੰ assign ਕੀਤਾ combo,
ਜਾਂ built-in stacked pipeline ਲਈ chatCore ਵੱਲੋਂ fallback ਕੀਤਾ default compression
combo): combo ਲਾਗੂ ਕਰਨ ਨਾਲ ਉਸ request ਲਈ `languageConfig.enabled` ਚਾਲੂ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ
`defaultLanguage` ਨੂੰ combo ਦੇ language packs ਤੋਂ set ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਜੇ saved value combo
ਦੇ packs ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਤਾਂ ਉਹੀ, ਨਹੀਂ ਤਾਂ combo ਦਾ ਪਹਿਲਾ pack, ਜੋ ਮੂਲ ਰੂਪ ਵਿੱਚ `en` ਹੁੰਦਾ
ਹੈ), ਜਦਕਿ saved `autoDetect` (ਮੂਲ ਰੂਪ ਵਿੱਚ ਚਾਲੂ) ਫਿਰ ਵੀ ਲਾਗੂ ਰਹਿੰਦਾ ਹੈ। Caveman input
engine ਆਪਣੇ rule-pack ਦੀ language ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਚੁਣਦਾ ਹੈ — ਹਰ text part ਮੁਤਾਬਕ ਅਤੇ,
auto-detect ਬੰਦ ਹੋਣ ਉੱਤੇ, `enabledPacks` ਦੇ ਆਧਾਰ ਉੱਤੇ gated ਹੋ ਕੇ।

ਸ਼ੈਲੀ × ਭਾਸ਼ਾ ਮੈਟ੍ਰਿਕਸ ਨੂੰ
`tests/unit/compression/output-styles-i18n-matrix.test.ts` ਦੁਆਰਾ ਪਿਨ ਕੀਤਾ ਗਿਆ ਹੈ: ਹਰ ਕੈਟਾਲਾਗ ਸ਼ੈਲੀ ਲਈ ਟੈਸਟ ਦੇ `BASELINE_LANGUAGES` ਵਿੱਚ ਇੱਕ
ਐਂਟਰੀ ਲਾਜ਼ਮੀ ਹੈ; ਜਿਹੜੀ ਸ਼ੈਲੀ locale-gated ਨਹੀਂ ਹੈ, ਉਸ ਨਾਲ
pt-BR ਅਨੁਵਾਦ ਭੇਜਣਾ ਲਾਜ਼ਮੀ ਹੈ (locale-gated `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`**: `<path>:<digits>:` ਰੂਪ ਦੀ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਲਾਈਨ ਵਾਲੀ ਸਮੱਗਰੀ,
   ਜਿੱਥੇ ਪਹਿਲੇ ਕੋਲਨ ਤੋਂ ਪਹਿਲਾਂ ਵਾਲੇ ਟੈਕਸਟ ਵਿੱਚ ਕੋਈ whitespace ਨਹੀਂ ਹੁੰਦੀ, ਸਿਰਫ਼ ਉਹੀ ਲਾਈਨਾਂ ਰੱਖਦੀ ਹੈ, ਵੱਧ ਤੋਂ ਵੱਧ
   30, ਜਿਸ ਤੋਂ ਬਾਅਦ ਹੋਰ ਮੇਲਾਂ ਦੀ ਗਿਣਤੀ ਅਤੇ ਮੇਲ ਖਾਂਦੀਆਂ ਫ਼ਾਈਲਾਂ ਦੀ ਸੂਚੀ ਹੁੰਦੀ ਹੈ;
   ਹਰ ਹੋਰ ਲਾਈਨ ਹਟਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਰਣਨੀਤੀ ਨੂੰ ਚਾਲੂ ਕਰਨ ਲਈ ਅਜਿਹੀ ਇੱਕ ਲਾਈਨ ਹੀ ਕਾਫ਼ੀ ਹੈ, ਇਸ ਲਈ
   `12:30:45` ਵਰਗੇ timestamp ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੀ ਲੌਗ ਲਾਈਨ ਵੀ ਗਿਣੀ ਜਾਂਦੀ ਹੈ।
3. **`shellOutput`**: ਉਹ ਆਉਟਪੁੱਟ ਜਿਸ ਵਿੱਚ ANSI CSI sequence (`ESC[` ਤੋਂ ਬਾਅਦ ਅੰਕ ਜਾਂ
   semicolons ਅਤੇ ਫਿਰ ਇੱਕ ਅੱਖਰ, ਜਿਵੇਂ color codes ਵਿੱਚ) ਜਾਂ ਟੈਕਸਟ ਵਿੱਚ ਕਿਤੇ ਵੀ whitespace ਤੋਂ ਪਹਿਲਾਂ `$`
   ਹੋਵੇ, ਉਹ sequences ਗੁਆ ਦਿੰਦੀ ਹੈ (ਹੋਰ escapes, ਜਿਵੇਂ `ESC[?25l` ਜਾਂ
   OSC window-title sequence, ਰੱਖੇ ਜਾਂਦੇ ਹਨ) ਅਤੇ ਆਪਣੀਆਂ ਆਖ਼ਰੀ 50 ਲਾਈਨਾਂ ਰੱਖਦੀ ਹੈ, ਜਦਕਿ ਲਗਾਤਾਰ
   ਦੁਹਰਾਈਆਂ ਲਾਈਨਾਂ ਨੂੰ ਇੱਕ ਵਿੱਚ ਸਮੇਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਕਿਉਂਕਿ ਇਹ ਜਾਂਚ `json` ਅਤੇ `errorMessage` ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਦੀ ਹੈ,
   ਅਜਿਹੇ `$` ਵਾਲੀ JSON ਜਾਂ error ਆਉਟਪੁੱਟ `shellOutput` ਚਾਲੂ ਹੋਣ ਦੌਰਾਨ
   ਉਨ੍ਹਾਂ ਤੱਕ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੀ।
4. **`json`**: 2,000 ਅੱਖਰਾਂ ਤੋਂ ਵੱਧ ਦਾ JSON payload ਜੋ `{` ਜਾਂ `[` ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ (ਵਿਕਲਪਿਕ
   whitespace ਤੋਂ ਬਾਅਦ) ਅਤੇ parse ਹੁੰਦਾ ਹੈ, ਉਸਦਾ ਸਾਰ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ: 7 ਤੋਂ ਵੱਧ items ਵਾਲੀ array
   ਆਪਣੇ ਪਹਿਲੇ 5 ਅਤੇ ਆਖ਼ਰੀ 2 items ਅਤੇ ਆਪਣੀ ਕੁੱਲ ਗਿਣਤੀ ਰੱਖਦੀ ਹੈ, ਅਤੇ object ਆਪਣੀਆਂ ਪਹਿਲੀਆਂ 20
   keys ਰੱਖਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਹਰ nested object ਜਾਂ array value ਨੂੰ `{…N keys}` placeholder ਨਾਲ
   ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ (array ਲਈ, N ਉਸਦੀ length ਹੈ) ਅਤੇ ਪਹਿਲੀਆਂ 20 ਤੋਂ ਬਾਅਦ ਹਟਾਈਆਂ keys ਦੀ ਗਿਣਤੀ ਕਰਨ ਵਾਲਾ
   `_remaining_<N>_keys` marker ਹੁੰਦਾ ਹੈ। Scalar values ਪੂਰੀਆਂ ਕਾਪੀ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ 20 keys
   ਜਾਂ ਇਸ ਤੋਂ ਘੱਟ ਅਤੇ ਬਿਨਾਂ nested values ਵਾਲਾ object ਸਿਰਫ਼ ਦੁਬਾਰਾ indent ਹੁੰਦਾ ਹੈ — minified object ਵਿੱਚ ਅੱਖਰ
   ਵਧ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਹ ਬਦਲਿਆ ਨਹੀਂ ਜਾਂਦਾ।
5. **`errorMessage`**: ਉਹ ਆਉਟਪੁੱਟ ਜਿਸ ਵਿੱਚ ਕਿਤੇ ਵੀ ਅਤੇ ਕਿਸੇ ਵੀ letter case ਵਿੱਚ `error:`,
   `error ` (ਸ਼ਬਦ ਤੋਂ ਬਾਅਦ ਇੱਕ ਸਪੇਸ, ਜਿਵੇਂ `no error found` ਵਿੱਚ), `[error]`,
   `exception:`, `exception `, `[exception]` ਜਾਂ `traceback` ਹੋਵੇ, ਆਪਣੀ ਪਹਿਲੀ ਲਾਈਨ,
   ਅਗਲੀਆਂ 10 ਲਾਈਨਾਂ ਅਤੇ ਆਖ਼ਰੀ 3 ਲਾਈਨਾਂ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰਲੀਆਂ ਲਾਈਨਾਂ ਦੀ ਥਾਂ
   `… [N frames elided] …` marker ਲਗਾਉਂਦੀ ਹੈ। Marker ਸਿਰਫ਼ ਉਦੋਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਪਹਿਲੀ
   ਲਾਈਨ ਤੋਂ ਬਾਅਦ 13 ਤੋਂ ਵੱਧ ਲਾਈਨਾਂ ਹੋਣ, ਇਸ ਲਈ 14 ਜਾਂ ਇਸ ਤੋਂ ਘੱਟ ਲਾਈਨਾਂ ਵਾਲੀ error ਆਉਟਪੁੱਟ ਛੋਟੀ ਨਹੀਂ ਹੁੰਦੀ (12 ਜਾਂ 13 ਲਾਈਨਾਂ ਉੱਤੇ
   ਆਖ਼ਰੀ 3 ਪਹਿਲਾਂ ਹੀ ਰੱਖੀਆਂ ਲਾਈਨਾਂ ਨੂੰ ਦੁਹਰਾਉਂਦੀਆਂ ਹਨ)।

ਕਿਸੇ ਰਣਨੀਤੀ ਦੇ ਮੇਲ ਖਾਣ ਤੋਂ ਬਾਅਦ, ਭਾਵੇਂ ਉਹ ਕੁਝ ਵੀ ਨਾ ਬਚਾਵੇ, ਬਾਅਦ ਦੀਆਂ ਰਣਨੀਤੀਆਂ
ਨਹੀਂ ਅਜ਼ਮਾਈਆਂ ਜਾਂਦੀਆਂ। ਜਦੋਂ ਮੇਲ ਖਾਂਦੀ ਰਣਨੀਤੀ ਕੋਈ ਅਨੁਮਾਨਿਤ tokens ਨਹੀਂ ਬਚਾਉਂਦੀ (ਲੰਬਾਈ ÷ 4, ਉੱਪਰ ਵੱਲ round ਕੀਤੀ) —
ਉਦਾਹਰਨ ਲਈ 25 ਜਾਂ ਇਸ ਤੋਂ ਘੱਟ ਲਾਈਨਾਂ ਵਾਲੀ code-like ਫ਼ਾਈਲ, ਜਾਂ 2,000
ਅੱਖਰਾਂ ਤੋਂ ਵੱਧ ਪਰ 7 ਜਾਂ ਇਸ ਤੋਂ ਘੱਟ items ਵਾਲੀ JSON array — ਤਾਂ aggressive engine ਮੂਲ tool
result ਨੂੰ ਰੱਖਦਾ ਹੈ: ਦੋਵੇਂ callers (`compressAggressive()` ਅਤੇ `compressAnthropicToolResultBlock()`)
`saved` ਦੇ 0 ਜਾਂ ਇਸ ਤੋਂ ਘੱਟ ਹੋਣ ਉੱਤੇ ਮੂਲ ਨੂੰ ਰੱਖਦੇ ਹਨ, ਜਦਕਿ `compressToolResult()` ਖੁਦ ਫਿਰ ਵੀ
ਉਸ ਰਣਨੀਤੀ ਦੀ ਆਉਟਪੁੱਟ ਵਾਪਸ ਕਰਦਾ ਹੈ। Tool-result ਕਦਮ ਅੰਤਿਮ ਫ਼ੈਸਲਾ ਨਹੀਂ ਹੈ:
engine ਦਾ fallback summarizer ਫਿਰ ਵੀ 8,192 ਅੱਖਰਾਂ ਤੋਂ ਲੰਬੇ `tool` ਜਾਂ `function` ਸੁਨੇਹੇ ਨੂੰ
ਛੋਟਾ ਕਰ ਸਕਦਾ ਹੈ (`maxTokensPerMessage`, 2,048, ਗੁਣਾ 4)।

#### ਕਦੋਂ ਵਰਤਣਾ ਹੈ

Tool result compression aggressive engine ਦਾ ਕਦਮ 1 ਹੈ (`open-sse/services/compression/aggressive.ts` ਵਿੱਚ `compressAggressive()`),
ਇਸ ਲਈ ਇਹ Aggressive mode ਵਿੱਚ ਅਤੇ stacked pipeline ਦੇ
`aggressive` ਕਦਮ ਵਿੱਚ ਚੱਲਦਾ ਹੈ। ਇਹ OpenAI-shape `tool` ਅਤੇ `function`
ਸੁਨੇਹਿਆਂ ਅਤੇ Anthropic `tool_result` blocks ਦੇ ਅੰਦਰਲੇ ਟੈਕਸਟ ਨੂੰ ਕੰਪ੍ਰੈੱਸ ਕਰਦਾ ਹੈ। ਹਰ ਰਣਨੀਤੀ ਦਾ
`aggressive.toolStrategies` ਅਧੀਨ ਆਪਣਾ switch ਹੈ, ਅਤੇ ਸਾਰੇ ਮੂਲ ਰੂਪ ਵਿੱਚ ਚਾਲੂ ਹਨ। Dashboard ਵਿੱਚ,
compression ਚਾਲੂ ਹੋਣ ਅਤੇ default mode Aggressive ਹੋਣ ਦੌਰਾਨ switches Caveman ਪੰਨੇ ਦੀ **Advanced** view ਵਿੱਚ ਹੁੰਦੇ ਹਨ।

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

stacked mode **ਕਈ engines ਨੂੰ ਕ੍ਰਮਵਾਰ** ਚਲਾਉਂਦਾ ਹੈ — ਆਮ ਤੌਰ ਉੱਤੇ ਪਹਿਲਾਂ RTK
(tool output ਉੱਤੇ 60-90% ਬਚਤ), ਫਿਰ ਬਾਕੀ ਟੈਕਸਟ ਉੱਤੇ Caveman (~46% input
ਬਚਤ)। ਇਕੱਠੇ ਕਰਨ ਉੱਤੇ, ਇਹ **78-95% ਯੋਗ ਰੇਂਜ** ਬਣਦੀ ਹੈ (ਉੱਪਰ Upstream Savings Math
ਵੇਖੋ): `1 - (1 - 0.60..0.90) × (1 - 0.46)` ਦੀ ਔਸਤ ≈89% ਹੈ।

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

```
ਇਨਪੁੱਟ (1000 tokens)
  → RTK (command-aware filter) → 200 tokens
    → Caveman (filler removal) → 108 tokens
  → ਆਉਟਪੁੱਟ (108 tokens, ~89% ਬਚਤ)
```

#### ਕਦੋਂ ਵਰਤਣਾ ਹੈ

stacked mode ਨੂੰ ਇਨ੍ਹਾਂ ਲਈ ਵਰਤੋ:

- Tool-heavy workflows (agentic coding, research)
- ਲਾਗਤ-ਸੰਵੇਦਨਸ਼ੀਲ batch processing
- ਜਦੋਂ ਤੁਹਾਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ token ਬਚਤ ਦੀ ਲੋੜ ਹੋਵੇ

Stacked pipelines ਨੂੰ global `stackedPipeline` compression
setting ਰਾਹੀਂ, ਜਾਂ routing combo ਨੂੰ ਦਿੱਤੇ named compression combo ਰਾਹੀਂ configure ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਉੱਪਰ
Per-Combo Override ਵੇਖੋ) — auto-combo `modePack` ਰਾਹੀਂ ਨਹੀਂ (ਉਹ field ਸਿਰਫ਼
auto-combo model selection ਨੂੰ ਮੁੜ weight ਕਰਦਾ ਹੈ, ਅਤੇ `stacked` ਕੋਈ ਵੈਧ pack name ਨਹੀਂ ਹੈ)।

---

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

ਵੱਖ-ਵੱਖ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਲਈ ਵਿਹਾਰ ਨੂੰ ਬਾਰੀਕੀ ਨਾਲ ਅਨੁਕੂਲ ਕਰਨ ਵਾਸਤੇ, ਤੁਸੀਂ ਗਲੋਬਲ ਕੰਪ੍ਰੈਸ਼ਨ ਮੋਡ ਨੂੰ **ਹਰੇਕ ਕਾਂਬੋ ਲਈ** ਓਵਰਰਾਈਡ ਕਰ ਸਕਦੇ ਹੋ:

```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, APIs, MCP, ਡੈਸ਼ਬੋਰਡ
- [ਕੰਪ੍ਰੈਸ਼ਨ ਨਿਯਮਾਂ ਦਾ ਫਾਰਮੈਟ](./COMPRESSION_RULES_FORMAT.md) — JSON ਨਿਯਮ-ਪੈਕ ਫਾਰਮੈਟ
- [ਕੰਪ੍ਰੈਸ਼ਨ ਭਾਸ਼ਾ ਪੈਕ](./COMPRESSION_LANGUAGE_PACKS.md) — ਭਾਸ਼ਾ-ਵਿਸ਼ੇਸ਼ Caveman ਨਿਯਮ