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

🗜️ Prompt Compression Guide — OmniRoute (Español)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 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

---

Ahorra automáticamente entre un 15 % y un 95 % del contexto apto. Para obtener una vista general rápida, consulta la sección Compresión del README.

Descripción general

OmniRoute implementa una canalización modular de compresión de prompts que se ejecuta proactivamente antes de que las solicitudes lleguen a los proveedores upstream. Esto significa que el ahorro de tokens se produce de forma transparente, sin necesidad de realizar cambios en tu flujo de trabajo.

Solicitud del cliente
  → Selector de estrategia de compresión
    → ¿Sobrescritura por combo? → Usar la configuración del combo
    → ¿Umbral de activación automática? → Usar el modo automático
    → ¿Modo predeterminado? → Usar la configuración global
    → ¿Desactivado? → Omitir la compresión
  → Modo de compresión seleccionado
    → Desactivado: Sin compresión
    → Ligero: Limpieza segura de espacios en blanco/formato (~15 %)
    → Estándar: Eliminación de relleno al estilo telegráfico (~30 %)
    → Agresivo: Envejecimiento del historial + resumen (~50 %)
    → Ultra: Poda heurística + reducción de bloques de código (~75 %)
    → RTK: Filtrado de salida de terminal/herramientas basado en comandos (rango upstream del 60-90 %)
    → Apilado: Canalización ordenada de varios motores, normalmente RTK y después Caveman (rango apto del 78-95 %)
  → Solicitud comprimida → Proveedor

---

Modos de compresión

Desactivado

No se aplica ninguna compresión. Todos los mensajes pasan sin cambios.

Modo ligero (~15 % de ahorro, <1 ms de latencia)

El modo más seguro: ningún cambio semántico, solo limpieza de formato:

Técnica	Descripción
collapseWhitespace	Combina líneas en blanco consecutivas y espacios finales
dedupSystemPrompt	Elimina mensajes de sistema duplicados
compressToolResults	Comprime salidas detalladas de herramientas/funciones
removeRedundantContent	Elimina instrucciones repetidas
replaceImageUrls	Acorta los URI de datos de imágenes en base64

Ideal para: Uso continuo y flujos de trabajo críticos para la seguridad.

Modo estándar (~30 % de ahorro)

Inspirado en Caveman: elimina palabras de relleno y expresiones verbosas, a la vez que conserva el significado:

• Elimina palabras de relleno ("por favor", "creo que", "básicamente", "en realidad")
• Condensa expresiones verbosas ("con el fin de" → "para", "como resultado de" → "porque")
• Elimina fórmulas de cortesía atenuantes ("¿Te importaría...?", "Si fuera posible...")
• Más de 30 reglas de expresiones regulares optimizadas para prompts de programación

Ideal para: Flujos de trabajo diarios de programación y equipos preocupados por los costes.

Modo agresivo (~50 % de ahorro)

Gestión inteligente del historial para sesiones largas:

• Envejecimiento de mensajes — los mensajes antiguos se comprimen progresivamente
• Resumen de resultados de herramientas — las salidas largas de herramientas se sustituyen por resúmenes
• Protecciones de integridad estructural — garantizan que los pares tool_use + tool_result se mantengan coherentes
• Consideración de la ventana de contexto — respeta los límites de tokens de cada modelo

Ideal para: Sesiones de depuración prolongadas y bases de código grandes.

Modo ultra (~75 % de ahorro)

Compresión máxima para situaciones en las que los tokens son críticos:

• Poda heurística — elimina mensajes por debajo del umbral de relevancia
• Reducción de bloques de código — comprime ejemplos de código repetitivos
• Truncamiento mediante búsqueda binaria — encuentra el punto de corte óptimo para la ventana de contexto
• Incluye todas las funciones del modo agresivo

Ideal para: Cuando alcanzas repetidamente los límites de contexto.

Modo RTK (rango upstream del 60-90 %)

El modo RTK está optimizado para las salidas detalladas de herramientas que aparecen en las sesiones con agentes de programación:

• Detecta clases de comandos/salidas como git status, git diff, git log, ejecutores de pruebas, compilaciones de TypeScript/Vite/Webpack, ESLint/Biome/Prettier, auditorías/instalaciones de npm, registros de Docker, salidas de infraestructura y salidas genéricas del shell
• Aplica paquetes de filtros JSON desde open-sse/services/compression/engines/rtk/filters/
• Importa filtros del esquema TOML v1 de RTK desde archivos filters.toml globales o del proyecto, con validación de pruebas integradas y control de confianza para los archivos del proyecto
• Incluye 49 filtros integrados con muestras de verificación en línea
• Elimina secuencias de control ANSI, barras de progreso, líneas repetidas y ruido que no permite tomar medidas
• Conserva fallos, errores, advertencias, archivos modificados, resúmenes y la parte final de las salidas largas
• Admite filtros de proyecto sujetos a controles de confianza, filtros globales y recuperación opcional de la salida sin procesar y redactada

Ideal para: Sesiones con agentes que incluyen transcripciones de shell, compilación, pruebas, git, grep y salidas de archivos.

Modo apilado (rango apto del 78-95 %)

El modo apilado ejecuta varios motores de compresión en un orden determinista. La canalización predeterminada es:

RTK -> Caveman

Este orden compacta primero la salida de terminal/herramientas y, a continuación, aplica la condensación semántica de Caveman al prompt restante en lenguaje natural. Las canalizaciones apiladas pueden configurarse globalmente o mediante combos de compresión asignados a combos de enrutamiento.

Ideal para: Contextos mixtos con registros extensos de herramientas, además de instrucciones humanas o resúmenes del asistente.

---

Cálculo del ahorro con los proyectos de origen

OmniRoute documenta los ahorros por compresión a partir de dos fuentes: las pruebas de rendimiento de los proyectos de origen y la propia composición de motores de OmniRoute.

Fuente	Cifra del README del proyecto de origen utilizada aquí
Caveman	~75% menos tokens de salida, 65% de ahorro medio de salida en las pruebas, intervalo de 22-87% y herramienta de compresión de entrada de ~46%
RTK	Ahorro de 60-90% en la salida de comandos; sesión de ejemplo de ~118,000 -> ~23,900 tokens, es decir, 79.7% de ahorro (~80%)

Para las cargas útiles de herramientas/contexto que se solapan, la combinación predeterminada de OmniRoute apila los motores:

RTK -> Caveman

Los ahorros combinados son multiplicativos, no aditivos:

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%

Esa cifra de 78-95% se aplica cuando tanto RTK como Caveman pueden reducir la misma carga útil de entrada/contexto. El modo de salida de respuestas de Caveman es independiente: cuando está habilitado, se utilizan los ahorros de salida propios de Caveman (65% de media, ~75% como cifra destacada e intervalo de 22-87%). Los ahorros totales de facturación dependen de la combinación de prompts y salidas.

Qué significa realmente "elegible"

El intervalo destacado del 15-95% es real, pero solo se aplica a contenido redundante o verboso: líneas de error repetidas, un registro de compilación que inunda la salida con la misma advertencia o un volcado sobredimensionado de grep/lectura de archivos. Esto no significa que todas las solicitudes ahorren esa cantidad.

Verificado empíricamente (tests/unit/compression/stacked-compression-tool-result-savings.test.ts): una ejecución stacked (RTK + Caveman) sobre un bloque tool_result con formato de Anthropic que contenía 300 líneas de error idénticas produjo un ahorro de tokens del 95.93% / un ahorro de caracteres del 96.26%, plenamente dentro del intervalo anunciado. Sin embargo, la misma canalización aplicada a una salida normal y no redundante de herramientas (una lista limpia de coincidencias de grep, una lectura breve de un archivo o texto conversacional normal) produce correctamente un ahorro cercano a cero, porque no hay nada repetitivo que eliminar y validateCompression() (validation.ts) se niega a enviar una reescritura que elimine o modifique bloques de código, URLs, encabezados, versiones o identificadores de constantes EN MAYÚSCULAS.

