Claude Code envía regularmente la transcripción de cada agente en segundo plano a su modelo

Artículo original ↗ Discusión en Hacker News ↗

Los resúmenes de estado integrados de Claude Code para agentes en segundo plano están consumiendo una proporción sorprendente de los tokens pagados por los usuarios, con algunos informes que muestran que entre 8% y 16% del uso total se va en llamadas periódicas “agent_summary” que actualizan una pequeña etiqueta de estado. Aunque el personal de Anthropic dice que la telemetría muestra un impacto medio menor y señala correcciones recientes además de planes para modos de resumen más baratos, muchos usuarios critican la falta de un interruptor claro, ven un conflicto de interés cuando los proveedores del modelo controlan tanto el harness como la facturación, y experimentan con hacks, clientes alternativos o binarios antiguos para reducir el desperdicio. El episodio alimenta una frustración más amplia con el bloat creciente de Claude Code, los límites opacos y las peculiaridades de privacidad, y provoca comparaciones con harnesses de terceros más ligeros y herramientas rivales.

Resúmenes de agentes en segundo plano y consumo de tokens

  • Problema central: Claude Code envía la transcripción completa de cada agente en segundo plano activo al modelo aproximadamente cada 30 segundos para generar resúmenes breves de estado.
  • Un usuario intensivo midió ~16% del gasto semanal equivalente en tokens debido a estas llamadas; otros informan rangos de ~3–8% hasta 15%+ según el flujo de trabajo y el uso de subagentes.
  • El impacto es peor para agentes de contexto largo (por ejemplo, cientos de miles de tokens) y muchos subagentes concurrentes.

Alcance, caché y mecánica

  • Los resúmenes solo se aplican a agentes en segundo plano que trabajan activamente, no a los inactivos. El uso normal de una sola sesión se ve menos afectado.
  • Algunos evaluadores dicen que los flujos de trabajo (“ultracode”) no se ven afectados, solo los subagentes.
  • Los prompts se sirven en gran medida desde la caché de prompts del proveedor, por lo que la mayoría son “lecturas baratas”, pero las lecturas grandes repetidas siguen acumulando coste.
  • TTL de caché: sesiones principales ~1 hora; subagentes por defecto ~5 minutos salvo que se amplíe mediante una escritura premium en caché. Esto hace que el comportamiento de la caché y el coste sean algo complejos y dependientes del momento.
  • Los usuarios señalan que una compactación automática agresiva cerca del vencimiento de la caché reduce costes, pero puede perjudicar la continuidad o “parecer una lobotomía” para algunas cargas de trabajo.

Respuesta del proveedor y correcciones previstas

  • Un ingeniero de Claude Code informa de telemetría que muestra resúmenes de aproximadamente:
    • ~2% del coste total (precios de lista de la API),
    • algo menos del 4% de las solicitudes,
    • ~6% del coste en la terminal, donde ocurren la mayoría de esas llamadas.
  • Reconocen que es “mucho para una línea de estado”, afirman haber lanzado una corrección para los fallos de caché (versión 2.1.311+) y están trabajando en un modo más barato que use notas breves para un modelo más pequeño.
  • Actualmente no hay un ajuste oficial para desactivar por completo los resúmenes sin desactivar también los agentes en segundo plano/forks.

Soluciones provisionales de usuarios y herramientas

  • Un script preload de Bun parchea setTimeout para interceptar y suprimir el temporizador de resumen sin modificar el binario; pruebas controladas muestran que reduce las llamadas de resumen a cero mientras los agentes siguen ejecutándose. Se han compartido runners de Windows y herramientas similares.
  • Algunos usuarios se quedan en versiones anteriores del CLI de Claude Code y desactivan las actualizaciones automáticas, alegando que las versiones más nuevas consumen más tokens mediante funciones en segundo plano.
  • Otros recurren a orquestadores externos/modelos de decisión (“decision models”) —por ejemplo, harnesses basados en Pi, omp.sh, puentes personalizados— para elegir modelos más baratos y evitar el comportamiento de Claude Code.

Incentivos, confianza y controversia

  • Muchos ven esto como un consumo de tokens innecesario y poco transparente que debería poder activarse o desactivarse por el usuario o ser gratis, especialmente para clientes empresariales o con precios de API.
  • Las opiniones divergen sobre la intención:
    • Algunos lo llaman explotador o incluso “fraude”, argumentando que los proveedores del modelo que también poseen el harness tienen un incentivo integrado para desperdiciar tokens.
    • Otros creen que es mala ingeniería/diseño de producto: funciones construidas en un entorno interno, insensible al coste, y luego lanzadas sin controles de coste adecuados.
    • Unos pocos sostienen que la competencia y la pérdida de usuarios limitan cuánto despilfarro deliberado sería racional.
  • Surge una frustración más amplia por la percepción de bloat de Claude Code, los cambios frecuentes de comportamiento, las cuotas opacas y un patrón de funciones intensivas en tokens.

Comparaciones con otros harnesses y modelos

  • Varios comentaristas prefieren harnesses más ligeros u OSS (Pi, omp.sh, Codex, Muse Code, Copilot), alegando:
    • Mejor eficiencia de tokens,
    • Comportamiento más predecible,
    • Valores predeterminados menos “tipo spyware” o intrusivos.
  • Otros dicen que Opus + Claude Code sigue ofreciendo una productividad excepcional para ellos incluso con un uso alto de tokens; las experiencias varían mucho según el tamaño del proyecto, el lenguaje y los flujos de trabajo.

Preocupaciones de privacidad y seguridad

  • Un problema aparte pero relacionado: Claude Code incluye el correo electrónico del usuario en prompts del sistema y a veces en encabezados HTTP (User-Agent) cuando los sitios solicitan información de contacto (por ejemplo, SEC, Wikipedia, Crossref).
  • Algunos usuarios lo eliminan mediante plugins; otros argumentan que el agente siempre debería pedir consentimiento antes de transmitir identificadores personales.
  • Hay preocupación por escenarios de prompt injection en los que sitios de terceros podrían exfiltrar PII o activar llamadas sensibles a herramientas sin aprobación explícita del usuario; otros ven las filtraciones actuales (por ejemplo, el correo en UA) como menores, pero coinciden en que hacen falta mejores mecanismos.