Opus o Sonnet: qué modelo elegir en Claude Code según la tarea

El caro no siempre gana. Esa es la frase entera y podría dejar el post aquí.

Como no vas a fiarte de una frase, vamos a ver cuándo compensa cada uno, con criterios que puedas aplicar sin tener que entender nada técnico.

Lo primero que hay que asumir: en Claude Code tienes un presupuesto. No es dinero, es consumo. Y elegir siempre el modelo más potente es la forma más rápida de quedarte sin él un miércoles.

¿Qué modelo uso para cada tarea en Claude Code?

La regla que uso yo, resumida:

Opus para pensar. Sonnet para ejecutar.

Cuando el problema es "no sé cómo hacer esto" o "esto está roto y no sé por qué", ahí quieres el modelo más capaz. Está razonando, no escribiendo.

Cuando el problema es "haz esto que ya está decidido", Sonnet lo hace igual de bien, más rápido y consumiendo bastante menos. Traducir un texto, aplicar un cambio en quince archivos, crear una estructura que ya has definido. Nada de eso requiere el modelo grande.

La tabla

| Modelo | Para qué | Coste relativo | Límite que duele | Veredicto | |---|---|---|---|---| | Opus | Diseñar, depurar problemas raros, decidir la arquitectura, tareas largas con muchos pasos | el más caro en consumo, con diferencia | te funde el presupuesto semanal si lo usas para todo | Guárdalo para cuando de verdad haya que pensar | | Sonnet | Ejecutar lo decidido, cambios repetitivos, escribir texto, tareas acotadas | mucho más barato y bastante más rápido | se pierde antes en problemas enrevesados con muchas piezas | El caballo de batalla del día a día |

Las capacidades y los límites de consumo cambian con cada versión que sale. Confirma en la documentación oficial cómo está la cosa cuando leas esto.

Cómo saber si una tarea es de pensar o de ejecutar

La pregunta que me hago antes de lanzar algo: ¿yo sé cómo se hace esto?

Si la respuesta es sí y solo me da pereza hacerlo, es tarea de ejecución. Sonnet.

Si la respuesta es no, y espero que la máquina me proponga el camino, es tarea de pensar. Opus.

Hay un tercer caso, el más traicionero: creo que sé cómo se hace pero me estoy equivocando. Ahí lanzas Sonnet, sale mal, insistes, sale peor, y acabas gastando más que si hubieras ido directo a Opus. Es el clásico de la falsa economía.

Señal para detectarlo: si llevas tres intentos con Sonnet y el problema no se mueve, no es cuestión de insistir. Cambia de modelo o cambia de enfoque, porque más de lo mismo no va a funcionar.

El error de dejarlo siempre en el más potente

Es lo que hace todo el mundo al principio, yo incluido. Si hay uno mejor, ¿por qué usar el otro?

Por dos motivos, y el primero no es el dinero.

El primero es la velocidad. Sonnet responde bastante más rápido. Cuando estás en un bucle de "cambia esto, mírame, cambia lo otro", esperar el doble en cada vuelta te saca del ritmo. Y cuando te sales del ritmo, te vas a mirar el móvil. Sabes que es verdad.

El segundo es el presupuesto. Los planes tienen límites de uso, y el modelo grande los consume mucho más rápido. Si te lo fundes el miércoles, el jueves y el viernes no trabajas con IA. Eso es peor que haber usado un modelo un poco menos brillante toda la semana.

De cómo repartir el presupuesto entre planes hablé en qué plan de Claude Code uso, que es la otra mitad de esta decisión.

¿Y si mezclo los dos en la misma sesión?

Es exactamente lo que hay que hacer, y es lo que casi nadie hace.

Mi flujo habitual en algo mediano: arranco con Opus para que entienda el proyecto y me proponga el plan. Discuto el plan con él, lo ajusto, y cuando ya sé lo que quiero, cambio a Sonnet para la ejecución. Si en mitad de la ejecución aparece un problema que nadie esperaba, vuelvo a subir.

Cambiar de modelo dentro de la misma conversación se hace con un comando y tarda un segundo. No hay que empezar de cero.

Lo importante es que el cambio sea consciente. Si dejas puesto el que había, acabas depurando un problema complicado con el modelo pequeño o traduciendo un texto con el grande. Las dos cosas son un desperdicio en direcciones opuestas.

Lo que cambia según el tamaño del proyecto

Con dos archivos, da igual lo que elijas. Cualquiera lo hace bien.

La diferencia aparece cuando el proyecto crece. Con muchos archivos, el modelo tiene que decidir cuáles mirar, entender cómo se relacionan y no romper lo que no está viendo. Ahí Opus es notablemente mejor y se nota en el resultado.

Pero ojo, porque hay una trampa: un proyecto grande consume mucho más de por sí, porque hay que leer más cosas. Si además lo haces con el modelo caro, el consumo se multiplica por dos vías a la vez.

La solución no es el modelo. Es darle solo la parte que hace falta para cada tarea, en vez de soltarle el proyecto entero cada vez. Eso lo explico en manejar el contexto en un proyecto grande, y es más rentable que cualquier decisión de modelo.

¿Y los modelos pequeños y rápidos?

Existe un tercer escalón por debajo, pensado para tareas muy simples y muy rápidas. Y tiene su hueco, aunque en Claude Code se usa poco de forma consciente.

Para qué sirve: clasificar cosas, extraer datos de un texto, responder preguntas de una línea. Trabajo de fuerza bruta donde no hay nada que razonar.

Para qué no sirve: nada que tenga que ver con tocar tu proyecto. Se pierde con facilidad y acabas revisando más de lo que has ahorrado.

Mi postura: si estás empezando, olvídate de este escalón. Con dos modelos y una regla clara para repartirlos ya vas a ir mucho mejor que el 90% de la gente, que deja puesto el que venía por defecto y no vuelve a mirarlo nunca.

Reglas rápidas que aplico sin pensar

Escribir o reescribir texto: Sonnet. Siempre. La diferencia de calidad para prosa normal no justifica el coste.

Cambios mecánicos en muchos archivos: Sonnet. Es trabajo de fuerza bruta, no de talento.

Algo falla y no entiendo por qué: Opus. Aquí es donde se paga solo. Un problema raro resuelto en tres minutos en vez de en cuarenta compensa cualquier consumo.

Planificar cómo estructurar algo nuevo: Opus, y merece la pena hablar un rato con él antes de escribir una sola línea.

Tareas largas sin supervisión, donde vas a dejarlo trabajando solo: Opus. Cuando no estás delante para corregir, quieres el que se equivoca menos.

Preguntas de "cómo se hace esto" mientras aprendes: Sonnet de sobra. Y si no te convence la respuesta, subes. Si estás empezando y todo esto te suena a chino, empieza por Claude Code para no programadores y vuelve a este cuando ya lo tengas instalado.

Si quieres saber por dónde empezar a meter IA en tu trabajo sin montar un circo, tengo un test corto que te da una respuesta según cómo trabajas.

Hacer el test de IA