Este es un comportamiento esperado y seguro, no un error: una sesión de programación que principalmente lea/busque con grep en archivos limpios experimentará un ahorro total moderado incluso con la compresión totalmente habilitada, mientras que una sesión que se encuentre con un bucle fallido o un linter demasiado prolijo verá el intervalo completo del 78-95% en ese tráfico. No utilice el bajo porcentaje de ahorro acumulado de una sola sesión como prueba de que la compresión está mal configurada; compruebe primero si la salida subyacente de la herramienta era realmente redundante.

---

Visualización del ahorro de tokens

Sin compresión:      47K tokens enviados al LLM
Con Lite:            40K tokens enviados          (15% de ahorro — seguro, siempre activo)
Con Standard:        33K tokens enviados          (30% de ahorro — reglas de estilo caveman)
Con Aggressive:      24K tokens enviados          (50% de ahorro — envejecimiento + resumen)
Con Ultra:           12K tokens enviados          (75% de ahorro — poda heurística)
Con RTK:             19K-5K tokens enviados       (60-90% de ahorro en la salida de comandos/herramientas)
Con Stacked:         10K-2.5K tokens enviados     (intervalo elegible de RTK+Caveman del 78-95%)

---

Configuración

Panel de control

Ve a Dashboard → Context & Cache:

• Caveman — selección de modo, paquetes de idioma, vista previa y valores predeterminados globales
• RTK — vista previa del filtro de comandos, configuración de seguridad de RTK y catálogo de filtros
• Compression Combos — canalizaciones de motores con nombre asignadas a combinaciones de enrutamiento
• Auto-Trigger Threshold — activa automáticamente la compresión cuando el número de tokens supera el umbral

Anulación por combinación

En Dashboard → Context & Cache → Compression Combos, asigna una combinación de compresión a una combinación de enrutamiento:

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

Esto te permite usar compresión apilada con proveedores gratuitos o de programación, mientras mantienes el modo ligero en las suscripciones de pago.

Esta asignación de "Anulación por combinación" es un control diferente de la anulación del modo de compresión de la combinación de enrutamiento (Default/Off/Lite/Standard/Aggressive/Ultra): dicha anulación no selecciona una canalización de combinación de compresión con nombre; simplemente establece el campo compressionMode consultado por resolveCompressionPlan. Puede configurarse en la tarjeta de la combinación (Dashboard → Combos) o, desde #6760, para cada combinación de enrutamiento en la lista "Assign to routing" de Dashboard → Context & Cache → Compression Combos, justo al lado de la casilla de asignación de canalización documentada anteriormente. Ambas interfaces guardan los cambios mediante el mismo endpoint PUT /api/combos/{id}.

Anulación por solicitud

Envía el encabezado de solicitud x-omniroute-compression para anular el plan de compresión de una sola solicitud. Tiene la máxima prioridad: prevalece sobre la anulación de la combinación de enrutamiento, el perfil activo, la activación automática y el valor predeterminado del panel. Los valores desconocidos se ignoran (la solicitud nunca se rechaza) y el interruptor maestro global sigue controlándolo todo: cuando la compresión está desactivada globalmente, el encabezado no puede activarla. Valores:

Valor	Efecto
off	Sin compresión para esta solicitud.
default	El perfil predeterminado derivado del panel (ignora el perfil activo).
engine:<id>	Un único motor cuando está habilitado, por ejemplo, engine:rtk.
<combo>	Una combinación con nombre, buscando primero por nombre (sin distinguir mayúsculas y minúsculas) y luego por id.

El plan aplicado se devuelve en el encabezado de respuesta X-OmniRoute-Compression: <mode>; source=<source>, donde <source> es uno de request-header, routing-override, active-profile, auto-trigger, default u off.

API

# Obtener la configuración de compresión
curl http://localhost:20128/api/settings/compression

# Actualizar la configuración de compresión
curl -X PUT http://localhost:20128/api/settings/compression \
  -H "Content-Type: application/json" \
  -d '{"defaultMode":"stacked","autoTriggerMode":"stacked","autoTriggerTokens":32000}'

