El mito del modelo caro: cuándo merece la pena de verdad el modelo de IA más caro

Existe ese reflejo de coger siempre el modelo más caro, porque caro tiene que ser mejor. Y a veces es verdad. Pero la mayoría de las veces pagas el sobreprecio por una profundidad de razonamiento que tu tarea ni siquiera usa. Pones a reescribir un correo a un modelo que podría pensarse un refactor de arquitectura complicado. Es como comprarte un deportivo para ir a por el pan y luego extrañarte de que la gasolina sea cara.

Este playbook es la guía honesta que me habría gustado tener al principio. No una tabla de marketing, sino una regla práctica por caso de uso que de verdad recuerdes después. Pasamos por coding, textos, agentes y tareas rutinarias, y miramos en cada uno dónde la clase top vale su precio y dónde la clase intermedia da exactamente el mismo resultado por una fracción.

El mito en una frase

La creencia dice: el mejor modelo da siempre el mejor resultado, así que en la duda coge el más caro. Suena lógico, pero es falso. Lo correcto es: el mejor modelo da el mejor resultado en tareas que necesitan profundidad real de razonamiento. En todo lo demás da el mismo resultado que la clase intermedia, solo que pagas más por él.

El error está en la palabra "mejor". Un modelo top no es mejor en general, es mejor pensando. Si tu tarea necesita poco pensar y mucho volumen, entonces "mejor pensando" es una propiedad por la que pagas sin usarla. Justo ahí es donde la mayoría quema dinero.

Las tres clases, sin tabla de precios

En vez de liarte con céntimos concretos que cambian cada mes de todas formas, quédate con las tres clases en relación entre sí. La clase top (en Anthropic se llama Opus, otros proveedores tienen su nivel más caro) cuesta por token un múltiplo de la intermedia. La clase intermedia (Sonnet en Anthropic, niveles comparables en otros sitios) es el daily driver para casi todo. La clase pequeña (Haiku, o el nivel Flash en Google) es bastante más barata todavía, y rápida.

Los factores exactos se mueven constantemente, por eso aquí no doy cifras fijas a propósito. Lo que se mantiene estable es la proporción: top es cara y lenta-minuciosa, intermedia es la todoterreno, pequeña es barata y rápida. Si tienes eso en la cabeza, aciertas el 90 por ciento de las decisiones sin abrir jamás una lista de precios.

La única pregunta que lo decide todo

Antes de elegir modelo, hazte una sola pregunta: ¿una persona con experiencia tendría que pensárselo mucho para esta tarea, o la hace dormida? Si tiene que pensárselo, necesitas profundidad de razonamiento, o sea más bien la clase top. Si la hace dormida, necesitas volumen, o sea la clase intermedia o la pequeña.

Un ejemplo lo hace tangible. "Encuentra el bug en este código async anidado que solo aparece bajo carga" es una tarea de pensar mucho. "Conviérteme estos puntos en un párrafo limpio" es una tarea de hacer dormido. La primera justifica el sobreprecio, la segunda no. Esa pregunta sustituye a ojo la mitad de todas las discusiones sobre modelos que he tenido nunca.

Coding: aquí es donde más compensa la clase top

El coding es el terreno donde la clase top se gana su dinero más a menudo, aunque tampoco siempre. En un refactor grande sobre varios ficheros, en un bug que atraviesa tres capas de abstracción, o en una decisión de arquitectura con muchas dependencias, la clase top gana de forma perceptible. Retiene más en la cabeza, se enreda menos, produce menos errores derivados que luego limpias tú a mano.

Pero, y este es el punto que se le escapa a la facción del deportivo: la mayor parte del coding diario no es tan difícil. Escribir una función, añadir un test, generar un trozo de boilerplate, conectar una API cuya documentación tienes al lado. Eso lo hace igual de bien la clase intermedia. Mi corte práctico: intermedia como opción por defecto en el IDE, y solo cuando noto "está dando vueltas o se le escapa la relación" subo a top para esa tarea concreta. Así pagas el sobreprecio solo por el diez por ciento de tareas que de verdad lo necesitan.

Textos: casi siempre intermedia, rara vez top

Al escribir la proporción se da la vuelta del todo. La inmensa mayoría de los textos, o sea párrafos de blog, descripciones de producto, correos, resúmenes, posts para redes, son tareas de hacer dormido para un modelo bueno. La clase intermedia los escribe limpios, con el tono correcto y sin que notes en el resultado que no hubo un modelo top de por medio. Pagar aquí el sobreprecio es casi siempre dinero tirado.

Hay excepciones, y sinceramente son pocas. Un texto largo que tiene que sostener una línea de argumentación continua a lo largo de muchos párrafos sin contradecirse. Una pieza que tiene que sopesar conocimiento experto de verdad. Ahí la top puede marcar la diferencia. Pero si lo que necesitas ahora es una newsletter, una landing page o diez variantes de un asunto de correo, coge la intermedia y disfruta de la diferencia en la factura a final de mes.

