Optimización de Tokens en Claude Code v2 — La Ventana Óptima

Hace unas semanas publiqué cómo reduje un 80 % mi consumo de tokens en Claude Code. El equivalente en API a precios de hoy: pasar de unos 100 USD diarios a 20-30 USD con las mismas horas de trabajo. Creía que había tocado techo.

No era techo. Era una meseta.

Iba a escribir un artículo titulado “ocho técnicas más para el siguiente nivel”. Lo tenía redactado. Pero antes de publicarlo decidí hacer algo que ningún artículo del nicho hace: medir si realmente las uso, no solo si las he instalado. Y luego, medir si funcionan cuando se usan.

Lo que encontré me obligó a tirar el borrador y empezar de cero.

Este artículo es lo que medí cuando dejé de creerme los README: de las ocho técnicas que prometen el siguiente nivel, algunas funcionan automáticas, otras necesitan una elección consciente que el agente no toma, y unas pocas hacen daño cuando se aplican fuera de su ventana óptima.

Al llegar a las dos más populares — Serena MCP y Caveman — verás los datos crudos de cinco experimentos A/B controlados sobre una pregunta que casi nadie hace: ¿realmente ahorran tokens?

Si no has leído el primero, léelo antes — este da por sentadas RTK, la selección de modelos y la gestión básica de contexto. Si ya lo has interiorizado, sigamos.

Los tres vectores del ahorro de tokens

Toda técnica de optimización ataca una de estas tres capas:

Vector de entrada — reducir lo que entra al contexto del agente. Skills, LSP, CLIs en vez de MCPs, external memory.

Vector de retención — reducir lo que se queda en el contexto una vez dentro. Tool Search, sub-agents aislados, compactación.

Vector de salida — reducir lo que Claude genera. Caveman.

La mayoría de artículos solo cubren el primero. El primero es donde el 80 % del ahorro vive, pero los otros dos son donde está el siguiente 10-15 %. Y, más importante: atacar los tres a la vez aumenta la calidad del output, no solo el coste. Un agente con contexto limpio se equivoca menos.

1. MCP Tool Search — verifica que ya lo tienes

Esta primera “técnica” no es una técnica. Es entender qué está pasando bajo el capó desde enero de 2026.

Anthropic introdujo Tool Search como feature nativa de su API. Cuando tienes muchos MCPs instalados con decenas de tools cada uno, en lugar de cargar todos los schemas al arranque (55K-60K tokens solo con 4 servidores activos), Claude carga un índice ligero y descubre las tools que necesita sobre la marcha mediante una search tool que usa regex + BM25.

En Claude Code esto funciona activado por defecto. No hay que configurar nada si usas Sonnet 4.5+ u Opus 4.5+. Si usas Haiku 4.5, no se soporta — y eso es un motivo razonable por sí solo para no usar Haiku como tu modelo principal.

Cómo verificar que está actuando: abre /context al principio de una sesión con varios MCPs. Si los schemas ocupan menos de 10K tokens aunque tengas 6+ servidores MCP conectados, Tool Search está haciendo su trabajo. Datos de la comunidad reportan reducciones de 77K → 8.7K tokens iniciales, un ahorro del 85-95 % sin tocar una línea de configuración.

Tómate 30 segundos para verificarlo hoy. Si /context te devuelve MCPs ocupando 40K tokens, algo está mal en tu setup — probablemente una versión vieja de Claude Code o un modelo no compatible.

2. CLI antes que MCP — el patrón que GitHub desbloqueó

Tengo un GitHub MCP instalado. Lo tenía, mejor dicho. Lo quité hace tres semanas y mi consumo en sesiones que tocaban issues y PRs cayó un orden de magnitud.

El GitHub MCP expone 93 tools. Cada una con su schema completo. Ocupa unos 55K tokens solo en definiciones, aunque uses tres tools al día. Y lo peor: las respuestas de esas tools están pensadas para ser exhaustivas — un list_issues te trae 50 issues con todos sus campos.

La alternativa es gh, el CLI oficial de GitHub. Claude Code ya sabe usarlo. No ocupa tokens antes de invocarse, y cuando lo invoca, la respuesta es texto plano que puedes filtrar con jq, grep, o --json con campos específicos.