# Obtener una vista previa de una carga útil específica de RTK/apilada
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"}]}'

# Enumerar los paquetes de filtros de RTK
curl http://localhost:20128/api/context/rtk/filters

# Probar RTK directamente con metadatos opcionales del comando
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"}'

---

Qué se protege

El motor de compresión siempre conserva:

• ✅ Bloques de código (delimitados y en línea)
• ✅ URL y rutas de archivos
• ✅ Estructuras JSON y datos estructurados
• ✅ Identificadores y tokens técnicos protegidos
• ✅ Expresiones matemáticas
• ✅ Definiciones de llamadas a herramientas/funciones
• ✅ Prompts del sistema (en modo ligero)

La recuperación de salida sin procesar de RTK oculta claves de API comunes, tokens de portador, tokens de Slack, claves de acceso de AWS, contraseñas, tokens y secretos antes de que se almacene cualquier dato.

---

Estadísticas de compresión

Cada solicitud comprimida incluye estadísticas en los registros del servidor:

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

---

Hoja de ruta por fases

Fase	Modos	Estado
Fase 1	Desactivado, Ligero	✅ Publicada
Fase 2	Estándar, Agresivo, Ultra	✅ Publicada
Fase 3	RTK, Apilado, Combinaciones de compresión	✅ Publicada
Fase 4	Estilos de salida, Ultra de nivel SLM, conjunto de evaluación	✅ Publicada
Fase 4C	Presupuesto de contexto adaptativo («dial») — motor de cálculo + API (contextBudget en PUT /api/settings/compression) + controles de modo/política del panel	✅ Publicada

---

Agradecimientos

Las reglas de compresión del modo estándar están inspiradas en Caveman de JuliusBrussee (⭐ 51K+) — el proyecto viral «por qué usar muchos tokens cuando pocos tokens bastan». Caveman informa de ~75% menos tokens de salida, un ahorro medio de salida del 65% en pruebas comparativas, un intervalo de salida del 22-87% y una herramienta de compresión de entrada de ~46%.

El modo RTK está inspirado en RTK - Rust Token Killer de RTK AI — el proyecto de compresión de alto rendimiento para filtrar la salida de terminales, compilaciones, pruebas, git y herramientas. RTK informa de un ahorro del 60-90%, y la sesión de ejemplo de su README muestra un ahorro de ~80%.

---

Sistemas avanzados de compresión

Además de los 7 modos estándar, OmniRoute incluye varios sistemas avanzados de compresión que funcionan automáticamente según el contexto.

Compresión consciente de la caché

Algunos proveedores (como Anthropic con almacenamiento en caché de prompts) admiten el almacenamiento en caché de prompts, lo que les permite almacenar en caché partes del prompt para reducir los costes y la latencia. Cuando el almacenamiento en caché está activado, la compresión agresiva puede, de hecho, perjudicar el rendimiento porque modifica los tokens almacenados en caché, invalidando así la caché.

El módulo cachingAware.ts resuelve este problema mediante la detección del contexto de almacenamiento en caché y el ajuste de la estrategia de compresión en consecuencia.

Cómo funciona

1. Detectar el contexto de almacenamiento en caché — Examina el cuerpo de la solicitud en busca de marcadores cache_control
2. Identificar proveedores con almacenamiento en caché — Comprueba si el proveedor de destino admite almacenamiento en caché
3. Ajustar la estrategia — Reduce aggressive/ultra a standard para los proveedores con almacenamiento en caché
4. Omitir el prompt del sistema — Los prompts del sistema suelen almacenarse en caché, por lo que no se comprimen
5. Usar transformaciones deterministas — Solo utiliza transformaciones que produzcan una salida coherente

Ejemplo de código

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" }, // ← Marcador de caché
};

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

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

Cuándo usarlo

La compresión consciente de la caché está siempre activada — no requiere configuración. Solo entra en funcionamiento cuando:

• La solicitud contiene marcadores cache_control
• El proveedor de destino admite el almacenamiento en caché de prompts (Anthropic, OpenAI, etc.)

Envejecimiento progresivo

