Cómo controlar costes de agentes de código con compresión de salida

Los agentes de código suelen encarecerse cuando empiezas a escalar porque sus bucles de herramientas devuelven más salida de la necesaria. Un intento típico ejecuta comandos, lee logs largos, reintenta por un error pequeño y vuelve a enviar contexto al siguiente paso.

Esto coincide con el modelo de estado conversacional de OpenAI para llamadas de varios turnos en la Responses API. Las entradas y salidas anteriores pueden seguir formando parte de turnos posteriores, mientras el uso informa los tokens de entrada y salida. Por eso, los resultados repetidos de herramientas pueden ampliar la entrada si la aplicación no gestiona el contexto de forma deliberada.

Por eso, los equipos pueden seguir viendo la misma variación de coste aunque mantengan fijo el modelo. El problema no tiene por qué ser un solo proveedor; puede ser la salida por acción y su efecto en las trazas de fallo y reintento.

Por qué se paga por contexto repetido

Un bucle de agente es caro cuando el contexto útil es pequeño y el ruido de salida es grande. Cuatro zonas recurrentes:

• Salida de comandos. build, lint y pruebas suelen producir miles de líneas para pocos hallazgos accionables.
• Metadatos repetidos. firmas de herramientas y esquemas que se repiten en cada petición.
• Reintentos. los mismos campos de contexto vuelven con el mismo objetivo.
• Escalado humano. la misma evidencia regresa al modelo para revisión y luego de nuevo al historial.

Qué debe hacer la compresión y qué no

La compresión no sustituye al modelo. Es un control de trazas. Debe mantener:

• Líneas relevantes en primer nivel para decidir rápido.
• Registros ocultos recuperables para auditoría.
• Reglas de recuperación deterministas para no perder evidencia.

Codag aplica ese patrón al reducir resultados grandes y aptos de herramientas antes de que el agente los lea. Su documentación actual describe una configuración de un solo comando que conecta automáticamente Claude Code y Codex; sus planes enumeran por separado el acceso por CLI, API y MCP. Según Codag, los bytes omitidos permanecen cifrados en la máquina local y se pueden recuperar bajo demanda, de modo que la evidencia de depuración sigue disponible.

Cuándo arrancar un piloto

Empieza si esto suena familiar:

• La salida de herramientas crece con cada reintento.
• El gasto sube tras introducir más agentes.
• La variación diaria de costes sube sin más tráfico de usuarios.
• La mayoría de costes vienen de loops de fallo y revisión, no de nuevas funciones.

No lo uses como primera medida si tus problemas están en governance o calidad de datos. Allí necesitas mejores reglas antes de optimizar salida.

Plan de piloto de 14 días

Mide contra una línea base y con pares. No uses opinión.

1. Selecciona un flujo estable como ticket triage, extracción o verificación de PR.
2. Registra intentos, acciones aceptadas, tasa de reintento y tokens por acción aceptada.
3. Compara la misma secuencia con y sin compresión.
4. Compara coste de modelo, tasa de fallback y tiempo de corrección humana.
5. Define umbrales de calidad y recuperación antes de escalar.

El objetivo no es bajar tokens desde el día uno, es mejorar de forma estable el coste por acción aceptada.

Impacto de negocio

Si tienes varios proveedores, la compresión mejora la utilización y puede ser una decisión de procuración temprana antes de cambiar contratos o pricing.

Combínalo con AI Agent Cost per Action para establecer un KPI principal. Para otras palancas, usa reduce LLM token costs y la calculadora de costos de LLM.

Si tu ejecución es interna y la compliance es crítica, nuestra servicio de AI enablement puede endurecer trazas, esquemas de recuperación y flujo de revisión humana antes de entrar en producción.

Preguntas de implementación

• Primero ordeno la acción o primero comprimo la salida?
• ¿Qué líneas son obligatorias para auditoría y cuáles puedo eliminar?
• ¿Cuál es el criterio de rollback si cae la calidad?

Regla: avanzar con compresión cuando caen la varianza de coste y los controles de calidad se mantienen bajo el mismo nivel de revisión humana.

Fuentes y nota de verificación

Estas fuentes primarias se volvieron a comprobar el 2 de septiembre de 2026. Valídalas de nuevo antes del despliegue y al menos cada trimestre:

• Visión general de Codag
• Planes y precios de Codag
• Documentación de Codag
• Documentación de Anthropic sobre herramientas y consumo de tokens
• Guía de Anthropic para gestionar costes en Claude Code
• Investigación sobre composición de prompts y caché