🗜️ Prompt Compression Guide — OmniRoute (Deutsch)

Komprimierungsmodi

Aus

Es wird keine Komprimierung angewendet. Alle Nachrichten werden unverändert weitergeleitet.

Lite-Modus (~15 % Einsparung, <1 ms Latenz)

Der sicherste Modus — keine semantischen Änderungen, nur Bereinigung der Formatierung:

Technik	Beschreibung
collapseWhitespace	Aufeinanderfolgende Leerzeilen zusammenführen und nachgestellte Leerzeichen entfernen
dedupSystemPrompt	Doppelte Systemnachrichten entfernen
compressToolResults	Ausführliche Werkzeug-/Funktionsausgaben komprimieren
removeRedundantContent	Wiederholte Anweisungen entfernen
replaceImageUrls	Base64-Bilddaten-URIs verkürzen

Am besten geeignet für: Dauerhafte Nutzung, sicherheitskritische Arbeitsabläufe.

Standardmodus (~30 % Einsparung)

Inspiriert von Caveman — entfernt Füllwörter und umständliche Formulierungen, ohne die Bedeutung zu verändern:

• Entfernt Füllwörter („please“, „I think“, „basically“, „actually“)
• Verkürzt umständliche Formulierungen („in order to“ → „to“, „as a result of“ → „because“)
• Entfernt höfliche Abschwächungen („Would you mind…“, „If you could possibly…“)
• Mehr als 30 für Programmier-Prompts optimierte Regex-Regeln

Am besten geeignet für: Tägliche Programmierabläufe, kostenbewusste Teams.

Aggressiver Modus (~50 % Einsparung)

Intelligente Verwaltung des Verlaufs für lange Sitzungen:

• Nachrichtenalterung — ältere Nachrichten werden zunehmend komprimiert
• Zusammenfassung von Werkzeugergebnissen — lange Werkzeugausgaben werden durch Zusammenfassungen ersetzt
• Schutz der strukturellen Integrität — stellt sicher, dass Paare aus tool_use und tool_result konsistent bleiben
• Berücksichtigung des Kontextfensters — beachtet die Token-Limits des jeweiligen Modells

Am besten geeignet für: Längere Debugging-Sitzungen, große Codebasen.

Ultra-Modus (~75 % Einsparung)

Maximale Komprimierung für Szenarien mit kritischem Token-Budget:

• Heuristisches Kürzen — entfernt Nachrichten unterhalb des Relevanzschwellenwerts
• Ausdünnen von Codeblöcken — komprimiert sich wiederholende Codebeispiele
• Kürzung per Binärsuche — ermittelt den optimalen Schnittpunkt für das Kontextfenster
• Umfasst alle Funktionen des aggressiven Modus

Am besten geeignet für: Situationen, in denen du wiederholt an Kontextgrenzen stößt.

RTK-Modus (vorgelagerter Bereich von 60–90 %)

Der RTK-Modus ist für ausführliche Werkzeugausgaben optimiert, die in Sitzungen mit Programmieragenten auftreten:

• Erkennt Befehls-/Ausgabeklassen wie git status, git diff, git log, Test-Runner, TypeScript-/Vite-/Webpack-Builds, ESLint/Biome/Prettier, npm-Audits/-Installationen, Docker-Protokolle, Infrastruktur- ausgaben und generische Shell-Ausgaben
• Wendet JSON-Filterpakete aus open-sse/services/compression/engines/rtk/filters/ an
• Importiert RTK-Filter des TOML-Schemas v1 aus projektbezogenen oder globalen filters.toml-Dateien, einschließlich Inline-Test-Validierung und vertrauensbasierter Freigabe für Projektdateien
• Enthält 49 integrierte Filter mit Inline-Verifizierungsbeispielen
• Entfernt ANSI-Steuersequenzen, Fortschrittsbalken, wiederholte Zeilen und irrelevantes Rauschen
• Behält Fehlschläge, Fehler, Warnungen, geänderte Dateien, Zusammenfassungen und das Ende langer Ausgaben bei
• Unterstützt vertrauensbasiert freigegebene Projektfilter, globale Filter und die optionale Wiederherstellung redigierter Rohausgaben

