Compresión de prompts: quitar el relleno antes de que el modelo lo lea
Qué es. Un modelo pequeño que se ejecuta localmente y que comprime un prompt: quita los tokens que no aportan significado y conserva los que sí. LLMLingua-2 es un clasificador de tokens de nivel BERT, destilado de GPT-4, diseñado específicamente para la compresión independiente de la tarea, y es 3–6× más rápido que el original.
Cómo funciona. Es una biblioteca de Python independiente: preprocesamiento que no depende del modelo, sin atarse a ninguna API. Usted le da texto y un tamaño objetivo; le devuelve el texto comprimido más los conteos de tokens:
from llmlingua import PromptCompressor
compressed = PromptCompressor().compress_prompt(long_context, target_token=500)
# → { compressed_prompt, origin_tokens, compressed_tokens, ratio }
# luego envíe compressed_prompt a cualquier modelo: API o el Claude CLIPor qué reduce tokens. Las afirmaciones son grandes y se reportan de forma consistente: hasta 20× de compresión con una pequeña caída de precisión, 95–98% de la precisión conservada con LLMLingua-2, y un caso de producción muy citado de una factura mensual que pasó de $42K → $2.1K sin cambiar de modelo. El argumento con el que coincidimos: los equipos persiguen modelos más baratos y no ven que sus prompts cargan 5–20× de relleno comprimible: contexto estático largo, fragmentos de RAG, documentos pegados.
Se ejecuta en CPU (una GPU solo lo acelera), así que es un filtro local de $0. Y como la salida es texto plano, funciona con el Claude CLI, no solo con la API: comprima localmente un bloque grande y luego páselo a claude -p. Rinde mejor con contexto grande pegado, no con el prompt de sistema del propio CLI (que el caché de prompts ya abarata). La única regla, sobre la que las fuentes son tajantes: presupueste pruebas A/B por tarea antes de confiar en él; una compresión agresiva puede romper tareas específicas. Esa advertencia es justo la razón por la que pertenece junto a un benchmark: podemos medir el costo en precisión en lugar de adivinarlo, y eso hicimos. Lo instalamos localmente (entorno aislado, CPU, modelo en caché en disco), lo conectamos a nuestro benchmark y corrimos una prueba A/B real: un documento largo de minutas de reunión con datos enterrados entre relleno, tres preguntas con respuestas conocidas, cada una hecha a claude-haiku-4.5 dos veces, con el contexto completo y con el comprimido. El resultado: 49% menos tokens de entrada, ~43% menos costo y las mismas 3/3 respuestas correctas; cada dato enterrado (una tarifa de entrega, el valor de un contrato, una ventana de SLA) sobrevivió, porque la pregunta fija lo que debe quedarse. El límite honesto: eso es para preguntas factuales sobre prosa. El código, las cadenas exactas y las tablas llenas de números son otra clase de tarea, y tendrán su propia prueba A/B antes de que confiemos en la compresión para ellas.
Memoria para agentes: recuperar la parte relevante, no todo el historial
Qué es. Una capa de memoria para agentes de chat. En lugar de reenviar la conversación entera (y una pila creciente de datos) en cada turno, Mem0 extrae, guarda y recupera solo lo relevante para el mensaje actual.
Cómo funciona. Guarda los recuerdos en una base de datos vectorial (con búsqueda híbrida semántica + por palabras clave BM25 + por entidades), y un paso de extracción de una sola pasada mantiene bajo el costo de escritura. SDK para Python y TypeScript más un CLI; pip install mem0ai. Se ejecuta como biblioteca local, como servidor Docker autoalojado o como nube administrada, y funciona con cualquier LLM a través de una interfaz estándar, incluido Claude.
Por qué reduce tokens. Es la solución estructural a la ventana de contexto que crece en cada turno. Las cifras de Mem0 en 2026: 91.6 en el benchmark LoCoMo usando solo ~7.0K tokens por recuperación, frente a los más de 25K tokens que gasta un enfoque de contexto completo para llegar a una calidad similar. En un chatbot con miles de turnos, pagar 7K en lugar de 25K por turno es un ahorro recurrente que se acumula.
El chatbot de DLR vuelve a pagar el contexto de la conversación en cada turno; esta es la palanca apuntada directamente a esa carga de trabajo. Poder autoalojarlo (biblioteca local o Docker) lo mantiene en nuestro hardware y con nuestras claves. La integración es más complicada que un filtro de una sola pasada (es un almacén de memoria que usted opera), así que es algo que se construye, no algo que se enchufa. Vale la pena hacer un piloto con tráfico real del chatbot y medir la diferencia de tokens por turno, como medimos el enrutamiento.
Observabilidad: vea exactamente adónde se fueron los tokens
Qué es. Un panel de terminal local que lee los registros de sesión de sus agentes de programación con IA (Claude Code, Codex, Gemini CLI, Aider, Cursor y más) y los convierte en una sola vista rápida de costo, tokens y tiempo.
Cómo funciona. Analiza los registros que ya están en disco, sin subir nada a ningún lado, y muestra los tokens de entrada/salida/caché, el costo estimado, las sesiones que más tokens queman, además de diagnósticos: ciclos de herramientas, llamadas repetidas, reintentos, pausas largas, ejecuciones colgadas y fallas de herramientas. También genera reportes en JSON / Markdown / HTML con controles de salud para CI y de fallas de herramientas.
Por qué ayuda con la factura. No reduce tokens directamente: le muestra cuáles sesiones y ciclos de herramientas se los están comiendo, para que pueda arreglar la fuga real. La historia del costo desbocado casi siempre es un ciclo sin techo; esta es la herramienta que hace visible ese ciclo localmente y por sesión, en tiempo real, y no después, en un panel de facturación con retraso.
Encaja exactamente con nuestra filosofía de lentes -eye de solo lectura: observar localmente, nunca subir nada, reportar. Es la pieza que faltaba para demostrar los ahorros contra el impuesto de tokens en lugar de estimarlos con una API de facturación que se retrasa horas. La de menor riesgo de las cuatro (solo lee registros), así que es la primera que hay que poner en marcha.
Extracción web: MarkItDown, pero para la web en vivo
Qué es. Una herramienta de línea de comandos que extrae, busca, rastrea y mapea la web, y devuelve Markdown limpio por defecto: listo para un LLM, con ~67% menos tokens que el HTML crudo. Instala skills para agentes y un servidor MCP, para que un agente pueda hacer trabajo web en vivo como herramienta.
Cómo funciona. La misma idea que MarkItDown, apuntada a la web en lugar de a un archivo en disco: obtiene la página, quita el ruido de diseño y de scripts, y emite el texto. Puede ejecutarse contra una instancia autoalojada (firecrawl --api-url http://localhost:3002 scrape …), y una URL de API personalizada omite por completo la autenticación, así que una instancia local no necesita clave.
Por qué reduce tokens. La misma palanca que la conversión de documentos: nunca le entregue HTML crudo a un modelo. Una página extraída como Markdown es una fracción de los tokens del DOM original, y es legible, así que puede verificarla antes de gastar.
Dos advertencias para un stack como el nuestro. Primero, se traslapa con lo que ya ejecutamos: nuestro lector de artículos reforzado y protegido contra SSRF convierte web → texto limpio para el sitio. Segundo, la API en la nube se factura por consumo, y la versión de código abierto autoalojada es el camino menos pulido (se comporta distinto a la nube, y autoalojarla es trabajo real). Para nosotros, la ruta local con --api-url es la única que cumple con la vara de $0; la clave alojada es una superficie de gasto que hay que sopesar, no adoptar por defecto. Una herramienta sólida: adóptela de forma deliberada, para trabajos de rastreo/búsqueda que nuestro lector no cubre, no por reflejo.
La misma idea, cuatro formas
Agrúpelas según dónde se ubican respecto a la llamada al modelo. LLMLingua y Firecrawl encogen la entrada antes de enviarla: comprimen un prompt, convierten una página. Mem0 cambia qué se envía, para empezar: recupera la parte relevante en lugar de todo el historial. agenttrace no toca la llamada; le muestra adónde se van los tokens para que pueda apuntar las otras tres. Junto con MarkItDown y Graphify, eso es un juego completo de herramientas locales para el único principio debajo de todo: haga el trabajo barato y determinista en su propio hardware, y gaste tokens facturados por consumo solo en la parte que necesita inteligencia.
Ninguna de estas reemplaza elegir el modelo correcto; eso es lo que mide el resto de este sitio. Se apilan encima: una entrada más pequeña y limpia es más barata en cualquier modelo que el enrutamiento ya haya elegido, así que reducir tokens en el origen multiplica el ahorro. Nuestro plan es el que siempre seguimos: hacer un piloto local de cada una, medir el antes y el después reales contra el benchmark y publicar las cifras, igual que hicimos con MarkItDown.
Estas son candidatas que estamos evaluando para nuestro propio stack, igual que hacemos benchmarks de cada modelo antes de recomendarlo. Las palancas que deciden qué modelo se ejecuta en primer lugar están en el manual.