OmniRoute/docs/i18n/no/docs/compression/COMPRESSION_GUIDE.md

🗜️ Prompt Compression Guide — OmniRoute (Norsk)

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

---

Spar automatisk 15–95 % på kvalifisert kontekst. For en rask oversikt, se delen om komprimering i README-filen.

Oversikt

OmniRoute implementerer en modulær pipeline for promptkomprimering som kjører proaktivt før forespørsler når oppstrømsleverandører. Dette betyr at tokenbesparelsene skjer transparent — uten at du trenger å endre arbeidsflyten.

Klientforespørsel
  → Valg av komprimeringsstrategi
    → Overstyring via kombinasjon? → Bruk kombinasjonsinnstillingen
    → Terskel for automatisk aktivering? → Bruk automatisk modus
    → Standardmodus? → Bruk global innstilling
    → Av? → Hopp over komprimering
  → Valgt komprimeringsmodus
    → Av: Ingen komprimering
    → Lett: Trygg opprydding av mellomrom/formatering (~15 %)
    → Standard: Fjerning av fyllord med Caveman (~30 %)
    → Aggressiv: Aldring av historikk + oppsummering (~50 %)
    → Ultra: Heuristisk beskjæring + uttynning av kodeblokker (~75 %)
    → RTK: Kommandobevisst filtrering av terminal-/verktøyutdata (60–90 % oppstrømsintervall)
    → Stablet: Ordnet pipeline med flere motorer, vanligvis RTK og deretter Caveman (78–95 % kvalifisert intervall)
  → Komprimert forespørsel → Leverandør

---

Komprimeringsmoduser

Av

Ingen komprimering brukes. Alle meldinger sendes gjennom uendret.

Lett modus (~15 % besparelse, <1 ms ventetid)

Den tryggeste modusen — ingen semantisk endring, bare opprydding av formatering:

Teknikk	Beskrivelse
collapseWhitespace	Slår sammen etterfølgende tomme linjer og avsluttende mellomrom
dedupSystemPrompt	Fjerner dupliserte systemmeldinger
compressToolResults	Komprimerer omfattende verktøy-/funksjonsutdata
removeRedundantContent	Fjerner gjentatte instruksjoner
replaceImageUrls	Forkorter base64-data-URI-er for bilder

Best for: Alltid aktiv bruk og sikkerhetskritiske arbeidsflyter.

Standardmodus (~30 % besparelse)

Inspirert av Caveman — fjerner fyllord og omstendelige formuleringer samtidig som meningen bevares:

• Fjerner fyllord («please», «I think», «basically», «actually»)
• Forkorter omstendelige fraser («in order to» → «to», «as a result of» → «because»)
• Fjerner høflige forbehold («Would you mind...», «If you could possibly...»)
• Over 30 regex-regler tilpasset kodeprompter

Best for: Daglige arbeidsflyter for koding og kostnadsbevisste team.

Aggressiv modus (~50 % besparelse)

Smart historikkhåndtering for lange økter:

• Aldring av meldinger — eldre meldinger komprimeres gradvis
• Oppsummering av verktøyresultater — lange verktøyutdata erstattes med oppsummeringer
• Vern av strukturell integritet — sikrer at par med tool_use + tool_result forblir konsistente
• Bevissthet om kontekstvinduet — tar hensyn til tokengrenser per modell

Best for: Langvarige feilsøkingsøkter og store kodebaser.

Ultra-modus (~75 % besparelse)

Maksimal komprimering for scenarier der tokenbruk er kritisk:

• Heuristisk beskjæring — fjerner meldinger under relevansterskelen
• Uttynning av kodeblokker — komprimerer repetitive kodeeksempler
• Avkorting med binærsøk — finner det optimale avkortingspunktet for kontekstvinduet
• Inkluderer alle funksjonene fra aggressiv modus

Best for: Når du gjentatte ganger når kontekstgrensene.

RTK-modus (60–90 % oppstrømsintervall)

RTK-modus er optimalisert for omfattende verktøyutdata som forekommer i økter med kodeagenter:

• Oppdager kommando-/utdataklasser som git status, git diff, git log, testkjørere, TypeScript/Vite/Webpack-bygg, ESLint/Biome/Prettier, npm-revisjoner/-installasjoner, Docker-logger, infrastrukturutdata og generiske shell-utdata
• Bruker JSON-filterpakker fra open-sse/services/compression/engines/rtk/filters/
• Importerer RTK TOML schema v1-filtre fra prosjektets eller globale filters.toml-filer, med validering av innebygde tester og tillitskontroll for prosjektfiler
• Leveres med 49 innebygde filtre med innebygde verifiseringseksempler
• Fjerner ANSI-kontrollsekvenser, fremdriftsindikatorer, gjentatte linjer og irrelevant støy
• Bevarer feil, advarsler, endrede filer, oppsummeringer og slutten av lange utdata
• Støtter tillitskontrollerte prosjektfiltre, globale filtre og valgfri gjenoppretting av sladdede råutdata

Best for: Agentøkter med shell-, bygge-, test-, git-, grep- og filutdatatranskripsjoner.

Stablet modus (78–95 % kvalifisert intervall)

Stablet modus kjører flere komprimeringsmotorer i en deterministisk rekkefølge. Standard-pipelinen er:

RTK -> Caveman

Denne rekkefølgen komprimerer først terminal-/verktøyutdata og bruker deretter semantisk kondensering med Caveman på den gjenværende prompten i naturlig språk. Stablede pipelines kan konfigureres globalt eller gjennom komprimeringskombinasjoner som er tilordnet rutingskombinasjoner.

Best for: Blandet kontekst med store verktøylogger samt instruksjoner fra brukere eller oppsummeringer fra assistenten.

---

Utregning av oppstrømsbesparelser

OmniRoute dokumenterer komprimeringsbesparelser fra to kilder: referansemålinger fra oppstrømsprosjekter og OmniRoutes egen kombinasjon av motorer.

Kilde	Tall fra oppstrøms-README som brukes her
Caveman	~75% færre utdatatokener, 65% gjennomsnittlig utdatasparing i referansemålinger, et intervall på 22-87% og et verktøy for ~46% komprimering av inndata
RTK	60-90% besparelse på kommandoutdata; eksempeløkt med ~118,000 -> ~23,900 tokener, eller 79.7% spart (~80%)

For overlappende verktøy-/kontekstnyttelaster stabler OmniRoutes standardkombinasjon motorene:

RTK -> Caveman

De kombinerte besparelsene er multiplikative, ikke additive:

kombinert    = 1 - (1 - RTK-besparelse) * (1 - Caveman-inndatabesparelse)
gjennomsnitt = 1 - (1 - 0.80) * (1 - 0.46) = 89.2%
intervall    = 1 - (1 - 0.60..0.90) * (1 - 0.46) = 78.4-94.6%

Tallet 78-95% gjelder når både RTK og Caveman kan redusere den samme inndata-/kontekstnyttelasten. Cavemans modus for responsutdata er separat: Når den er aktivert, brukes Cavemans egne utdatabesparelser (65% i gjennomsnitt, ~75% som hovedtall, et intervall på 22-87%). De totale faktureringsbesparelsene avhenger av blandingen av ledetekster og utdata.

Hva «kvalifisert» faktisk betyr

Hovedintervallet på 15-95% er reelt, men det gjelder bare for overflødig eller omstendelig innhold — gjentatte feillinjer, en byggelogg som spammer den samme advarselen, en overdimensjonert grep-/fillesingsdump. Det betyr ikke at hver forespørsel sparer så mye.

Empirisk verifisert (tests/unit/compression/stacked-compression-tool-result-savings.test.ts): En stacked-kjøring (RTK + Caveman) mot en Anthropic-formet tool_result-blokk med 300 identiske feillinjer ga 95.93% tokenbesparelse / 96.26% tegnbesparelse — klart innenfor det annonserte intervallet. Men når den samme prosesseringskjeden kjøres mot normale, ikke-overflødige verktøyutdata (en ren liste over grep-treff, en kort fillesing, vanlig samtaletekst), gir den korrekt nok nær null besparelse, fordi det ikke finnes noe repetitivt å fjerne, og validateCompression() (validation.ts) nekter å levere en omskriving som ville fjernet eller endret kodeblokker, URL-er, overskrifter, versjoner eller konstantidentifikatorer med BARE STORE BOKSTAVER.

Dette er forventet og trygg atferd, ikke en feil: En kodeøkt som for det meste leser/søker med grep i ryddige filer, vil gi beskjedne totale besparelser selv når komprimering er fullt aktivert, mens en økt som støter på en feilsløyfe eller en pratsom linter, vil oppnå hele intervallet på 78-95% for den trafikken. Ikke bruk én enkelt økts lave samlede besparelsesprosent som bevis på at komprimeringen er feilkonfigurert — sjekk først om de underliggende verktøyutdataene faktisk var overflødige.

