Claude Haiku, Sonnet, Opus o Fable: cuándo utilizar cada uno

Elegir un modelo de inteligencia artificial para un proyecto ya no consiste simplemente en identificar cuál es el más potente. Cuando desarrollamos aplicaciones, automatizamos procesos o construimos agentes de IA, tenemos que encontrar un equilibrio entre capacidad de razonamiento, velocidad de respuesta, consumo de tokens y coste real de ejecución.

Anthropic ha publicado una guía especialmente interesante sobre esta decisión, comparando sus cuatro familias de modelos Claude: Haiku 5.5, Sonnet 5.5, Opus 5.5 y Fable 5.2. La conclusión es bastante más interesante que una clasificación de mayor a menor potencia: utilizar siempre el modelo más avanzado no garantiza obtener mejores resultados ni optimizar la inversión.

De hecho, una de las recomendaciones más importantes es aprender a combinar modelos dentro de un mismo proyecto. Podemos reservar los más avanzados para decisiones complejas y delegar operaciones rutinarias en alternativas más rápidas y económicas, sin que eso implique necesariamente sacrificar la calidad del resultado.

Vamos a analizar qué ofrece cada modelo, cuánto cuesta y, sobre todo, cómo elegir la combinación adecuada para nuestros proyectos.

Los cuatro modelos de Claude y para qué sirve cada uno

La familia Claude cuenta actualmente con cuatro modelos de disponibilidad general. Cada uno está pensado para resolver un tipo de problema y ofrece un equilibrio diferente entre rendimiento, latencia y coste.

Aunque todos pueden trabajar con herramientas, procesar imágenes y utilizar ventanas de contexto amplias, eso no significa que sean igualmente adecuados para cualquier escenario. La complejidad de las tareas y el nivel de autonomía que necesitamos son factores fundamentales para tomar la decisión.

Claude Haiku 5.5: velocidad y eficiencia para tareas repetitivas

Claude Haiku 5.5 es el modelo más rápido y económico de la familia. Está especialmente orientado a operaciones de gran volumen, con instrucciones concretas y resultados relativamente fáciles de comprobar.

Podemos utilizarlo para clasificar documentos, extraer información estructurada, categorizar solicitudes, identificar intenciones o decidir a qué proceso debe dirigirse una petición. También tiene sentido cuando necesitamos ejecutar miles de operaciones similares y el coste individual de cada llamada es importante.

Imaginemos un sistema que recibe miles de solicitudes de atención al cliente cada día. Haiku podría identificar el idioma, clasificar el motivo de contacto y extraer los datos relevantes antes de enviar la información al proceso correspondiente.

No necesitamos necesariamente un modelo con las mayores capacidades de razonamiento para identificar si una solicitud corresponde a facturación, soporte o una consulta comercial. La clave está en comprobar que los resultados son suficientemente fiables para nuestro caso de uso.

Claude Sonnet 5.5: el equilibrio para aplicaciones empresariales

Sonnet 5.5 representa una alternativa especialmente interesante para tareas bien definidas que requieren más capacidad que una simple clasificación. Es rápido, ofrece buenos resultados en escenarios cotidianos y cuesta considerablemente menos que Opus.

Entre sus posibles aplicaciones encontramos la generación de contenido, la elaboración de documentos, la resolución de problemas de programación bien delimitados, los asistentes conversacionales y los agentes que ejecutan procesos repetitivos.

Pensemos en un asistente comercial que necesita elaborar respuestas a clientes utilizando información previamente recuperada de un CRM. Sonnet podría interpretar la consulta, preparar una respuesta contextualizada y devolver un resultado estructurado que posteriormente validaría nuestra aplicación.

También sería un candidato para automatizaciones de marketing, generación de borradores, análisis de documentación y producción de informes. Cuando el proceso está bien diseñado y las instrucciones son claras, no siempre es necesario recurrir a un modelo más costoso.

Claude Opus 5.5: el modelo de referencia para trabajo complejo

Opus 5.5 ocupa una posición especialmente interesante dentro de la estrategia de Anthropic. Aunque no es el modelo más potente de toda la familia, la compañía lo recomienda como punto de partida para la mayoría de las tareas de programación y trabajo intelectual.