Am besten geeignet für: Agentensitzungen mit Shell-, Build-, Test-, Git-, Grep- und Dateiausgabe-Transkripten.

Gestapelter Modus (geeigneter Bereich von 78–95 %)

Der gestapelte Modus führt mehrere Komprimierungs-Engines in einer deterministischen Reihenfolge aus. Die Standard-Pipeline lautet:

RTK -> Caveman

Diese Reihenfolge komprimiert zunächst Terminal-/Werkzeugausgaben und wendet anschließend die semantische Verdichtung von Caveman auf den verbleibenden natürlichsprachlichen Prompt an. Gestapelte Pipelines können global oder über Komprimierungs-Combos konfiguriert werden, die Routing-Combos zugewiesen sind.

Am besten geeignet für: Gemischten Kontext mit umfangreichen Werkzeugprotokollen sowie menschlichen Anweisungen oder Assistentenzusammenfassungen.

---

Berechnung der Einsparungen aus vorgelagerten Projekten

OmniRoute dokumentiert Komprimierungseinsparungen aus zwei Quellen: Benchmarks vorgelagerter Projekte und der eigenen Engine-Kombination von OmniRoute.

Quelle	Hier verwendete Angabe aus der vorgelagerten README
Caveman	~75% weniger Ausgabetokens, durchschnittlich 65% Ausgabeeinsparungen im Benchmark, eine Spanne von 22-87% und ein Tool zur Eingabekomprimierung um ~46%
RTK	60-90% Einsparungen bei Befehlsausgaben; Beispielsitzung mit ~118,000 -> ~23,900 Tokens oder 79.7% Einsparung (~80%)

Bei sich überschneidenden Tool-/Kontext-Nutzdaten kombiniert die standardmäßige OmniRoute-Konfiguration die Engines:

RTK -> Caveman

Die kombinierten Einsparungen sind multiplikativ, nicht additiv:

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%

Die Angabe 78-95% gilt, wenn sowohl RTK als auch Caveman dieselben Eingabe-/Kontext-Nutzdaten reduzieren können. Der Caveman-Antwortausgabemodus ist davon getrennt: Wenn er aktiviert ist, gelten die eigenen Ausgabeeinsparungen von Caveman (durchschnittlich 65%, ~75% als Hauptangabe, Spanne von 22-87%). Die gesamten Abrechnungseinsparungen hängen vom Verhältnis Ihrer Eingaben zu Ausgaben ab.

Was „geeignet“ tatsächlich bedeutet

Die angegebene Spanne von 15-95% ist real, gilt aber nur für redundante oder ausführliche Inhalte — wiederholte Fehlerzeilen, ein Build-Protokoll, das dieselbe Warnung unablässig ausgibt, oder eine übermäßig große Ausgabe von grep/Dateilesevorgängen. Das bedeutet nicht, dass jede Anfrage so viel einspart.

Empirisch verifiziert (tests/unit/compression/stacked-compression-tool-result-savings.test.ts): Ein stacked-Durchlauf (RTK + Caveman) für einen Anthropic-förmigen tool_result-Block mit 300 identischen Fehlerzeilen erzielte 95.93% Token-Einsparungen / 96.26% Zeicheneinsparungen — genau innerhalb der angegebenen Spanne. Wird dieselbe Pipeline jedoch mit einer normalen, nicht redundanten Tool-Ausgabe ausgeführt (einer sauberen grep-Trefferliste, einem kurzen Dateilesevorgang oder gewöhnlichem Konversationstext), erzielt sie korrekterweise nahezu keine Einsparungen, weil keine Wiederholungen entfernt werden können und validateCompression() (validation.ts) keine Überarbeitung ausliefert, durch die Codeblöcke, URLs, Überschriften, Versionen oder vollständig großgeschriebene Konstantenbezeichner entfernt oder verändert würden.

