25 de septiembre de 2026

Medí el desperdicio de mis sesiones con agentes. Mi primer resultado era falso. Los tres siguientes, también.

El primer número que obtuve fue este:

(a) ≥25% de sesiones con ≥1 patrón de desperdicio  →  63%     ✅
(b) esas sesiones cuestan ≥1,8x la mediana         →  13,11x  ✅

Trece veces. Había fijado los umbrales antes de mirar los datos, precisamente para no autoengañarme, y los había superado con un margen ridículo. Durante unos minutos pensé que tenía el hallazgo.

No lo tenía. Y no fue la única vez: después encontré otros resultados que parecían buenos y eran el mismo error con otra ropa. Este post va de esos errores, porque creo que son más útiles que cualquier cifra de ahorro. Es el error que hay detrás de casi todas las que se publican en este sector.

Qué medí

Los CLIs de agentes escriben transcripciones completas en disco. En Claude Code están en ~/.claude/projects/**/*.jsonl, una línea JSON por mensaje, con el contador de tokens real de cada turno: input_tokens, output_tokens, cache_read_input_tokens, cache_creation_input_tokens. No hay que estimar nada ni llamar a ninguna API.

Mi corpus:

Buscaba patrones de redacción que, según un estudio preregistrado con 4.644 runs, multiplican el trabajo del agente sin mejorar la tasa de éxito. Dos ejemplos: pedir "compara varias aproximaciones" dispara torneos de ramas que se descartan, y el lenguaje de certeza ("asegúrate de que", "verifica que") dispara ciclos de verificación redundante.

El análisis es determinista: expresiones regulares y aritmética. Cero tokens de IA, cero red.

Error 1: conté sesiones

Marqué cada sesión como "con patrón" si alguno de sus prompts hacía match, y comparé la mediana de coste de los dos grupos.

El problema está en esa frase: una sesión contiene muchos prompts. Cuantos más prompts tenga, más oportunidades hay de que alguno haga match. Y una sesión con más prompts tiene, casi por definición, más turnos y más coste.

No estaba midiendo "los patrones de desperdicio cuestan dinero". Estaba midiendo "las sesiones largas contienen más texto, y por tanto más coincidencias". El 13x era el tamaño de la sesión mirándose en un espejo.

Lo que hace este error especialmente tramposo es que la dirección del efecto es la que esperas. Si el resultado hubiera salido invertido, habría buscado el fallo de inmediato. Como salió a favor de mi hipótesis, casi no lo busco.

La corrección es medir por episodio: un prompt del usuario, más todo el trabajo del agente hasta el siguiente prompt del usuario. Cada episodio tiene exactamente un prompt, así que la oportunidad de hacer match es la misma para todos.

Error 2: no todos los "prompts del usuario" los escribí yo

Al cortar por episodios, uno de los patrones sobrevivía. El lenguaje de certeza salía a 1,9x el coste mediano, con 12 casos y significación estadística marginal. Coincidía con el mecanismo del paper. Tenía buena pinta.

Más tarde, revisando otra cosa, descubrí que el 41% de los mensajes que yo había contado como prompts míos no los había escrito yo. En los transcripts de Claude Code llegan con el mismo rol de "usuario":

• los informes que devuelven los subagentes al terminar (91 de 275),
• el texto de las skills que el harness inyecta al invocarlas (23 de 275).

Y esos textos están llenos de "make sure", "verify that", "ensure". De los 12 episodios con lenguaje de certeza, 9 eran el propio agente hablándose a sí mismo. Con mis prompts reales quedan 3. Con 3 casos no hay nada.

Recortando bien, mis 275 "prompts" se quedan en 161 reales y los episodios en 133. Así queda cada regla:

Ninguna es significativa. Y fíjate en las dos que tienen ratios grandes: sus episodios hacen entre 8 y 18 veces más llamadas a herramientas. Otra vez el tamaño. Lo que queda de la hipótesis del prompt en mis datos es, honestamente, nada.

Error 3: los errores no salían caros, salían largos

La tercera vez ya no fue con mis datos. Para salir del n=1 analicé TraceLab, un dataset público de la Universidad de Washington (Zhu et al., 2026, licencia CC BY 4.0): unas 4.300 sesiones reales de 43 desarrolladores con Claude Code y Codex. Las cifras que doy de TraceLab son análisis míos sobre sus datos, no conclusiones de sus autores.

Los episodios con tres o más errores de herramienta costaban 8,6x la mediana de los que no tenían ninguno. Era el candidato perfecto para un freno: "tu agente está en un bucle de errores y te está costando nueve veces más".

Comparando solo episodios con el mismo número de llamadas a herramientas:

El efecto desaparece. Los episodios con errores no son caros porque fallen; fallan más porque son más largos. El 8,6x era, por tercera vez, el tamaño.

Con los subagentes pasa algo parecido, aunque no idéntico. En los 19 usuarios de TraceLab con datos suficientes, los episodios que lanzan subagentes cuestan una mediana de 4,0x más. A igual longitud, entre 1,0x y 2,2x. Lanzar subagentes es una buena señal de que un episodio va a ser caro, pero no es, por sí sola, una prueba de desperdicio.

Lo que sí encontré

Los mismos datos, mirados sin una hipótesis que defender, dicen cosas bastante más grandes.

El 99,6% del volumen de entrada es contexto que ya habías enviado

cache-read : 1.117.523.688 tokens
output     :     4.216.354 tokens
                   265 : 1

El prompt que escribes es una fracción minúscula de lo que se paga. Optimizar la redacción es optimizar el 0,4% del volumen. En TraceLab, el contexto cacheado es el 59,5% del coste total.