Es el modelo predeterminado en Claude Code para los planes y entornos compatibles, y Anthropic aconseja comenzar utilizando su nivel de esfuerzo medium. A partir de ahí, podemos decidir si merece la pena reducir costes con Sonnet o aumentar las capacidades con Fable.

Opus resulta adecuado para depuración compleja, desarrollo de funcionalidades que afectan a múltiples componentes, análisis de grandes cantidades de información y agentes que necesitan tomar decisiones a lo largo de numerosos pasos.

También destaca como candidato para escenarios que implican interacción con interfaces mediante computer use o procesamiento intensivo de información visual. En este tipo de procesos no basta con ejecutar una instrucción correctamente: el sistema debe interpretar resultados, adaptar su comportamiento y mantener la coherencia durante toda la ejecución.

Claude Fable 5.2: para los problemas técnicos más exigentes

Fable 5.2 es el modelo de disponibilidad general más capaz de Anthropic para trabajos técnicos especialmente complejos. Está orientado a escenarios que requieren razonamiento profundo, planificación avanzada y resolución de problemas difíciles en programación, finanzas y ciencias.

Su utilización cobra sentido en grandes migraciones de software, cambios arquitectónicos, investigaciones técnicas complejas y proyectos que implican coordinar numerosos agentes especializados.

Por ejemplo, una migración importante de una aplicación empresarial puede requerir analizar dependencias, identificar riesgos, establecer una estrategia y coordinar modificaciones en diferentes componentes. En ese contexto, utilizar Fable para la planificación y las decisiones más difíciles puede ser razonable, aunque otros modelos ejecuten después buena parte del trabajo.

Eso sí, Fable no debería convertirse automáticamente en nuestra primera opción para cualquier tarea. Su precio por token duplica el de Opus, por lo que debemos comprobar que la mejora obtenida justifica la inversión.

Anthropic también dispone de Claude Mythos 5.2, especializado en investigación de ciberseguridad y ciencias de la vida, pero su acceso está limitado a programas de verificación específicos. No forma parte de las cuatro alternativas de disponibilidad general que estamos comparando.

¿Cuánto cuesta utilizar Claude Haiku, Sonnet, Opus y Fable?

El precio es uno de los factores que más condicionan la elección cuando pasamos de realizar pruebas a desplegar una aplicación en producción. Una diferencia aparentemente pequeña en el coste por llamada puede convertirse en una partida importante cuando ejecutamos cientos de miles de operaciones.

Estos son los precios publicados por Anthropic para su API, expresados en dólares estadounidenses por millón de tokens:

Modelo	Tokens de entrada	Tokens de salida	Lectura de caché
Haiku 5.5, prompts de hasta 100.000 tokens	0,10 $	0,50 $	0,01 $
Haiku 5.5, prompts de más de 100.000 tokens	0,50 $	2,50 $	0,05 $
Sonnet 5.5	2 $	10 $	0,10 $
Opus 5.5	4 $	20 $	0,20 $
Fable 5.2	8 $	40 $	0,20 $

Precios de referencia de Claude API publicados en noviembre de 2026. No incluyen necesariamente otros costes del sistema ni reflejan las tarifas de todos los proveedores.

Las diferencias son importantes. Sonnet cuesta la mitad que Opus por token de entrada y salida, mientras que Fable cuesta el doble que Opus. Haiku introduce además un aspecto que conviene tener especialmente presente: su precio aumenta cuando el prompt supera los 100.000 tokens.

Por tanto, no basta con elegir Haiku porque sea el modelo más barato. Si nuestro proceso utiliza continuamente grandes volúmenes de contexto, debemos estudiar si Sonnet puede ofrecer mejores resultados con un coste total competitivo.

El precio por token no es el coste real de una tarea

Aquí encontramos una de las reflexiones más interesantes del artículo original: el modelo más barato por token no siempre es el más barato por tarea completada correctamente.

Imaginemos que estamos construyendo un agente capaz de analizar incidencias técnicas y proponer soluciones. Un modelo económico puede necesitar varias llamadas adicionales, consumir más tokens, cometer errores que obliguen a repetir parte del proceso o requerir más intervenciones de otros componentes.