Las conversaciones largas acumulan muchos turnos de mensajes, pero los turnos más antiguos pierden relevancia. El módulo progressiveAging.ts degrada los mensajes según la distancia entre turnos:

• Turnos recientes (0-3): Se conservan literalmente (con todos los detalles)
• Turnos intermedios (4-8): Compresión ligera (limpieza de espacios en blanco y formato)
• Turnos antiguos (9+): Compresión Caveman (eliminación de contenido superfluo y resumen)
• Turnos muy antiguos (20+): Se resumen de forma exhaustiva o se descartan

Ejemplo de código

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 turnos más ...
];

const { messages: aged, saved } = applyAging(messages, {
  verbatim: 3, // Primeros 3 turnos: literales
  light: 8, // Turnos 4-8: compresión ligera
  moderate: 20, // Turnos 9-20: compresión Caveman
  // Turnos 21+: resumen exhaustivo
});

// saved = número de tokens ahorrados

Cuándo usarlo

El envejecimiento progresivo está siempre activado para los modos aggressive y ultra. Es especialmente eficaz para:

• Sesiones de programación prolongadas
• Conversaciones de varios días
• Flujos de trabajo con agentes y muchas llamadas a herramientas

Modo de salida cavernícola

El módulo outputMode.ts inyecta instrucciones en el prompt del sistema para hacer que el propio modelo produzca una salida comprimida y concisa (un estilo «cavernícola»).

Cómo funciona

En lugar de comprimir la entrada, este modo añade un prompt del sistema como:

«Responde con el mínimo de palabras. Omite las cortesías. Usa frases cortas».

Esto funciona especialmente bien para:

• Generación de código (salida más concisa = menos tokens)
• Preguntas y respuestas rápidas (sin necesidad de explicaciones detalladas)
• Procesamiento por lotes (maximiza el rendimiento)

Cuándo usarlo

El modo de salida cavernícola es opcional; actívalo mediante la configuración combinada:

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

Estilos de salida (catálogo)

El modo de salida cavernícola anterior es la ruta heredada de estilo único. La fase 4 lo generalizó en un catálogo de estilos de salida componibles: OUTPUT_STYLE_CATALOG en open-sse/services/compression/outputStyles/catalog.ts. Cada estilo es una instrucción del prompt del sistema que hace que el propio modelo produzca una salida más económica; los estilos pueden activarse juntos y se inyectan en el orden del catálogo.

Estilo	id	Qué hace	Idiomas de las instrucciones
Prosa concisa	terse-prose	Elimina relleno, artículos y expresiones de duda; mantiene exacto el contenido técnico. El mismo texto que el modo de salida cavernícola heredado (referenciado, no repetido).	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
Menos código	less-code	Escalera YAGNI: el cambio funcional más pequeño, sin abstracciones no solicitadas.	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
Coleta (desarrollador sénior perezoso)	ponytail	«El mejor código es el que nunca se escribió»: reutilizar > reescribir, causa raíz > síntoma, el diff funcional más corto.	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
Tengo TDAH (acción primero)	i-have-adhd	La acción primero (comando/ruta/fragmento antes que la prosa), pasos numerados y limitados, UN siguiente paso concreto, sin preámbulo/resumen/cierres. Adaptado de ayghri/i-have-adhd (MIT).	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
CJK conciso (文言)	terse-cjk	Estilo ultraconciso de chino clásico.	zh (restringido por configuración regional: solo se ofrece cuando el idioma resuelto es zh)

Cada estilo incluye tres niveles de intensidad —lite, full, ultra— y cada nivel termina con la cláusula de límites compartida, que conserva literalmente los bloques de código, las rutas de archivos, los comandos, los mensajes de error, las URLs y los identificadores.

Cómo funciona la inyección

applyOutputStyles() (open-sse/services/compression/outputStyles/apply.ts) resuelve la selección respecto al catálogo (los identificadores desconocidos y los estilos que no coinciden con la configuración regional se descartan, sin generar nunca un error), concatena las instrucciones seleccionadas en el orden del catálogo, añade la cláusula de límites una sola vez e inserta el resultado al principio del prompt del sistema tras un único marcador de idempotencia ([OmniRoute Output Styles]); volver a aplicarlo no produce ningún efecto. Cuando el idioma detectado de la solicitud dispone de una traducción, se inyecta la instrucción localizada en lugar de la inglesa.