El benchmark de Jannik Reinhard sobre una tarea enterprise (listar dispositivos no compatibles en Intune y exportar a CSV) mostró ahorros de 35× comparando Microsoft Graph MCP contra el mgc CLI + az + PowerShell. No 35 %, 35 veces menos tokens. La regla generaliza a cualquier servicio con CLI maduro.

La regla práctica que sigo: si existe un CLI maduro para el servicio, prefiero el CLI sobre el MCP. GitHub, GitLab, Slack, Vercel, Cloudflare, AWS, GCP — todos tienen CLI oficiales potentes. Los MCPs son cómodos para servicios sin CLI propio (Notion, Linear, Jira de forma limitada). Para el resto, CLI siempre.

Efecto lateral positivo: cuando Claude aprende a invocar gh con parámetros precisos, el patrón se transfiere a gh run, gh api, gh workflow. Un CLI bien diseñado es una API que el agente ya conoce.

3. Skills con Progressive Disclosure — tu CLAUDE.md está gordo

El patrón Progressive Disclosure es el que Anthropic usa en su sistema de Skills para cargar información en tres niveles progresivos:

Nivel 1 — metadata, ~100 tokens por skill, siempre en contexto. Nivel 2 — el cuerpo de la skill, se carga solo si el agente decide que la skill aplica. Nivel 3 — recursos externos (scripts, templates), solo si la skill los invoca.

Traducción práctica: todo ese CLAUDE.md de 800 líneas con reglas sobre “cómo desplegar”, “cómo crear migraciones”, “cómo generar componentes Vue siguiendo nuestro estilo” está cargándose en cada sesión, uses o no esas reglas.

Alex Op documentó un caso real: migró un CLAUDE.md de 1.207 líneas a skills con Progressive Disclosure tras descubrir que el archivo se descomponía en ~15 % universal, 60 % específico de tarea, 15 % deep-dive y 10 % obsoleto. ahorro del 83 % en coste de sesión. 100 skills caben en menos de 5K tokens al arranque — menos que un solo MCP mediano.

Qué debe ir en CLAUDE.md y qué en skills:

Va en CLAUDE.md	Va en Skills
Reglas universales del proyecto	Procedimientos ocasionales
Convenciones que aplican siempre	Conocimiento específico de un tipo de tarea
Estructura de carpetas y tipos	Templates y checklists

La regla que uso: si una instrucción aplica a menos del 50 % de las tareas, no debería estar en CLAUDE.md. Debería ser una skill.

Aviso importante: en los evals de Vercel, las skills no se invocan en el 56 % de los casos donde aplicarían. Incluso con instrucciones explícitas mandando al agente usarlas, el techo del eval fue 79 %. Como contrapunto, embeber la documentación directamente en AGENTS.md (8 KB plano siempre cargado) consiguió 100 % de pass rate en sus tests. La conclusión incómoda: para conocimiento que el agente tiene que aplicar de forma fiable, un AGENTS.md bien escrito gana a un sistema de skills con progressive disclosure. Las skills siguen valiendo para procedimientos opcionales, no para reglas que necesitas que se ejecuten siempre.

4. Filesystem como memoria — Manus tenía razón

Probablemente ya estés haciendo esto sin haberle puesto nombre. Tienes notas en docs/, scratchpads en tmp/, READMEs por carpeta. Lo que cambia este capítulo no es la práctica, es el frame con el que la piensas.

La idea: tratar el contexto activo como RAM (volátil, caro, finito) y el filesystem como disco (persistente, gratis, infinito). El agente no intenta mantener todo en la cabeza — lee y escribe archivos como un programador humano. Cuando algo deja de ser relevante para la tarea actual, sale del contexto activo y vuelve a su sitio en disco. Cuando vuelve a hacer falta, se relee.

En mi vault del brain-dump tengo un directorio .agent/ con esta estructura:

.agent/
├── memory.md           # Índice maestro — siempre se lee primero
├── tasks/
│   ├── current.md      # Tarea activa
│   └── completed/      # Resúmenes de tareas pasadas (YYYY-MM-DD-slug.md)
├── knowledge/          # Conocimiento destilado por Claude
└── scratchpad/         # Notas volátiles por fecha

El memory.md es un índice de una línea por entrada con wiki-links al detalle. Al arrancar una sesión, Claude lee ese índice (1-2K tokens), decide qué archivo concreto necesita para la tarea actual, y lo lee solo si hace falta. Al terminar, escribe un resumen en completed/ y actualiza el índice.