Por el contrario, un modelo más avanzado podría resolver el problema en menos pasos. Aunque cada token resulte más caro, el coste total de obtener una solución válida podría ser inferior.

Anthropic presenta un ejemplo relacionado con el benchmark FrontierCode 2.0. En sus pruebas, Fable 5.2 con esfuerzo high consiguió un resultado cercano al de Opus 5.5 con esfuerzo max —45,3 % frente a 45,5 %—, pero con aproximadamente la mitad del coste por tarea.

Esto no significa que Fable siempre resulte más económico. Significa que debemos medir el proceso completo, especialmente en los casos difíciles, en lugar de utilizar únicamente las tablas de precios para tomar decisiones.

Qué modelo Claude elegir según el tipo de proyecto

La elección resulta más sencilla cuando dejamos de pensar en modelos de forma aislada y empezamos a relacionarlos con tareas concretas.

Esta sería una guía inicial basada en las recomendaciones de Anthropic:

Escenario	Modelo recomendado	Esfuerzo inicial
Clasificación y extracción masiva de datos	Haiku 5.5	medium
Chatbots y asistentes conversacionales	Sonnet 5.5	low o medium
Generación habitual de documentos e informes	Sonnet 5.5	high
Desarrollo de funcionalidades bien definidas	Sonnet 5.5	medium
Depuración y desarrollo de software complejo	Opus 5.5	medium
Agentes que interactúan con interfaces	Opus 5.5	medium
Arquitectura de software y grandes migraciones	Fable 5.2	medium y después high
Investigación técnica y análisis científico complejo	Fable 5.2	medium y después high
Proyecto cuya dificultad todavía desconocemos	Opus 5.5	medium

Esta tabla es un punto de partida, no una regla universal. Una tarea aparentemente sencilla puede ocultar una complejidad importante, mientras que un proceso que parece sofisticado puede descomponerse en operaciones simples que un modelo económico resuelva perfectamente.

Por ejemplo, generar un documento comercial a partir de una plantilla puede ser un buen trabajo para Sonnet. Sin embargo, elaborar un informe financiero complejo a partir de múltiples fuentes, detectar inconsistencias y justificar las conclusiones podría requerir Opus o incluso Fable.

La diferencia no está únicamente en el formato del resultado, sino en el razonamiento necesario para producirlo.

El nivel de esfuerzo es casi tan importante como el modelo

Otra de las variables que debemos incorporar al diseño es el nivel de esfuerzo, conocido en Claude como effort.

Este parámetro permite ajustar los recursos de razonamiento utilizados por el modelo. Un nivel superior puede ayudar a resolver problemas difíciles, realizar más comprobaciones o ejecutar más herramientas, pero normalmente también aumenta el consumo y la latencia.

Anthropic recomienda no cambiar inmediatamente a un modelo superior cuando los resultados no son satisfactorios. Antes deberíamos comprobar si el modelo actual puede mejorar aumentando su esfuerzo.

Una estrategia razonable sería comenzar con un nivel moderado, comprobar los resultados y aumentar gradualmente el esfuerzo cuando sea necesario. Si seguimos sin obtener la calidad esperada, entonces podremos probar un modelo superior con un nivel de esfuerzo inferior.

No debemos olvidar que aumentar el esfuerzo no proporciona automáticamente capacidades que el modelo no tiene. Puede ayudarle a utilizar mejor sus recursos, pero existen problemas cuya complejidad justifica directamente elegir otro modelo.

¿Y si dejamos de utilizar siempre el máximo esfuerzo?

Este es otro punto especialmente interesante desde la perspectiva del coste.

En una prueba sobre SWE-bench Pro, Anthropic comparó dos estrategias con Opus 5.5. La primera ejecutaba todas las tareas con esfuerzo high, mientras que la segunda comenzaba con low y repetía únicamente los fallos utilizando high.

La segunda estrategia resolvió aproximadamente el 97 % de las tareas por un coste medio de 0,17 dólares, frente al 95,3 % y 0,29 dólares de ejecutar todo directamente con esfuerzo alto.