Dies ist erwartetes und sicheres Verhalten, kein Fehler: Eine Programmiersitzung, die hauptsächlich saubere Dateien liest bzw. mit grep durchsucht, erzielt selbst bei vollständig aktivierter Komprimierung nur moderate Gesamteinsparungen, während eine Sitzung, die auf eine fehlschlagende Schleife oder einen übermäßig ausführlichen Linter trifft, bei diesem Datenverkehr die volle Spanne von 78-95% erreicht. Verwenden Sie den niedrigen Gesamteinsparungsprozentsatz einer einzelnen Sitzung nicht als Beleg dafür, dass die Komprimierung falsch konfiguriert ist — prüfen Sie zuerst, ob die zugrunde liegende Tool-Ausgabe tatsächlich redundant war.

---

Visualisierung der Token-Einsparungen

Ohne Komprimierung: 47K Tokens an das LLM gesendet
Mit Lite:           40K Tokens gesendet          (15% eingespart — sicher, immer aktiv)
Mit Standard:       33K Tokens gesendet          (30% eingespart — Caveman-Sprechregeln)
Mit Aggressive:     24K Tokens gesendet          (50% eingespart — Alterung + Zusammenfassung)
Mit Ultra:          12K Tokens gesendet          (75% eingespart — heuristische Bereinigung)
Mit RTK:            19K-5K Tokens gesendet       (60-90% bei Befehls-/Tool-Ausgaben eingespart)
Mit Stacked:        10K-2.5K Tokens gesendet     (geeignete RTK+Caveman-Spanne von 78-95%)

---

Konfiguration

Dashboard

Navigieren Sie zu Dashboard → Context & Cache:

• Caveman — Modusauswahl, Sprachpakete, Vorschau und globale Standardwerte
• RTK — Vorschau des Befehlsfilters, RTK-Sicherheitseinstellungen und Filterkatalog
• Compression Combos — benannte Engine-Pipelines, die Routing-Kombinationen zugewiesen sind
• Auto-Trigger Threshold — aktiviert automatisch die Komprimierung, wenn die Token-Anzahl den Schwellenwert überschreitet

Überschreibung pro Kombination

Weisen Sie unter Dashboard → Context & Cache → Compression Combos einer Routing-Kombination eine Komprimierungskombination zu:

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

Dadurch können Sie bei kostenlosen/Coding-Anbietern gestapelte Komprimierung verwenden, während für kostenpflichtige Abonnements der Lite-Modus beibehalten wird.

Diese Zuweisung zur „Überschreibung pro Kombination“ ist ein anderes Steuerelement als die Überschreibung des Komprimierungsmodus der Routing-Kombination (Default/Off/Lite/Standard/Aggressive/Ultra) — diese Überschreibung wählt keine benannte Pipeline einer Komprimierungskombination aus; sie legt lediglich das Feld compressionMode fest, das von resolveCompressionPlan ausgewertet wird. Sie kann entweder auf der Kombinationskarte (Dashboard → Combos) oder seit #6760 für jede Routing-Kombination in der Liste „Assign to routing“ unter Dashboard → Context & Cache → Compression Combos direkt neben dem oben dokumentierten Kontrollkästchen für die Pipeline-Zuweisung festgelegt werden. Beide Oberflächen speichern die Einstellung über denselben Endpunkt PUT /api/combos/{id}.

Überschreibung pro Anfrage

Senden Sie den Anfrage-Header x-omniroute-compression, um den Komprimierungsplan für eine einzelne Anfrage zu überschreiben. Er hat die höchste Priorität — er setzt die Überschreibung der Routing-Kombination, das aktive Profil, den automatischen Auslöser und den Standardwert des Panels außer Kraft. Unbekannte Werte werden ignoriert (die Anfrage wird niemals abgelehnt), und der globale Hauptschalter bleibt weiterhin maßgeblich: Wenn die Komprimierung global deaktiviert ist, kann sie durch den Header nicht aktiviert werden. Werte:

Wert	Wirkung
off	Keine Komprimierung für diese Anfrage.
default	Das vom Panel abgeleitete Standardprofil (ignoriert das aktive Profil). Verlustbehaftete Engines bleiben deaktiviert.
safe	Entspricht dem Weglassen des Headers: nur Deduplizierung und Zusammenfassung von Leerraum.
allow-lossy	Behält den Operatorplan dieser Anfrage einschließlich Zusammenfassungen, Relevanzfiltern und Stilumschreibungen bei.
engine:<id>	Eine einzelne Engine, sofern aktiviert, z. B. engine:rtk. Dies ist die anfragebezogene Aktivierung für diese Engine.
<combo>	Eine benannte Kombination, die zuerst anhand des Namens (ohne Beachtung der Groß-/Kleinschreibung) und anschließend anhand der ID abgeglichen wird.

Ohne allow-lossy, engine:<id> oder eine benannte Kombination werden verlustbehaftete Engines nicht angewendet. Wenn die Komprimierung aktiviert ist, erhält die Anfrage weiterhin Sitzungs-Deduplizierung und die Zusammenfassung von Leerraum.

Der angewendete Plan wird im Antwort-Header X-OmniRoute-Compression: &lt;mode&gt;; source=<source> zurückgegeben, wobei <source> einen der Werte request-header, routing-override, active-profile, auto-trigger, default oder off hat.

API

# Komprimierungseinstellungen abrufen
curl http://localhost:20128/api/settings/compression

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

# Vorschau einer bestimmten RTK-/gestapelten Nutzlast anzeigen
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-Filterpakete auflisten
curl http://localhost:20128/api/context/rtk/filters

# RTK direkt mit optionalen Befehlsmetadaten testen
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"}'

---

Was geschützt wird

Die Komprimierungs-Engine bewahrt immer Folgendes:

• ✅ Codeblöcke (abgegrenzt und inline)
• ✅ URLs und Dateipfade
• ✅ JSON-Strukturen und strukturierte Daten
• ✅ Bezeichner und geschützte technische Tokens
• ✅ Mathematische Ausdrücke
• ✅ Definitionen von Tool-/Funktionsaufrufen
• ✅ System-Prompts (im Lite-Modus)

Die Wiederherstellung der RTK-Rohausgabe schwärzt gängige API-Schlüssel, Bearer-Tokens, Slack-Tokens, AWS-Zugriffsschlüssel, Passwörter, Tokens und Geheimnisse, bevor irgendetwas dauerhaft gespeichert wird.

---

Komprimierungsstatistiken

Jede komprimierte Anfrage enthält Statistiken in den Serverprotokollen:

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

---

Phasen-Roadmap

Phase	Modi	Status
Phase 1	Aus, Leicht	✅ Ausgeliefert
Phase 2	Standard, Aggressiv, Ultra	✅ Ausgeliefert
Phase 3	RTK, Gestapelt, Komprimierungskombinationen	✅ Ausgeliefert
Phase 4	Ausgabestile, Ultra auf SLM-Niveau, Evaluierungs-Harness	✅ Ausgeliefert
Phase 4C	Adaptives Kontextbudget („Regler“) — Rechen-Engine + API (contextBudget bei PUT /api/settings/compression) + Modus-/Richtliniensteuerung im Dashboard	✅ Ausgeliefert

---

Danksagungen

Die Komprimierungsregeln des Standard-Modus sind von Caveman von JuliusBrussee (⭐ 51K+) inspiriert — dem viralen Projekt „Warum viele Token verwenden, wenn wenige Token genügen“. Caveman gibt ~75% weniger Ausgabe-Tokens, durchschnittliche Einsparungen von 65% bei Benchmark-Ausgaben, eine Ausgabespanne von 22-87% und ein Tool zur Eingabekomprimierung von ~46% an.

