Elegir el modelo de Claude correcto para cada tarea

La mayoría elige un modelo de Claude igual que elige un teléfono: agarra el más potente y se queda tranquilo. Buen instinto, mala opción por defecto. Terminas pagando precio de Opus para reformatear fechas. La pregunta de fondo no es "¿cuál modelo es el mejor?" sino "¿qué tipo de fallo es el que menos me puedo permitir en esta tarea?". Esta guía te da un proceso de decisión que puedes repetir, un patrón de routing listo para producción, un ejemplo resuelto paso a paso y los detalles que, sin que te des cuenta, te inflan la factura o la latencia. Vas a terminar pudiendo justificar la elección de modelo tarea por tarea, en vez de imponer uno solo en toda tu app.

01 · Prerrequisitos: conoce tu tarea antes que tu modelo

Antes de poder elegir un modelo necesitas tener tres cosas por escrito. Saltarte esto es justo de donde salen las quejas de "el modelo barato no da la talla". La tarea nunca se caracterizó, así que le estabas pidiendo al modelo que se tragara una ambigüedad que el prompt tenía que haber eliminado.

• La forma de la tarea. ¿Es transformación (clasificar, extraer, reescrituras cortas, dar formato) o razonamiento (decisiones de varios pasos, planificación, debug, cualquier cosa donde el modelo tenga que sostener varias restricciones a la vez)? La transformación rara vez necesita la gama alta. El razonamiento es donde Opus se gana su precio.
• El costo de una respuesta equivocada. Sé concreto. Un borrador interno mal etiquetado solo cuesta volverlo a correr. Una decisión equivocada de cara al cliente, una mala decisión de seguridad o una lógica de negociación con fallos cuestan confianza o dinero. Anota el número aunque sea a ojo.
• Si el usuario ve la latencia. Un chat donde alguien está esperando necesita velocidad. Un proceso nocturno por lotes no. Ahí puedes correr un modelo más potente y más lento sin que nadie lo note.

Si puedes responder esas tres, la elección de modelo es casi mecánica. Si no, no hay modelo que te salve. Solo vas a terminar culpando al barato.

02 · Las tres preguntas que de verdad lo deciden

Hazlas en orden. Gana la primera que te dé una respuesta clara.

1. ¿La tarea pide razonamiento profundo de varios pasos o es casi todo transformación? Clasificar, extraer y reescrituras cortas son transformación. Un modelo más rápido y barato las resuelve, y el presupuesto que ahorras lo metes en volumen. El razonamiento de varios pasos (planificar, hacer debug entre archivos, sopesar concesiones) es donde la gama más potente saca ventaja.
2. ¿Cuánto cuesta una respuesta equivocada? Las decisiones de cara al cliente, los temas de seguridad y la lógica de negociación justifican el modelo de razonamiento más potente. Los borradores internos y los resúmenes desechables, no. Ajusta el modelo al radio de impacto, no a tu ambición.
3. ¿El usuario ve la latencia? Si alguien está mirando un spinner, inclínate por Sonnet o Haiku y plantéate usar streaming para que la salida aparezca de inmediato. Si es un proceso en segundo plano, la latencia te sale gratis, así que corre el modelo que dé la mejor respuesta.

Un mapeo aproximado

Esto es un punto de partida, no una ley. Vuelve a probarlo con tus propios datos.

• Haiku: clasificación a gran volumen, routing, etiquetado, extracción simple, triage de primera pasada, chequeos de confianza baratos.
• Sonnet: la mayoría del trabajo de aplicación: redactar, resumir, ediciones de código, workflows con tools, cualquier cosa interactiva donde quieras una buena respuesta rápido.
• Opus: lo más difícil y de más largo aliento: refactors complejos, investigación profunda, deliberación multiagente, cualquier cosa donde equivocarse salga tan caro que la corrección le gane al costo.

03 · Ajusta el prompt antes de subir de modelo

Esta es la mejora de rendimiento más barata que vas a conseguir, y la que todos se saltan porque subir de modelo es una línea y reescribir un prompt da trabajo.

La gente hace benchmark del modelo y se olvida del prompt. Un modelo más débil con un prompt afilado y lleno de ejemplos le gana sin problema a uno más potente con un prompt vago, y a una fracción del costo. Antes de irte a una gama más grande, prueba esto:

• Agrega dos o tres ejemplos resueltos del mapeo exacto de entrada a salida que quieres. Los ejemplos few-shot cierran más brecha que un cambio de modelo, y te cuestan un puñado de tokens.
• Deja claros los casos de fallo. "Si la fecha es ambigua, devuelve null en vez de adivinar" elimina toda una clase de respuestas equivocadas que ningún tamaño de modelo arregla por su cuenta.
• Restringe la salida. Para todo lo que vaya a leer una máquina, fuerza un tool call o usa structured outputs para que el modelo solo rellene valores en vez de inventarse también el envoltorio.