Son resultados de un benchmark concreto, no una garantía para cualquier aplicación empresarial. Sin embargo, ilustran una posibilidad muy interesante: no necesitamos utilizar siempre la configuración más exigente si somos capaces de detectar automáticamente cuándo una respuesta es incorrecta.

Esto funciona especialmente bien en desarrollo de software, donde podemos ejecutar pruebas, compilar código o comprobar si una operación produce el resultado esperado. En procesos empresariales también podemos aplicar validaciones, aunque verificar una respuesta comercial o una conclusión jurídica resulta bastante más complicado que comprobar el resultado de una prueba automatizada.

Combinar varios modelos: una arquitectura más inteligente

Hasta ahora hemos hablado de cómo elegir un modelo, pero probablemente la decisión arquitectónica más interesante sea no depender exclusivamente de uno.

Anthropic propone diferentes estrategias para combinar modelos según su capacidad, coste y función dentro del sistema. La idea es bastante sencilla: utilizar modelos económicos para el trabajo rutinario y reservar los más avanzados para las decisiones que realmente necesitan sus capacidades.

Este planteamiento encaja especialmente bien con la evolución de los sistemas de agentes de IA, donde una solución puede implicar planificación, ejecución de herramientas, consultas a diferentes fuentes, generación de contenido y validación de resultados.

Un ejemplo práctico con Dynamics 365

Imaginemos que queremos desarrollar un sistema de atención comercial conectado con Dynamics 365 Sales y un conjunto de fuentes documentales de la empresa.

La solución podría utilizar los cuatro modelos de la siguiente manera:

• Haiku 5.5: clasifica las solicitudes entrantes, identifica su intención y extrae información relevante para el proceso.
• Sonnet 5.5: prepara borradores de respuestas comerciales, resume interacciones y genera comunicaciones basadas en datos recuperados.
• Opus 5.5: coordina investigaciones más complejas, interpreta información procedente de diferentes sistemas y decide qué pasos adicionales necesita el proceso.
• Fable 5.2: participa en tareas excepcionales de arquitectura, análisis técnico complejo o rediseño de integraciones, sin intervenir necesariamente en cada solicitud.

Este es un ejemplo de arquitectura posible, no una integración nativa que Anthropic proporcione directamente para Dynamics 365. Su implementación requeriría diseñar las conexiones mediante las APIs, herramientas y mecanismos de seguridad correspondientes.

La ventaja es que evitamos utilizar Fable u Opus para resolver miles de operaciones que Haiku podría ejecutar de forma satisfactoria. Al mismo tiempo, mantenemos la posibilidad de escalar a un modelo más capaz cuando aparece una situación que requiere mayor razonamiento.

Por supuesto, esta arquitectura no tiene por qué utilizar cuatro modelos. En muchos proyectos bastará con combinar dos, y en otros utilizar un único modelo será más sencillo y económico.

Los subagentes pueden reducir el consumo de los modelos avanzados

Uno de los patrones más interesantes que explica Anthropic consiste en delegar tareas secundarias en subagentes que utilizan modelos más económicos.

Un subagente trabaja con su propia ventana de contexto y devuelve los resultados al agente principal. Esto permite separar la recopilación de información y las operaciones rutinarias de las decisiones que necesitan un razonamiento más avanzado.

Pensemos en un agente principal que debe investigar por qué está fallando una aplicación. En lugar de dedicar miles de tokens de Opus a leer archivos de registro completos, puede utilizar un subagente basado en Haiku para localizar errores, identificar archivos relevantes y resumir los resultados.

Opus recibe entonces información más concreta y puede concentrarse en diagnosticar el problema y decidir qué cambios deben realizarse. Además de reducir potencialmente el consumo, esta separación evita llenar el contexto del modelo principal con información que no necesita conservar.

En Claude Code podemos establecer el modelo de un subagente mediante propiedades como model: haiku o model: sonnet en su definición. También existe la variable CLAUDE_CODE_SUBAGENT_MODEL para establecer el modelo predeterminado de los subagentes que no especifican uno.

Eso sí, no todas las tareas son buenas candidatas para delegación. Si un subagente interpreta mal un archivo o presenta una conclusión incorrecta, puede provocar que el agente principal tome decisiones sobre información equivocada.

