El 94% de Mis Tokens de Claude Code Fueron al Modelo Equivocado. Así Que Dejé de Pagarle a Opus por Hacer el Trabajo de Haiku.
Sientes que has hecho todo bien con Claude Code. Hooks instalados. CLAUDE.md pulido hasta 6,890 tokens. Cada servidor MCP eliminado, con esa disciplina de la que te sientes silenciosamente orgulloso un viernes por la noche.
Entonces llega el miércoles, tres días antes de que se reinicien tus límites semanales, y ya estás al 80% de uso. Incluso con el plan Max.
Ahí es cuando empiezas a preguntarte qué te estaba comprando realmente esa disciplina.
RESUMEN. Puedes retorcer tu configuración de Claude Code todo lo que quieras. Encontré una herramienta gratuita que no miente sobre la hinchazón, reduce costos drásticamente y hace a Claude más agudo, no solo más barato. Esto es lo que hice y cómo puedes replicarlo.
Durante meses había estado escuchando a Boris Cherny y leyendo los ensayos de Anthropic sobre ingeniería de contexto. Hice la tarea. MCPs eliminados. CLAUDE.md recortado. Para cuando también archivé los archivos MEMORY e instalé el hook SessionEnd, los números hablaban por sí solos: 643 sesiones en treinta días con cero crashes y cero pánico de /context.
Al final de mis tokens, salí a buscar. Y encontré una joya. Una herramienta de auditoría que no solo cuenta tokens. Te dice cuándo Claude se está volviendo tonto.
La Puntuación Que Me Hizo Cerrar la Pestaña
La ejecuté la semana pasada. Seis agentes en paralelo, sesenta segundos. Primera cosa en pantalla: Health Score C, 69 de 100.
No D, no F. C. La nota de un chico que pensaba que había estudiado bien. Tenía margen, o mejor dicho, un abismo.
Total Session Overhead: 23.5K tokens, 2.3% de la ventana de un millón de tokens. CLAUDE.md global en 6,890. Skills en 1,809. Commands 1K, cero herramientas MCP, el resto sentado donde esperaba. Los números eran pequeños.
Y entonces vi la línea que me hizo dejar de hacer scroll.
Real session baseline averages 43.2K tokens (+83.9% vs estimate). Gap is from unmeasured system overhead.
La herramienta de auditoría me estaba diciendo que ella misma estaba submidiendo. El marco XML, las instrucciones MCP, los prompts del sistema que vienen con cada llamada al modelo (admítelo, tú tampoco los revisas). Cosas que nunca veo en /context, que había estado pagando en cada mensaje.
Lo que pensaba que estaba midiendo era la mitad de lo que realmente se facturaba.
Ese es el momento en que cambió el enfoque. La puntuación es una calificación de arquitectura disfrazada de medidor de llenado. La mitad de la hinchazón que estaba pagando, nunca la vi.
La Deuda de Tokens No Es Solo Financiera
Cada post de Medium sobre costos de Claude Code lo enmarca igual. Tu contexto está lleno. Estás pagando demasiado. Recorta tu CLAUDE.md.
Medio correcto. La otra mitad es que la deuda de tokens es dual.
La capa financiera es la obvia. La API de Anthropic es stateless. Cada turno recarga toda la pila. El prompt caching divide el costo por diez pero la ventana en sí no se encoge. Así que si tienes un archivo fantasma de 1,410 tokens en MEMORY de un proyecto terminado, y envías 3,347 mensajes al día, y haces eso durante dieciocho días... son 85 millones de tokens facturados por cero valor. De un archivo.
Para escala: 137 millones de tokens facturables es lo que consumí el mes pasado, total. Un solo archivo fantasma se llevó varios por ciento del volumen. En silencio.
La capa cognitiva es de la que nadie habla. Según la guía publicada de Anthropic y confirmado por el diseño de la herramienta de auditoría, la calidad baja después del 50-70% de llenado de contexto. La compactación tiene pérdidas. Con 9.7 millones de tokens promedio por sesión en una ventana de un millón de tokens, son aproximadamente diez compactaciones por sesión. Seis mil compactaciones en treinta días. Cada una recorta algo (una regla, una convención, un pedazo de alcance que estableciste hace dos horas).
Y luego está el overhead que no puedes ver. El propio equipo de ingeniería de Anthropic reportó que las definiciones de herramientas MCP consumían 134K tokens antes de que lanzaran Tool Search. Un usuario de Reddit documentó 67,000 tokens perdidos solo por conectar cuatro servidores MCP. Nada de eso aparece en /context.
Los tokens no utilizados te cuestan dinero. El costo mayor es que pagas por degradar la calidad de tu propio razonamiento, en cada turno.
Había escrito, en febrero, que CLAUDE.md es el nuevo .env, no el nuevo README. Traté el archivo como un problema de configuración. Esa era la mitad del panorama. La capa cognitiva, no la había visto.
Seis Agentes, Sesenta Segundos, Un Veredicto
La herramienta se llama token-optimizer. Es un plugin de Claude Code, código abierto, en el GitHub de Alex Greensh. Lo instalas con una línea: /plugin marketplace add alexgreensh/token-optimizer.
La arquitectura es honesta. Seis agentes corriendo en paralelo. Sonnet maneja las decisiones críticas, Haiku hace el trabajo de conteo, y Opus entra solo al final para la síntesis. Un dashboard vive en localhost:24842 y se actualiza automáticamente en cada hook SessionEnd.
Lo que hace que ninguna otra hace: rastrea qué tan tonto se está volviendo tu AI conforme avanza la sesión. Cita del repo, no mía. /context te muestra el medidor. Esto te muestra la arquitectura bajo el medidor Y la degradación de calidad a lo largo del tiempo.
La herramienta también admite sus propios límites. El +83.9% de submedición que cité antes? Viene de la auditoría diciéndome a sí misma: "Gap is from unmeasured system overhead." Una herramienta que reconoce lo que no puede ver es más creíble que una que pretende verlo todo.
Hace tres semanas, escribí sobre el día que mi plan Pro Max duró quince minutos antes de que ejecutara /context y viera la hinchazón por primera vez. Pensé que había visto lo peor. /context te dice que el refrigerador está lleno. Token-optimizer te dice que la mitad de la comida está vencida.
También encaja con una tesis que he estado impulsando durante meses. La razón por la que esto funciona es porque es un plugin nativo de CLI, no un servidor MCP. Corre dentro del bucle de ejecución de Claude Code, no sobre un protocolo de herramientas remoto. Es un pequeño punto de datos en por qué las herramientas nativas de CLI vencen a los servidores MCP para agentes de AI.
Seis agentes, sesenta segundos, un dashboard. Y cada hallazgo que produce, tienes que aplicarlo tú mismo.
La Palanca Visible Paga Menos
Esto es lo que la auditoría encontró primero. Tres archivos MEMORY de proyecto, archivados de trabajo terminado. Uno de ellos era de 1,410 tokens por sí solo. Haz las cuentas: 1,410 tokens × 3,347 mensajes al día × 18 días que el archivo estuvo en MEMORY después de que dejé de tocar el proyecto. Son 85 millones de tokens facturados por cero valor, de un archivo.
Para escala, mi consumo facturable total ese mes fue de 137 millones. Un archivo fantasma se comió aproximadamente 0.6% de todo mi volumen mensual, sin contribuir nada.
Multiplica eso por los otros: dos archivos MEMORY más archivados. Seis citas de incidentes antiguos de Twitter en el CLAUDE.md global, retiradas. Descripciones verbosas de skills recortadas. Comandos de plugins que nunca invoqué, podados.
La limpieza total medida: -1,386 tokens por mensaje en la capa de archivos, una caída del 5.9%. Más otros 2,565 tokens recortados del corpus bajo demanda.
La regla que generalizaría: si un archivo MEMORY no ha sido referenciado en un prompt durante 14 días, archívalo por defecto. Los docs de Anthropic recomiendan un límite de auto-carga de 200 líneas. El límite práctico real es 14 días de referencia.
Ahora aquí está la verdad incómoda.
5.9% no es el medio bocado de pan que suena. Es la capa que puedes ver, lo que la convierte en la capa con la que todos se obsesionan. Pero también es la capa que paga menos.
El archivo fantasma es el aperitivo. El plato principal está en otro lado.
Dos Mejores Prácticas Que Copié de Threads. Ambas Me Costaron.
Dos hallazgos que la auditoría marcó que no atraparías leyendo cada doc de Anthropic de tapa a tapa.
El primero. Tenía un skill llamado questionnaire-prospect con una descripción de 438 caracteres. La auditoría lo marcó pasando el umbral. Después de aproximadamente 250 caracteres, Claude Code trunca silenciosamente la descripción en el menú de skills. El SKILL.md completo aún se carga cuando se invoca el skill, pero en el menú donde Claude decide si activar el skill en primer lugar, la descripción está mutilada.
Resultado: Claude ve una oración cortada, no entiende cuándo debería dispararse el skill, y silenciosamente lo ignora. El skill no se rompe. Simplemente deja de activarse de manera confiable. Recorté la descripción a 223 caracteres. El óptimo recomendado por la auditoría es 80 caracteres. Ninguno de los docs oficiales de Anthropic que he leído menciona este comportamiento de truncamiento.
Lo que escribes en una descripción, y lo que Claude realmente ve, no están garantizados de ser lo mismo.
El segundo. Un hook PostToolUse ejecutando vitest después de cada Edit/Write. TDD aplicado al flujo de trabajo del agente, nunca se envía estado roto. Sonaba genial en Reddit. Sonaba genial en un thread que estaba leyendo.
Vida real, con un archivo editado treinta veces durante una refactorización: treinta ejecuciones de pruebas. Treinta reportes de vitest contaminando el contexto de Claude (cada reporte es un mensaje del sistema en su ventana de contexto). Treinta golpes de latencia. La auditoría lo marcó en el momento que se ejecutó. Desactivé el hook. La latencia se limpió. El contexto se mantuvo más limpio.
La regla que va más allá de vitest: un hook PostToolUse genérico que coincida con Edit/Write es casi siempre una trampa. Los hooks deberían dispararse en transiciones de fase (SessionEnd, fin de feature, deploy). No en operaciones atómicas.
Hilo común de ambos: las mejores prácticas genéricas no son lo mismo que las mejores prácticas para TU proyecto en TU volumen. Un desarrollador senior no ejecuta la suite de pruebas después de cada guardado. La ejecuta antes del commit. Misma lógica para agentes.
Estos son los patrones que señalé en cada tutorial de Claude Code que se desmorona en producción. Había estado coleccionando mejores prácticas como skills: en una carpeta, por si acaso, pagadas en silencio.
Por Qué el Enrutamiento Hizo al AI Más Agudo, No Solo Más Barato
Este es el hallazgo que la auditoría clasificó como número uno. Y es la sección a la que apunta el título.
Treinta días de uso. 643 sesiones. 137 millones de tokens facturables. Mezcla de modelos: 94% Opus, 0% Sonnet, 4% Haiku, 2% otros.
Sonnet en cero. En 137 millones de tokens.
No había elegido Opus sobre Sonnet. Simplemente nunca configuré enrutamiento en primer lugar. La auditoría lo etiquetó con una proyección de ahorro del 50-75%. En los siete días que tengo visibles en el reporte, gasté $1,668. Una disciplina de enrutamiento del 50% ahorra $834 a la semana. 75% ahorra $1,250.
Ahí es donde aterriza honestamente el ángulo de costo, no en la limpieza de archivos. Pero el costo es la mitad de la historia. El giro que hace el título es este: el enrutamiento no solo ahorra dinero. Hace al AI más agudo. Tres mecanismos.
Opus tiene un temperamento. Está afinado para pensar. Cuando le das una tarea acotada, la amplía, porque eso es lo que hace bien. Toma una semana típica. Estoy depurando un flujo en mi tienda WooCommerce y le hago a un agente Explore una pregunta simple: "encuentra cada referencia a checkout_cta en el storefront." Una tarea de grep. Literalmente. Haiku hace esto en cuatro segundos por una fracción de centavo.
En modo 94% Opus, el agente lee 23 archivos, contextualiza los usos, nota una inconsistencia entre los formatos de viñetas markdown y blockquote en módulos antiguos versus nuevos, propone una refactorización, abre una discusión sobre factorizar el patrón en una plantilla compartida. No había pedido nada de eso. Quería una lista de archivos. Obtuve una mini revisión de arquitectura. Costo: aproximadamente $0.30, ocho minutos, contexto consumido para nada porque ya había seguido adelante.
Enrutado a Haiku, misma consulta: lista en cuatro segundos, $0.001, contexto intacto.
Opus no está mal aquí. Opus está mal asignado. Pedirle a Opus que haga grep es como pedirle a un arquitecto senior que cuente cajas en un armario.
Sonnet en refactorizaciones acotadas es más disciplinado que Opus. Para transformaciones en un alcance definido, refactorizar un módulo, agregar una característica dentro de un perímetro, Sonnet entrega una salida que se mantiene alineada. Menos propuestas alternativas no solicitadas. Herramienta correcta, alcance correcto.
Opus liberado de tareas acotadas mejora en las decisiones arquitectónicas que realmente necesitas. Cuando dejas que Opus maneje grep Y conteo Y búsqueda Y decisiones arquitectónicas, para cuando lo invocas en el problema difícil, su contexto ya está contaminado por 47 sesiones de grep. La regla "la calidad baja después del 70%" vive aquí. No solo pagas a Opus para hacer el trabajo de Haiku. También pagas el precio oculto: tu Opus es menos agudo cuando realmente lo necesitas.
Opus sigue siendo la elección correcta para razonamiento complejo, para eso lo afina Anthropic. Haiku no es "más inteligente" en absoluto. El matiz es que Haiku está mejor asignado, en la tarea correcta, con un contexto limpio.
La Palanca Que la Auditoría No Pudo Jalar por Mí
La auditoría te muestra. La auditoría no arregla todo.
De los hallazgos en el reporte, la limpieza de archivos es auto-aplicable. Archiva un archivo, se mantiene archivado. La hinchazón de skills es parcialmente auto: las descripciones se acortan en el lugar. El hook de vitest es binario, encendido o apagado.
¿El enrutamiento de modelos? Eso es diferente.
La herramienta inyecta un bloque de enrutamiento en CLAUDE.md global con un TTL de 48 horas. Si no lo refresco, se auto-elimina, porque los patrones de uso cambian. No puedo auto-disciplinarme desde un archivo de configuración. Tengo que despachar conscientemente: Explore y lookup van a Haiku. Refactorizaciones en alcance van a Sonnet. Decisiones arquitectónicas van a Opus.
Esa es disciplina humana. Medible, pero no automatizable.
El mensaje real de la auditoría no es "aquí están los archivos para archivar." Es más cercano a: aquí está la deuda que tu flujo de trabajo acumula, y la palanca dominante pasa por ti, no por mí.
Misma estructura que algo que envié hace un par de meses, cuando dejé que Claude Code auditara mis propias trescientas setenta y cuatro sesiones y el reporte regresó incómodamente honesto. /insights auditó mi comportamiento. token-optimizer audita mi configuración. En ambos casos, la corrección es humana.
El número 50-75% es una proyección en el momento de la auditoría. Mi ganancia real depende de mi disciplina de enrutamiento durante las próximas dos semanas. Marco honesto.
Dos Semanas Después: Lo Que la Puntuación Movió y No Movió
Ejecuté la auditoría de nuevo dos semanas después. Puntuación diferente, forma diferente.
La limpieza de archivos se mantuvo. Los archivos MEMORY archivados permanecieron archivados. Las descripciones de skills se mantuvieron recortadas. -1,386 tokens por mensaje en la capa de archivos, línea base. -2,565 tokens en el corpus bajo demanda. Esas ganancias no requieren fuerza de voluntad. Son estructurales.
La capa de enrutamiento es donde estaba la prueba real. Me había comprometido a despachar tareas de Explore y lookup a Haiku, refactorizaciones a Sonnet, decisiones arquitectónicas a Opus. Dos semanas de despacho consciente. La mezcla de modelos cambió, pero no tan limpiamente como había imaginado. El TTL de 48 horas en el bloque de enrutamiento en CLAUDE.md global hizo su trabajo: cuando volví al Opus-por-defecto un martes por la tarde, la auditoría lo atrapó la próxima vez que la ejecuté.
Detección de deriva es la característica que subestimé. La herramienta toma una instantánea de tu configuración en la instalación y vigila lo que regresa. Si un hook que desactivé se reinstala, lo veo. Si un archivo de memoria que archivé regresa, también lo veo. La mezcla de modelos deslizándose de vuelta al 90% Opus también aparece en rojo en el dashboard.
Lo que veo claramente ahora: el lado cualitativo es real. Las tareas de Explore que enruto a Haiku regresan más rápido, en contexto más limpio, y las llamadas de Opus que guardo para decisiones arquitectónicas llegan en un contexto que no ha sido ya masticado. Sesiones que solían llegar al 70% de llenado antes de la compactación ahora lo alcanzan un tercio después. La factura no registrará ese cambio. La salida sí.
Una C no es "mala." Significa que hay margen, y ahora sabes dónde.
Las palancas reales no están donde Medium sigue apuntando. Están en el enrutamiento, y en los hooks que copias de threads sin probar en tu propia configuración.
Token-optimizer es parte de mi rutina ahora, sentado junto a graphify, que es una historia para otro día. Estoy más tranquilo, y Claudius está más agudo 😊
Menos tentado a vagar y revisar si el pasto está más verde en Codex.
Fuentes
- token-optimizer por Alex Greensh: github.com/alexgreensh/token-optimizer
- Anthropic Engineering, Advanced Tool Use (reducción de Tool Search de 134K a 8.7K): anthropic.com/engineering/advanced-tool-use
- Documentación de memoria de Claude Code (límite de auto-carga de 200 líneas, caída de calidad al 50-70% de llenado): code.claude.com/docs/en/memory