Un formato que reduce tokens en agentes IA un 75%

Caveman, un proyecto open source de Julius Brussee, reduce el consumo de tokens en agentes de IA en un 75% cambiando cómo el modelo formatea sus respuestas: elimina artículos, relleno y cortesías. Combinado con memory systems open source como agentmemory y técnicas de prompt caching, conseguís ahorros que transforman la viabilidad económica de los agentes que consultaban APIs todo el tiempo.

Ponele que vos tenés un agente de IA que necesita consultar APIs, buscar en bases de datos, validar esquemas y tomar decisiones. Cada paso cuesta tokens. Un agente típico en 2026 consume 800-1200 tokens de overhead apenas en context acumulado en una sola sesión (prompts, system instructions, history). Multiplicá eso por miles de sesiones al mes y te das cuenta de por qué reducir tokens agentes IA se convirtió en obsesión de equipos que usan IA en producción. No es solo una cuestión de costo, aunque OpenRouter a USD 20/1M tokens contra otras plataformas que cobran 100x más hace la diferencia brutal. Es que sin eficiencia, los agentes se vuelven lentos, impredecibles, y llega un punto donde directamente no cierran los números.

El problema: agentes IA con sobrepeso de contexto

Un agente típico no arranca virgen. Arranca con instrucciones de sistema (200-400 tokens), historial de sesión anterior (100-300 tokens), definiciones de tools/schemas (200-600 tokens según la complejidad), y el mensaje actual del usuario (50-200 tokens). Eso es 550-1500 tokens de baseline antes de que haga nada. Si lo corrés 1000 veces al día, hablamos de 550,000 a 1,500,000 tokens quemados en puro overhead.

El tema es que la mayoría de esa información es repetitiva. Las instrucciones de sistema no cambian. Los schemas de APIs tampoco. El historial se acumula pero gran parte es contenido que ya fue procesado. “Ojo”, acá viene lo bueno: si conseguís comprimir eso sin perder información útil, de repente los números cierran.

Hay tres líneas de ataque documentadas en 2026 que efectivamente funcionan.

Tres enfoques que cortan costos: formato, caching y memoria

Lo interesante es que no son excluyentes. Un agente serio combina los tres.

1) Cambiar el formato de salida (Caveman): El modelo habla como cavernícola. Sin artículos (“el”, “la”, “un”), sin cortesías (“por favor”, “gracias”), sin conectores que son puro relleno (“además”, “de todas formas”). El resultado real reporta 61-68% de reducción en texto discursivo, aunque el marketing dice “75%”.

2) Cachear prompts estáticos (Claude API): Si tu sistema prompt o tu reference text no cambia, prompt caching hace que esos tokens cuesten 75% menos. Implementás con `cache_control` parameter en el SDK de Anthropic. Los tokens cached caen de, ponele, 1 token a 0.25 tokens. Escalá eso a millones de requests.

3) Memoria persistente comprimida (agentmemory, Mem0): En vez de mandar todo el historial cada vez, comprimís y almacenás offline. Cuando el agente necesita contexto, consultá la memoria. agentmemory logra 92% de reducción versus full-context mediante deduplicación SHA-256 y compresión LLM, con puntuación de 95.2% en LongMemEval-S.

Caveman: el formato que cortó 883 puntos en Hacker News

Caveman es un proyecto open source de Julius Brussee que mecanismo es tan simple que parece casi absurdo. Le decís al modelo “respondé como si la alfabetización fuera un lujo”. Elimina artículos, preposiciones innecesarias, toda pompa.

Imaginá que pedís un análisis de mercado. En estilo normal:

“El análisis del mercado de tecnología indica que, además de las tendencias tradicionales, han surgido nuevas oportunidades para innovación disruptiva que podrían transformar la manera en que las empresas operan.”

En Caveman:

“Mercado tech: nuevas oportunidades innovación. Empresas transformarán operaciones.” En ejecutar agentes sin depender de APIs profundizamos sobre esto.

El segundo dice lo mismo con 66% menos tokens (y los LLMs entienden el patrón al toque). Caveman documenta cuatro niveles de intensidad: Lite (eliminate articles), Full (remove connectors), Ultra (compress grammar), Wenyan (archaic Chinese, basically unreadable pero máxima compresión). La mayoría de agentes productivos usan Full o Ultra.

