Claude Opus vs Sonnet vs Haiku
¿Qué necesita realmente el modelo top-tier?

Todo el mundo en ops LLM tiene la misma intuición: la mayoría de las requests no necesitan el modelo top. Nadie publica los datos. Así que hicimos el experimento nosotros mismos.

Diez mil requests prod reales, clasificadas en seis categorías de tareas, cada una enviada a Claude Haiku 4.5, Sonnet 4.6 y Opus 4.7. Salidas scoreadas a ciegas por dos evaluadores humanos más un juez LLM. Esto es donde la calidad diverge de verdad, y donde no diverge.

Metodología

Sacamos 10 000 requests reales de tres fuentes: un chatbot de soporte al cliente, un agente RAG de research interno, y una integración de asistencia al código. Cada request fue clasificada en una de las seis categorías por un pequeño classifier antes del routing:

1. Saludos / small talk, "hola", "buenas", "gracias", "qué tal"
2. Q&A factual corto, "cuál es la capital de Portugal", "cuándo se fundó X"
3. Resumen, condensar un documento de 1-5K tokens en 150 tokens
4. Extracción estructurada, sacar entidades nombradas, fechas o campos desde un texto
5. Razonamiento multi-paso, "compara estos tres enfoques y recomienda"
6. Generación / refactoring de código, tareas de código no triviales

Cada request atacó los tres modelos. Salidas scoreadas de 1 a 5 en tres ejes:

• Corrección (factualmente correcto, sin alucinación)
• Completitud (responde íntegramente a la pregunta)
• Utilidad (¿la aceptaría un usuario real?)

Dos evaluadores humanos puntuaron una muestra estratificada de 2 000 salidas a ciegas. Un juez LLM (otro modelo, Gemini 2.5 Pro, para evitar el sesgo de self-preference) puntuó las 30 000. Acuerdo humano/LLM: 94 % en corrección, 89 % en los otros dos ejes.

Los resultados principales

Aquí va el score medio por modelo y categoría, en escala 1-5:

El patrón es claro: para las dos primeras categorías, los tres modelos son esencialmente indistinguibles. Para las dos últimas, Haiku se hunde. Sonnet y Opus están cerca, pero Opus tira por delante de forma significativa en código.

Donde Haiku es realmente suficiente

Saludos, small talk, Q&A factual corto: los scores están a 0,05 puntos de Opus. Al delta de coste en juego. Haiku es ~19× más barato que Opus en input, ~19× más barato en output, no es nada.

Para un bot de soporte al cliente donde el 40 % de las requests son una variante de "hola, ¿puedo resetear mi contraseña?", routear ese 40 % a Haiku en lugar de Opus ahorra un 76 % en esa porción de la factura, con una pérdida de calidad aproximadamente nula.

Resumen y extracción estructurada: los scores de Haiku bajan claramente (4,3 vs 4,7+), pero en absoluto, una salida a 4,31 sigue siendo útil. Para resumen no crítico, digests de email, blurbs de dashboard, notas internas, el delta no vale 19× el coste. Para resumen customer-facing (documentos jurídicos, info médica), quieres Sonnet como mínimo.

Donde Sonnet es suficiente

Para resumen, extracción y la mayoría de tareas de razonamiento, Sonnet saca 4,4-4,7, lo que es esencialmente indistinguible de Opus para un evaluador humano. Los deltas precisos:

• Resumen: Opus gana por 0,08 puntos
• Extracción: Opus gana por 0,07 puntos
• Razonamiento multi-paso: Opus gana por 0,33 puntos

Dos de los tres están en el margen de error. El delta de razonamiento es real pero puedes cerrar la mayoría con mejor prompting sobre Sonnet. En coste, Sonnet es 5× más barato que Opus. Para la gran mayoría de las tareas de razonamiento, Sonnet es la elección correcta.

Donde Opus justifica su precio

La generación de código y el razonamiento multi-paso complejo son los lugares donde Opus justifica su prima de 5× sobre Sonnet y 95× sobre Haiku.

