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.

En las arquitecturas de OpenAI para llamadas de agentes, la salida de la herramienta, el estado y la facturación de la llamada se resuelven en el mismo flujo. Cuando la salida repetida crece, el coste por acción crece antes de que mejore la calidad del resultado.

Por eso, muchos equipos cambian a un modelo más barato y siguen viendo la misma variación de coste. El problema real es la salida por acción, y su efecto en trazas de rechazo y retry.

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 propone justamente ese patrón para resultados de terminal y MCP con instalación de un comando y compatibilidad con toolchains de coding. La promesa es reducir ruido y mantener acceso a la evidencia no mostrada.

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

Vuelve a validar estas fuentes en cada expansión y al menos cada trimestre:

• Visión general de Codag
• Planes y precios de Codag
• Documentación de Codag
• Anthropic Agent tool documentation
• Anthropic advanced tool use guidance
• Investigación sobre composición de prompts y caché