Por eso tiene sentido reservar los modelos pequeños para actividades cuyos resultados puedan verificarse fácilmente y mantener las decisiones de mayor impacto bajo el control del agente principal.

La ventana de contexto también afecta al coste

Los cuatro modelos actuales cuentan con una ventana de contexto de un millón de tokens y admiten hasta 128.000 tokens de salida. Son capacidades considerables, pero disponer de una ventana enorme no significa que debamos utilizarla continuamente.

Cada vez que una aplicación vuelve a enviar grandes cantidades de contexto, ese contenido influye en el consumo. La caché de prompts puede reducir significativamente el coste de reutilizar información, pero no elimina la necesidad de diseñar cuidadosamente qué datos recibe cada modelo.

Esto resulta particularmente importante en agentes que mantienen conversaciones largas, consultan numerosas herramientas o trabajan durante muchas iteraciones.

Por ejemplo, una arquitectura que mantiene cientos de miles de tokens en el contexto de Opus puede ser menos eficiente que otra donde Haiku o Sonnet procesan previamente la documentación y trasladan únicamente los resultados relevantes.

El principio es sencillo: cuanto más costoso sea el modelo que toma las decisiones, más importante será evitar que su contexto se convierta en un almacén indiscriminado de información.

Cuidado al cambiar de modelo durante una conversación

Anthropic también advierte sobre un detalle técnico que puede pasar desapercibido: la caché de prompts está asociada al modelo que la generó.

Cuando cambiamos de modelo durante una conversación, la primera petición al nuevo modelo puede necesitar reconstruir esa información en su propia caché. Esto introduce un coste adicional que debemos contemplar si nuestro sistema cambia constantemente de modelo.

Una alternativa consiste en realizar esos cambios en puntos naturales del proceso. En Claude Code podemos utilizar /compact para reducir el contexto antes del cambio, mientras que en desarrollos basados en la API podemos iniciar una nueva conversación proporcionando un resumen estructurado del trabajo realizado.

Además, los bloques de razonamiento conservados no son completamente intercambiables. Su compatibilidad depende de los modelos y del entorno utilizado, y un modelo de menor nivel puede perder los bloques de razonamiento generados por uno superior.

Por tanto, cambiar de modelo no debería plantearse siempre como una simple sustitución del identificador dentro de una petición. Conviene diseñar explícitamente cómo transferimos la información necesaria para continuar el trabajo.

Compatibilidad: no todos los modelos se comportan igual en la API

Aunque los cuatro modelos comparten numerosas capacidades, Anthropic señala diferencias que debemos tener presentes antes de migrar una aplicación o configurar un sistema multimodelo.

Una de ellas es el razonamiento adaptativo. Opus 5.5 y Fable 5.2 lo mantienen activado obligatoriamente, mientras que Haiku y Sonnet permiten configuraciones diferentes. Esto afecta a la estructura de las respuestas y a los parámetros que podemos enviar.

También existen particularidades en la selección de herramientas. Por ejemplo, Sonnet 5.5, Opus 5.5 y Fable 5.2 no admiten determinados valores de tool_choice que fuerzan directamente la utilización de una herramienta. Anthropic recomienda utilizar auto, definir herramientas estrictas mediante strict: true y especificar claramente en las instrucciones cuándo deben emplearse.

En el caso de las aplicaciones con computer use, hay que comprobar igualmente la versión del conjunto de herramientas soportado. Los modelos actuales requieren computer_toolset_20260801 en los entornos compatibles indicados por Anthropic.

Y hay otro detalle relevante si trabajamos con varios proveedores: los alias de los modelos no tienen por qué resolverse a la misma versión en todas las plataformas. Anthropic señala diferencias entre su propia API y servicios como Amazon Bedrock, Google Cloud o Microsoft Foundry.

Para un proyecto empresarial, esto refuerza la necesidad de validar identificadores, disponibilidad, parámetros y comportamiento en el servicio concreto donde vamos a desplegar la solución.

¿Cómo saber si estamos utilizando el modelo adecuado?

Podemos leer benchmarks, comparar precios y seguir las recomendaciones del fabricante, pero la decisión definitiva debería tomarse utilizando nuestras propias tareas.

