# Un modelo barato puede hacer el 90% del trabajo

El movimiento por defecto es apuntar el modelo más grande e inteligente a todo. Funciona en la demo y, en silencio, te lleva a la quiebra a escala — porque la mayor parte de lo que hace un agente no es razonar, es mecánico, y estás pagando sueldo de genio por leer un formulario. La solución es aburrida y vale ~90%: deja que un modelo inteligente planifique, y que los modelos baratos hagan. Acá está la economía, y la única regla arquitectónica que lo hace posible.

- **Author:** Fedor Chishchin
- **Published:** 2026-06-03
- **Tags:** agents, architecture, business
- **Source:** https://fedorthinks.com/es/blog/cheap-model-most-of-the-work

---

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](https://www.cloudzero.com/blog/llm-api-pricing-comparison/)
— 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](https://www.cloudzero.com/blog/llm-api-pricing-comparison/).
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](https://www.langchain.com/blog/planning-agents) y
otros estiman el ahorro en
[**hasta 90%** frente a usar un modelo frontier para todo](https://www.philschmid.de/agentic-pattern).
Esto no es un truco marginal. Es cercano a
[cómo opera Klarna](https://www.mindstudio.ai/blog/ai-agent-token-cost-optimization-multi-model-routing):
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](/blog/cheap-code-is-expensive): 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](https://www.mindstudio.ai/blog/ai-agent-token-cost-optimization-multi-model-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](/blog/cheap-code-is-expensive): 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í.