Der RTK-Modus ist von RTK - Rust Token Killer von RTK AI inspiriert — dem hochleistungsfähigen Projekt zur Komprimierung von Befehlsausgaben für Terminal-, Build-, Test-, Git- und Tool-Ausgabefilterung. RTK gibt Einsparungen von 60-90% an, wobei die Beispielsitzung in der README eine Einsparung von ~80% zeigt.

---

Erweiterte Komprimierungssysteme

Zusätzlich zu den 7 Standardmodi umfasst OmniRoute mehrere erweiterte Komprimierungssysteme, die abhängig vom Kontext automatisch arbeiten.

Cache-bewusste Komprimierung

Einige Anbieter (wie Anthropic mit Prompt-Caching) unterstützen Prompt-Caching, wodurch sie Teile des Prompts zwischenspeichern können, um Kosten und Latenz zu reduzieren. Wenn Caching aktiviert ist, kann aggressive Komprimierung die Leistung sogar beeinträchtigen, da sie die zwischengespeicherten Tokens verändert und dadurch den Cache ungültig macht.

Das Modul cachingAware.ts löst dieses Problem, indem es den Caching-Kontext erkennt und die Komprimierungsstrategie entsprechend anpasst.

Funktionsweise

1. Caching-Kontext erkennen — Durchsucht den Request-Body nach cache_control-Markierungen
2. Caching-Anbieter identifizieren — Prüft, ob der Zielanbieter Caching unterstützt
3. Strategie anpassen — Stuft aggressive/ultra bei Caching-Anbietern auf standard herab
4. System-Prompt überspringen — System-Prompts werden üblicherweise zwischengespeichert und daher nicht komprimiert
5. Deterministische Transformationen verwenden — Verwendet nur Transformationen, die eine konsistente Ausgabe erzeugen

Codebeispiel

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" }, // ← Cache-Markierung
};

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

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

Verwendung

Die Cache-bewusste Komprimierung ist immer aktiviert — es ist keine Konfiguration erforderlich. Sie wird nur aktiv, wenn:

• Der Request cache_control-Markierungen enthält
• Der Zielanbieter Prompt-Caching unterstützt (Anthropic, OpenAI usw.)

Progressive Alterung

Lange Unterhaltungen sammeln viele Nachrichtenwechsel an, ältere Wechsel werden jedoch zunehmend weniger relevant. Das Modul progressiveAging.ts reduziert Nachrichten abhängig von ihrem Abstand zum aktuellen Wechsel:

• Aktuelle Wechsel (0–3): Werden unverändert beibehalten (vollständige Details)
• Mittlere Wechsel (4–8): Leichte Komprimierung (Bereinigung von Leerzeichen und Formatierung)
• Alte Wechsel (9+): Caveman-Komprimierung (Entfernung von Füllwörtern, Zusammenfassung)
• Sehr alte Wechsel (20+): Werden stark zusammengefasst oder verworfen

Codebeispiel

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 weitere Wechsel ...
];

const { messages: aged, saved } = applyAging(messages, {
  verbatim: 3, // Erste 3 Wechsel: unverändert
  light: 8, // Wechsel 4–8: leichte Komprimierung
  moderate: 20, // Wechsel 9–20: Caveman-Komprimierung
  // Wechsel ab 21: starke Zusammenfassung
});

// saved = Anzahl der eingesparten Tokens

Verwendung

Die progressive Alterung ist in den Modi aggressive und ultra immer aktiviert. Sie ist besonders effektiv für:

• Lang andauernde Coding-Sitzungen
• Mehrtägige Unterhaltungen
• Agentische Workflows mit vielen Tool-Aufrufen

Caveman-Ausgabemodus

Das Modul outputMode.ts fügt System-Prompt-Anweisungen ein, damit das Modell selbst eine komprimierte, knappe Ausgabe (im „Caveman“-Stil) erzeugt.

Funktionsweise

Anstatt die Eingabe zu komprimieren, fügt dieser Modus einen System-Prompt wie den folgenden hinzu:

„Antworte mit möglichst wenigen Worten. Verzichte auf Höflichkeitsfloskeln. Verwende kurze Sätze.“

