Introducción

Tus Skills de IA funcionan. Los resultados están ahí. Pero ¿lo has notado? Superas tus límites de tokens rápidamente y te quedas bloqueado por el "rate limit" de Claude Code.

Imagina: un skill que se ejecuta regularmente y desperdicia 200 000 tokens en cada ejecución. Con la ventana deslizante de 5 horas del plan Pro, lo saturas en 3-4 ejecuciones. Bloqueado durante 5 horas de espera.

La auditoría de tokens es la herramienta para dejar de chocar contra ese techo tan rápido — y seguir construyendo sin esperar el reinicio.

1. ¿Qué es un token, en realidad?

Un token = una parte diminuta de información que el modelo de IA debe procesar.

• Hola = 1 token
• Una frase media = 10-15 tokens
• Una página de documentación = 500-1 500 tokens
• Una base de datos entera = millones

El coste es doble: - Input (lo que le das al modelo) = 1 crédito - Output (lo que el modelo genera) = 5 créditos

Así que si un skill lee 100 000 tokens y genera 20 000, el coste real = 100 000 + (20 000 × 5) = 200 000 unidades.

2. Las trampas: por qué saturas tus límites rápidamente

Trampa 1: Leer mucho para usar poco

Escenario real: tienes 500 fichas de clientes. Tu skill debe analizar 3. Pero sin filtro, lee las 500.

• Impacto: +150 000 tokens input inútiles por ejecución
• Riesgo: superas tu límite en 5 horas (en vez de 8), bloqueado hasta el reinicio
• Solución: consultar la base de datos de forma inteligente, no en bloque

Trampa 2: Hacer a mano lo que Python podría hacer

Escenario real: el modelo de IA transforma JSON en CSV. Genera texto. Python podría haberlo hecho en 1 ms.

• Impacto: +40 000 tokens output desperdiciados (cuestan 5× más)
• Riesgo: 200 000 tokens adicionales por ejecución
• Solución: delegar al código lo que no necesita razonamiento

Trampa 3: Releer y reescribir en cada ejecución

Escenario real: el martes generas una ficha de análisis de uno de tus competidores. El viernes llega un nuevo documento. Relees TODOS los 500 análisis anteriores para regenerar la ficha.

• Impacto: +200 000 tokens input en cada actualización (en vez de 5 000 para el nuevo análisis)
• Riesgo: doblas tu consumo innecesariamente
• Solución: modo incremental — procesar solo los datos nuevos

Trampa 4: Inflar el contexto de sistema

Escenario real: el "prompt" del skill (instrucciones, templates, ejemplos) pasa de 5 KB a 25 KB. Son 5 000 tokens de contexto fijo en cada llamada.

• Impacto: +5 000 tokens input × 100 ejecuciones = 500 000 tokens/mes perdidos
• Riesgo: cuota saturada más rápido con cada cambio del skill
• Solución: externalizar los templates pesados, cargarlos bajo demanda

Trampa 5: Usar un modelo demasiado potente para una tarea simple

Escenario real: usas Opus 4.6 para extraer cifras de una lista. Con Haiku habría bastado.

• Impacto: consumo 2-3× más alto para el mismo resultado
• Riesgo: cuota saturada innecesariamente
• Solución: adaptar el modelo a la complejidad real

3. Los riesgos de no auditar

📊 Riesgo de cuota

• Un skill costoso × unas pocas ejecuciones = saturado en 5 horas
• Sin auditoría, no sabes dónde recortar — así que dejas de trabajar
• Pierdes el tiempo esperando el reinicio de la ventana deslizante

⏱️ Riesgo de productividad

• Skills pesados → chocas contra el rate limit cada 5 horas
• Ya no puedes testear, iterar ni experimentar con fluidez
• Te quedas bloqueado en pleno proyecto, esperando el reinicio

🚀 Riesgo de escalabilidad

• Mientras eres el único, pasa. Pero ¿y si otros se unen y comparten el límite?
• Conflicto sobre la cuota compartida → todos se bloquean mutuamente

⚙️ Riesgo operacional

• Despliegas un nuevo skill sin medir su impacto sobre tu cuota
• No sabes por qué estás bloqueado la siguiente vez

4. Cómo funciona: auditar en 3 fases

¿Qué es un auditor? Es un script automatizado que analiza tu skill como un inspector examinando una casa: revisa cada paso ("¿lees este archivo? ¿cuántos tokens?"), hace el cálculo y te dice dónde estás desperdiciando.

Fase 1: Cartografiar

El skill escanea todas las etapas de tu workflow: - ¿Qué archivos se leen? - ¿Qué cálculos se hacen? - ¿Qué se genera?

Fase 2: Medir

Para cada etapa, estima los tokens consumidos: - Archivos reales en el proyecto → medida con wc para mayor precisión - ¿Sin datos reales? → estimación conservadora - Acumulación de contexto → contabilizada (habitualmente el 15-40% del coste)