Cómo activarlos

En el panel: Contexto → Configuración → Compresión; hay una fila por estilo con un interruptor de activación/desactivación y un selector de nivel. Mediante programación, la configuración de compresión conserva la selección de esta forma:

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

Compatibilidad con versiones anteriores: la configuración combinada heredada outputMode: "caveman" sigue funcionando y se asigna a terse-prose, siendo idéntica byte por byte a la antigua inyección en todos los idiomas heredados.

Selección de idioma: con languageConfig.enabled activado, autoDetect elige el idioma del último mensaje del usuario (el mismo detector que usan los motores de entrada); desactivar autoDetect fija defaultLanguage. Desactivado → inglés.

La matriz de estilos × idiomas está fijada por tests/unit/compression/output-styles-i18n-matrix.test.ts: un estilo nuevo no puede publicarse sin al menos una traducción a pt-BR (o una excepción explícita registrada), y un estilo existente no puede perder silenciosamente una configuración regional. Para añadir un estilo, consulta EXTENDING_COMPRESSION.md.

Compresión de resultados de herramientas

El módulo toolResultCompressor.ts proporciona 5 estrategias de compresión especializadas para resultados de herramientas (llamadas a funciones, salidas de agentes, resultados de búsqueda, etc.):

1. Compresión de resultados de búsqueda — Elimina resultados redundantes y conserva los N primeros
2. Compresión de lectura de archivos — Trunca archivos grandes y conserva cabeceras/importaciones
3. Compresión de ejecución de código — Conserva únicamente los elementos esenciales de stdout/stderr
4. Compresión de consultas de bases de datos — Limita las filas y elimina metadatos detallados
5. Compresión de respuestas de API — Elimina campos nulos y condensa matrices

Cuándo usarla

La compresión de resultados de herramientas está siempre activada cuando hay llamadas a herramientas. No se necesita configuración.

Canalización apilada

El modo apilado ejecuta varios motores en secuencia: normalmente RTK primero (ahorro del 60-90 % en la salida de herramientas) y después Caveman (un 30 % de ahorro adicional en el texto restante). Esto consigue un ahorro total del 78-95 %.

Cómo funciona

Entrada (1000 tokens)
  → RTK (filtro con reconocimiento de comandos) → 200 tokens
    → Caveman (eliminación de relleno) → 140 tokens
  → Salida (140 tokens, 86 % de ahorro)

Cuándo usarla

Usa el modo apilado para:

• Flujos de trabajo con uso intensivo de herramientas (programación con agentes, investigación)
• Procesamiento por lotes sensible a los costes
• Cuando necesites el máximo ahorro de tokens

Configúralo mediante la configuración combinada:

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

---

Anulaciones de compresión por combo

Puedes anular el modo de compresión global para cada combo a fin de ajustar el comportamiento para distintos casos de uso:

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

Esto resulta útil para:

• Combos de programación: Usa el modo aggressive para sesiones largas
• Combos de preguntas y respuestas rápidas: Usa el modo lite para obtener respuestas rápidas
• Combos con uso intensivo de herramientas: Usa el modo stacked para maximizar el ahorro
• Combos de producción: Usa el modo cache-aware para proveedores con almacenamiento en caché

---

Véase también

• Configuración del entorno — Variables de entorno de compresión
• Guía de arquitectura — Funcionamiento interno del pipeline de compresión
• Guía del usuario — Primeros pasos con la compresión
• Compresión RTK — Filtros RTK, modelo de confianza, puerta de verificación y recuperación de la salida sin procesar
• Motores de compresión — Caveman, RTK, apilamiento, APIs, MCP y panel de control
• Formato de las reglas de compresión — Formato JSON de los paquetes de reglas
• Paquetes de idioma de compresión — Reglas de Caveman específicas de cada idioma