El gasto no se distribuye, se concentra

En mis datos, el 10% de los episodios más caros se lleva el 67% del gasto. La media de un episodio ($7,10) es 5,4 veces la mediana ($1,31).

Y dentro de ese 10%, una sesión concreta:

$574  ·  875 turnos  ·  3.554 llamadas a herramientas  ·  79 subagentes  ·  66 horas

Sesenta y seis horas seguidas. Nada la paró: ni el agente, ni el harness, ni yo.

Esta sí se sostiene fuera de mi máquina. En TraceLab, el 10% de los episodios más caros es el 60% del gasto, y el 10% de las sesiones, el 85%. Por usuario, la mediana es exactamente el 50%, y 18 de 35 desarrolladores están por encima.

Es el mismo patrón que documentó Armin Ronacher en septiembre de 2026, cuando dejó una "fábrica de software" de agentes corriendo sin supervisión, con modelos de OpenAI: 35 horas, unos 1.200 dólares de API, 75.000 líneas de código y 79 commits que juzgó sin ningún valor. (Su post da dos recuentos de tokens distintos para la misma tirada, así que esa cifra la dejo fuera.) Él montó el experimento a propósito. Yo tenía una tirada de 66 horas en el disco sin saberlo.

El coste fijo de cada turno existe, pero no suele ser el problema

Todo lo que el agente carga antes de que escribas nada (prompt de sistema, herramientas, skills, reglas) se vuelve a pagar en cada turno. En mi caso era alto porque tengo muchas skills instaladas que casi nunca uso. Pero en los usuarios de Claude Code de TraceLab la mediana ronda los 18.000 tokens y supone cerca del 9% del gasto. Merece una mirada, no un titular. Si quieres ver el tuyo, Claude Code lo enseña con su propio comando /context, sin instalar nada.

Error 4, de propina: los secretos que no lo eran

Pasé un detector de secretos por mis propios transcripts y me asusté: una docena de credenciales con pinta de reales, filtradas por entropía para descartar ejemplos. Una de ellas, un token de GitHub, aparecía 89 veces, copiado por el agente en comandos, resultados de herramientas y contextos de subagentes.

Antes de rotar nada miré el contexto de cada aparición. Ninguna era real. El token de GitHub era uno falso a propósito, con formato válido, que yo mismo había pedido para probar un escáner de secretos. La clave de AWS era el fixture de un test. Los JWT eran enlaces de verificación de localhost. El resto, ficheros .env de ejemplo y secretos de desarrollo local.

Lo que sí es real es el mecanismo: un valor que entra una vez en la conversación acaba copiado decenas de veces, en texto plano en el disco y enviado al proveedor. Esta vez era un token falso. Y no siempre lo es: cuando repetí el análisis con las reglas completas de gitleaks apareció uno real que mi detector casero no conocía, una clave de API que yo mismo pegué en el chat para que el agente la configurase. Cinco copias. Ya está revocada.

Fuera de mi máquina también hay indicios. GitGuardian publicó este año que los commits co-firmados por Claude Code filtran secretos al 3,2%, frente al 1,5% de media en GitHub, con un matiz que ellos mismos subrayan: la filtración ocurre dentro de un flujo humano, no es solo culpa de la herramienta. Y en un dataset público de transcripts que su autor limpió antes de publicar quedan 34 marcas de secretos redactados.

La lección es la misma que la del resto del post, con otra cara: un detector que no mira el contexto se equivoca con total seguridad. Si pasas un escáner por tus transcripts (gitleaks es el estándar y funciona en local), revisa dónde aparece cada hallazgo antes de alarmarte. Y si alguna vez pegaste una clave real en el chat, dala por expuesta aunque no la encuentres.

Por qué esto importa más allá de mi máquina

Hay varias herramientas vendiendo "62% de reducción de tokens" o "40-70% menos factura". Ninguna publica su diseño experimental.

Yo me equivoqué cuatro veces, con datos que controlaba por completo, con los umbrales fijados de antemano y con el objetivo explícito de no engañarme. Un proveedor que vende ahorro no tiene ese incentivo. Tiene el contrario.

Si alguien te enseña una cifra de ahorro, la pregunta útil no es de cuánto es. Es:

1. ¿Está controlada por tamaño? Si el grupo "con el problema" hace el doble de trabajo que el grupo "sin el problema", la cifra no dice nada.
2. ¿Qué se está contando como entrada del usuario? En los agentes, el propio sistema escribe en el canal del usuario.
3. ¿Hay grupo de control, o solo un antes y un después?
4. ¿Qué cuenta como "tarea completada"? Sin esa definición el ahorro se mide en tokens, y los tokens son fáciles de bajar: basta con que el agente haga menos trabajo del que hacía falta.

Límites de todo esto

Mis datos son de una sola persona: 16 sesiones, 133 episodios. TraceLab añade 43 desarrolladores, pero de un mismo grupo de investigación y con más uso de Codex que de Claude Code.

Mis sesiones no son representativas: hay bastante investigación con navegador, no solo programación.

El coste está calculado a tarifa API pública sobre un uso que fue de suscripción. Sirve como unidad común de esfuerzo; no es una factura que haya pagado. Y una confesión más: mi primera tabla de precios era de una generación anterior de modelos y sobrevaloraba Opus unas tres veces. Las cifras de este post usan la tarifa vigente; los porcentajes apenas cambian, los dólares sí.

Las reglas de detección son expresiones regulares que escribí yo y que nadie ha validado contra anotación humana.

La conclusión que me llevo no es una cifra. Es una costumbre: cada vez que un número de coste me guste, antes de creérmelo, comparar grupos del mismo tamaño.