Fase 3: Recomendar

El skill identifica las etapas costosas > 15% del total y propone optimizaciones:

Cada optimización está cuantificada: "esta acción te ahorra 45 000 tokens = -8% del coste total".

5. Ejemplo real: competitor_analyze

Nuestro skill competitor_analyze analiza la inteligencia competitiva.

Estado actual: - 478 000 tokens consumidos por ejecución - Modelo requerido: Opus 4.6 (pesado) - Frecuencia: ~2-3 veces/semana en periodo activo - Impacto sobre la cuota: impacta fuertemente las sesiones y nos encontramos bloqueados en "rate limit" antes en la ventana deslizante de 5 horas

¿Adónde van los tokens? (ver gráfico a continuación)

Optimizaciones propuestas: 1. Leer los análisis de forma incremental → -14% (ahorro: 67 000 tokens) 2. Modo incremental para los temas → -10% (ahorro: 48 000 tokens) 3. Externalizar los templates del SKILL → -4% (ahorro: 19 000 tokens)

Impacto: - Tokens consumidos (optimizado): 271 000 (-43%) - Ganancia por ejecución: 207 000 tokens ahorrados - Resultado: en vez de saturar en 5-6 ejecuciones, puedes lanzar 8-10 en la ventana de 5 horas - Concretamente: pasas de "bloqueado en 2 lanzamientos" a "liberado con 3-4 lanzamientos adicionales"

6. Plan de acción para tu equipo (o para ti, si trabajas solo)

Paso 1: ¿Qué skills auditar?

• Listar todos tus skills en producción
• Clasificarlos por frecuencia de uso: "el que lanzamos 10 veces/semana debe ser eficiente"
• Empezar por el top 3 de los skills más frecuentes

Paso 2: Lanzar la auditoría

/token_audit <nombre_del_skill>

→ Informe generado automáticamente, sin esfuerzo

Paso 3: Leer el informe

Puedes leer directamente: - Tabla Resumen: tokens consumidos, etapa más costosa, modelo recomendado - Tabla Optimizaciones: qué cambiar, ganancia estimada, complejidad

Paso 4: Decidir qué optimizar

Regla simple: - Ganancia > 100 000 tokens Y complejidad baja? → Hacer ahora - Ganancia > 50 000 tokens Y complejidad media? → Planificar cuando haya tiempo - Ganancia < 50 000 tokens? → Ignorar, no hay ROI

Paso 5: Implementar y validar

• Implementar la optimización
• Relanzar la auditoría unas semanas después para confirmar las ganancias

PD: también puedes crear un Skill "Arquitecto de software" (hablaremos de ello) que usará este informe de auditoría y otros elementos para proponerte un plan de optimización avanzado.

Frecuencia recomendada (realista para una persona)

• Cuando lanzas un nuevo skill: auditoría en cuanto lo despliegues
• Cuando tu cuota se satura demasiado rápido: auditoría de los sospechosos
• Cada trimestre: auditoría del skill más pesado (para seguir el crecimiento de los datos)

7. ROI: Por qué vale la pena

Inversión

• Tiempo: unas pocas horas para auditar tus 3-5 skills más pesados
• Herramientas: gratuito (integrado en Claude Code)
• Implementación: depende de las optimizaciones elegidas (1-20 días según la complejidad)

Retorno

• Corto plazo (unos días): -20% a -40% en los 3 skills prioritarios = liberar 3-5 ejecuciones por ventana de 5h
• Medio plazo (1-3 meses): portfolio completo optimizado = pasar de "bloqueado tras 2-3 lanzamientos" a "5-6 lanzamientos libres"
• Largo plazo: puedes experimentar, testear e iterar sin chocar contra el rate limit cada 5 horas

Ejemplo concreto: - Lanzas 3 skills pesados en producción - Consumo inicial: saturado tras 2 lanzamientos en la ventana de 5h - Tras auditorías y optimizaciones: -40% de consumo - Resultado: en vez de bloquearte, tienes 3-4 lanzamientos adicionales = productividad recuperada - Tiempo invertido: 1-2 días para las auditorías + 5-10 días para las optimizaciones prioritarias - ROI: puedes trabajar con fluidez en vez de gestionar bloqueos constantes

8. Los adjuntos de este artículo

1. Anexo A: Cómo usar el skill /token_audit

→ spec_token_audit.md

Todo lo que necesitas saber para: - Instalar el skill en tu proyecto - Usarlo (aunque no sepas programar) - Interpretar el informe generado - Conocer las limitaciones (solo mide el uso estático, no la telemetría real de ejecución)

2. Anexo B: Caso concreto — Auditoría del skill competitor_analyze

→ token_audit_competitor_analyze.md

Lee el informe real para ver: - Tabla de costes detallada por etapa - Dónde se "desperdician" los tokens - 5 optimizaciones propuestas con ganancia cuantificada - Comparación antes/después

