El costo por tarea completada empieza a importar más que el precio nominal por token

El precio por millón de tokens cuenta una historia incompleta. Para un chatbot breve, la tarifa de entrada y salida puede aproximar bastante bien el costo. En un agente que trabaja durante minutos u horas, la ecuación cambia. El sistema puede releer contexto, llamar herramientas, inspeccionar resultados, corregirse y volver a ejecutar pasos. Anthropic pone el tema sobre la mesa al vincular parte de la reducción estimada de costo de Fable 5.1 con el precio de cache reads y señalar ahorros mayores en cargas altamente agentic. Eso obliga a evaluar el workflow entero, no una llamada aislada al modelo.

La unidad correcta es el trabajo aceptado. Si un modelo barato requiere tres intentos para producir una salida usable y otro más caro la logra en uno, comparar solo tokens puede llevar a la decisión equivocada. La métrica útil es costo por tarea terminada y aceptada bajo un estándar de calidad. Para calcularla se suman inferencia, herramientas externas, búsquedas, ejecución de navegador, almacenamiento y cualquier reintento automático. Después se divide por trabajos que realmente pasan validación. Esa cifra puede parecer menos elegante que una tabla de precios, pero se conecta directamente con margen y capacidad operativa.

El tiempo también es un costo. Un agente puede usar pocos tokens y aun así bloquear un proceso durante demasiado tiempo. Por eso conviene medir costo financiero y latencia de extremo a extremo. En tareas comerciales, un run de veinte minutos quizá sea irrelevante si reemplaza horas de trabajo; en atención al cliente, veinte minutos puede destruir la experiencia. El mismo modelo puede ser correcto para un agente de investigación y malo para una respuesta conversacional. Evaluar por tarea obliga a incorporar el SLA real del producto y evita declarar un ganador universal donde solo existen combinaciones adecuadas para cada caso.

La verificación debe entrar en la cuenta. Muchos benchmarks premian obtener una respuesta correcta, pero un sistema de producción necesita demostrar que la acción ocurrió. Publicar un archivo y descargarlo para verificarlo consume pasos; revisar una fuente antes de escribir también. Esos costos no son desperdicio, son parte de comprar confiabilidad. Si una estrategia reduce el gasto eliminando controles y después produce duplicados o acciones incorrectas, el ahorro es falso. El costo por tarea aceptada incluye la evidencia necesaria para poder cerrar el run. Esa es una diferencia clave entre un demo agentic y una operación que puede facturarse.

Las pruebas tienen que parecerse al negocio. Para comparar modelos en Goatify, deberíamos construir suites de tareas representativas: investigar cinco fuentes y redactar, actualizar un recurso fijo, programar una publicación, clasificar leads o construir una pieza. Cada prueba registra costo, duración, cantidad de tool calls, reintentos, intervenciones humanas y resultado final. Luego podemos comparar modelos y niveles de esfuerzo sobre el mismo contrato. Así se evita adoptar una novedad por hype y se crea una base de datos propia sobre qué combinación funciona mejor para nuestros clientes y nuestros márgenes.

La consecuencia comercial es potente. Una vez que sabemos el costo real por trabajo, podemos empaquetar servicios con mucha más claridad. Podemos decidir qué tareas se incluyen en un plan, cuáles necesitan límites y dónde conviene usar un modelo premium. También podemos explicar por qué una automatización vale más que “X tokens”: el cliente compra un resultado validado. La economía agentic madura cuando costo, calidad y confiabilidad se miden juntos. El proveedor de modelo seguirá publicando precios, pero la ventaja de Goatify estará en saber cuánto cuesta convertir esos modelos en trabajo terminado que alguien realmente quiera pagar.