Resultado: sesiones de varias horas con contexto activo bajo 30K tokens, incluso cuando la “memoria” acumulada del proyecto lleva semanas creciendo.

El patrón lo popularizó Manus (planning-with-files). Anthropic tiene una Memory Tool oficial, pero tiene problemas reales: es caja negra, no es grep-eable, no la versionas con git, no es portable a otros agentes.

El patrón filesystem no tiene ninguno de esos problemas. Es Markdown plano en tu repo. Lo lees tú. Lo versionas. Funciona con cualquier agente que sepa hacer Read y Write. Y como es un convenio declarado en tu CLAUDE.md, es determinista: sabes exactamente qué recordará el agente y qué no.

La regla en mi CLAUDE.md es un párrafo: “al iniciar una sesión no trivial, lee .agent/memory.md; al terminar una tarea, mueve current.md a completed/ y actualiza el índice”. El resto lo hace Claude solo.

Si prefieres no montártelo a mano hay dos proyectos open source que automatizan el patrón: engram (memoria estructurada para agentes con triggers automáticos) y claude-mem (captura todo lo que Claude hace durante la sesión, lo comprime con el agent-sdk e inyecta el contexto relevante en sesiones futuras). Cada uno con su filosofía — más declarativo el primero, más automático el segundo. Pruébalos si no quieres declarar tu propio convenio.

5. Sub-agents como context burners

En el artículo v1 hablé de Agent Teams — equipos de agentes especializados que ejecutan pipelines. El matiz del v2: no todos los sub-agents son iguales. Los que más ahorran son los que yo llamo context burners.

Un sub-agent tradicional devuelve información al padre. Un context burner devuelve solo un resumen. La diferencia en tokens es brutal.

Ejemplo: quiero saber dónde se usa la función calculateTax en un repo grande. Opción mala: el agente principal hace grep, Read archivo1, Read archivo2, Read archivo3, acumula 8K tokens de lecturas que no necesita conservar. Opción buena: delega a un sub-agent code-researcher con el prompt “dime dónde se usa calculateTax y si hay patrones de uso”. El sub-agent lee lo que necesite (8K tokens dentro de SU contexto), y devuelve al padre un resumen de 200 tokens: “se usa en 5 sitios, 3 en billing/, 2 en reports/, todos pasan userId como primer arg”.

El padre recibe 200 tokens útiles, no 8K de ruido. Esos 8K nunca entran al contexto principal — se “quemaron” dentro del sub-agent y desaparecieron al terminar.

En pipelines de 10+ sub-agents, esto es 3-5x más barato que el patrón orchestrator clásico donde todos los outputs se acumulan en un coordinador central.

Requisitos para que funcione bien:

1. Sub-agents con scope muy estrecho. Uno por función. No sub-agents que “hacen varias cosas”.
2. Prompts que obligan a devolver resúmenes, no transcripciones. “Devuelve máximo 300 tokens” es una instrucción literal válida.
3. Uso de isolation: worktree en frontmatter cuando el sub-agent modifica archivos, para no contaminar el working directory del padre.

Contrapunto honesto: Cognition dice que son mala idea

Walden Yan, de Cognition (los de Devin), publicó Don’t Build Multi-Agents argumentando que los sub-agents paralelos producen context pollution: toman decisiones implícitas que no comparten con sus hermanos, y los outputs resultantes son inconsistentes. Su alternativa es un agente lineal único con compactación agresiva.

Mi opinión después de seis meses con Agent Teams en producción: Walden tiene razón a medias, y las medias son lo interesante.

El context pollution que describe existe — lo he visto. Ocurre cuando dos sub-agents tienen tareas solapadas o comparten responsabilidad sobre el mismo subconjunto del código. Dos agentes escribiendo tests en el mismo módulo produce tests duplicados y decisiones contradictorias.

No ocurre cuando los sub-agents están aislados por responsabilidad: uno lee, otro escribe tests, otro revisa, otro documenta. Cada uno con un scope tan estrecho que no puede pisar a los demás. Ahí el context burner pattern funciona sin pollution.

Conclusión: los multi-agentes no son universalmente malos. Lo malo es hacerlos sin disciplina de scope.

6. LSP / Serena MCP — la herramienta de la que todo el mundo habla bien

Aquí empieza la parte interesante. Las dos secciones siguientes son las que justifican la afirmación de la introducción de “tirar el borrador y empezar de cero”.

