El coste invisible de los sistemas agénticos
Lo que el usuario ve como una acción puede ser una cadena de inferencias. La unidad contable debe seguir la ejecución real, no la forma de la interfaz.
El consumo en la sombra
Un run puede incluir llamadas que no producen una burbuja visible:
- modelo de razonamiento del agente raíz;
- workers delegados;
- moderación o routing;
- evaluadores y críticos;
- consolidación de memoria;
- embeddings y recuperación;
- generación o comprensión multimodal;
- resumen de sesión;
- supervisión de esperas;
- preparación y validación de un agente nuevo.
Cobrar una cantidad fija por run o contar únicamente tokens de la respuesta principal simplifica la interfaz, pero impide conocer el coste de producción. También crea incentivos perversos: mover trabajo a una llamada «interna» lo vuelve invisible sin hacerlo gratuito.
Una unidad interna estable
El coste de proveedor puede almacenarse en una unidad entera pequeña —por ejemplo, micro-unidades monetarias— para evitar errores de coma flotante. La unidad comercial que ve el cliente puede seguir siendo un crédito, una cuota o una métrica de uso.
Separar ambas capas permite:
- recalcular márgenes sin reescribir el historial técnico;
- cambiar la presentación comercial;
- comparar proveedores y modelos;
- conciliar eventos con facturas;
- conservar el coste aunque un uso esté patrocinado y no se cobre.
El coste interno no es el precio al cliente. Incluye la rate card del proveedor y puede ampliarse con otros costes atribuibles; el precio añade política comercial, riesgo y margen.
Medir las categorías nativas
Los proveedores distinguen categorías diferentes. Como mínimo, el evento debe poder representar:
- tokens de entrada sin caché;
- lectura y escritura de caché;
- almacenamiento de caché cuando corresponda;
- tokens de salida;
- tokens o unidades de razonamiento facturables;
- imagen, audio, vídeo u otras modalidades;
- embeddings y búsquedas;
- unidades no textuales definidas por el proveedor.
No existe un multiplicador universal de caché. Las tarifas y categorías cambian entre proveedores, modelos y fechas. Estimar tokens a partir de caracteres puede servir para un preflight, pero no reemplaza el uso reportado por el proveedor al liquidar.
Cada llamada debe generar un evento lógico
El invariante del modelo objetivo es que toda operación facturable produzca un evento de uso con:
- identidad idempotente;
- tenant, usuario raíz y agente ejecutor;
- run, llamada y cadena de delegación;
- consumidor interno que originó la llamada;
- proveedor y modelo efectivo;
- cantidades por categoría;
- versión de la rate card;
- clase de cargo;
- timestamps y resultado.
La entrega puede ser al menos una vez. La idempotencia convierte reintentos del mismo evento en una única entrada lógica. «Exactamente una vez» no se presume sobre toda la red.
Tres clases de cargo
Medir todo no obliga a cobrar todo del mismo modo. Conviene clasificar:
| Clase | Significado |
|---|---|
| Facturable | Trabajo directamente asociado a una capacidad consumida por el cliente. |
| Overhead | Trabajo interno necesario para prestar o proteger el servicio, atribuible para análisis. |
| Sistema | Actividad patrocinada por la plataforma o necesaria para su operación general. |
Extracto. La ausencia de cobro no debe producir ausencia de medida. Un coste patrocinado sigue siendo coste y necesita propietario.
La clase forma parte de la política. El evento técnico conserva qué ocurrió; una regla versionada decide cómo se presenta o se carga.
Atribución no es cobro
Cuando un agente personal delega en uno compartido, existen varias identidades:
- la persona que originó la tarea;
- el agente que inició la delegación;
- el agente que ejecutó la llamada;
- la organización que gobierna la capacidad;
- la bolsa o centro de coste que finalmente paga.
La atribución conserva siempre esa cadena. El cobro puede recaer en usuario, organización o plataforma según una política explícita. Mezclar ambas decisiones borra la señal necesaria para revisar la política.
El marco FinOps diferencia igualmente la asignación de costes —visibilidad y responsabilidad— de mecanismos formales de showback o chargeback. La plataforma puede mostrar quién causó un coste sin descontarlo de su cuota individual.
Ledger append-only y correcciones
El ledger debe añadir eventos, no editar consumos históricos. Una corrección se representa mediante un asiento compensatorio que referencia al original.
Esta propiedad permite auditar:
- qué se registró inicialmente;
- qué regla se aplicó;
- por qué se corrigió;
- qué saldo resultó.
Append-only no significa inmutable ante el error; significa que el error y su corrección permanecen visibles.
Autorizar antes, liquidar después
Una operación larga no conoce necesariamente su coste final. Puede aplicar un patrón de reserva y liquidación:
- estimar un techo razonable;
- autorizar o retener capacidad antes de empezar;
- ejecutar con límites;
- liquidar el consumo real;
- liberar la diferencia o registrar el exceso permitido.
Es una analogía con autorización y captura de pagos, no un estándar específico para agentes. Requiere semántica propia para TTL, reservas concurrentes, cancelación, fallos parciales y liquidación idempotente.
El modelo más barato que siga siendo elegible
El coste también se controla antes de medir. Las tareas internas deberían usar el modelo de menor coste que cumpla:
- capacidad y modalidad;
- contexto y herramientas;
- calidad evaluada;
- residencia y seguridad;
- política del tenant;
- latencia y disponibilidad requeridas.
FrugalGPT y RouteLLM muestran que cascadas y routers pueden equilibrar coste y calidad en benchmarks concretos. Sus resultados no se trasladan automáticamente a una carga empresarial; la plataforma necesita sus propias evaluaciones y debe registrar la razón de routing.
Rate cards como snapshots
Los precios no son conocimiento permanente. Cada rate card necesita:
- proveedor y modelo o deployment;
- versión y fecha de observación;
- intervalo de vigencia;
- moneda y unidad;
- región o tier cuando afecten;
- categorías de entrada, salida y caché;
- fuente oficial.
FOCUS ofrece un vocabulario abierto para normalizar costes y uso y refuerza la necesidad de conciliación y procedencia. No define cómo debe facturarse un agente, pero ayuda a evitar un modelo aislado de los sistemas FinOps de la organización.
Estado y límites
ALLAN dispone de ledger, atribución por delegación e integración de metering, pero el rediseño completo hacia coste nativo por categoría y clases de cargo es una propuesta en transición. El documento económico de partida no está versionado en la revisión base y no se utiliza como prueba de disponibilidad.
Esta edición excluye precios, márgenes, planes y defectos operativos concretos. No existe una fórmula universal para repartir overhead ni una reserva óptima para toda carga. Esas políticas deben basarse en datos observados y quedar versionadas.
Referencias
Fuentes editoriales de ALLAN
Platform Server/docs/metering-and-subscriptions-design.md.docs/economic-model-redesign.md, borrador interno no versionado utilizado solo como propuesta de evolución.docs/model-provider-management-design.md, para resolución y modelo efectivo.
Fuentes externas
- FinOps Foundation, Allocation y Unit Economics, marco operativo, consultado en 2026.
- FinOps Open Cost and Usage Specification, FOCUS 1.4, especificación abierta ratificada en 2026.
- Stripe, Meter events y separate authorization and capture, documentación oficial; el segundo se utiliza solo como analogía.
- OpenTelemetry, Generative AI semantic conventions, especificación en evolución.
- Ong, I. et al., RouteLLM, ICLR 2025.
- Chen, L. et al., FrugalGPT, preprint, 2023.
- OpenAI, What are tokens and how to count them?, documentación oficial, consultada en 2026.
- Anthropic, Pricing, y Google, Gemini API billing, páginas oficiales consultadas en 2026 para verificar la diversidad de categorías, no para fijar precios en esta publicación.