Lo que nadie menciona es que esto sólo funciona si el modelo está entrenado para esto. Claude maneja Caveman mejor que otros porque durante el entrenamiento procesa tokens impredecibles con cierta robustez.

Compiladores de schema agent-native: APIs 10x más pequeñas

Acá el juego cambia. No cambiás el estilo del modelo, cambiás la ESTRUCTURA de lo que el agente tiene que parsear.

Speakeasy documenta 160x reduction en token usage con dynamic toolsets. Convierten OpenAPI/GraphQL/AsyncAPI/Protobuf a un formato que entienden los agentes sin inflación. En vez de mandar un schema OpenAPI completo (que es 500-1500 tokens fácil), mandás una representación agent-native que ocupa 50-100 tokens y contiene exactamente la misma información funcional.

Zuplo hizo algo parecido con token-based rate limiting. OpenAPI MCP Server lo integra. La idea es: los LLMs no necesitan documentación legible por humanos. Necesitan estructura parseable. Cuando hacés eso, se ahorra 70-75% de tokens en tool definitions.

Memory systems open source: agentmemory vs Mem0 vs Memori

Acá es donde se pone denso pero también donde vemos 90%+ de ahorro en sesiones largas. Esto se conecta con lo que analizamos en privacidad en llamadas a APIs externas.

agentmemory es la opción open source más citada. Funciona así: después de cada tool execution, corre un PostToolUse hook que filtra privacidad, comprime con LLM, genera embeddings, los indexa en vector database, full-text search y knowledge graph. La siguiente sesión no trae todo el historial, trae solo lo relevante según embedding similarity. Dedup por SHA-256 mata duplicados, compresión LLM mata redundancia conceptual.

Mem0 es más enterprise: SQL-first, query optimization, integra con llama_index, langchain, etc. Memori agrega git-like versioning, útil si necesitás auditoria o rollback de cambios de estado.

Prompt caching de Claude API: inversión upfront, payoff exponencial

Esto es potente porque no requires cambiar nada de tu lógica de agente. Es un parametro en el SDK.

Funcioná así: metés `cache_control: “ephemeral”` en un bloque de texto estático (system prompt, reference docs, examples) y Claude cachea esos tokens en el servidor. Las primeras 4 requests usan full tokens (1 token cada uno). Desde la quinta en adelante, esos tokens cached cuestan 0.25 tokens cada uno. Si tu reference text es 1000 tokens, ahorras 750 tokens por request, vez 100 requests al mes, hablamos de 75,000 tokens ahorrados.

Caso real: un agente que procesa reportes de clientes. El system prompt (200 tokens) + guía de análisis (300 tokens) + ejemplos de output (400 tokens) = 900 tokens de overhead que NO cambian entre requests. Con caching, esos 900 tokens se cachean después del primer hit. En 500 requests mensuales, el ahorro es 900 × 500 × 0.75 = 337,500 tokens libres. A USD 20/1M tokens, eso es USD 6.75/mes por agente. Escalá a 50 agentes, ahorrás USD 337/mes. Relacionado: stack completo de herramientas para agentes.

Implementación práctica: CLAUDE.md y memoria permanente

La técnica que menos hype tiene pero más resultado muestra es CLAUDE.md, documentada por Nacho Conesa en 2026. Es un archivo de 200-300 tokens que reemplaza 800-1200 tokens de conversación.

Qué metes:

• Convenciones de código (naming, patterns, frameworks usados)
• Contexto del proyecto (qué hace, arquitectura, dependencias)
• Instrucciones personalizadas (estilo de respuesta, lenguaje, tone)
• Estado conocido (últimos cambios, bugs conocidos, WIPs)

El agente lee CLAUDE.md una vez y ya tiene 95% del contexto que necesita para el resto de la sesión. Versus: “Acá va mi proyecto, acá el código, acá el problema…” (800+ tokens cada vez).

Caso concreto: desarrollador trabajando con Claude Code. Sin CLAUDE.md, cada mensaje es “mi proyecto usa FastAPI, TypeScript, Docker, pytest, las variables de entorno van en .env, los tests en tests/, la estructura es app/routes, app/models, app/db…” (150+ tokens solo en contexto repetido). Con CLAUDE.md de 250 tokens, eso se cachea de entrada y no vuelve a repetirse. En una sesión de 20 mensajes, ahorra 150 × 20 × 0.75 (con caching) = 2,250 tokens. Mensual en USD = 0.04. No es nada. Pero lo importante es: el agente es más rápido, menos confuso, y baja el overhead cognitivo.