---

Visualisering av tokenbesparelser

Uten komprimering: 47K tokener sendt til LLM
Med Lite:          40K tokener sendt          (15% spart — trygt, alltid aktivert)
Med Standard:      33K tokener sendt          (30% spart — regler for caveman-språk)
Med Aggressive:    24K tokener sendt          (50% spart — aldring + oppsummering)
Med Ultra:         12K tokener sendt          (75% spart — heuristisk beskjæring)
Med RTK:           19K-5K tokener sendt       (60-90% spart på kommando-/verktøyutdata)
Med Stacked:       10K-2.5K tokener sendt     (78-95% kvalifisert RTK+Caveman-intervall)

---

Konfigurasjon

Kontrollpanel

Gå til Kontrollpanel → Kontekst og hurtigbuffer:

• Caveman — valg av modus, språkpakker, forhåndsvisning og globale standardinnstillinger
• RTK — forhåndsvisning av kommandofilter, sikkerhetsinnstillinger for RTK og filterkatalog
• Komprimeringskombinasjoner — navngitte motorforløp tilordnet rutingskombinasjoner
• Terskel for automatisk aktivering — aktiverer komprimering automatisk når antallet tokener overstiger terskelen

Overstyring per kombinasjon

I Kontrollpanel → Kontekst og hurtigbuffer → Komprimeringskombinasjoner tilordner du en komprimeringskombinasjon til en rutingskombinasjon:

Kombinasjon: "free-tier-fallback"
  Komprimeringskombinasjon: "coding-agent-stack"
  Forløp: RTK -> Caveman
  Mål:
    1. if/kimi-k2.7-code
    2. if/qwen3.8-max-preview

Dette lar deg bruke stablet komprimering hos kostnadsfrie leverandører og kodeleverandører, samtidig som du beholder lettmodus for betalte abonnementer.

Denne tilordningen «Overstyring per kombinasjon» er en annen kontroll enn overstyringen av komprimeringsmodus for rutingskombinasjoner (Standard/Av/Lett/Normal/Aggressiv/Ultra) — denne overstyringen velger ikke et navngitt forløp for en komprimeringskombinasjon. Den angir bare feltet compressionMode som brukes av resolveCompressionPlan. Den kan angis enten på kombinasjonskortet (Kontrollpanel → Kombinasjoner) eller, siden #6760, per rutingskombinasjon i listen «Tilordne til ruting» under Kontrollpanel → Kontekst og hurtigbuffer → Komprimeringskombinasjoner, rett ved siden av avmerkingsboksen for forløpstilordning som er dokumentert ovenfor. Begge grensesnittene lagrer gjennom det samme endepunktet PUT /api/combos/{id}.

Overstyring per forespørsel

Send forespørselshodet x-omniroute-compression for å overstyre komprimeringsplanen for én enkelt forespørsel. Det har høyest prioritet — det overstyrer rutingskombinasjonens overstyring, den aktive profilen, automatisk aktivering og standardinnstillingen i panelet. Ukjente verdier ignoreres (forespørselen avvises aldri), og den globale hovedbryteren styrer fortsatt alt: Når komprimering er slått av globalt, kan ikke hodet slå den på. Verdier:

Verdi	Effekt
off	Ingen komprimering for denne forespørselen.
default	Standardprofilen fra panelet (ignorerer den aktive profilen).
engine:<id>	Én enkelt motor når den er aktivert, f.eks. engine:rtk.
<combo>	En navngitt kombinasjon, først samsvart etter navn (uten hensyn til store og små bokstaver), deretter etter id.

Den anvendte planen returneres i svarhodet X-OmniRoute-Compression: <mode>; source=<source>, der <source> er én av request-header, routing-override, active-profile, auto-trigger, default eller off.

API

# Hent komprimeringsinnstillinger
curl http://localhost:20128/api/settings/compression

# Oppdater komprimeringsinnstillinger
curl -X PUT http://localhost:20128/api/settings/compression \
  -H "Content-Type: application/json" \
  -d '{"defaultMode":"stacked","autoTriggerMode":"stacked","autoTriggerTokens":32000}'

# Forhåndsvis en bestemt RTK-/stablet nyttelast
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"}]}'

# Vis RTK-filterpakker
curl http://localhost:20128/api/context/rtk/filters

# Test RTK direkte med valgfrie kommandometadata
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"}'

---

Hva som beskyttes

