La razón por la que no se ve el desperdicio de tokens no es el fallo, sino la redundancia: leer el mismo archivo dos veces, reintentar con los mismos argumentos, volver a llamar la misma herramienta. Por eso hice una CLI que lee trazas ya finalizadas y señala qué paso volvió a hacer algo que ya estaba hecho.
[Probarlo]
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Funciona localmente sin registro. No descarga torch, así que la instalación toma apenas unos segundos. Requiere Python 3.12 o superior. Los archivos de sesión de Claude Code están en ~/.claude/projects/.
Esta es una salida real al ejecutarlo sobre una sesión pública de Claude Code (258 turnos):
Result: WASTE DETECTED
- category breakdown: 0 error_repeat, 0 side_effect, 1 idempotent, 0 unclassified
1. requery — Read on .../boot.ts
- turns: turn 50 → re-run at turn 58 (of 258 total)
- state: No modification of this file in between — re-read output is unchanged.
- re-consumed across 200 subsequent turns (≈439 tokens/turn → 87800 amplification tokens)
- estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
[Cómo lo determina]
No almacena ni visualiza trazas como Langfuse o Phoenix. Lee trazas ya terminadas y señala únicamente el desperdicio.
Son 2 pasos. Primero agrupa las llamadas a la misma herramienta con los mismos argumentos, y luego verifica si el sha256 de la salida es exactamente igual. Si la salida es distinta, asume que el estado cambió y no lo marca.
No hay evaluación por LLM. Si se le da la misma traza, siempre devuelve el mismo resultado.
El desperdicio detectado se clasifica en cuatro tipos: repetición de error (reintentar el mismo error sin corregir la causa), reejecución con efectos secundarios (volver a llamar una herramienta que cambia el estado con los mismos argumentos), zona gris (repeticiones de solo lectura: no hay efectos secundarios, pero sí gasto de tokens) y no clasificable. Herramientas como Bash o PowerShell, cuyos efectos pueden cambiar por completo según el contenido de los argumentos, no se juzgan solo por el nombre y quedan como no clasificables.
[Qué encontró en datos públicos]
Lo ejecuté tal cual sobre el benchmark Toolathlon (22 modelos frontier × 3 ejecuciones, 6,780 trazas, 176,270 tool spans) y aparecieron 8,042 llamadas duplicadas.
Usar ese número tal cual sería inflarlo. El 47% corresponde a zona gris (como repetir la declaración de tarea completada o recrear un directorio que ya existe), así que al excluir eso quedan 4,251 casos. Eso equivale al 2.41% de los tool spans.
Lo más llamativo fueron 1,343 reejecuciones duplicadas de herramientas que cambian el estado, y entre ellas hubo 459 casos de envío repetido de correos con los mismos argumentos. Aun así, esto detecta que “la misma herramienta fue llamada dos veces con los mismos argumentos”; no puede confirmarse solo con la traza si el correo realmente se envió dos veces.
[Lo inesperado]
Claude Code en sí resultó más eficiente de lo que esperaba. Medí seis veces patrones candidatos como releer archivos o reintentos sin sentido, y en cinco de ellas prácticamente no aparecieron en sesiones reales de CC. Ya lo está bloqueando mediante caché y mantenimiento de contexto.
Donde el desperdicio sí era más marcado fue en entornos con varios servidores MCP conectados. Hubo una diferencia de 3x entre CC con 20 herramientas (0.80%) y Toolathlon con 523 (2.41%).
[Limitaciones]
Todavía no hay casos medidos de ahorro real. Se puede detectar y estimar, pero no hay ni un solo dato de alguien que haya visto esto, corregido algo y reducido de verdad su factura.
El 47% de la zona gris no se filtra; solo se clasifica y se muestra. Si una repetición de solo lectura es desperdicio real o no depende del contexto de ejecución, y eso es algo que yo no puedo decidir.
Cursor y Codex todavía no están soportados.
Los detectores que fallan en la validación se descartan. Hice un detector de relectura de archivos, pero en una muestra de 30 casos quedó muy por debajo del umbral de precisión del 70% (incluso con una evaluación generosa, 3.3%; con una estricta, 0%), así que lo eliminé, y dejé tanto las predicciones como los resultados en el documento de prerregistro.
[Para cerrar...]
Voy a seguir investigando y validando en esta área.
Perdón porque el readme está en inglés..
Si lo usan, me gustaría recibir feedback sobre qué partes creen que deberían mejorar o qué funciones adicionales les gustaría ver.
De ahora en adelante, por favor sigan de cerca a clew. ¡Muchas gracias...!!
1 comentarios
[Para que sea más fácil de leer, les dejé una traducción al coreano del README.]
Clew
Un detector determinista que encuentra trabajo desperdiciado en trazas de agentes.
Clew lee trazas completas de ejecución de agentes de IA y encuentra pasos que repiten trabajo ya hecho: volver a llamar la misma herramienta con los mismos argumentos, reintentar una llamada fallida con los mismos argumentos, o volver a consultar información que ya está en el contexto. Como funciona sin evaluación de LLM, si le das la misma traza siempre devuelve el mismo resultado.
pip install "clew-custos[detect]"python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.mdEjemplo de salida real ejecutado sobre una sesión pública de Claude Code:
Result: WASTE DETECTED
1. requery — Read on
.../boot.tsPor qué importa esto
En las sesiones de agentes de codificación con IA, el desperdicio solo se hace visible en la factura. Como todas las llamadas a herramientas devuelven 200 y nada da error, el desperdicio no se ve a simple vista. Pero dentro de la traza, el agente vuelve a leer el mismo archivo dos veces, reintenta llamadas fallidas con los mismos argumentos y vuelve a invocar la misma herramienta con el mismo payload.
Como las operaciones de lectura (
read) representan entre 65% y 90% de los tokens en una sesión de agente de codificación, este tipo de desperdicio se acumula sin llamar la atención. Las herramientas de observabilidad muestran la traza, pero no te dicen qué pasos fueron redundantes.Qué detecta
Clew busca tres patrones de redundancia:
repeat — se repite la llamada a la misma herramienta/nodo
requery — se vuelve a llamar la misma herramienta con la misma entrada (misma salida)
pingpong — dos agentes intercambian esencialmente el mismo contenido (multiagente)
Cada hallazgo se clasifica en cuatro tipos:
error_repeat — la salida es un error y aun así se repite la misma llamada
side_effect — se vuelve a ejecutar una herramienta que cambia el estado (enviar/escribir/crear, etc.)
idempotent — se repite una herramienta de solo lectura/declarativa (sin efectos secundarios, pero consume tokens)
unclassified — herramientas fuera del mapeo. Como el efecto depende del payload, no se infiere solo por el nombre de la herramienta (Bash/PowerShell, etc.)
[Cómo funciona]
Es una cascada de 2 etapas:
compuerta estructural — agrupa llamadas a la misma herramienta con los mismos argumentos (normalizados)
compuerta de identidad — verifica si el sha256 de la salida coincide exactamente. Si no coincide, significa que el estado cambió, así que no se marca
Primero, una verificación estructural barata filtra candidatos, y la verificación semántica cara (embeddings + coseno) solo se ejecuta cuando hace falta. Como no hay evaluación de LLM, el resultado es determinista; eso importa si quieres meterlo en CI.
[Formatos de entrada]
Claude Code — analiza directamente el JSONL de la sesión
LangGraph — detecta redundancia de cadenas dentro de la traza
LangChain·CrewAI·AutoGen·LlamaIndex, etc. — parsea trazas instrumentadas en formato estándar OpenTelemetry/OpenInference (hay soporte de formato, y la validación empírica por framework sigue en curso)
trazas públicas de benchmark (Toolathlon, RedundancyBench)
Las sesiones de Cursor y Codex todavía no están soportadas; se están revisando sus formatos locales.
[Resultados de validación]
Benchmark público (Toolathlon, 6,780 trazas, 176,270 tool spans):
se detectaron 8,042 llamadas redundantes. De esas, 47% están en zona gris (operaciones idempotentes, declaración de completado); excluyéndolas, quedan 4,251 casos (2.41% de los tool spans). Aproximadamente 3 veces más que en sesiones de Claude Code (0.80%).
Se detectaron 1,343 ejecuciones redundantes de herramientas que modifican estado, incluyendo 459 envíos de correo repetidos con los mismos argumentos. Aun así, esto solo detecta que la misma herramienta fue llamada de forma redundante con los mismos argumentos; no se confirmó si realmente ocurrió un efecto secundario.
Benchmark etiquetado (RedundancyBench):
precision 0.826 (estimación de límite inferior para redundancia dentro de un archivo). Una parte importante de las etiquetas de RB corresponde a redundancia entre archivos (
cross-file), fuera del alcance de un diseño de análisis por sesión. El recall es bajo, 0.157.[Límites honestos]
Todavía no hay casos medidos de ahorro real. Se puede detectar y estimar, pero hay 0 casos con datos before/after donde un usuario haya corregido algo y la factura realmente haya bajado.
El 47% de lo marcado en el benchmark está en zona gris (re-ejecución idempotente). No se filtra; solo se clasifica, porque que una re-ejecución de solo lectura sea desperdicio depende de contexto que no se puede ver.
Como exige coincidencia exacta de sha256, no se marca nada si la salida cambia aunque sea un poco. Esa es la razón del recall bajo; es un diseño inclinado hacia la precisión.
Claude Code está inusualmente bien optimizado. Se midieron seis patrones de posible desperdicio en sesiones reales de CC, y cinco de ellos no estaban presentes allí. El desperdicio interesante apareció no en CC en sí, sino en entornos MCP con múltiples herramientas.
La estimación de costo (
amplification) es una estimación, no una medición, y solo es posible en el formato de Claude Code.Se descarta lo que no está validado
Se había creado un detector de relectura de archivos, pero en una muestra de 30 anotaciones humanas su precisión quedó muy por debajo del umbral preregistrado (70%): 3.3% siendo generosos, o 0% con criterio estricto, así que fue descartado. Tanto la predicción como el resultado quedaron registrados juntos en el documento de preregistro.