Claude Code gasta 16% de tu gasto en una línea de estado

Cada 30 segundos, por cada agente en segundo plano

Claude Code envía el transcript completo de cada agente en segundo plano a su propio modelo —normalmente Opus— y le pide que describa su acción más reciente en 3 a 5 palabras. La respuesta nunca llega al modelo ni a tu conversación: solo actualiza la línea de estado del agente en el panel de agentes.

Según la medición del equipo de Flamerix AI, publicada en un gist con licencia MIT, esa rutina representó el 16,4% de todo el gasto de Claude Code en la semana previa a desactivarla, por encima del 15,7% que consumió la conversación principal. También fue el 19,7% de todas las peticiones a la API —cerca de una de cada cinco— y el 96% de ese gasto corrió sobre Opus. La relación de tokens de entrada por cada token de salida era de aproximadamente 9.000 a 1.

No existe ningún ajuste que lo apague. Desde la versión 2.1.232 (agosto de 2026) viene activado por defecto para agentes interactivos en segundo plano, y el intervalo lo fija un flag del servidor, no tu configuración.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Cómo se detectó: la telemetría que casi nadie mira

El hallazgo salió del export de OpenTelemetry de Claude Code. Al agrupar los eventos claude_code.api_request por query_source, apareció una categoría llamada agent_summary que costaba más que la conversación principal completa.

Ese detalle importa para cualquier equipo: las herramientas de costos que leen transcripts en disco no ven estas peticiones, porque no se escriben en los logs de sesión. Solo el export de OpenTelemetry las muestra. Flamerix AI señala además que el issue #86879 del repositorio recoge cuatro mediciones independientes que ubican el fenómeno entre el 18% y el 26%.

La tendencia venía creciendo. En su telemetría, la cuota semanal de gasto pasó de 3,5–7% en julio a 7,3% y luego 11,8% en la semana en que adoptaron la 2.1.233, hasta llegar a cerca del 16% a mediados de octubre.

Por qué el interruptor oficial no sirve

La opción documentada agentProgressSummaries del SDK viene en false, pero en el bundle es un término de una operación OR y todos los caminos de código que la escriben la ponen en true. La variable no documentada CLAUDE_CODE_AGENT_PROGRESS_SUMMARIES solo puede encender los resúmenes, nunca apagarlos.

El intervalo tampoco ayuda: viene de un flag del servidor por familia de modelo y está limitado a un rango de 30 a 240 segundos. El valor por defecto ya es el mínimo, y ningún valor desactiva el temporizador.

Otras dos salidas conocidas tienen costo oculto:

DISABLE_NON_ESSENTIAL_MODEL_CALLS, que algunos empaquetadores configuran, no aparece en el binario.
CLAUDE_CODE_FORK_SUBAGENT=0 y CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 sí lo detienen, pero se llevan por delante los subagentes fork o los agentes en segundo plano.

El caché de prompt abarata la operación, pero no la vuelve barata: cerca del 98% de estas llamadas relee el transcript desde caché, y el 2% que golpea caché frío carga más de un tercio de su costo total. La versión 2.1.310 ya incluye un modo corto —unos 2.000 tokens de notas en lugar del transcript completo— pero viene desactivado y solo los flags del servidor pueden cambiarlo.

Cómo funciona el hook de 80 líneas

no-agent-summary.js es un preload de Bun de aproximadamente 80 líneas. Intercepta setTimeout y setInterval: cuando el texto fuente de un callback contiene un ancla del resumidor (por ejemplo, la línea de log [AgentSummary] Timer fired), devuelve un handle inerte en lugar de armar el temporizador. Todos los demás temporizadores pasan intactos.

¿Por qué un hook de temporizadores y no algo más simple? Porque el módulo se distribuye como bytecode precompilado de Bun, así que editar su texto JS dentro del binario no cambia nada, y el cliente de API no pasa por un globalThis.fetch interceptable. Pero Function.prototype.toString sigue devolviendo el código fuente de un callback aunque corra desde bytecode, así que el temporizador se reconoce por una cadena dentro de él. El temporizador inerte usa exactamente 2³¹−1 ms, porque Node y Bun interpretan un delay mayor como 1 ms y un delay "infinito" se dispararía de inmediato.

La instalación es corta: se coloca el archivo en una ruta estable, se exporta BUN_OPTIONS con el flag --preload en el perfil de shell, se ejecuta claude daemon stop --any y se reinician las sesiones abiertas. El daemon, el host de pty y las sesiones precalentadas heredan el entorno del cliente que inició el daemon, así que un daemon arrancado antes de configurar la variable sigue lanzando sesiones sin el hook.

