Cómo construir un cost receipt por ejecución para detectar cobros anómalos antes de que lleguen a fin de mes

Paso 1 — Define una identidad estable para cada ejecución. Crea un runid antes de abrir un contenedor o llamar un modelo y propágalo a runtime, herramientas y eventos de facturación. Registra versión de habilidad, modelo, región y perfil de recursos. El identificador debe sobrevivir a reintentos lógicos sin hacer que dos efectos distintos parezcan uno. Si un workflow reanuda después de una pausa, enlaza el nuevo tramo con el mismo trabajo y un attemptid separado. Esta estructura permite reconstruir una factura sin depender del nombre de una tarea o de timestamps aproximados.

Paso 2 — Emite eventos de lifecycle desde una fuente operacional. Guarda sessionstarted, asignaciones de CPU o memoria relevantes, tool calls, esperas, cierres y errores. No intentes replicar cada métrica interna del proveedor; conserva señales suficientes para explicar duración y recursos. Usa un reloj consistente y escribe eventos de forma append-only. Si el agente termina de forma inesperada, un reconciliador debe detectar que falta sessionclosed y decidir cuándo cerrar o marcar la sesión. El ledger operacional será tu referencia independiente frente a las unidades que luego aparecen en facturación.

Paso 3 — Normaliza unidades y reglas de precio. Convierte tokens, segundos, GB-hora, llamadas y cargos fijos a una estructura común con proveedor, SKU, cantidad, tarifa, moneda y fecha de vigencia. No incrustes precios dentro del prompt. Versiona la tabla porque las tarifas cambian. Cuando una factura oficial llegue, conserva también el identificador del line item para poder enlazarlo. Si un proveedor aplica créditos o reembolsos, regístralos como ajustes separados en lugar de modificar silenciosamente el costo histórico. El recibo debe explicar el neto sin borrar el bruto original.

Paso 4 — Estima un envelope antes de ejecutar. Para workflows repetibles, calcula un rango basado en percentiles históricos y añade límites por tipo de herramienta. Una ejecución puede recibir softlimit y hardlimit. Al alcanzar el primero, reduce paralelismo o eleva una alerta; el segundo activa un checkpoint seguro. Diseña qué significa pausar: guardar estado, cerrar contenedor y no repetir acciones externas cuando se reanude. Un presupuesto no sirve si detener el run obliga a empezar desde cero y duplicar envíos, compras o modificaciones que ya ocurrieron.

Paso 5 — Reconciliación y anomalías. Al cerrar, compara el ledger operacional con la medición facturable. Define tolerancias por proveedor y alerta cuando duración, memoria, llamadas o total se separen del patrón. También compara costo por outcome: éxito, error recuperable, abandono o resultado rechazado. Un run que cuesta poco pero falla no es eficiente. Guarda una explicación automática de la desviación basada en hechos: más herramientas, sesión más larga, modelo distinto o diferencia no reconciliada. Esa última categoría debe escalarse; no inventes una causa para hacer cuadrar el reporte.

Paso 6 — Expón el receipt a personas distintas. Ingeniería necesita detalle por fase; finanzas necesita total y reconciliación; un cliente puede necesitar solo costo, rango esperado y estado. Mantén una fuente estructurada y genera vistas según rol. En Goatify, este receipt puede acompañar habilidades críticas y alimentar límites de plan, optimización y soporte. La promesa no es que todas las ejecuciones costarán lo mismo. Es que cada variación puede atribuirse, y que una anomalía se detecta cerca del run que la produjo en lugar de aparecer semanas después como una cifra inexplicable. Esa evidencia también permite negociar presupuestos y planes con datos propios, sin depender de promedios que mezclan workloads muy diferentes.