Komprimeringsmotoren bevarer alltid:

• ✅ Kodeblokker (inngjerdede og innebygde)
• ✅ URL-er og filbaner
• ✅ JSON-strukturer og strukturerte data
• ✅ Identifikatorer og beskyttede tekniske symboler
• ✅ Matematiske uttrykk
• ✅ Definisjoner av verktøy-/funksjonskall
• ✅ Systeminstruksjoner (i lite-modus)

Gjenoppretting av rådata fra RTK sladder vanlige API-nøkler, bearer-tokener, Slack-tokener, AWS-tilgangsnøkler, passord, tokener og hemmeligheter før noe lagres.

---

Komprimeringsstatistikk

Hver komprimerte forespørsel inkluderer statistikk i serverloggene:

{
  "originalTokens": 47200,
  "compressedTokens": 40120,
  "savingsPercent": 15.0,
  "techniquesUsed": ["collapseWhitespace", "dedupSystemPrompt"],
  "mode": "lite",
  "engine": "caveman",
  "compressionComboId": "coding-agent-stack",
  "durationMs": 0.8,
  "rtkRawOutputPointers": []
}

---

Faseplan

Fase	Moduser	Status
Fase 1	Off, Lite	✅ Lansert
Fase 2	Standard, Aggressive, Ultra	✅ Lansert
Fase 3	RTK, Stacked, Compression Combos	✅ Lansert
Fase 4	Output Styles, SLM-tier Ultra, eval harness	✅ Lansert
Fase 4C	Adaptivt kontekstbudsjett ("dial") — beregningsmotor + API (contextBudget på PUT /api/settings/compression) + kontroller for modus/retningslinjer i kontrollpanelet	✅ Lansert

---

Takk

Komprimeringsreglene for standard-modus er inspirert av Caveman av JuliusBrussee (⭐ 51K+) — det virale prosjektet «why use many token when few token do trick». Caveman rapporterer ~75% færre utdatatokener, 65% gjennomsnittlig besparelse av utdatatokener i referansetester, et utdataområde på 22-87% og et verktøy for inndatakomprimering på ~46%.

RTK-modus er inspirert av RTK - Rust Token Killer av RTK AI — prosjektet for høyytelseskomprimering av kommandoutdata fra terminaler, bygg, tester, git og filtrering av verktøyutdata. RTK rapporterer besparelser på 60-90%, og eksempeløkten i README-filen viser at ~80% ble spart.

---

Avanserte komprimeringssystemer

I tillegg til de 7 standardmodusene inkluderer OmniRoute flere avanserte komprimeringssystemer som fungerer automatisk basert på konteksten.

Hurtigbufferbevisst komprimering

Noen leverandører (som Anthropic med hurtigbufring av systeminstruksjoner) støtter hurtigbufring av systeminstruksjoner, slik at de kan hurtigbufre deler av systeminstruksjonen for å redusere kostnader og ventetid. Når hurtigbufring er aktivert, kan aggressiv komprimering faktisk svekke ytelsen fordi den endrer de hurtigbufrede tokenene og dermed ugyldiggjør hurtigbufferen.

Modulen cachingAware.ts løser dette ved å oppdage hurtigbufferkontekst og justere komprimeringsstrategien deretter.

Slik fungerer det

1. Oppdag hurtigbufferkontekst — Skanner forespørselsinnholdet etter cache_control-markører
2. Identifiser hurtigbufferleverandører — Kontrollerer om målleverandøren støtter hurtigbufring
3. Juster strategien — Nedgraderer aggressive/ultra til standard for hurtigbufferleverandører
4. Hopp over systeminstruksjonen — Systeminstruksjoner hurtigbufres vanligvis, så ikke komprimer dem
5. Bruk deterministiske transformasjoner — Bruk bare transformasjoner som gir konsistente resultater

Kodeeksempel

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" }, // ← Hurtigbuffermarkør
};

const ctx = detectCachingContext(body, { provider: "anthropic" });
// → { hasCacheControl: true, provider: "anthropic", isCachingProvider: true }

const strategy = getCacheAwareStrategy("aggressive", ctx);
// → { strategy: "standard", skipSystemPrompt: true, deterministicOnly: true }

Når det skal brukes

Hurtigbufferbevisst komprimering er alltid aktivert — ingen konfigurasjon er nødvendig. Den aktiveres bare når:

• Forespørselen har cache_control-markører
• Målleverandøren støtter hurtigbufring av systeminstruksjoner (Anthropic, OpenAI osv.)