Serena es un MCP que expone operaciones semánticas del Language Server Protocol: find_symbol, find_referencing_symbols, get_symbols_overview. La promesa: en lugar de que Claude haga Read src/services/user.ts y se lleve 3000 tokens de archivo completo para encontrar el método login, invoca find_symbol("UserService.login") y recibe solo el método: 200 tokens.

El benchmark grepai reportó reducción del 97 % en input tokens comparando workflows con y sin Serena en tareas de navegación de código. En latencia, 45 segundos → 50 milisegundos.

Suena perfecto. Lo instalé. Y ahí empezó el problema.

El problema 1: el agente no la usa

Una semana después de instalarla, midiendo todas mis sesiones reales en dos máquinas distintas, descubrí que el agente la había invocado en menos del 1 % de las sesiones donde aplicaba. La inmensa mayoría de las veces optó por Read y Grep igual que antes de instalarla. Cero impacto en factura.

Pensé que era un problema de adopción solucionable con reglas duras. Edité mi CLAUDE.md global con esto:

Navegación de código (Serena MCP)
Cuando trabajes en archivos de código (.ts, .php, .py, etc.):
- Antes de Read para localizar un símbolo: intenta find_symbol primero.
- Para "qué llama a X": find_referencing_symbols, no grep.
- Solo lee el archivo entero si necesitas contexto que rodea al símbolo.

Otra semana, otra medición. La regla movió la aguja menos de un punto porcentual — al menos en mi setup, con esa redacción y ese modelo. El agente decide en cada turno si la herramienta aplica y la regla no es vinculante: es una sugerencia que pondera contra todas las demás señales del prompt. En mi caso CLAUDE.md actuó como recomendación de peso bajo, no como imperativo.

Pero la sorpresa estaba en la siguiente capa de la cebolla. Para entenderla del todo conviene primero ver las dos técnicas que faltan en este recorrido.

7. Context Rot — gestión de sesiones largas

No voy a repetir este capítulo. Lo cubrí hace unos días en Claude Code 1M contexto: context rot y gestión de sesiones, donde audité 928 sesiones para entender cómo decae la calidad del agente antes incluso de llenar el contexto, y por qué compactar al 60 % gana a esperar al warning del 90 %.

Si no lo has leído, léelo antes de instalar las técnicas de este artículo. Sin disciplina de context management, todas las optimizaciones del mundo te ahorran tokens pero no te devuelven la calidad perdida cuando la ventana se llena de ruido.

8. Caveman — el ataque al vector de salida

Las siete técnicas anteriores reducen lo que entra al contexto del agente. Caveman es la única que ataca la otra columna de la factura: lo que Claude genera.

La skill, creada por Julius Brussee y popular en GitHub con miles de stars en pocas semanas, fuerza a Claude a responder “como cavernícola”: sin artículos, sin palabras de relleno, frases telegráficas. Suena ridículo. Funciona.

Tiene tres intensidades:

• lite: elimina filler y hedging, mantiene gramática completa. Profesional pero ajustado.
• full (default): elimina artículos, fragments OK, sinónimos cortos. Estilo cavernícola clásico.
• ultra: abreviaciones (fn, req, →), strip conjunctions, máxima compresión.

El README anuncia un ahorro promedio del 65 % en tokens de output (rango 22-87 %). Sus benchmarks son outputs cortos tipo “explica por qué este componente React re-renderiza” — preguntas técnicas con respuestas conversacionales donde el fluff es proporcionalmente alto.

Lo que el README no cuenta: qué pasa con outputs largos y estructurados (docs técnicos con código y diagramas), qué intensidad es realmente el sweet spot, y si el efecto se mantiene en sesiones de implementación o solo en explicación. Eso es lo que midió mi A/B #4 en el siguiente capítulo.

Activación en sesión: /caveman, o /caveman lite|full|ultra para fijar intensidad. La regla permanente en mi CLAUDE.md global la probé y la quité — ya viste por qué.

El experimento de las cinco ventanas

⚠️ Antes de leer las cifras: esto es n=1 por celda. Una tarea por experimento, una ejecución, sin re-runs para medir varianza. Los números son reproducibles en mi entorno (un monorepo personal Symfony PHP + Next.js admin + Astro web, Sonnet 4.6) pero las re-ejecuciones con temperature ≠ 0 pueden moverse 20-30 %. Lo replicable es la dirección de la curva — en qué ventana cada herramienta gana o pierde — no las cifras exactas. Si vas a citar este artículo, cita la dirección, no los porcentajes puntuales.