Dies funktioniert besonders gut für:

• Codegenerierung (knappere Ausgabe = weniger Tokens)
• Kurze Fragen und Antworten (keine ausführlichen Erklärungen erforderlich)
• Stapelverarbeitung (maximaler Durchsatz)

Verwendung

Der Caveman-Ausgabemodus ist optional — aktiviere ihn über die Combo-Konfiguration:

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

Ausgabestile (Katalog)

Der oben beschriebene Caveman-Ausgabemodus ist der veraltete Pfad mit nur einem Stil. Phase 4 hat ihn zu einem Katalog kombinierbarer Ausgabestile erweitert: OUTPUT_STYLE_CATALOG in open-sse/services/compression/outputStyles/catalog.ts. Jeder Stil ist eine System-Prompt- Anweisung, die das Modell selbst dazu bringt, kostengünstigere Ausgaben zu erzeugen; Stile können gemeinsam aktiviert werden und werden in der Reihenfolge des Katalogs eingefügt.

Stil	id	Funktion	Anweisungssprachen
Knapp formuliert	terse-prose	Füllwörter/Artikel/Relativierungen weglassen; technische Substanz exakt beibehalten. Derselbe Text wie im alten Caveman-Ausgabemodus (referenziert, nicht erneut eingegeben).	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
Weniger Code	less-code	YAGNI-Leiter: kleinste funktionierende Änderung, keine nicht angeforderten Abstraktionen.	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
Pferdeschwanz (fauler Senior-Entwickler)	ponytail	„Der beste Code ist der Code, der nie geschrieben wurde“: Wiederverwenden > Neuschreiben, Ursache > Symptom, kürzester funktionierender Diff.	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
Ich habe ADHS (Aktion zuerst)	i-have-adhd	Aktion zuerst (Befehl/Pfad/Snippet vor Prosa), nummerierte begrenzte Schritte, EIN konkreter nächster Schritt, keine Einleitung/Zusammenfassung/Schlussformeln. Adaptiert von ayghri/i-have-adhd (MIT).	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
Knappes CJK (文言)	terse-cjk	Ultraknapper klassisch-chinesischer Stil.	zh (gebietsschemagebunden: wird nur angeboten, wenn die ermittelte Sprache zh ist)

Jeder Stil wird mit drei Intensitätsstufen ausgeliefert — lite, full, ultra — und jede Stufe endet mit der gemeinsamen Begrenzungsklausel, die Codeblöcke, Dateipfade, Befehle, Fehlermeldungen, URLs und Bezeichner unverändert beibehält.

Funktionsweise der Injektion

applyOutputStyles() (open-sse/services/compression/outputStyles/apply.ts) gleicht die Auswahl mit dem Katalog ab (unbekannte IDs und nicht zum Gebietsschema passende Stile werden verworfen und verursachen nie einen Fehler), verkettet die ausgewählten Anweisungen in Katalogreihenfolge, hängt die Begrenzungsklausel einmal an und stellt das Ergebnis im System-Prompt hinter einer einzelnen Idempotenzmarkierung ([OmniRoute Output Styles]) voran — eine erneute Anwendung bewirkt nichts. Wenn für die erkannte Anfragesprache eine Übersetzung vorhanden ist, wird anstelle der englischen Anweisung die lokalisierte Anweisung injiziert.

Aktivierung

Im Dashboard: Kontext → Einstellungen → Komprimierung — eine Zeile pro Stil mit einem Ein-/Aus-Schalter und einer Stufenauswahl. Programmgesteuert speichert die Komprimierungskonfiguration die Auswahl wie folgt:

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

Abwärtskompatibilität: Die alte Kombinationseinstellung outputMode: "caveman" funktioniert weiterhin und wird terse-prose zugeordnet; in jeder Legacy-Sprache ist die Injektion bytegenau mit der alten identisch.