Agentes: la clave es mezclar, no maximizar

Con los agentes la mayoría comete el error más caro de todos: ponen el botón del modelo más caro para el agente entero y luego lo dejan correr cientos de pasos. Un agente que hace veinte llamadas a herramientas para encontrar un fichero, leer una tabla y publicar un estado casi no piensa en la mayoría de esos pasos. Y aun así pagas la tarifa top en cada uno.

El truco es mezclar. La decisión pesada de planificación al principio ("cómo abordo este problema, qué pasos y en qué orden") la puede asumir un modelo top. La ejecución roma de después ("llama a esta herramienta, lee el resultado, pasa al siguiente paso") corre igual de fiable en la clase intermedia o pequeña. Cuando construyas un agente, pregúntate por cada tipo de paso qué clase necesita, en vez de clavar una clase para todo el agente. Esa suele ser la diferencia entre un agente que sale a cuenta y uno que se come tu presupuesto.

Tareas rutinarias: aquí la top es quemar dinero puro

Clasificar, etiquetar, formatear, extraer tres campos de un texto, resúmenes cortos, decisiones sencillas de sí o no. Eso son tareas rutinarias, y son el lugar donde brilla la clase pequeña. Rápida, barata, y para este tipo de tarea igual de certera que cualquier cosa por encima. Soltar un modelo top sobre una tarea de etiquetado es como pagar a un catedrático para que ordene fichas.

La tentación de coger igualmente la clase grande suele venir de la inseguridad ("¿y si alguna vez se complica?"). Mejor monta una pequeña escalada: clase pequeña por defecto, y solo los casos en los que duda o que claramente se salen del molde pasan a la intermedia. En tareas de volumen, donde haces miles de pasadas, esa única elección decide factores en la factura, no porcentajes.

El truco del asesor: la top planifica, la intermedia ejecuta

Hay un patrón que junta las ventajas de los dos mundos, y funciona sorprendentemente a menudo. Dejas que la clase top haga el plan una vez al principio, el trabajo duro de pensar, la estrategia, la arquitectura. Después le pasas ese plan a la clase intermedia, que lo va ejecutando paso a paso. Una llamada cara de pensar, muchas llamadas baratas de ejecutar.

Sale a cuenta porque pensar es escaso y ejecutar es frecuente. Pagas la tarifa top exactamente una vez por la parte que la merece, y no por los veinte pasos romos siguientes. Tenemos un playbook propio para esto (Opus como asesor, Sonnet como ejecutor) que enseña el montaje en detalle. Si tu caso de uso tiene una separación clara entre "pensar bien una vez" y "después ejecutar mucho", ese es casi siempre el camino más económico.

Pruébalo tú en vez de creértelo

Aquí está el mini experimento que acaba con cualquier discusión de fe. Coge diez tareas reales de tu día a día, no inventadas. Haz que cada una la resuelva una vez la clase top y una vez la intermedia. Después pon los resultados uno al lado del otro y pregúntate con honestidad: ¿en cuántas veo de verdad una diferencia que valga algo para mí?

En la mayoría de la gente la respuesta es descorazonadora: en dos o tres de diez. Es decir, que en siete de cada diez tareas llevaban pagando el sobreprecio para nada. Y justo esas dos o tres tareas en las que la diferencia se veía, esas son tus candidatas a top. El resto lo mandas a partir de ahora a la intermedia. Esta prueba lleva un cuarto de hora y a menudo te ahorra dinero durante meses, porque después ya no adivinas, sabes.

La regla práctica que se queda

Si de todo este playbook te quedas con una sola frase, que sea esta: coge la clase intermedia por defecto y sube a top solo cuando la tarea exija pensar de verdad, en profundidad, algo que una persona con experiencia tampoco resolvería dormida. Refactor de código sobre muchos ficheros, bug enrevesado, decisión de arquitectura dura, texto largo con argumentación continua. Esos son los casos top. Todo lo demás lo puede la intermedia, y la rutina la pequeña.

Caro no es mejor, caro es más minucioso. Y la minuciosidad solo es una ventaja cuando la tarea la reclama. En cuanto empiezas a preguntar por tarea en vez de coger la clase grande por sistema, tu factura suele bajar drásticamente sin que la calidad de tus resultados sufra ni un milímetro. No es un truco, es simplemente dejar de pagar por un razonamiento que no usas.

Si quieres profundizar: el playbook "Opus como asesor, Sonnet como ejecutor" enseña el montaje del asesor paso a paso, y "Controles de coste de Claude Code para el daily driver" te ayuda a integrar el salto a top de forma controlada en tu día a día. Si quieres empezar desde el principio del todo, mira en el nivel 1 la lección de comparación de modelos, ahí ponemos el cimiento sobre el que se apoya este playbook.