Si la adopción no funciona ni instalando ni forzando, llegué a una pregunta más útil: cuando estas herramientas SÍ se usan, ¿realmente ahorran?. Los números que aparecen en sus README (“97 % Serena”, “65 % Caveman”) son single points: una tarea concreta, un escenario favorable. ¿Aguantan en otros escenarios?

Monté cinco experimentos A/B controlados. En cada uno lancé dos sub-agents en paralelo, mismo modelo (Sonnet 4.6), mismo prompt salvo la única variable: una variante con la herramienta obligada, otra con la herramienta prohibida. Sin filtraciones de contexto entre ambos. El output que produzca cada uno es comparable porque ambos parten del mismo enunciado.

Estos son los cinco escenarios y los resultados reales en tokens:

A/B #1 — Búsqueda read-only

“Localiza la clase EmailSequence (PHP) en este repo. Reporta: ruta, firma del constructor, métodos públicos con sus firmas, y los 3 primeros archivos que la instancien. Output máximo 30 líneas.”

Variante	Total tokens	Turns	Tools
Sin Serena (Read+Grep+Bash)	1,111K	31	12× Bash + 4× Read
Con Serena (find_symbol)	443K	13	6× mcp__serena__*
Δ con Serena	-60.1 %	-58 %	—

Resultado idéntico, ambos llegaron a la misma respuesta. Serena ganó por 60 % en tokens y por menos de la mitad de turns.

Hasta aquí el discurso del nicho se cumple. Ahora viene el matiz que nadie cuenta.

A/B #2 — Implementación de 7 features nuevas

Mismo prompt. Tarea: implementar 7 páginas + 7 endpoints + 7 hooks + schemas (~1400 líneas de código nuevo, 30 archivos tocados, 22 nuevos). Sub-agent A obligado a usar Serena, sub-agent B prohibido.

Variante	Total tokens	Turns	Líneas entregadas
Sin Serena	5.50M	121	30 archivos / 1437+ 21-
Con Serena	10.37M	166	30 archivos / 1425+ 21-
Δ sin Serena	-47 %	-27 %	=0

Con Serena costó casi el doble. Mismo output.

Aviso de sesgo: este escenario tiene una proporción alta de archivos nuevos (22 de 30) — escritura sobre lectura. Serena se diseñó para navegar código existente, no para crear archivos. Que pierda aquí dice que no aplicarla por defecto en este tipo de tarea cuesta el doble, no que la herramienta sea mala. El A/B #3 a continuación es el que va al sweet spot teórico: refactor cross-file de código existente.

A/B #3 — Refactor cross-file (el sweet spot teórico de Serena)

Tarea: extraer ContactNameResolver compartido a partir de un patrón duplicado en 3 archivos. Inyectarlo, refactorizar los call sites, mantener semántica. es exactamente el caso de uso de find_symbol + find_referencing_symbols + replace_symbol_body.

Variante	Total tokens	Turns	Líneas entregadas
Sin Serena	1.16M	41	5 archivos / 38+ 17-
Con Serena	2.48M	80	5 archivos / 34+ 20-
Δ sin Serena	-53 %	-49 %	=0

Mismo refactor. Mitad de tokens y mitad de turns sin Serena.

A/B #5 — Auditoría read-only multi-file (segundo intento de sweet-spot)

Tras el resultado de #3, monté un quinto A/B con un escenario aún más conservador: tarea 100 % read-only, sin escritura, sobre una clase con muchos referenciantes. “Audita la clase Campaign: firma, métodos públicos, todos los archivos del proyecto que la usan, e inconsistencias.” 19 archivos referenciantes. El caso de uso de manual de Serena.

Variante	Total tokens	Tool uses	Duración
Sin Serena (Read+Grep)	29.7K	3	56s
Con Serena (find_symbol + find_referencing_symbols)	44.5K	15	73s
Δ sin Serena	-33 %	-80 %	-23 %

Otra vez sin Serena gana. Tres greps amplios + un read del archivo principal cubren la auditoría en menos input que 15 invocaciones MCP semánticas.

¿Por qué entonces ganó en el A/B #1? Mi lectura: en una búsqueda atómica de un solo símbolo en un repo grande (#1: 1100 archivos PHP, encontrar 1 clase), Serena salta directo al símbolo y se ahorra los grep exploratorios. En cuanto la tarea se vuelve estructurada con N símbolos y N referencias, las llamadas semánticas se acumulan y el grep masivo gana por economía de escala.

