El modelo más económico que todavía hace el trabajo

La mayoría de los equipos elige un modelo potente y caro y le manda todas las peticiones: la opción segura por defecto. Pero en un producto real, la mayoría de las peticiones son rutinarias: buscar un dato, clasificar, un resumen corto. Pagar precios de frontera por trabajo que un modelo más ligero y económico resuelve perfectamente es puro desperdicio, y un benchmark público no puede encontrarlo por usted, porque la respuesta depende por completo de sus tareas y de su definición de “correcto”.

La revisión cambia la pregunta de “¿qué modelo es el mejor?” a “para cada cosa que mi producto realmente hace, ¿cuál es el modelo más económico que todavía la hace bien?”. Ese es un problema de medición, y para medir existe el harness. Para el método de calificación que hay debajo, vea cómo probamos los modelos.

Para cada acción que realiza su sistema, construimos tareas a partir de los datos reales que vería el modelo y de la respuesta correcta que debería producir. Luego cada modelo candidato ejecuta cada tarea muchas veces (repetición, no una sola pasada con suerte) y un modelo potente e independiente califica cada respuesta contra la respuesta correcta conocida. Se registra el costo real en tokens de cada respuesta, así que cada decisión de enrutamiento queda con su precio exacto.

El entregable no es “cámbiese al modelo X”. Es una tabla de enrutamiento por acción: modelos más ligeros y de bajo costo para la mayoría rutinaria, y el modelo premium reservado para las tareas de razonamiento de verdad difíciles que lo necesitan, cada elección respaldada por una tasa de aprobación medida. Cómo se aplica esa tabla en tiempo de ejecución es el tema de el enrutamiento de prompts.

La capacidad más nueva, y la que la mayoría de los equipos no tiene forma de medir, es tratar al propio harness de agentes como un candidato. Cuando el trabajo pasa por el Claude Agent SDK (el mismo motor detrás de los agentes de programación y los asistentes), el costo no son solo los tokens del modelo; es todo el ciclo: contexto repetido, llamadas a herramientas, reintentos. La consola ejecuta ese harness completo contra las mismas tareas que los modelos por API y los pone lado a lado.

Eso responde una pregunta con dinero real detrás: ¿qué trabajo de agentes que se cobra por suscripción puede pasar a un modelo por API de menor costo con la misma calidad? Importa ahora porque el uso del SDK de agentes está pasando de una suscripción de tarifa fija a créditos con cobro por uso, así que el trabajo que parecía “gratis” con la suscripción está por traer una factura por llamada. Saber de antemano qué parte se puede reenrutar sin perder calidad es la diferencia entre una migración tranquila y una factura sorpresa. Seguimos este cambio como tema permanente en Pricing & Billing Watch, incluida la pausa que Anthropic hizo en junio de 2026 justo a este cambio (pausado, no cancelado).

Las comparaciones de costo son fáciles de maquillar, así que la revisión reporta dos bases y le deja alternar entre ellas:

• Equivalente con cobro por uso (limpio). Lo que costaría el trabajo a las tarifas normales de API del modelo resultante: la base comparable para hacer las cuentas de enrutamiento frente a otros modelos por API.
• Consumo real de la suscripción (facturado). El gasto real, incluida la rotación de caché y la sobrecarga del ciclo del harness, que en las pruebas resultó cerca de 2.6× la cifra limpia. Esto es lo que usted paga realmente hoy.

Mostrar ambas es el punto: la cifra limpia mantiene justa la comparación de enrutamiento, y la cifra facturada muestra el costo real de dejar el trabajo en el harness. Para el ahorro principal usamos por defecto la base conservadora, de modo que sea una cifra que usted pueda defender ante un equipo de finanzas, no solo en una diapositiva de marketing.

En concreto, una revisión le entrega cuatro cosas:

• Una tabla de enrutamiento por acción: el modelo aprobado más económico para cada trabajo.
• Una cifra de ahorro defendible: calculada a partir de corridas calificadas sobre tareas reales, con ambas bases de costo a la vista.
• Un veredicto de harness frente a API: qué trabajo de agentes puede pasar a un modelo de menor costo antes de que llegue el cobro por uso.
• Una nueva revisión repetible: vuelva a correrla cuando salga un modelo nuevo o cambien sus tareas, y la tabla se actualiza.

Cada cifra sale de una corrida de benchmark real: modelos × tareas × corridas repetidas, con cada respuesta calificada contra la referencia. Los casos de estudio publican solo métricas agregadas y nombres públicos de modelos; los datos del cliente, las respuestas crudas y el texto interno de las tareas nunca salen de la revisión. Y cuando una tarea es demasiado ambigua para que cualquier modelo la responda de forma confiable, el proceso la marca como un problema de la respuesta de referencia que hay que corregir, no como un modelo al que culpar. El método es el producto; la honestidad es lo que hace que la cifra de ahorro valga algo.