Errores comunes al reducir tokens

1. Comprimir tanto que el agente “alucinó” información que no está. Caveman Ultra o Wenyan pueden hacer que el modelo interpole tokens que no debería. Solución: validar salida con schemas. Caveman Full funciona mejor para agentes que Caveman Ultra.

2. Poner caching en datos que cambian cada request. Si metés `cache_control: “ephemeral”` en un user message o en datos dinámicos, no ganás nada. El caché se invalida inmediatamente. Cacheá solo prompts de sistema y reference texts estáticos.

3. Memory systems sin limpieza de datos viejos. agentmemory con vector embeddings crecerá sin freno si no purgás memoria >30 días. Mem0 + versioning ayuda, pero requiere mantenimiento. Plan un garbage collector. Para más detalles técnicos, mirá elegir plataforma para proyectos open source.

4. Combinar Caveman + compressed schemas + memory = interpretación errada. Cuando reducís en tres frentes simultáneamente, el agente pierde granularidad. Un agente production tiene que ser conservador: Caveman Full + schema optimization SÍ, memory compression SÍ, pero pruebá cada uno independientemente antes de combinar.

Preguntas Frecuentes

¿Caveman funciona con todos los modelos?

No. Claude maneja Caveman al 95%+. GPT-4 y Gemini pueden interpretar el patrón, pero no siempre. Llama puede fallar en Caveman Ultra. Si estás multi-model, quedate en Caveman Lite o Full, o probá primero.

¿Cuánto cuesta implementar agentmemory?

Cero en licencia (open source). El costo es infraestructura: necesitás vector database (Pinecone, Weaviate, Milvus) y posiblemente PostgreSQL para metadata. Self-hosted sale USD 50-200/mes en AWS/GCP, SaaS USD 100-500/mes según volumen.

¿Prompt caching está disponible en OpenRouter?

No. OpenRouter routea a Claude API, pero los parámetros de caching no se pasan. Necesitás llamar directo a Claude API con `client = Anthropic()` e incluir `cache_control` en el message content. OpenRouter lo soportará cuando Anthropic lo habilite en el backend.

¿CLAUDE.md reemplaza el prompt de sistema?

No. CLAUDE.md es complementario. Tu system prompt es donde van instrucciones críticas (“respondé siempre en JSON”, “nunca borres datos sin confirmar”). CLAUDE.md es donde va contexto del proyecto y convenciones. Juntos, ahorran 60-75% de tokens de “setup” en cada sesión.

¿Vale la pena Caveman si solo tengo 10 agentes?

Sí, si corren en volumen alto. 10 agentes × 100 requests/día × 30 días = 30,000 requests/mes. Con Caveman Full cortás 60%, eso es 18,000 tokens ahorrados diarios = 540,000 tokens/mes = USD 10.80/mes. Pequeño pero no nulo. Si tenés 50 agentes en producción, son USD 54/mes. Si tenés 500, son USD 540/mes.

Conclusión

Reducir tokens agentes IA en 2026 no es un nice-to-have, es supervivencia de escala. Un agente sin optimizar es un agente costoso, lento, y que escala mal. Las tres técnicas funcionan, no son experimentales, y tienen implementaciones open source o integradas en los principales SDKs.

La combinación ganadora para la mayoría de equipos es: Caveman Full (reduce formato sin perder potencia), prompt caching (reduce overhead de prompts estáticos), y memory (reduce acumulación histórica). Implementadas juntas, conseguís 60-75% de ahorro en tokens de producción sin reescribir lógica de agente. Eso es brutal en costos y latencia.

Si tenés agentes en OpenRouter o Claude API directa, investigá prompt caching. Si estás en Bedrock o auto-hosted, agentmemory es tu punto de entrada. CLAUDE.md, sin costo, debería estar en todo proyecto. Probá una técnica, mide, sumá la siguiente.

Fuentes

• Caveman GitHub — Proyecto open source de Julius Brussee para formato terse
• agentmemory GitHub — Sistema de memoria con 92% reduction vs full-context
• Nacho Conesa — Guía de CLAUDE.md y memoria permanente (2026)
• Speakeasy — Dynamic toolsets y 160x reduction en tokens
• Redis — LLM token optimization y prompt caching