Sprachauswahl: Wenn languageConfig.enabled aktiviert ist, wählt autoDetect die Sprache der neuesten Benutzernachricht aus (derselbe Detektor wie bei den Eingabe-Engines); durch Deaktivieren von autoDetect wird defaultLanguage festgelegt. Aus → Englisch.

Die Stil-×-Sprachen-Matrix wird durch tests/unit/compression/output-styles-i18n-matrix.test.ts festgeschrieben: Ein neuer Stil kann nicht ohne mindestens eine pt-BR-Übersetzung (oder eine ausdrücklich nachverfolgte Ausnahme) ausgeliefert werden, und ein vorhandener Stil kann nicht unbemerkt ein Gebietsschema verlieren. Informationen zum Hinzufügen eines Stils finden Sie unter EXTENDING_COMPRESSION.md.

Komprimierung von Tool-Ergebnissen

Das Modul toolResultCompressor.ts bietet 5 spezialisierte Komprimierungsstrategien für Tool-Ergebnisse (Funktionsaufrufe, Agentenausgaben, Suchergebnisse usw.):

1. Komprimierung von Suchergebnissen — Entfernt redundante Ergebnisse, behält die besten N
2. Komprimierung gelesener Dateien — Kürzt große Dateien, behält Header/Importe bei
3. Komprimierung der Codeausführung — Behält nur wesentliche stdout/stderr-Ausgaben bei
4. Komprimierung von Datenbankabfragen — Begrenzt Zeilen, entfernt ausführliche Metadaten
5. Komprimierung von API-Antworten — Entfernt Null-Felder, verdichtet Arrays

Verwendungszeitpunkt

Die Komprimierung von Tool-Ergebnissen ist immer aktiviert, wenn Tool-Aufrufe vorhanden sind. Es ist keine Konfiguration erforderlich.

Gestapelte Pipeline

Der gestapelte Modus führt mehrere Engines nacheinander aus — üblicherweise zuerst RTK (60–90 % Einsparung bei Tool-Ausgaben), danach Caveman (weitere 30 % Einsparung beim verbleibenden Text). Dadurch werden insgesamt 78–95 % Einsparung erreicht.

Funktionsweise

Eingabe (1000 Token)
  → RTK (befehlsbewusster Filter) → 200 Token
    → Caveman (Entfernung von Füllwörtern) → 140 Token
  → Ausgabe (140 Token, 86 % Einsparung)

Verwendungszeitpunkt

Verwenden Sie den gestapelten Modus für:

• Tool-intensive Workflows (agentenbasierte Programmierung, Recherche)
• Kostensensible Stapelverarbeitung
• Wenn Sie maximale Token-Einsparungen benötigen

Konfiguration über eine Kombination:

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

---

Überschreibungen der Komprimierung pro Combo

Sie können den globalen Komprimierungsmodus für jede Combo einzeln überschreiben, um das Verhalten für verschiedene Anwendungsfälle präzise anzupassen:

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

Dies ist nützlich für:

• Coding-Combos: Verwenden Sie den Modus aggressive für lange Sitzungen
• Schnelle Frage-und-Antwort-Combos: Verwenden Sie den Modus lite für schnelle Antworten
• Tool-intensive Combos: Verwenden Sie den Modus stacked für maximale Einsparungen
• Produktions-Combos: Verwenden Sie den Modus cache-aware für Anbieter mit Caching-Unterstützung

---

Siehe auch

• Umgebungskonfiguration — Umgebungsvariablen für die Komprimierung
• Architekturleitfaden — Interna der Komprimierungspipeline
• Benutzerhandbuch — Erste Schritte mit der Komprimierung
• RTK-Komprimierung — RTK-Filter, Vertrauensmodell, Verifizierungs-Gate und Wiederherstellung der Rohausgabe
• Komprimierungs-Engines — Caveman, RTK, Stacking, APIs, MCP und Dashboard
• Format der Komprimierungsregeln — JSON-Format für Regelpakete
• Sprachpakete für die Komprimierung — Sprachspezifische Caveman-Regeln

---

OmniRoute-Quellcode (a58000c7685f)