La conclusión: la ventana óptima de Serena es más estrecha de lo que sugiere incluso su sweet-spot teórico. Es find-this-one-thing en repos grandes, no audit-this-class-and-its-graph.

A/B #4 — Caveman para output verbal

La misma metodología aplicada a Caveman. Tarea: documentar el flujo end-to-end de email de confirmación en ~1500 palabras. Output verbal puro, no toca código. Cuatro variantes: sin Caveman, lite, full (default), ultra.

Variante	Output tokens	Δ output	Total	Δ total	Coste	Δ coste
Sin Caveman	6.6K	—	805K	—	$0.65	—
Caveman lite	4.7K	-29 %	572K	-29 %	$0.62	-5 %
Caveman full	2.5K	-63 %	842K	+5 %	$0.48	-26 %
Caveman ultra	5.4K	-19 %	754K	-6 %	$0.53	-18 %

Caveman sí ahorra, en su ventana óptima (output verbal puro). Pero el “lineal cuanto más extremo, más ahorro” se rompe: ultra ahorra menos que full, y no por poco. Más sobre eso en breve.

Matiz crítico: qué está midiendo realmente la columna “Output tokens”

La tabla anterior usa output_tokens del runtime: toda la prosa que genera el agente durante la sesión — narración de tool results, resúmenes intermedios, comentarios sobre el código que está leyendo, y al final el documento. Caveman comprime ese conjunto.

Pero si lo que te importa es el artefacto (el documento de 1500 palabras), conviene aislarlo y tokenizarlo solo. Lo hice: guardé los cuatro documentos finales como .txt y los pasé por un tokenizer compatible (cl100k_base, aproximación cercana a Anthropic para texto en castellano). Resultado:

Variante	Tokens del documento final	Δ vs none
Sin Caveman	2.607	—
Caveman lite	3.422	+31 %
Caveman full	3.751	+44 %
Caveman ultra	3.641	+40 %

Todas las variantes Caveman producen un documento más grande, no más pequeño. El “ahorro de output” del A/B #4 es real, pero ocurre en el ruido conversacional, no en el artefacto. Cuando obligas al agente a producir el mismo documento final, las abreviaciones (fn, req, →), los fragments y la falta de artículos tokenizan peor que la prosa normal, y el agente compensa la densidad con más sub-secciones para no quedarse corto.

Conclusión refinada: Caveman comprime la conversación, no los entregables. Si la sesión es exploratoria con mucho ida y vuelta del agente, gana. Si la sesión produce un artefacto que vas a leer/publicar, pierde — y de paso lo entrega más feo.

Tres lecciones que el discurso del nicho omite

Junta los cinco experimentos y la conclusión es incómoda para el marketing de cualquier herramienta:

Lección 1: Serena solo gana en tareas read-only

Cuando hay que escribir, refactorizar u orquestar más de un cambio, el agente con Serena gasta el doble. Por tres razones que se ven en los datos crudos:

1. Protocol overhead MCP (hipótesis): cada find_symbol devuelve signatura completa + ubicación + cuerpo. Un Read o Grep devuelve solo lo pedido. El cache_read se infla — en el A/B de implementación, 10.13M con Serena vs 5.36M sin. Matiz importante: cache_read cuesta 10× menos que tokens de input nuevos ($0,30/M vs $3/M en Sonnet 4.6), así que el delta de coste real es menor que el delta de tokens crudo. Aun así, el coste sube y los turns suben.
2. El agente con Serena disponible explora más (hipótesis sobre el modelo, no fenómeno medido): 80 turns vs 41 sin ella en el refactor. Más “voy a comprobar primero”. Sin Serena va más directo. Mi lectura de los traces sugiere esto, pero no lo he aislado experimentalmente.
3. Las edits con replace_symbol_body requieren find_symbol previo. Dos pasos donde Edit es uno.

Esto no significa que Serena sea mala. Significa que su ventana de utilidad es más estrecha que su README sugiere. Es eficiente en exploración pura (“dime dónde está esto y dónde se usa”) y deja de compensar en el momento que mezclas exploración con escritura.

Lección 2: Caveman comprime conversación, no artefactos

Dos curvas no monotónicas, una en cada medición:

• Output total del agente (A/B #4): lite -29 %, full -63 %, ultra -19 %. Full gana porque comprime el ruido conversacional sin caer en abreviaciones costosas.
• Documento final aislado y tokenizado: lite +31 %, full +44 %, ultra +40 %. Todas las variantes Caveman bloatean el artefacto.

Las dos curvas comparten causa: las abreviaciones (fn, req, →) y los fragments tokenizan peor que prosa normal, y el agente compensa la densidad escribiendo más sub-secciones para “no quedarse corto”. En la métrica de output total esto queda enmascarado por el ahorro masivo de prosa intermedia; en la métrica del artefacto solo queda el coste de la rareza.

Conclusión práctica: usa Caveman en sesiones exploratorias o de debugging donde el agente charla mucho y el artefacto final es trivial (un patch corto, un answer breve). No lo uses cuando el artefacto es lo que cuenta — un docs, un blog post, una RFC. Para esos casos, prosa normal gana en tokens y en legibilidad.

Lección 3: Las reglas duras en CLAUDE.md no fuerzan adopción

Una semana de regla explícita y obligatoria en mi CLAUDE.md global (“antes de Read intenta find_symbol”) apenas movió la aguja: la diferencia entre instalar la herramienta y forzarla con regla fue menos de un punto porcentual. Una semana entera, decenas de sesiones, y el agente seguía decidiendo por su cuenta.

¿Qué falla? Las reglas en CLAUDE.md son texto libre que el agente compara contra otras señales del prompt. Si la tarea es “arregla este bug”, el agente decide “voy a leer el archivo completo” porque le da contexto, y la regla genérica de “intenta find_symbol primero” se diluye. El CLAUDE.md no manda, sugiere — y la sugerencia se pierde cuando hay otra señal más fuerte en el prompt.

La adopción real requiere otra cosa:

• Hooks deterministas (SessionStart, PreToolUse) que ejecuten setup automático en vez de confiar en que el agente recuerde una regla.
• Skill triggers explícitos con palabras-llave que el usuario suele usar, no jerga técnica.
• Decisión consciente del operador: yo invoco la skill o tool antes de la tarea cuando sé que aplica, no espero que el agente lo deduzca.

Lo importante: conoce la ventana óptima de cada herramienta

El frame que ningún artículo del nicho está usando:

Cada herramienta tiene una ventana óptima. Las reglas genéricas la sacan de su ventana. Activarla por defecto puede ser contraproducente. La parte difícil ya no es instalar; es saber cuándo activar cada cosa.

La tabla que sigue resume mis hipótesis tras los cinco A/B (n=1 cada uno) y mi experiencia diaria. las cifras concretas son indicativas: dependen de tu stack, modelo y tipo de tarea. Léela como mapa de “dónde mirar primero”, no como benchmark validado:

Herramienta	Ventana donde gana (en mi experiencia)	Fuera de esa ventana
Serena MCP	exploración read-only (find clase, find usos)	refactor / implementación → en mi A/B, +47 a +53 % tokens
Caveman (cualquiera)	sesiones exploratorias / debug con mucha conversación intermedia y artefacto trivial	sesiones que producen artefactos (docs, RFCs, blog posts) → bloatea el entregable
Sub-agents context burner	tareas que generan mucho contexto descartable	tareas con outputs solapados → context pollution
Filesystem memory	proyectos largos con sesiones repetidas	scripts one-shot
CLI vs MCP	servicios con CLI maduro (gh, aws, gcloud)	servicios sin CLI (Notion, Linear)
Skills (Progressive Disclosure)	procedimientos ocasionales	reglas universales del proyecto

Activar todas siempre es lo opuesto de lo que la mayoría de tutoriales sugiere (“instálalo y olvídate”). En mi experiencia, la herramienta sale de su ventana, gasta más tokens y degrada la calidad porque el agente intenta usarla incluso cuando no aplica.

Lo que sigue funcionando en automático

No todo es elección consciente. Hay tres optimizaciones que funcionan transparentes, sin que el agente tenga que recordarlas:

• Tool Search nativo de Anthropic. Cargado por default en Sonnet 4.5+ y Opus 4.5+. -85 % en MCP tokens iniciales.
• RTK (token-killing wrapper de comandos Bash). Reescribe git status, find, npm test para producir output comprimido sin que el agente lo pida. Stackea con todo.
• Filesystem memory (.agent/memory.md). El agente lee el índice al arrancar y decide qué archivo cargar. No requiere reglas duras porque la decisión está en el contenido del índice, no en una directiva.

Estas son las que recomiendo de verdad para todo el mundo. las que requieren elección consciente del agente (Serena, Caveman) las recomiendo solo si activas tú la decisión, no si esperas que el agente lo haga por ti.

Lo que no funcionó

Para mantener honestidad, esto fue al cubo de la basura:

Reglas duras en CLAUDE.md global obligando Serena/Caveman. Una semana de medición controlada, +0.3 puntos porcentuales en adopción Serena y 0 % en Caveman. El agente las ignora.

Caveman permanente como activación por defecto. Lo probé. Dos problemas: el output se vuelve difícil de auditar, y cuando la sesión termina produciendo un artefacto (un commit message largo, una respuesta detallada), Caveman lo bloatea en lugar de comprimirlo. Lo dejé como activación selectiva por sesión.

Migración completa de CLAUDE.md a skills. Lo probé con el vault. Algunas reglas universales (“todo en español”, “kebab-case sin tildes”) dejaron de aplicarse porque las skills no se activaban. Reverti las universales a CLAUDE.md; las específicas se quedaron en skills. Lección: Progressive Disclosure no es sustituto total.

Cuatro configuraciones distintas de sub-agents paralelos. Tres degradaban la calidad por context pollution. Solo context burner con scope estrecho ganaba de forma estable a lo largo de las pruebas.

Una predicción

Apuesto algo: los MCPs tal como existen hoy serán minoría en 12 meses. El patrón Skills + CLIs se los va a comer en todas las categorías donde exista un CLI maduro. Lo que quedará serán servicios sin alternativa CLI (Notion, Linear parcial, algunos SaaS internos).

Apuesto algo más matizado: el discurso público sobre Serena va a evolucionar de “instálala y úsala siempre” a “actívala selectivamente para exploración” conforme más gente mida en escenarios reales en lugar de citar el README. Si mis experimentos se reproducen con otros datasets, la conversación cambia. Si no, habré aprendido yo.

Resumen accionable

Si solo vas a hacer dos cosas este fin de semana:

1. Quita el GitHub MCP. Usa gh. Es la optimización con mayor ROI / esfuerzo de toda la lista.
2. Crea un .agent/memory.md en tu proyecto principal. 15 minutos de setup. Cambia la forma en que Claude mantiene contexto entre sesiones.

Si tienes una tarde entera:

3. Migra la mitad más ocasional de tu CLAUDE.md a skills.
4. Instala Serena pero no la pongas como regla en CLAUDE.md. Úsala manualmente cuando sepas que la tarea es exploración pura.
5. Caveman solo si la sesión es exploratoria con mucha charla intermedia. Si vas a producir un artefacto (docs, post, RFC), no lo actives — bloatea el entregable.

El resto (Tool Search, sub-agents con scope, context rot) son disciplina continua, no instalaciones puntuales.

Conclusión

El artículo v1 trataba de comprimir mejor lo que el agente ya hacía. Este iba a tratar de cambiar lo que hace — instalando ocho herramientas que prometen el siguiente nivel.

Lo que medí dice tres cosas: instalar herramientas no garantiza que el agente las use. Forzarlas con reglas duras casi tampoco. Y cuando se usan fuera de su ventana óptima, cuestan más en vez de menos.

La pregunta que conviene hacerse no es “qué herramientas instalo para ahorrar tokens”, sino “qué ventana óptima tiene cada herramienta de mi caja, y cuándo activarla”. La primera te la responde cualquier README; la segunda la descubres midiendo.

Si te llevas una sola idea: las técnicas que ahorran de verdad son las transparentes (RTK, Tool Search, filesystem memory). El resto son herramientas que rinden dentro de su ventana y estorban fuera de ella. La parte difícil es saber cuál es esa ventana en tu setup.

P.D.: Los cinco A/B se ejecutaron con Sonnet 4.6 sobre un monorepo personal (Symfony backend + Next.js admin + Astro web), midiendo sobre los JSONLs reales del runtime de Claude Code. Si quieres replicarlos, escríbeme y te paso prompts y setup. Y si aún no has leído el primero — cómo reduje un 80 % mi consumo de tokens — empieza por ahí: este es la secuela.

Si encuentras otras formas, me tienes en Twitter como @lm_martinbar.