⚠️ Las limitaciones del auditor (imprescindible conocerlas)

La auditoría de tokens es potente, pero tiene fronteras importantes. Ser honesto al respecto es usar la herramienta correctamente.

1. Es un análisis estático, no real

La auditoría lee tu código (SKILL.md, archivos referenciados) y estima los tokens consumidos. No ejecuta el skill de verdad.

Implicación: - Las estimaciones son generalmente cercanas a la realidad (±15%), pero no exactas - Si tu skill contiene un bucle condicional ("procesar los análisis solo si tienen menos de 7 días"), la auditoría considera el peor caso (procesar todo) - Los volúmenes reales dependen de los datos del día → variables

Cuándo es un problema: - Un skill con muchas ramas condicionales → la auditoría puede sobreestimar - Un skill que hace llamadas a APIs externas (WebFetch) → el volumen real depende del tamaño de las páginas

2. Sin telemetría real de ejecución

La auditoría no tiene acceso a las métricas de ejecución real (¿cuántos tokens costó realmente la última ejecución?).

Implicación: - Solo tienes estimaciones, no medidas certificadas - Imposible validar una optimización con certeza antes/después sin instrumentar el código

Cuándo es un problema: - Si necesitas una validación financiera precisa → debes instrumentar tu código (añadir logging de costes reales) - Si un skill supera 1M de unidades → las diferencias se vuelven significativas en euros

3. La ratio de conversión tokens → euros es estimada

La auditoría estima "output = 5× el coste de input" (regla Claude). Es correcto en promedio.

Realidad matizada: - Es exacto para Sonnet 4.6 y Opus 4.6 - Pero las tarifas evolucionan (nuevos modelos, cambios de precios) - Y tus contratos con clientes podrían tener tarifas distintas

4. No mejora las decisiones "de negocio" del skill

La auditoría puede decir "lees 140 análisis, podrías leer 50 y hacer incremental".

Pero: "¿hay que hacer realmente modo incremental?" Es una decisión de negocio, no técnica.

Ejemplo: un skill que revalida TODOS los competidores cada mes (no incremental): es una elección. La auditoría lo señala, pero la respuesta "es más seguro" podría ser válida.

5. La complejidad real puede estar subestimada

La auditoría clasifica las optimizaciones por complejidad (baja / media / alta), pero: - Una optimización "baja" según la auditoría podría ser "alta" en tu codebase (código antiguo, dependencias) - Las estimaciones presuponen código limpio y modular

Resumen de limitaciones:

Conclusión sobre las limitaciones:

La auditoría es una herramienta de diagnóstico, no una máquina de predicción. Sus estimaciones son suficientemente buenas para priorizar, pero no suficientes para decir "esto costará exactamente X€".

Usa la auditoría: - ✅ Para identificar las fugas evidentes (> 100k tokens) - ✅ Para priorizar las optimizaciones (ganancia ÷ esfuerzo) - ✅ Para justificar cambios de arquitectura - ❌ Para cálculos de coste al céntimo - ❌ Para validar resultados (requiere logging real)

Conclusión

Auditar tus skills es pasar del "¿por qué estoy bloqueado cada 5 horas?" al "sé dónde recortar".

Es el equivalente de una auditoría energética para tu cuota: descubres dónde están las fugas, las tapas, y de repente tienes 5-6 lanzamientos fluidos en vez de 2-3 antes del bloqueo.

3 puntos clave: 1. Los tokens que desperdicias se acumulan rápido y te bloquean cada 5 horas 2. Sin auditoría, el desperdicio es invisible — simplemente dejas de poder trabajar 3. Las optimizaciones son sencillas y el impacto es inmediato (ventanas productivas más largas)

¿Listo para empezar? Lanza una auditoría de tu skill más frecuente. Tendrás un informe en 5 minutos. Las ganancias llegarán después.

Preguntas frecuentes

P: ¿La auditoría ralentiza mis skills? R: No. La auditoría es un análisis estático (lee tu código), no una ejecución real.

P: ¿Y si solo tengo skills pequeños? R: La auditoría de skills pequeños (< 1 500 tokens) no vale la pena. Céntrate en tus 3-5 mayores consumidores.

P: ¿Se pueden auditar los skills de la competencia? R: Imposible (no tienes acceso a su código). La auditoría solo tiene sentido para tus propios skills.

P: ¿Y si un skill supera 500 000 tokens por ejecución? R: Es una señal de alerta. Auditoría prioritaria. Habitualmente hay un 40-50% de ahorro posible.

P: ¿Cuánto cuesta una auditoría? R: Cero (es gratuita, integrada en Claude Code). Implementar las optimizaciones lleva de 1 a 20 días según la complejidad.

P: ¿Vale la pena si trabajo solo? R: ¡Sí, todavía más! Eres directamente el afectado por la cuota. Un skill optimizado = 2-3 semanas de trabajo en vez de 1.