Tabla de contenido
Compresión de contexto determinista y segura para caché en agentes de codificación LLM: por qué la creamos, cómo funciona y cómo se compara con Headroom.
Cada paso que da un agente de codificación, reenvía todo su historial de trabajo al modelo: cada obtener-apt Registra cada advertencia del compilador, cada barra de progreso. En una tarea larga, el modelo vuelve a leer la misma salida de compilación docenas de veces, y usted paga por cada lectura. Compresor OptScale elimina esa redundancia en vuelo. Se ejecuta dentro de OptScale AI y reescribe la salida de la herramienta generada por máquina en un formato más corto, completamente etiquetado y recuperable, sin tocar al agente, sus indicaciones ni sus resultados. Su motor es el proyecto de código abierto optscale-compressor: un único binario determinista de Rust.
Prefacio: ¿Por qué construir el nuestro propio?
Espacio libre es un compresor de contexto de código abierto (Apache 2.0) ya establecido, y OptScale Kompressor comenzó como una adaptación de sus compresores algorítmicos. Entonces, ¿por qué no simplemente usar Headroom? Porque Headroom pasó de ser un compresor a una plataforma, y necesitábamos un compresor.
En lo que se ha convertido Headroom
Realizamos una auditoría de Headroom v0.40.0 (rama principal, 10 de octubre de 2026) comparándolo con optscale-kompressor 0.13. Las líneas sin procesar se contaron de la misma manera para ambos proyectos, excluyendo las pruebas.
| Contenido | Formatos | ¿Qué hace Kompressor? |
|---|---|---|
| Generar y empaquetar la salida | apto, dpkg, pepita, npm, hacer, compilar y enlazar pasos |
Pliega las líneas repetidas en una sola línea más [×N], con marcas de tiempo, identificadores y números normalizados |
| Registros | Registros y rastreos de pila con marcas de tiempo y etiquetas de nivel. | Mismo formato; los registros largos conservan los errores con contexto, las primeras advertencias vistas, los resúmenes y la cola. |
| Diagnóstico del compilador | archivo:línea:columna: error: de gcc/clang, TypeScript, Python |
Conserva todos los diagnósticos, descarta la fuente eco y los cursores cuando son más pequeños. |
| El terminal redibuja | \r Barras de progreso, medidores de descarga, bucles de entrenamiento; flujos de líneas de una sola plantilla |
Conserva solo el último fotograma; colapsa las secuencias de plantillas. |
| JSON | Objetos y matrices, incluyendo contenido anidado en cadenas. | Muestra matrices largas, conservando siempre errores, valores atípicos y puntos de cambio. |
| Tablas | CSV, TSV, Markdown | Muestra las filas, conserva el encabezado. |
| Resultados de la búsqueda | grep -n, ripgrep |
Agrupa por archivo, conserva los archivos principales y cuenta el resto. |
| Diferencias | Unificado y git diff |
Estrecha los trozos hasta las líneas alrededor de cada cambio. |
| Listados y volcados | encontrar, ls -l, PD, df, Docker PS; objdump, readelf, Nuevo Méjico, xxd |
Conserva una muestra textual de la cabecera y la cola. |
| Código fuente | Python, JavaScript, TypeScript, Go, Rust, Java, C#, C, C++ | Omite los cuerpos de funciones largas, conserva las firmas; el resultado debe volver a analizarse. |
| Configuración | YAML, TOML, INI | Elimina comentarios y líneas en blanco; pliega bloques generados repetidos. |
| Mezclado | Prosa con bloques incrustados | Comprime los bloques, pero la prosa permanece idéntica byte a byte. |
| HTML | Páginas web y lenguaje de marcado | Detectado por separado y plegado como texto plano; sin extracción de artículos. |
| Texto sin formato | Todo lo demás | Pliega las líneas duplicadas; los documentos nunca se pliegan según la plantilla. |
La compresión es una de las muchas tareas de Headroom. El mismo código fuente se distribuye de la siguiente manera:
- memoria del agente;
- un ciclo de aprendizaje que reescribe
CLAUDE.md; - modelado de salida y un enrutador modelo;
- una caché semántica y compresión de imágenes;
- seguimiento de suscripciones;
- Envoltorios para 18 agentes de codificación e IDE.
Esa amplitud se ajusta a un optimizador de escritorio por desarrollador. No es el componente que necesitábamos.
Por qué eso importaba
- Un componente, no una plataforma. Kompressor presta servicio a muchos equipos y agentes a la vez dentro de OptScale AI. El proxy de código abierto de Headroom es de un solo usuario: el estado reside en
~/.headroom, y la identidad solo se acepta desde el bucle de retorno. Cientos de configuraciones también tendrían que fijarse y mantenerse fijas. - El determinismo decide la caché, y la caché decide la factura. La mayor parte de la entrada de un agente se factura como lecturas de caché (sección 1). Si la misma herramienta comprime la salida de forma diferente en el siguiente turno, se vuelve a calcular el precio de toda la conversación. Headroom envía el último mensaje del usuario a sus compresores, y su modelo de aprendizaje automático se ejecuta con un presupuesto de tiempo, por lo que su salida puede depender de la pregunta y de la carga de la máquina. El nuestro depende únicamente de su entrada: sin reloj, sin aleatoriedad, sin consulta.
- Eliminar la redundancia, no el significado. La función de resumen ofrece una excelente relación de compresión. Al adaptar el compresor de prosa de Headroom, se eliminaron 6,2 puntos más, pero se perdieron 12,9 puntos de los detalles que los agentes reutilizaron. Kompressor se basa en reglas, cada omisión está etiquetada y se puede recuperar, y su comportamiento se puede auditar línea por línea.
- Un solo proceso, un solo camino. La compresión y la recuperación residen en un único archivo binario. El proxy inyecta la herramienta de recuperación y la ejecuta por sí mismo, por lo que nunca pueden discrepar sobre el modo, el inquilino o el estado.
Conservamos las mejores ideas de Headroom: la compresión y recuperación, los compresores principales de JSON, registro, búsqueda y diferencias, y sus hallazgos sobre Claude Code y Codex, tras un proxy. Eliminamos todo lo que hacía que la salida dependiera de algo más que la entrada, y todo lo que no fuera compresión.
TL;DR
- Medido sobre el importe real, tarea por tarea, en Terminal-Bench 2.1 con el descuento de caché de indicaciones incluido (configuración en la sección 4).
- 22,7% menor coste que sin compresión, 25% menos tokens de entrada y ningún cambio significativo en la tasa de resolución.
- Aproximadamente el doble del ahorro que ofrece Headroom. Con la misma base de referencia, Headroom ahorró 8,21 TP3T con sus valores predeterminados y 11,61 TP3T en su configuración más agresiva. En comparación directa, Kompressor es 15,8% más barato y envía 24% tokens de entrada menos. Su tasa de resolución es estadísticamente la misma (81,1% frente a 81,6%).
- Ofrece una compresión 2,8 veces mayor que Headroom con su modelo de aprendizaje automático activado, y 8,6 veces mayor que sin él. Kompressor elimina 62,81 TP3T de los 34,2 millones de caracteres de la salida real de la herramienta, frente a los 22,61 TP3T y 7,31 TP3T, en aproximadamente 1/440 del tiempo que necesita el modelo de Headroom. Todos los detalles eliminados se conservan.
- Mejor ajuste: Entrenamiento de ML, compilación de código fuente y canalizaciones de datos. Se eliminan entre 55 y 811 TP3T de la salida de la herramienta y se descuentan entre 26 y 371 TP3T de la factura.
- Peticiones más pequeñas: Las solicitudes de más de 200.000 tokens se vuelven 15 veces más raras, lo que mantiene a los agentes fuera de la ventana de contexto.
El problema
Un agente de codificación ejecuta un comando, lee el resultado, piensa y ejecuta el siguiente, y en cada turno envía toda la conversación de vuelta al modelo. A continuación, se presentan tres hechos:
- La mayor parte del mensaje es la salida de la herramienta. Representa aproximadamente la mitad de todos los bytes de las indicaciones en nuestros registros. Casi todo lo demás es razonamiento cifrado, que no se puede comprimir.
- La salida de la herramienta es altamente redundante. Las barras de progreso se actualizan, los gestores de paquetes se repiten y los ejecutores de pruebas imprimen líneas casi idénticas.
- El almacenamiento en caché instantáneo cambia la economía. Aproximadamente 93% de los tokens de entrada son lecturas de caché a una décima parte del precio. Un compresor que daña la caché puede costar más de lo que ahorra.
Cómo funciona
agente → OptScale AI ──→ Kompressor ──→ proveedor de modelos │ │ │ └─→ almacén de referencias (de corta duración, por organización) │ └─ el modelo llama a kompressor_retrieve(ref) → se devuelve el contenido original
- Determinista y basado en reglas. Sin llamadas a ML ni LLM. Misma entrada, mismos bytes, en cada turno.
- Etiquetado y recuperable. Cada elisión se convierte en un marcador como
[×37 ref:k_Qm9v…]o[... Se omitieron 412 líneas de registro [ref:k_…]; 3 ERRORES, 1 ADVERTENCIA]. El ID es un hash del contenido eliminado, y el modelo puede recuperarlo durante una hora. - Peor aún, falla al abrirse. Un resultado que no sea menor se descarta, y cualquier error envía la solicitud sin cambios.
- Solo salida de la máquina. Los mensajes del sistema, del desarrollador y del asistente, las salidas de menos de ~512 caracteres y los bloques que contienen puntos de interrupción de caché nunca se modifican.
- Pequeño y rápido. Un binario estático de aproximadamente 33 000 líneas de Rust, con un tiempo de procesamiento de unos 0,2 ms por KB de salida de la herramienta. Utiliza almacenamiento SQLite y está empaquetado para Linux, macOS y contenedores.
Cada salida de la herramienta se clasifica y se envía a un compresor diseñado para su formato:
| Contenido | Formatos | ¿Qué hace Kompressor? |
|---|---|---|
| Generar y empaquetar la salida | pasos con apt, dpkg, pip, npm, make, compilación y enlace | Pliega las líneas repetidas en una sola línea más [×N], con marcas de tiempo, identificadores y números normalizados. |
| Registros | Registros y rastreos de pila con marcas de tiempo y etiquetas de nivel. | Mismo formato; los registros largos conservan los errores con contexto, las primeras advertencias vistas, los resúmenes y la cola. |
| Diagnóstico del compilador | archivo:línea:columna: error: de gcc/clang, TypeScript, Python | Conserva todos los diagnósticos, descarta la fuente eco y los cursores cuando son más pequeños. |
| El terminal redibuja | barras de progreso, medidores de descarga, bucles de entrenamiento; flujos de líneas de una sola plantilla | Conserva solo el último fotograma; colapsa las secuencias de plantillas. |
| JSON | Objetos y matrices, incluyendo contenido anidado en cadenas. | Muestra matrices largas, conservando siempre errores, valores atípicos y puntos de cambio. |
| Tablas | CSV, TSV, Markdown | Muestra las filas, conserva el encabezado. |
| Resultados de la búsqueda | grep -n, ripgrep | Agrupa por archivo, conserva los archivos principales y cuenta el resto. |
| Diferencias | Unificado y git diff | Estrecha los trozos hasta las líneas alrededor de cada cambio. |
| Listados y volcados | find, ls -l, ps, df, docker ps; objdump, readelf, nm, xxd | Conserva una muestra textual de la cabecera y la cola. |
| Código fuente | Python, JavaScript, TypeScript, Go, Rust, Java, C#, C, C++ | Omite los cuerpos de funciones largas, conserva las firmas; el resultado debe volver a analizarse. |
| Configuración | YAML, TOML, INI | Elimina comentarios y líneas en blanco; pliega bloques generados repetidos. |
| Mezclado | Prosa con bloques incrustados | Comprime los bloques, pero la prosa permanece idéntica byte a byte. |
| HTML | Páginas web y lenguaje de marcado | Detectado por separado y plegado como texto plano; sin extracción de artículos. |
| Texto sin formato | Todo lo demás | Pliega las líneas duplicadas; los documentos nunca se pliegan según la plantilla. |
El caballo de batalla es eliminación de duplicados, no resumen.: el modelo siempre conserva al menos una instancia real de cada línea distinta, y siempre sabe qué se eliminó y cómo recuperarlo.
Lo que mejoramos con respecto a Headroom
El motor de OptScale Kompressor se basa en los compresores algorítmicos de Headroom. Las dos primeras listas comparan las capas deterministas. La siguiente prueba también evalúa el rendimiento de Headroom con su modelo de aprendizaje automático en la detección de Magika y en un modelo ModernBERT para texto plano y código. Hemos omitido el aprendizaje automático por diseño.
Por qué eso importaba
Las primeras cinco filas corresponden a compresores de la tabla de la sección 2; el resto son mecanismos nuevos.
| Contenido | Efecto |
|---|---|
| El terminal redibuja | Una secuencia de entrenamiento de 30.807 caracteres se convirtió en 274 caracteres. |
| Diagnóstico del compilador con fuente con eco (Headroom las lee como coincidencias de grep) | En una salida de gcc, 1.873 de 2.334 caracteres eran eco y circunflejos. |
| Volcados binarios y de desensamblaje, direcciones nunca normalizadas | Una línea 880 readelf La tabla se convirtió en aproximadamente 1000 caracteres. |
| Flujos de líneas de una sola plantilla | +2,3 puntos de cobertura |
Instalación de paquetes, cada Configurando ( ) línea mantenida |
Un 27,6K apto El registro pasó de 15% a 97% fue eliminado. |
márgenes de numeración de línea (gato -n, sed -n, grep -n): números eliminados, cuerpo comprimido por tipo, números vueltos a colocar |
Se eliminaron 33 cargas útiles, que pasaron de 0% a 54%. |
Marco de arnés del agente (Códice ID de fragmento, Tiempo en la pared, código de salida): separado y vuelto a adjuntar textualmente |
Se eliminó un resultado de Codex Python de 0% a 87%. |
| Registros o código dentro de cadenas JSON, comprimido por el compresor propio de ese formato | — |
| Recuperación a distancia: recuperar un fragmento omitido por líneas, caracteres, puntero JSON o grep | — |
Mejorado: cosas que ambos hacen
Si bien ambos motores procesan el mismo contenido, el nuestro va más allá:
- Líneas repetidas, plegadas incluso cuando no son adyacentes;
- texto plano, comprimido sin ML;
- cargas útiles mixtas de prosa y datos;
- Código fuente truncado y en C/C++;
- archivos de configuración generados.
El efecto medido se puede apreciar en la reproducción a continuación. Kompressor también se mantiene independiente de las consultas y determinista, verifica la salida de cada compresor de forma centralizada y estima los tokens con mayor precisión.
Medido: el mismo tráfico a través de ambos, con y sin el ML de Headroom.
Reprodujimos las mismas 6255 salidas de herramientas reales (34,2 millones de caracteres) a través de tres motores, todos con la configuración predeterminada:
- optscale-kompressor 0.13;
- Headroom 0,40 con su modelo ML desactivado;
- Headroom 0.40 con su modelo ML activado: detección Magika más su modelo ModernBERT (la compilación ONNX int8 de 274 MB), en ONNX Runtime.
| Tipo de contenido | Cuota de tráfico | Compresor | Espacio libre, ML en | Espacio libre, ML apagado |
|---|---|---|---|---|
| Listados y volcados | 27.8% | 81.8% | 22.6% | 7.0% |
| Texto sin formato | 25.3% | 41.0% | 20.6% | 5.2% |
| Generar resultados y registros | 19.3% | 75.4% | 17.1% | 4.2% |
| Código fuente | 13.8% | 35.0% | 31.9% | 0.0% |
| Resultados de la búsqueda | 11.1% | 82.7% | 25.5% | 25.4% |
| Diferencias, configuración, HTML, JSON | 2.7% | 40.9% | 19.8% | 12.5% |
| Todos los resultados de herramientas elegibles | 100% | 62.8% | 22.6% | 7.3% |
| Tiempo por KB de salida de la herramienta | 0,2 ms | 87 ms | 1,5 ms |
El modelo ML triplica la compresión de Headroom, y Kompressor aún elimina 2,8 veces más, en aproximadamente 1/440 del tiempo. El modelo de Headroom alcanzó 5273 de las 6255 salidas, pero solo comprimió 3090. Necesitó una media de 0,3 s por salida y hasta 6,8 s, utilizando aproximadamente cinco núcleos. El código fuente es el único tipo donde ambos se aproximan: 32% frente a nuestro 35%.
Lo que hace el modelo. El modelo de Headroom conserva un subconjunto ordenado de las palabras de entrada y descarta el resto, añadiendo un marcador de recuperación al final. Los espacios en blanco y la sangría desaparecen, y las líneas sin palabras conservadas se borran. Algunos ejemplos de la reproducción:
| Aporte | Salida de Headroom ML |
|---|---|
from __future__ import annotations / import asyncio / import functools |
__futuro__ anotaciones / asyncio / functools |
self.pre_approved = invitación o pre_approved |
autoaprobado o |
43a020: andi $7, $3, 255 |
$7, $3, 255 |
El proceso finalizó con el código 0. |
El proceso finalizó con el código 0. |
Las importaciones de Python pierden sus palabras clave, las asignaciones pierden su lado derecho y el desensamblaje pierde sus direcciones e instrucciones. Kompressor nunca reescribe una línea que conserva. Las líneas se mantienen tal cual o se reemplazan por un marcador etiquetado.
Determinismo. En las repeticiones, tanto en reposo como bajo una carga de CPU elevada, el modelo produjo una salida idéntica byte a byte. Sin embargo, con ONNX limitado a un solo hilo, 3 de las 400 salidas superaron el límite de tiempo de 20 segundos de Headroom y regresaron sin comprimir. Por lo tanto, la salida de Headroom aún depende de la velocidad de la máquina. Kompressor no tiene un límite de tiempo que cumplir.
Retención de lo que los agentes reutilizan. Para cada resultado, tomamos los tokens concretos (rutas de archivo, identificadores, versiones) que el agente utilizó en sus siguientes acciones. Luego, comprobamos si cada token seguía siendo visible en el texto comprimido:
| Compresor | Espacio libre, ML en | Espacio libre, ML apagado | |
|---|---|---|---|
| Caracteres eliminados | 21,5 millones | 7,7 millones | 2,5 millones |
| Los tokens reutilizados aún son visibles. | 86.9% | 96.2% | 98.3% |
| Tokens reutilizados ocultos, por cada millón de caracteres eliminados | 34 | 28 | 39 |
| Fichas ocultas recuperables mediante recuperación | 100% | 69% | 30% |
Headroom muestra más de estos tokens en línea principalmente porque elimina mucho menos. Por cada carácter eliminado, los tres motores los ocultan a una tasa similar. La diferencia está en lo que sucede después. Cada token que oculta Kompressor se encuentra dentro de un fragmento nombrado por una referencia en su salida, a una recuperación de distancia. Algunos de los tokens ocultos de Headroom se dividen mediante su plegado de directorio sin pérdidas (./src/Makefile se convierte ./src/ los Makefile). El resto están detrás de su marcador de recuperación, o han desaparecido.
Nuestra opinión sobre el aprendizaje automático en Headroom
Para Headroom, añadir un modelo fue una decisión acertada. Sus reglas dejan intacta la mayor parte del tráfico de agentes: se eliminan 7%. El aprendizaje automático es la forma más económica de cubrir lo que las reglas no manejan. La reproducción demuestra su eficacia: el aprendizaje automático triplica la compresión de Headroom. Además, encuentra ahorros donde nuestras reglas se detienen deliberadamente, eliminando 28% del código fuente y 12% del texto plano que Kompressor deja intactos. El modelo también es más estable de lo esperado: tanto en reposo como bajo carga pesada, la misma entrada produjo la misma salida.
Seguimos manteniendo el aprendizaje automático fuera de la ruta de la solicitud, por cinco razones que provienen de las mismas mediciones:
- Las reglas dejan menos trabajo para el aprendizaje automático. La mayor parte de lo que recupera el modelo de Headroom proviene de datos que sus propias reglas no recuperan. Nuestras reglas, por sí solas, eliminan 62,81 TP3T del mismo tráfico, frente a los 22,61 TP3T que logran las reglas y el modelo de Headroom en conjunto. El aprendizaje automático tiene un impacto mucho mayor en una base de 71 TP3T que en una de 631 TP3T.
- La latencia se produce en cada turno del agente. El coste computacional no es el problema: unas 4,3 horas de CPU para los 34,2 millones de caracteres es insignificante comparado con la factura de LLM. El tiempo sí lo es. El modelo añadió una media de 0,3 s por salida de la herramienta y hasta 6,8 s, estando ocupado en cinco núcleos, y una solicitud suele contener varias salidas. Nuestro motor tarda 0,2 ms por KB. Con el tiempo de espera de 5 segundos de WebSocket de Codex, la mitad de las salidas más lentas se cortaron y se enviaron sin comprimir.
- Un presupuesto de tiempo es una fuente oculta de indeterminismo. El modelo es determinista, pero el presupuesto de 20 segundos de Headroom no lo es. En una máquina más lenta o con mayor carga de trabajo, una salida comprimida ayer se procesa hoy, y la caché de solicitudes se recalcula. Cada solicitud comparte el presupuesto, por lo que la contención hace que esto sea más probable en producción que en nuestra reproducción.
- Eliminar palabras no es lo mismo que eliminar la redundancia. El modelo de Headroom conserva un subconjunto de las palabras y añade un único marcador al final. El modelo no puede determinar dónde faltan las palabras. La sintaxis también se ve afectada: 2241 de las 2441 salidas comprimidas con código indentado perdieron toda su indentación. Las asignaciones pierden sus lados derechos, y la línea del propio agente “Process exited with code 0” se convierte en “Process exited code 0”. En comparación con las reglas de Headroom por sí solas, el modelo oculta 118 tokens más que los agentes reutilizan. Kompressor conserva cada línea que muestra textualmente y marca cada elisión donde ocurrió.
Peso operativo. El envío del modelo implica:
- una descarga de 274 MB en tiempo de ejecución, o incluyéndola en un paquete;
- un entorno de ejecución ONNX por proceso;
- un sistema de prueba inicial y una cola de inferencia;
- presupuestos de tiempo y disyuntores, que son en sí mismos una causa del punto 3.
Ese es gran parte del crecimiento de la plataforma descrito en el prefacio.
Nuestra conclusión no es “nunca usaremos aprendizaje automático”. Un modelo podría integrarse como una opción para el procesamiento de texto y código que nuestras reglas dejan intacto, el único ámbito donde genera ahorros significativos. Para ello, tendría que cumplir con los mismos requisitos que el resto del motor:
- salida que no depende del tiempo;
- Cada elisión indicaba dónde había ocurrido;
- toda elisión recuperable;
- una frase guardada, nunca reescrita.
Los modelos actuales de eliminación de palabras no cumplen ninguno de estos requisitos, por lo que el motor determinista es la primera opción.
Donde Headroom todavía hace más
- HTML: Headroom extrae el texto del artículo; nosotros convertimos el HTML en texto.
- Brechas que aún no hemos cerrado:
- colapso del marco de pila;
pytestresúmenes;- Compactación de CSV sin pérdida de datos;
- una gramática de PHP;
- Relecturas con números de línea cambiados.
- El archivo dice: Headroom los protege por defecto. Los comprimimos porque cada elisión es recuperable.
Cómo medimos
| Punto de referencia en tiempo real | Terminal-Bench 2.1, 89 tareas; Codex CLI en GPT-5.5 ($5.00 / $0.50 / $30.00 por M tokens sin caché / con caché / de salida); Harbor, 3 pruebas concurrentes |
| Brazos | Sin compresión · Espacio libre, configuración predeterminada con su modelo ML · Espacio libre, configuración más agresiva (recuperación desactivada, tamaño mínimo de 120 tokens, como máximo 8 elementos de matriz) · OptScale Kompressor a través de OptScale AI |
| Métrico | Costo facturado por el proveedor y tokens por prueba |
| Análisis | Promedios por tarea, comparados entre los brazos para las 87 tareas que completó cada brazo; las diferencias se analizaron para determinar su significación estadística. Los porcentajes por cohorte y por tarea se calculan a partir de datos sin redondear, por lo que pueden diferir en un punto de las cifras recalculadas a partir de valores de tabla redondeados. |
| Exclusiones | Pruebas que fallaron en la configuración del agente por razones externas (metadatos del repositorio de paquetes caducados, una descarga fallida) y 7 pruebas de Kompressor afectadas por un defecto conocido de integración de transmisión. |
| Repetición | 6255 salidas de herramientas de al menos 512 caracteres (34,2 millones de caracteres) de nuestros registros de Terminal-Bench; optscale-kompressor 0.13 y Headroom 0.40 con su modelo ML desactivado y activado. |
Cada ahorro aquí es la diferencia entre billetes reales, con el descuento de caché incluido. Los ahorros declarados por el usuario, que valoran los tokens eliminados según la tarifa de la lista no almacenada en caché, no se utilizan.
Antes de realizar cualquier cambio en las naves de Kompressor, se vuelve a ejecutar con dos corpus. El primero son nuestros propios registros de Terminal-Bench 2.1. El segundo es un conjunto independiente de 715 millones de caracteres de salida de herramientas de ejecuciones públicas de la clasificación de Terminal-Bench 4.0, que abarca diez combinaciones de agentes y modelos. Cada ejecución verifica la cobertura, el determinismo, la estabilidad de la caché y que los detalles que reutilizan los agentes se mantengan.
Resultados
Todas las cifras corresponden a una ejecución completa de las 87 tareas que realizó cada brazo.
| Por carrera completa | Sin compresión | Espacio libre | Compresor |
|---|---|---|---|
| Costo | $107.89 | $99.04 | $83.40 |
| Tokens de entrada | 96,1 millones | 95,5 millones | 72,2 millones |
| tokens de entrada no almacenados en caché | 6,68 millones | 5,16 millones | 4,46 millones |
| Tareas resueltas | 82.2% | 81.6% | 81.1% |
| Tiempo medio de ensayo | 4,8 minutos | 5,3 minutos | 4,5 minutos |
El doble de ahorro
| Contra ninguna compresión | Costo | Resuelto |
|---|---|---|
| Compresor | −22,7% | 81.1% |
| Espacio libre, configuración más agresiva | −11,6% | 85.1% |
| Espacio libre, predeterminado | −8,2% | 81.6% |
El ahorro de Kompressor es 2.0× El entorno más agresivo de Headroom y 2.8× su valor predeterminado. Su ahorro en costos y tokens es estadísticamente significativo; las diferencias en la tasa de resolución no lo son.
Cara a cara con Headroom
| Kompressor vs Headroom | Cambiar |
|---|---|
| Costo | −15,8% |
| Tokens de entrada | −24,4% |
| tokens de entrada no almacenados en caché | −13,6% |
| Tasa de resolución | −0,5 pt (81,1% frente a 81,6%, no significativo) |
Kompressor resultó más económico en 54 de las 87 tareas. La diferencia se concentra en tareas largas y con gran cantidad de registros: entrenamiento de aprendizaje automático, compilación cruzada y modelado estadístico. En tareas cortas, ninguna de las herramientas ofrece una reducción significativa.
Por cohorte de tarea
| Grupo de trabajo | Salida de la herramienta por tarea | Remoto | Bill contra sin compresión |
|---|---|---|---|
| Entrenamiento, muestreo y evaluación de aprendizaje automático (17 tareas) | 598.000 caracteres | 81% | −26% |
| Ingeniería inversa y seguridad (12) | 310.000 caracteres | 69% | −5% |
| Compilación de software desde el código fuente (10) | 1.178.000 caracteres | 64% | −28% |
| Configuración del servicio y git (10) | 262.000 caracteres | 58% | −14% |
| Canalizaciones de datos y medios (9) | 288.000 caracteres | 55% | −37% |
| Texto, documentos y secuencias (7) | 120.000 caracteres | 51% | −23% |
| Algoritmos, matemáticas y acertijos (22) | 99.000 caracteres | 48% | −8% |
El aprendizaje automático, las compilaciones de código fuente y las canalizaciones de datos generan 83% del ahorro total. El apéndice desglosa cada grupo tarea por tarea. Generan la mayor cantidad de resultados de la herramienta y son las que más cuestan de ejecutar. La compresión es más débil cuando los resultados son pequeños (tareas algorítmicas) y cuando se trata de prosa que no debe plegarse.
Solicitudes más pequeñas
Un token almacenado en caché es barato, pero aun así se envía y sigue ocupando espacio en la ventana de contexto.
| Sin compresión | Espacio libre | Compresor | |
|---|---|---|---|
| Mensaje enviado por ejecución | 96,1 millones de tokens · ~418 MB | 95,5M · ~415 MB | 72,2 millones · ~314 MB |
| Solicitud del percentil 90 | 106.9K tokens · ~465 KB | 110,5 KB · ~481 KB | 66,5 KB · ~289 KB |
| Solicitudes superiores a 100.000 tokens | 11.2% | 12.0% | 3.2% |
| Solicitudes superiores a 200.000 tokens | 1.9% | 0.6% | 0.13% |
Las cifras en bytes se estiman en 4,35 bytes de JSON de solicitud por token, medidas en las ejecuciones sin compresión.
- Ventana de contexto. Sin compresión, 1,9% de solicitudes superaron los 200K de la ventana de 258K de GPT-5.5, y dos pruebas tuvieron que compactar su contexto. Con Kompressor, el problema se redujo a 0,13%, y una prueba se compactó.
- Máximo contexto en tareas pesadas.
mcmc-muestreo-stanalcanzó un máximo de 60.000 tokens en lugar de 165.000;café-cifar-10a 68K en lugar de 152K. - Sin almacenamiento en caché de mensajes. Cuando un proveedor o nivel no almacena en caché, el recorte de tráfico 25% se aplica directamente a la factura.
Conclusión
Las reglas deterministas, implementadas correctamente, superan a una plataforma más grande con un modelo de aprendizaje automático. En Terminal-Bench 2.1, OptScale Kompressor toma 22,7% de descuento en la factura real, aproximadamente el doble del ahorro de Headroom., Sin cambios apreciables en el éxito de la tarea. Con el mismo tráfico, elimina 2,8 veces más información que Headroom con su modelo de aprendizaje automático, en una fracción del tiempo, y cada detalle eliminado permanece a una sola recuperación de distancia. Su rendimiento es óptimo donde los agentes generan la mayor cantidad de datos: entrenamiento de aprendizaje automático, compilación de código fuente y procesamiento de datos.
Pruébalo:
- Código abierto: ejecutar optscale-kompressor como un único binario.
- En OptScale AI: Activar Kompressor en OptScale AI y cada agente que esté detrás comenzará a guardar a partir de la siguiente solicitud, sin cambios por parte del cliente.
Apéndice: resultados tarea por tarea
- Remoto es la proporción ponderada por facturación de la salida de la herramienta elegible de cada tarea que se toma en la reproducción. Se consideran elegibles las salidas de al menos 512 caracteres.
- Espacio libre En esa columna, se ejecutó con su modelo de aprendizaje automático activado, al igual que en las ejecuciones en vivo.
- Costo los Resuelto provienen de las carreras en vivo.
- Dos tareas,
qemu-startuplosqemu-alpino-ssh, la configuración del agente falló en cada ejecución comprimida y no aparecen en la lista.
Entrenamiento, muestreo y evaluación de aprendizaje automático
Eliminado 81% (Espacio libre 21%) · factura −26% (Espacio libre +10%) · resuelto 84% (Espacio libre 84%, ninguno 88%). La cohorte más fuerte. Los bucles de entrenamiento y los muestreadores imprimen progreso y métricas por miles, y el costo por ensayo se redujo a la mitad. mcmc-muestreo-stan, café-cifar-10 los tabla de clasificación mteb. El valor atípico es texto rápido de tren: Se eliminó 96%, pero un contexto más económico permitió que el agente consultara una larga sesión de entrenamiento durante más tiempo. Aun así, costó mucho menos que con Headroom.
| Tarea | Salida de la herramienta | Eliminado: Kompressor · Headroom | Coste por prueba: ninguno · Headroom · Kompressor | Resuelto: ninguno · Headroom · Kompressor |
|---|---|---|---|---|
texto rápido de tren |
2.807 mil | 96% · 21% | $3.16 · $8.85 · $5.12 | 1/2 · 1/3 · 2/3 |
mcmc-muestreo-stan |
2.089 mil | 74% · 17% | $3.69 · $3.19 · $1.15 | 2/2 · 2/3 · 3/3 |
café-cifar-10 |
1.727 mil | 72% · 20% | $4.79 · $3.04 · $2.30 | 2/2 · 3/3 · 3/3 |
tabla de clasificación mteb |
940 mil | 46% · 40% | $2.15 · $2.52 · $1.04 | 1/2 · 3/3 · 3/3 |
rstan-to-pystan |
585 mil | 64% · 24% | $1.37 · $1.47 · $1.08 | 2/2 · 3/3 · 3/3 |
muestreador de rechazo adaptativo |
512K | 71% · 21% | $1.22 · $0.80 · $0.84 | 2/2 · 3/3 · 3/3 |
planificador de lotes de inferencia llm |
241 mil | 50% · 30% | $0.68 · $0.76 · $0.66 | 2/2 · 3/3 · 1/2 |
segmento de celda sam |
203K | 37% · 34% | $1.13 · $0.77 · $0.83 | 2/2 · 3/3 · 3/3 |
pytorch-model-cli |
198K | 51% · 18% | $0.76 · $0.79 · $0.72 | 2/2 · 3/3 · 3/3 |
paralelismo de tuberías de antorchas |
174K | 50% · 38% | $0.74 · $0.62 · $0.75 | 2/2 · 2/3 · 3/3 |
datos reshard-c4 |
168K | 75% · 19% | $0.99 · $0.88 · $1.00 | 2/2 · 3/3 · 3/3 |
tokens del conjunto de datos de recuento |
141 mil | 20% · 23% | $0.42 · $0.39 · $0.36 | 2/2 · 3/3 · 3/3 |
mteb-retrieve |
125 mil | 41% · 26% | $0.42 · $0.36 · $0.24 | 2/2 · 3/3 · 3/3 |
gpt2-codegolf |
125 mil | 42% · 8% | $2.43 · $1.96 · $1.26 | 1/2 · 2/3 · 2/3 |
recuperación de modelos PyTorch |
63K | 62% · 9% | $0.44 · $0.41 · $0.43 | 1/2 · 0/3 · 0/3 |
paralelismo tensorial de antorcha |
53K | 54% · 37% | $0.44 · $0.53 · $0.50 | 2/2 · 3/3 · 2/3 |
inferencia de modelo hf |
20 mil | 6% · 21% | $0.47 · $0.40 · $0.44 | 2/2 · 3/3 · 2/3 |
Ingeniería inversa y seguridad
Eliminado 69% (Espacio libre 27%) · factura −5% (Espacio libre −16%) · resuelto 76% (Espacio libre 86%, ninguno 83%). El desensamblaje, las tablas de símbolos y las listas de palabras se comprimen muy bien. Sin embargo, estas tareas son cortas y económicas, por lo que su coste varía más según la ruta del agente que según el contexto. En este aspecto, Headroom se destacó claramente.
| Tarea | Salida de la herramienta | Eliminado: Kompressor · Headroom | Coste por prueba: ninguno · Headroom · Kompressor | Resuelto: ninguno · Headroom · Kompressor |
|---|---|---|---|---|
trazado de ruta inverso |
1.032 mil | 76% · 35% | $1.34 · $1.49 · $1.54 | 2/2 · 3/3 · 2/3 |
corregir vulnerabilidad de código |
718K | 77% · 29% | $0.43 · $0.37 · $0.50 | 2/2 · 3/3 · 3/3 |
trazado de rutas |
687K | 66% · 21% | $3.30 · $0.95 · $2.22 | 2/2 · 3/3 · 3/3 |
crack-7z-hash |
563K | 69% · 19% | $0.76 · $1.16 · $1.35 | 2/2 · 3/3 · 3/3 |
secreto vulnerable |
157K | 59% · 25% | $0.19 · $0.21 · $0.39 | 2/2 · 3/3 · 3/3 |
extraer-elfo |
135 mil | 41% · 30% | $0.60 · $0.53 · $0.47 | 1/2 · 1/3 · 1/3 |
recuperación de contraseña |
119 mil | 38% · 10% | $0.41 · $0.28 · $0.52 | 2/2 · 3/3 · 3/3 |
romper-filtro-js-desde-html |
103K | 41% · 20% | $0.50 · $0.56 · $0.27 | 2/2 · 3/3 · 0/1 |
criptoanálisis lineal feal |
66K | 38% · 24% | $0.61 · $0.71 · $0.51 | 2/2 · 3/3 · 3/3 |
filtrar-js-desde-html |
56K | 25% · 32% | $0.53 · $0.66 · $0.63 | 0/2 · 0/3 · 0/3 |
logits de extracción de modelos relu |
52K | 11% · 3% | $0.44 · $0.56 · $0.41 | 1/2 · 3/3 · 2/3 |
criptoanálisis diferencial feal |
34K | 27% · 18% | $0.56 · $0.68 · $0.40 | 2/2 · 3/3 · 3/3 |
Creación de software desde el código fuente
Eliminado 64% (Espacio libre 26%) · factura −28% (Espacio libre −6%) · resuelto 80% (Espacio libre 83%, ninguno 80%). La mayor cantidad de salida de herramientas de cualquier cohorte, alrededor de 1,2 millones de caracteres por tarea: instalaciones de paquetes, configurar comprobaciones, líneas del compilador y diagnósticos. crear intérprete mips, compilar pmars los construir-punto-de-vista-ray Su coste se ha reducido aproximadamente a la mitad. Aquí es donde la diferencia con Headroom se hace más evidente.
| Tarea | Salida de la herramienta | Eliminado: Kompressor · Headroom | Coste por prueba: ninguno · Headroom · Kompressor | Resuelto: ninguno · Headroom · Kompressor |
|---|---|---|---|---|
hacer-perdición-para-mips |
3.177 mil | 65% · 28% | $10.28 · $8.85 · $6.80 | 0/2 · 0/3 · 0/3 |
fix-ocaml-gc |
1.701 mil | 67% · 24% | $2.27 · $2.48 · $1.74 | 2/2 · 3/3 · 3/3 |
crear intérprete mips |
1.538 mil | 69% · 34% | $2.75 · $4.17 · $1.42 | 0/2 · 2/3 · 1/3 |
compilar-compcert |
1.483 mil | 62% · 22% | $3.74 · $2.81 · $3.18 | 2/2 · 3/3 · 3/3 |
construir-punto-de-vista-ray |
925 mil | 64% · 22% | $1.95 · $1.33 · $0.98 | 2/2 · 2/3 · 3/3 |
compilar-cython-ext |
801K | 46% · 27% | $1.43 · $1.97 · $1.86 | 2/2 · 3/3 · 3/3 |
fallo del montón de memoria personalizado |
715 mil | 63% · 20% | $0.96 · $0.88 · $0.58 | 2/2 · 3/3 · 3/3 |
compilar pmars |
683K | 72% · 18% | $1.02 · $0.81 · $0.52 | 2/2 · 3/3 · 3/3 |
sqlite-con-gcov |
403K | 67% · 20% | $0.63 · $0.48 · $0.44 | 2/2 · 3/3 · 3/3 |
instalar-windows-3.11 |
357K | 38% · 8% | $1.97 · $1.65 · $2.03 | 2/2 · 3/3 · 2/3 |
Configuración del servicio y Git
Eliminado 58% (Espacio libre 15%) · factura −14% (Espacio libre 0%) · resuelto 69% (Espacio libre 60%, ninguno 85%). Las instalaciones de servicios y los escaneos de repositorios grandes se comprimen bien (sanitizar-git-repo, 79%). Los comandos git cortos y las pequeñas diferencias se transmiten casi sin cambios, por diseño. kv-store-grpc los servidor pypi Falló en todas las pruebas exhaustivas con ambas herramientas.
| Tarea | Salida de la herramienta | Eliminado: Kompressor · Headroom | Coste por prueba: ninguno · Headroom · Kompressor | Resuelto: ninguno · Headroom · Kompressor |
|---|---|---|---|---|
sanitizar-git-repo |
1.256 mil | 79% · 3% | $1.74 · $1.32 · $1.58 | 2/2 · 1/3 · 2/3 |
cartero |
916K | 45% · 26% | $2.14 · $1.69 · $1.79 | 2/2 · 2/3 · 2/2 |
configurar-servidor-web-git |
141 mil | 67% · 20% | $0.79 · $1.08 · $0.65 | 1/2 · 1/3 · 1/3 |
arreglar-git |
96K | 1% · 8% | $0.36 · $0.82 · $0.36 | 2/2 · 2/3 · 3/3 |
git-multibranch |
79 mil | 18% · 10% | $0.92 · $1.01 · $0.67 | 2/2 · 3/3 · 3/3 |
Registro de solicitudes de nginx |
67 mil | 28% · 4% | $0.31 · $0.35 · $0.26 | 2/2 · 3/3 · 3/3 |
kv-store-grpc |
34K | 12% · 21% | $0.48 · $0.36 · $0.31 | 1/2 · 0/3 · 0/3 |
servidor pypi |
20 mil | 20% · 9% | $0.31 · $0.39 · $0.32 | 1/2 · 0/3 · 0/3 |
recuperación de fugas de Git |
10K | 2% · 7% | $0.24 · $0.24 · $0.30 | 2/2 · 3/3 · 3/3 |
certificado autofirmado de openssl |
4K | 4% · 0% | $0.10 · $0.13 · $0.08 | 2/2 · 3/3 · 3/3 |
Canalizaciones de datos y medios
Eliminado 55% (Espacio libre 15%) · factura −37% (Espacio libre −38%) · resuelto 78% (Espacio libre 81%, ninguno 72%). Ambas herramientas redujeron la factura en una cantidad similar; Headroom resultó ligeramente más económico y resolvió un poco más. La mayor parte del ahorro es extraer-movimientos-de-video, donde ambos agentes tomaron un camino mucho más económico que el no comprimido. Cuando el contenido decide, Kompressor toma la delantera: procesador de documentos financieros disminuyó de $1,23 a $0,37 por ensayo.
| Tarea | Salida de la herramienta | Eliminado: Kompressor · Headroom | Coste por prueba: ninguno · Headroom · Kompressor | Resuelto: ninguno · Headroom · Kompressor |
|---|---|---|---|---|
extraer-movimientos-de-video |
1.012 mil | 59% · 14% | $10.83 · $4.75 · $5.89 | 2/2 · 3/3 · 3/3 |
recuperación de db-wal |
650 mil | 48% · 20% | $0.96 · $1.45 · $1.21 | 0/2 · 1/3 · 1/3 |
procesador de documentos financieros |
351 mil | 54% · 20% | $1.23 · $1.32 · $0.37 | 1/2 · 3/3 · 3/3 |
Universidad sparql |
260 mil | 36% · 34% | $0.67 · $0.39 · $0.68 | 2/2 · 3/3 · 3/3 |
procesamiento de vídeo |
194K | 55% · 3% | $1.79 · $1.26 · $1.23 | 0/2 · 0/3 · 0/3 |
optimización de consultas |
76K | 9% · 4% | $1.10 · $0.81 · $0.78 | 2/2 · 3/3 · 2/3 |
rangos de fechas del resumen del registro |
22K | 77% · 39% | $0.15 · $0.14 · $0.11 | 2/2 · 3/3 · 3/3 |
sqlite-db-truncate |
20 mil | 7% · 12% | $0.19 · $0.20 · $0.23 | 2/2 · 3/3 · 3/3 |
fusión de datos de múltiples fuentes |
10K | 17% · 17% | $0.18 · $0.20 · $0.22 | 2/2 · 3/3 · 3/3 |
Texto, documentos y secuencias
Eliminado 51% (Espacio libre 32%) · factura −23% (Espacio libre +3%) · resuelto 62% (Espacio libre 57%, ninguno 43%). Los documentos generados por máquina se comprimen bien: código G en gcode-to-text (76%) y archivos de estructura de proteínas en ensamblaje de proteínas (61%). La prosa no lo hace, por diseño: LaTeX en caja h llena es 18%. En ensamblaje de ADN, Headroom comprime más que nosotros.
| Tarea | Salida de la herramienta | Eliminado: Kompressor · Headroom | Coste por prueba: ninguno · Headroom · Kompressor | Resuelto: ninguno · Headroom · Kompressor |
|---|---|---|---|---|
ensamblaje de proteínas |
297K | 61% · 27% | $1.17 · $1.42 · $1.26 | 0/2 · 2/3 · 2/3 |
caja h llena |
161 mil | 18% · 16% | $0.58 · $0.74 · $0.48 | 1/2 · 3/3 · 1/3 |
ensamblaje de ADN |
156K | 37% · 58% | $1.23 · $1.20 · $0.94 | 1/2 · 0/3 · 3/3 |
gcode-to-text |
128K | 76% · 28% | $1.30 · $1.55 · $0.75 | 0/2 · 1/3 · 1/3 |
inserción de ADN |
93K | 53% · 48% | $0.53 · $0.44 · $0.41 | 0/2 · 0/3 · 0/3 |
edición de texto a gran escala |
3K | 0% · 6% | $0.72 · $0.46 · $0.49 | 2/2 · 3/3 · 3/3 |
registro de expresiones regulares |
<1K | — · — | $0.34 · $0.21 · $0.22 | 2/2 · 3/3 · 3/3 |
Algoritmos, matemáticas y acertijos
Eliminado 48% (Espacio libre 25%) · factura −8% (Espacio libre −11%) · resuelto 95% (Espacio libre 94%, ninguno 93%). Principalmente razonamiento, con resultados pequeños: la mediana es de 270 caracteres, por debajo del umbral de compresión. El costo total del conjunto es de aproximadamente $15 por ejecución, por lo que hay poco margen de ahorro, y las dos herramientas se sitúan dentro del margen de error.
| Tarea | Salida de la herramienta | Eliminado: Kompressor · Headroom | Coste por prueba: ninguno · Headroom · Kompressor | Resuelto: ninguno · Headroom · Kompressor |
|---|---|---|---|---|
evaluación metacircular similar a un esquema |
485 mil | 65% · 31% | $1.29 · $1.18 · $1.37 | 2/2 · 3/3 · 3/3 |
guerras centrales de promedio ganador |
338K | 37% · 24% | $1.45 · $1.84 · $1.14 | 2/2 · 3/3 · 3/3 |
fusionar-diferencias-tarea-arc-agi |
156K | 55% · 14% | $0.84 · $0.81 · $0.69 | 2/2 · 3/3 · 3/3 |
tune-mjcf |
151 mil | 20% · 18% | $1.12 · $0.93 · $0.47 | 2/2 · 3/3 · 3/3 |
modernización de COBOL |
140 mil | 45% · 35% | $0.99 · $0.72 · $1.20 | 2/2 · 3/3 · 3/3 |
optimización de cartera |
136K | 53% · 28% | $0.43 · $0.49 · $0.36 | 2/2 · 3/3 · 3/3 |
ajuste raman |
132K | 46% · 6% | $1.72 · $0.71 · $1.44 | 0/2 · 0/3 · 0/3 |
ajedrez con expresiones regulares |
130 mil | 28% · 30% | $2.31 · $1.33 · $2.04 | 1/2 · 2/3 · 2/2 |
circuito-fibsqrt |
104K | 60% · 41% | $0.81 · $0.78 · $0.90 | 2/2 · 3/3 · 1/1 |
mayor autovalor |
81 mil | 36% · 18% | $0.70 · $0.94 · $0.84 | 2/2 · 3/3 · 3/3 |
compresor de escritura |
65 mil | 23% · 8% | $0.74 · $0.72 · $0.53 | 2/2 · 3/3 · 3/3 |
mejor jugada de ajedrez |
52K | 66% · 66% | $0.36 · $0.31 · $0.36 | 2/2 · 3/3 · 3/3 |
terminal sin cabeza |
46K | 73% · 30% | $0.42 · $0.37 · $0.45 | 2/2 · 3/3 · 3/3 |
modernizar-pila-científica |
40 mil | 50% · 26% | $0.18 · $0.21 · $0.16 | 2/2 · 3/3 · 3/3 |
bn-fit-modify |
35 mil | 6% · 23% | $0.29 · $0.34 · $0.35 | 2/2 · 3/3 · 3/3 |
restricciones-programación |
25 mil | 52% · 0% | $0.16 · $0.16 · $0.15 | 2/2 · 3/3 · 3/3 |
búsqueda de distribución |
23K | 42% · 3% | $0.20 · $0.27 · $0.24 | 2/2 · 3/3 · 3/3 |
óxido-políglota-c |
15 mil | 36% · 32% | $0.71 · $0.52 · $0.72 | 2/2 · 3/3 · 3/3 |
políglota-c-py |
7K | 35% · 16% | $0.48 · $0.69 · $0.48 | 2/2 · 3/3 · 3/3 |
cancelar-tareas-asíncronas |
5K | 76% · 22% | $0.16 · $0.23 · $0.20 | 2/2 · 3/3 · 3/3 |
código a partir de una imagen |
2K | 0% · 0% | $0.13 · $0.13 · $0.12 | 2/2 · 3/3 · 3/3 |
Probar más comisiones |
1K | 0% · 2% | $0.09 · $0.09 · $0.12 | 2/2 · 3/3 · 3/3 |
Preguntas frecuentes
¿Necesitamos cambiar nuestros agentes, mensajes o código para usar Kompressor?
No. Kompressor se ejecuta en línea dentro de la puerta de enlace de IA de OptScale como un proxy: usted dirige sus agentes a la puerta de enlace y la compresión se aplica automáticamente a cada solicitud, sin modificar el agente, sus mensajes ni sus resultados. No requiere migración de SDK ni instrumentación por agente, y añade aproximadamente 0,2 ms por KB de salida de la herramienta.
¿La compresión afectará al almacenamiento en caché de las solicitudes o hará que alguna vez una solicitud cueste más?
No. Kompressor es determinista: la misma herramienta comprime la salida a los mismos bytes en cada iteración, sin reloj, aleatoriedad ni dependencia de la pregunta del usuario, por lo que las lecturas de la caché del proveedor (aproximadamente 93% de tokens de entrada, facturados a una décima parte del precio) siguen siendo válidas. Además, no admite errores, por lo que cualquier resultado que no sea menor se descarta y cualquier error permite que la solicitud continúe sin cambios.
¿Puede Kompressor dejar caer algo que el modelo realmente necesita?
Elimina duplicados en lugar de resumir, por lo que el modelo conserva al menos una copia real de cada línea distinta, y cada omisión se etiqueta y se puede recuperar; el modelo puede recuperar el original durante una hora mediante una llamada de recuperación que la puerta de enlace ejecuta para él. Solo modifica la salida de la herramienta generada por la máquina de aproximadamente 512 caracteres, nunca los mensajes del sistema, del desarrollador o del asistente. En la prueba de rendimiento, la tasa de resolución no varió estadísticamente (81,1% frente a 82,2% sin compresión).
¿Qué cargas de trabajo se benefician más de Kompressor?
El ahorro depende de la carga de trabajo. Las mayores ventajas se obtienen en el entrenamiento de aprendizaje automático, la compilación desde el código fuente y los flujos de datos, donde se eliminan entre 55 y 811 TP3T de la salida de la herramienta y se reduce la factura entre un cuarto y un tercio. Las tareas cortas que requieren mucho razonamiento y la prosa simple tienen poco margen de eliminación por diseño, así que no se espera un ahorro significativo en esos casos.
¿Cómo podemos confirmar el ahorro en nuestro propio tráfico?
Cada cifra de referencia representa la diferencia entre las facturas reales del proveedor con el descuento por caché ya incluido, no los tokens con precio de lista sin caché. En su propio tráfico, puede reservar una porción como grupo de control sin forma y comparar los tokens facturados uno al lado del otro, etiquetados como medidos frente a estimados. Cuando un proveedor o nivel no utiliza caché en absoluto, la reducción aproximada de 25% en el tráfico instantáneo se refleja directamente en la factura.