Un modelo barato puede hacer el 90% del trabajo

Cuando alguien construye su primer agente, recurre al mejor modelo para todo. Por supuesto que lo hace — es la opción segura, da las mejores respuestas, y en una demo el costo es un error de redondeo. Apuntás el modelo más inteligente al problema entero y lo ves funcionar.

Después pasa a producción, el volumen de llamadas sube unos cuantos órdenes de magnitud, y llega la cuenta. Y resulta que "simplemente usá el mejor modelo" no era un default neutral. Era la decisión de pagar precio premium por cada paso trivial — y la mayoría de los pasos son triviales.

La brecha de precios es enorme, y nadie la mira

Acá está el número que debería replantear todo. En 2026, los precios de las API de LLM van desde alrededor de $0.10 por millón de tokens de entrada para modelos pequeños hasta $30 por millón para los modelos frontier de razonamiento — una brecha de aproximadamente 300x para tokens que, en una tarea fácil, producen una salida indistinguible.

CloudZero lo dijo sin rodeos en su versión práctica: usar un modelo frontier para una carga de trabajo que no necesita razonamiento frontier puede costar 16x más sin ninguna mejora significativa en la calidad. Dieciséis veces el precio por la misma respuesta. Nunca aceptarías eso en ningún otro lugar de tu stack, pero con los modelos la mayoría de los equipos ni siquiera revisa — eligen el mejor una vez y enrutan todo a través de él.

La mayor parte de lo que hace un agente no es pensar

La razón por la que esto es tan derrochador es que una tarea de agente no es un gran acto de genialidad. Abrí una real y vas a encontrar un puñado de pasos genuinamente difíciles enterrados en una pila de pasos mecánicos: extraer un campo de este JSON, clasificar este mensaje, reformatear esa lista, decidir qué herramienta llamar, resumir un párrafo, completar una plantilla. La parte difícil — entender el objetivo y planificar el enfoque — puede ser uno de cincuenta pasos.

Correr un modelo de razonamiento de $30 por millón en "sacá el ID del pedido de este texto" es pagar la tarifa por hora de un ingeniero senior para ordenar alfabéticamente un cajón. No está mal porque falle — funciona bien. Está mal porque estás comprando una capacidad que no usás, cincuenta veces por tarea, para siempre.

El patrón: un modelo inteligente planifica, los baratos hacen

La solución tiene un nombre — plan-and-execute (planificar y ejecutar) — y es exactamente lo que suena. Un modelo capaz (caro) mira la solicitud y produce un plan: el razonamiento, la descomposición, la estrategia. Después modelos baratos y rápidos ejecutan cada paso de ese plan, porque una vez que el pensamiento está hecho, los pasos son mecánicos y un modelo pequeño los hace igual de bien.

El artículo de LangChain y otros estiman el ahorro en hasta 90% frente a usar un modelo frontier para todo. Esto no es un truco marginal. Es cercano a cómo opera Klarna: un modelo frontier analiza la intención del cliente y traza los pasos de resolución, y modelos más pequeños hacen el trabajo real — sacar datos de la cuenta, procesar el reembolso, generar la respuesta. Gastá el genio una vez, en la parte que lo necesita; comprá el resto al por mayor.

Y acá viene la parte que sorprende a la gente: la calidad normalmente no baja. En un paso estrecho y bien definido, un modelo pequeño suele ser mejor — más rápido, más predecible, y con menos probabilidad de "ponerse creativo" con una tarea que quería exactamente una cosa aburrida. Ajustar el modelo al trabajo no es un sacrificio. El modelo sobredimensionado nunca estuvo aportando nada en esos pasos en primer lugar.

La regla que lo hace posible: nunca hardcodees el modelo

Hay una trampa, y es arquitectónica. Solo podés enrutar por tarea si tu código no está soldado a un solo modelo. Si gpt-whatever está hardcodeado en medio de tu lógica de negocio, no podés meter un modelo barato para los pasos mecánicos sin cirugía — así que no lo hacés, y seguís pagando de más.

Esta es la misma disciplina a la que sigo volviendo: el modelo es una dependencia, y las dependencias van detrás de un límite, inyectadas, no horneadas adentro. Un nombre de modelo hardcodeado en tu lógica es un olor a código por la misma razón que lo es un precio hardcodeado o una API key hardcodeada — es un detalle intercambiable disfrazado de hecho fijo. Ponelo detrás de una costura limpia y "usá un modelo más barato acá" se vuelve un cambio de config, no una refactorización. (Cambié el proveedor entero detrás de uno de mis productos modificando un solo valor — eso no es suerte, es simplemente no hardcodear lo que siempre iba a cambiar.)

Una vez que el modelo es un parámetro intercambiable, el routing (enrutamiento) sale naturalmente: un clasificador liviano o unas pocas reglas heurísticas deciden la complejidad de cada paso y lo envían al nivel correcto. Solo con el routing — modelo barato para la mayoría simple, modelo frontier para la minoría difícil — se reporta comúnmente que se recorta 60–80% del costo mientras se mantiene la calidad en los casos difíciles.

Por qué el default derrochador gana igual

Si esto es tan obviamente mejor, ¿por qué no lo hace todo el mundo? Por la misma razón por la que la arquitectura barata gana la reunión: el derroche es invisible justo cuando estás decidiendo. En la demo, "el mejor modelo para todo" es lo más simple de construir y cuesta centavos. La cuenta que lo convierte en un error no llega hasta que escalaste — y para ese momento es una línea de cinco o seis cifras pegada a código que hardcodeó el modelo en todas partes, así que arreglarlo ahora es un proyecto. El default vago es barato de elegir y caro de convivir. No ahorraste esfuerzo; postergaste una cuenta y la dejaste acumularse.

También hay un tema de estatus: recurrir al modelo más grande se siente como la opción seria y segura. No lo es. Gastar plata de frontier en un paso de formateo no es rigor — es simplemente no haber mirado. La ingeniería de verdad es saber cuál 10% de tu pipeline necesita el cerebro caro y tener la arquitectura para enviar solo ese 10% allí.

El modelo frontier no es el alarde. Saber dónde no lo necesitás, sí.