Tres variables controlan el comportamiento: CC_AGENT_SUMMARY_MODE (off por defecto, pass como control A/B que carga el hook pero arma todos los temporizadores), CC_AGENT_SUMMARY_LOG para registrar coincidencias y CC_AGENT_SUMMARY_MARKER para dejar constancia de que el preload está activo.

Qué cambia y qué no cuando lo instalas

Los subagentes, agentes en segundo plano, skills forkeadas y sesiones en background siguen funcionando normal. Solo se omite el fork de resumen.
El cambio visible es que el estado por agente en el panel deja de actualizarse, y task_progress del SDK se queda sin resumen.
El overhead es bajo: un Function.prototype.toString por cada callback distinto, guardado en un WeakMap. La medición del autor pasó de unos 10 ms a 17 ms en claude --version.
El binario no se modifica. Una actualización puede deshacerlo en silencio, por eso hay que volver a verificar después de cada update.
La coincidencia es por texto fuente: si Anthropic renombra la línea de log, mueve las cadenas a una constante compartida o cambia a timers/promises, el hook no coincide con nada y los resúmenes vuelven sin avisar.
Probado en Linux con Claude Code 2.1.257 a 2.1.312. macOS y Windows no están probados, y en Windows el gate /$bunfs/ probablemente nunca instala el hook.

La única verificación que atrapa todos los modos de falla es la telemetría: con OpenTelemetry exportando, query_source = agent_summary debe quedarse en cero. El propio autor aclara que modificar el comportamiento en runtime de un cliente puede entrar en conflicto con los términos del servicio que usas, y que revisar eso corre por tu cuenta.

Qué significa esto para tu startup

El caso es una lección sobre economía de agentes, no solo sobre un parche. Anthropic publicó el 27 de octubre de 2026 una guía de control de costos para Claude Code en Google Cloud, según blockchain.news, con tres palancas: controlar, medir y demostrar ROI. La compañía recomienda presupuestos por proyecto, topes de gasto por usuario o grupo, y exportar métricas de OpenTelemetry desglosadas por skill, plugin, agente y servidor MCP.

El contexto ayuda a dimensionar por qué importa. Desde el 15 de junio de 2026, las cargas automatizadas —Agent SDK, claude -p, GitHub Actions— se facturan contra un pool de crédito mensual separado de US$20 en Pro, US$100 en Max 5x y US$200 en Max 20x, según TechTimes. Ese mismo medio reportó una demanda colectiva en la que un suscriptor alega que Max 20x entrega entre 6 y 8 veces el uso de Pro, no veinte.

Y el gasto por tarea no es un detalle menor. TechRepublic comparó Claude Code con Sonnet 5.5 frente a Codex con GPT-6.1 Sol: US$14,19 por tarea contra US$1,04, y 27,7 millones de tokens por tarea contra 3,2 millones. Del lado de los loops autónomos, TechTimes recogió que Uber habría consumido su presupuesto anual de IA para Claude Code en cuatro meses, con costos por ingeniero de US$500 a US$2.000 mensuales, y que la división Experiences and Devices de Microsoft terminó la mayoría de sus licencias en junio de 2026.

Tres acciones concretas para esta semana:

Activa el export de OpenTelemetry antes de optimizar nada. Si no puedes agrupar tus eventos por query_source, no vas a ver este gasto ni ningún otro gasto lateral. Es la única medición que detecta el problema.
Revisa tu overhead de arranque con /context. Un análisis de iTechify sobre tokens de inicio recoge la medición de un redactor de How-To Geek que encontró unos 84.600 tokens de overhead antes de escribir la primera palabra, y el caso de un desarrollador que documentó 66.000 tokens en definiciones de herramientas MCP. Ese costo se reenvía en cada turno.
Si corres agentes en segundo plano en CI o headless, evalúa el hook con criterio. Antes de instalarlo, confirma que tu caso de uso no depende del estado por agente en el panel, que estás en Linux y que tu equipo acepta el riesgo de que una actualización lo rompa sin aviso.

Conclusión

El resumen de agentes es un buen ejemplo de una categoría de gasto que casi ningún equipo mide: trabajo auxiliar que no produce output para el usuario pero que consume tokens al mismo ritmo que el trabajo real. La respuesta correcta no es solo parchear el cliente, sino instrumentar la telemetría para que la próxima vez que aparezca una categoría desconocida en tu factura, la veas antes de que llegue al 16%.