Progressiv aldring

Lange samtaler akkumulerer mange meldingsrunder, men eldre runder blir mindre relevante. Modulen progressiveAging.ts reduserer detaljnivået i meldinger basert på avstanden i antall runder:

• Nylige runder (0-3): Beholdes ordrett (alle detaljer)
• Mellomgamle runder (4-8): Lite-komprimering (opprydding i mellomrom og formatering)
• Gamle runder (9+): Caveman-komprimering (fjerning av fyllord, oppsummering)
• Svært gamle runder (20+): Oppsummeres kraftig eller fjernes

Kodeeksempel

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 runder til ...
];

const { messages: aged, saved } = applyAging(messages, {
  verbatim: 3, // De første 3 rundene: ordrett
  light: 8, // Runde 4–8: lite-komprimering
  moderate: 20, // Runde 9–20: caveman-komprimering
  // Runde 21+: kraftig oppsummering
});

// saved = antall sparte tokener

Når det skal brukes

Progressiv aldring er alltid på for modusene aggressive og ultra. Det er spesielt effektivt for:

• Langvarige kodeøkter
• Samtaler som varer i flere dager
• Agentbaserte arbeidsflyter med mange verktøykall

Huleboermodus for utdata

Modulen outputMode.ts legger inn instruksjoner i systemledeteksten for å få selve modellen til å produsere komprimerte, konsise utdata (en «huleboerstil»).

Slik fungerer det

I stedet for å komprimere inndataene legger denne modusen til en systemledetekst som:

«Svar med færrest mulig ord. Dropp høflighetsfraser. Bruk korte setninger.»

Dette fungerer spesielt godt for:

• Kodegenerering (mer konsise utdata = færre tokener)
• Raske spørsmål og svar (ikke behov for utførlige forklaringer)
• Satsvis behandling (maksimer kapasiteten)

Når den bør brukes

Huleboermodus for utdata er valgfri — angi den via kombinasjonskonfigurasjonen:

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

Utdatastiler (katalog)

Huleboermodusen ovenfor er den eldre banen med én stil. Fase 4 generaliserte den til en katalog med kombinerbare utdatastiler: OUTPUT_STYLE_CATALOG i open-sse/services/compression/outputStyles/catalog.ts. Hver stil er en instruksjon i systemledeteksten som får selve modellen til å produsere rimeligere utdata. Stiler kan aktiveres sammen og legges inn i katalogrekkefølge.

Stil	id	Hva den gjør	Instruksjonsspråk
Konsis prosa	terse-prose	Fjern fyllord/artikler/forbehold; behold det tekniske innholdet nøyaktig. Samme tekst som den eldre huleboermodusen for utdata (referert til, ikke skrevet på nytt).	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
Mindre kode	less-code	YAGNI-stige: minste fungerende endring, ingen abstraksjoner som ikke er etterspurt.	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
Hestehale (lat seniorutvikler)	ponytail	«Den beste koden er koden som aldri blir skrevet»: gjenbruk > omskriving, grunnårsak > symptom, korteste fungerende diff.	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
Jeg har ADHD (handling først)	i-have-adhd	Handling først (kommando/bane/kodesnutt før prosa), nummererte og avgrensede trinn, ETT konkret neste trinn, ingen innledning/oppsummering/avslutningsfraser. Tilpasset fra ayghri/i-have-adhd (MIT).	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
Konsis CJK (文言)	terse-cjk	Ultrakonsis stil på klassisk kinesisk.	zh (språkinnstillingsbegrenset: tilbys bare når det valgte språket er zh)

Hver stil leveres med tre intensitetsnivåer — lite, full, ultra — og hvert nivå avsluttes med den felles avgrensningsklausulen, som bevarer kodeblokker, filbaner, kommandoer, feilmeldinger, URL-er og identifikatorer ordrett.

Slik fungerer innleggingen

applyOutputStyles() (open-sse/services/compression/outputStyles/apply.ts) avstemmer utvalget mot katalogen (ukjente id-er og stiler som ikke samsvarer med språkinnstillingen, fjernes og fører aldri til feil), slår sammen de valgte instruksjonene i katalogrekkefølge, legger til avgrensningsklausulen én gang og plasserer resultatet først i systemledeteksten bak én idempotensmarkør ([OmniRoute Output Styles]) — gjentatt bruk gjør ingenting. Når språket som er oppdaget i forespørselen, har en oversettelse, legges den lokaliserte instruksjonen inn i stedet for den engelske.