No necesitamos comenzar con una evaluación enorme. Podemos seleccionar un conjunto representativo de casos reales y ejecutar las mismas pruebas con diferentes modelos y niveles de esfuerzo.

Mi propuesta sería evaluar cinco dimensiones:

1. Calidad del resultado: cuántas tareas se completan correctamente y cuántas requieren intervención adicional.
2. Coste por tarea válida: cuánto gastamos realmente incluyendo reintentos, llamadas adicionales y utilización de herramientas.
3. Latencia: cuánto tarda el sistema en responder y cómo afecta esa espera a la experiencia del usuario.
4. Fiabilidad: cómo se comporta ante entradas ambiguas, información incompleta y situaciones difíciles.
5. Complejidad operativa: cuánto cuesta mantener, supervisar y evolucionar la arquitectura.

Conviene además diferenciar entre tareas habituales y casos especialmente exigentes. Anthropic muestra que una pequeña proporción de problemas difíciles puede concentrar una parte considerable del gasto total, por lo que evaluar únicamente escenarios sencillos nos daría una imagen distorsionada.

En un sistema de atención comercial, por ejemplo, podríamos comprobar cuánto cuesta gestionar una consulta habitual, cuánto cuesta investigar una incidencia compleja y qué porcentaje de solicitudes necesita escalar a un modelo superior.

Con estos datos podremos determinar si una arquitectura basada en Sonnet y Opus resulta más eficiente que utilizar únicamente Opus. También descubriremos si la incorporación de Haiku aporta realmente un ahorro o si la complejidad adicional de la orquestación termina anulando sus beneficios.

Antes de llevar la nueva configuración a producción, conviene ejecutarla sobre una muestra de tráfico real en modo de evaluación, sin que sus respuestas sustituyan todavía a las del sistema existente. De este modo podremos comparar calidad, coste y comportamiento bajo condiciones más cercanas a las que encontrará la aplicación.

El verdadero objetivo no es utilizar el mejor modelo, sino diseñar el mejor sistema

Hay una idea que me parece especialmente relevante en toda esta comparación: la arquitectura de una solución de IA importa tanto como el modelo que utilizamos.

Durante mucho tiempo, la conversación sobre inteligencia artificial se ha centrado en comparar modelos mediante benchmarks y decidir cuál ocupa la primera posición. Sin embargo, cuando llevamos esas capacidades a una aplicación empresarial, aparecen otras preguntas: cuánto cuesta cada operación, qué latencia podemos aceptar, cómo verificamos los resultados y qué sucede cuando el sistema se equivoca.

Mi punto de partida sería Opus 5.5 con esfuerzo medium cuando todavía no conocemos bien la dificultad del problema, siguiendo la recomendación de Anthropic. Una vez identificado el comportamiento de la aplicación, intentaría desplazar hacia Sonnet o Haiku todas las tareas que puedan resolverse con la misma calidad y menor coste.

Reservaría Fable 5.2 para aquellos escenarios donde una mayor capacidad de razonamiento aporte una ventaja demostrable. Y antes de aumentar continuamente el esfuerzo de cualquier modelo, invertiría en mecanismos de verificación que permitan detectar errores y repetir únicamente las operaciones necesarias.

También evitaría complicar una solución sencilla con una arquitectura multiagente que no necesita. Coordinar varios modelos introduce costes de planificación, intercambio de información y validación que solamente compensan cuando existe suficiente volumen de trabajo o una división de responsabilidades realmente útil.

En definitiva, no se trata de utilizar la inteligencia artificial más potente en todas partes, sino de aplicar la capacidad adecuada en cada momento. Ese enfoque es el que puede ayudarnos a construir soluciones más eficientes, escalables y sostenibles desde el punto de vista económico.

Porque, al final, el éxito de una aplicación empresarial de IA no debería medirse por el nombre del modelo que utiliza, sino por los resultados que consigue y el valor que aporta al negocio.

¿Quieres saber más sobre las soluciones de inteligencia artificial generativa de Microsoft? Yo te asesoro. ¿Por qué no me preguntas cómo puedo ayudarte?

Información basada en la publicación Which Claude model should you build with? Fable, Opus, Sonnet, or Haiku