Ejemplos donde Opus tiró claramente por delante en nuestro test:

• Refactoring multi-fichero. Sonnet producía código que compilaba pero introducía bugs sutiles (mal scope, edge cases olvidados). Opus era sistemáticamente más cuidadoso.
• Diseño de algoritmo nuevo. "Escribe un rate limiter que gestione tanto sliding window como token bucket." El primer intento de Sonnet se saltaba el problema de contención del sliding window; Opus lo cogió.
• Razonamiento en cadena larga (7+ pasos). Problemas donde la salida de cada paso alimenta al siguiente. La tasa de error de Sonnet se componía; Opus se mantenía estable.

Si tu producto es un asistente de código, un asesor de arquitectura o un agente de research que encadena muchos pasos, Opus merece la pena. Para la mayoría del resto de productos, estás pagando de más.

La regla real del 70 %

Esta es la distribución de categorías en nuestra muestra de 10 000 requests:

El 70 % de las requests (las cuatro primeras categorías) se trataban sin pérdida de calidad sobre Haiku o Sonnet. Solo el 9 %, la porción de código, necesitaba realmente Opus para sacar el score máximo.

Si routeas:

• Saludos + Q&A corto → Haiku (40 %)
• Resumen + extracción → Sonnet (32 %)
• Razonamiento → Sonnet (19 %)
• Código → Opus (9 %)

Coste efectivo a tarifas publicadas de Anthropic: 1,32 $ por 1 000 requests. Todo sobre Opus: 4,75 $ por 1 000 requests. O sea, una reducción del 72 %, medible sobre una muestra lo bastante grande para que la significación estadística sea ajustada (p < 0,001 sobre scoring apareado).

El folclore "el 70 % de las requests no necesitan el modelo top" es aproximadamente correcto. Los datos lo confirman.

Los caveats y lo que esto no demuestra

Tres caveats honestos:

1. El dominio importa. Nuestras requests venían de tres productos específicos. Una herramienta de research científico o un analizador de contratos jurídicos probablemente tendría una distribución muy distinta, con razonamiento y extracción dominando. Hay que lanzar esta clasificación sobre tu tráfico para conocer tu reparto.

2. Haiku 4.5 es inusualmente fuerte. La versión 4.5 ha cerrado un gran hueco de calidad con Sonnet en retrieval y extracción. Estos números serían peores sobre Haiku 3.5 o anterior. Vigila las versiones cuando planifiques tus reglas de routing.

3. La deriva de tarea es real. El mismo usuario puede enviar un saludo, una pregunta de razonamiento y una tarea de código en una conversación. Hay que clasificar por request, no por usuario o por sesión. Aquí es donde un buen router se gana el pan.

Lo que debe hacer un router

A partir de estos datos, la lógica de routing no es misteriosa:

1. Clasificar la request entrante en menos de 1 ms con un modelo pequeño o un classifier de reglas.
2. Buscar el tier correcto para esa categoría, según tu configuración.
3. Aplicar los overrides, reglas por clave, por cliente, topes de coste que fuerzan un downgrade.
4. Trackear los resultados, loguear qué mapping categoría-a-modelo tuvo qué tasa de aceptación, y ajustar.

Nuestro router hace los pasos 1-3 en 0,4 ms de media. El paso 4 es importante para el tuning a largo plazo, observas tu tasa de aceptación por route y ajustas.

La conclusión

Si haces correr todas tus requests sobre tu modelo top-tier, estás quemando 3-4 $ por 1 $ de beneficio real de calidad sobre el 70-80 % de requests que no lo necesitan. Los datos son inequívocos.

La buena pregunta no es "¿qué modelo es el mejor?". Es "¿qué modelo es suficiente, por categoría de request?". Y la respuesta, medida sobre tráfico real, casi siempre incluye Haiku y Sonnet para la mayoría de tu volumen.

---

A leer también: Las matemáticas ocultas del pricing LLM profundiza en por qué tu coste por request es más grande de lo que el precio publicado sugiere.