Slik aktiveres det

I kontrollpanelet: Kontekst → Innstillinger → Komprimering — én rad per stil med en av/på-bryter og en nivåvelger. Programmatisk lagrer komprimeringskonfigurasjonen utvalget slik:

{
  "outputStyles": [
    { "id": "i-have-adhd", "level": "full" },
    { "id": "less-code", "level": "lite" }
  ]
}

Bakoverkompatibilitet: Den eldre kombinasjonsinnstillingen outputMode: "caveman" fungerer fortsatt og tilordnes terse-prose, byte-identisk med den gamle innleggingen på alle eldre språk.

Språkvalg: Når languageConfig.enabled er på, velger autoDetect språket i den nyeste brukermeldingen (samme detektor som inndatamotorene). Hvis autoDetect slås av, låses defaultLanguage. Av → engelsk.

Matrisen for stil × språk er låst av tests/unit/compression/output-styles-i18n-matrix.test.ts: En ny stil kan ikke leveres uten minst en pt-BR-oversettelse (eller et eksplisitt sporet unntak), og en eksisterende stil kan ikke miste en språkinnstilling uten varsel. Se EXTENDING_COMPRESSION.md for å legge til en stil.

Komprimering av verktøyresultater

Modulen toolResultCompressor.ts tilbyr 5 spesialiserte komprimeringsstrategier for verktøyresultater (funksjonskall, agentutdata, søkeresultater osv.):

1. Komprimering av søkeresultater — Fjerner overflødige resultater, beholder de N beste
2. Komprimering av fillesing — Avkorter store filer, bevarer deklarasjonshoder/importer
3. Komprimering av kodekjøring — Beholder bare nødvendig stdout/stderr
4. Komprimering av databasespørringer — Begrenser rader, fjerner ordrike metadata
5. Komprimering av API-svar — Fjerner null-felt, kondenserer matriser

Når den bør brukes

Komprimering av verktøyresultater er alltid på når verktøykall finnes. Ingen konfigurasjon er nødvendig.

Stablet prosesskjede

Stablet modus kjører flere motorer i rekkefølge — vanligvis RTK først (60–90 % besparelse på verktøyutdata), deretter Caveman (ytterligere 30 % besparelse på den gjenværende teksten). Dette gir 78–95 % samlet besparelse.

Slik fungerer det

Inndata (1000 tokener)
  → RTK (kommandobevisst filter) → 200 tokener
    → Caveman (fjerning av fyllord) → 140 tokener
  → Utdata (140 tokener, 86 % besparelse)

Når den bør brukes

Bruk stablet modus for:

• Verktøytunge arbeidsflyter (agentbasert koding, forskning)
• Kostnadssensitiv satsvis behandling
• Når du trenger maksimal tokenbesparelse

Konfigurer via kombinasjonskonfigurasjonen:

{
  "strategy": "auto",
  "config": {
    "auto": {
      "modePack": "stacked"
    }
  }
}

---

Overstyringer for komprimeringskombinasjoner

Du kan overstyre den globale komprimeringsmodusen per kombinasjon for å finjustere virkemåten for ulike brukstilfeller:

{
  "id": "coding-combo",
  "strategy": "priority",
  "config": {
    "auto": {
      "weights": { "taskFit": 0.5 },
      "modePack": "quality-first"
    }
  },
  "compressionOverride": {
    "mode": "aggressive",
    "stackedPipelines": ["rtk", "caveman"],
    "preserveToolDefinitions": true
  }
}

Dette er nyttig for:

• Kodekombinasjoner: Bruk modusen aggressive for lange økter
• Kombinasjoner for raske spørsmål og svar: Bruk modusen lite for raske svar
• Verktøytunge kombinasjoner: Bruk modusen stacked for maksimal besparelse
• Produksjonskombinasjoner: Bruk modusen cache-aware for leverandører som støtter hurtigbufring

---

Se også

• Miljøkonfigurasjon — Miljøvariabler for komprimering
• Arkitekturveiledning — Intern virkemåte for komprimeringsprosessen
• Brukerveiledning — Kom i gang med komprimering
• RTK-komprimering — RTK-filtre, tillitsmodell, verifiseringsport, gjenoppretting av råutdata
• Komprimeringsmotorer — Caveman, RTK, stabling, API-er, MCP, kontrollpanel
• Format for komprimeringsregler — JSON-format for regelpakker
• Språkpakker for komprimering — Språkspesifikke Caveman-regler