04 · El patrón que aguanta: enruta, no estandarices

Estandarizar en un solo modelo es la decisión más cara que puedes tomar, porque cada tarea termina pagando por la tarea más difícil. El patrón que uso en todos mis proyectos es enrutar: por defecto una gama media o baja, y escalar al modelo más potente solo cuando la tarea viene marcada como crítica o cuando falla un chequeo de confianza barato.

// Por defecto, barato. Escala solo cuando de verdad importa.
const POR_DEFECTO = "claude-haiku-4-5"
const MAS_FUERTE = "claude-opus-4-8"

function elegirModelo(tarea: { critica: boolean; bajaConfianza: boolean }) {
  return tarea.critica || tarea.bajaConfianza ? MAS_FUERTE : POR_DEFECTO
}

La señal de "baja confianza" es la mitad interesante del asunto. No necesitas un detector sofisticado. Basta con una primera pasada barata que devuelva un campo de confianza, un auto-chequeo que marque incertidumbre o una regla simple (extracción vacía, campos contradictorios, un valor fuera de rango) para decidir si vale la pena gastar dinero de Opus en una segunda mirada. La mayoría de las tareas nunca llega a disparar la escalada, así que pagas la gama alta solo en la rebanada que de verdad la necesita.

05 · En Opus, las perillas importan más que el cambio

Si ya aterrizaste en Opus, tu siguiente palanca no es otro modelo. Es cuánto lo dejas pensar. En la gama Opus actual, dos controles mueven el balance costo-calidad más que cambiar de gama:

• El thinking adaptativo deja que el modelo decida cuándo y cuánto razonar en cada request, en vez de que tú andes ajustando un presupuesto fijo de tokens. Actívalo para cualquier cosa que no sea trivial; déjalo apagado en transformación pura, donde razonar es gastar tokens de más.
• El «effort» (low, medium, high y más arriba) controla cuánto piensa y actúa el modelo. Más effort es trabajo más a fondo y más tokens; menos effort son respuestas más cortas, rápidas y baratas. Para la mayoría del trabajo donde la inteligencia importa, high como mínimo es el punto justo; baja a medium o low en rutas sensibles al costo o atadas a la latencia.

El movimiento práctico es barrer estos valores en tu propio set de evaluación en vez de andar adivinando. Muchas veces, poner más effort desde el arranque de una tarea agéntica reduce el total de turnos y termina saliendo más barato que un ajuste tímido que da vueltas sin avanzar. La relación no es monótona, así que mídela.

06 · Ejemplo resuelto: enrutar un pipeline de extracción

Digamos que estás sacando campos estructurados de un flujo de documentos entrantes, de esos que corren todo el día a volumen. Así aterriza el proceso de decisión.

1. Caracterízalo. Casi todo transformación (extracción), alto volumen y no visible al usuario (es una cola). El costo de una extracción equivocada: bajo de forma individual, pero se va acumulando, así que te conviene un chequeo de corrección barato.
2. Por defecto, Haiku. Es una tarea de transformación a volumen, justo lo suyo. Fuerza un tool call para que la salida tenga forma de esquema y no de prosa.
3. Agrega un gate de confianza. Haz que el extractor devuelva una confianza por campo o marque los campos requeridos que falten. Si algo se ve flojo (campo requerido vacío, valores contradictorios, un monto fuera de un rango razonable), escala ese documento puntual a Opus para una segunda pasada cuidadosa.
4. Mide la tasa de escalada. Si escala el 3% de los documentos, estás pagando precio de Opus en el 3% del volumen y precio de Haiku en el resto, una fracción de lo que costaría estandarizar en Opus, con el mismo piso de calidad donde importa.

La lección se generaliza: el modelo barato carga con el peso, el modelo potente se ocupa de las excepciones, y el chequeo de confianza es la pieza barata que los conecta. Casi nunca necesitas la gama alta en cada ítem. La necesitas en los ítems donde equivocarse sale caro, y un gate pequeño te los encuentra.

Elegir un modelo no es una decisión de arquitectura de una sola vez; es un juicio por tarea que vas a revisar a medida que salen modelos y tu tráfico cambia. Empieza por caracterizar la tarea y el costo de equivocarte, ajusta el prompt antes de irte a una gama más grande, y enruta para que cada tarea pague solo por la inteligencia que necesita. Hazlo y la elección de modelo deja de ser una adivinanza. Pasa a ser la respuesta correcta más barata a una pregunta que de verdad puedes formular.