Anthropic publicó Claude Haiku 4.5 el 15 de octubre de 2025, y durante los meses siguientes el modelo ha ido encontrando su lugar en los despliegues reales. No es la estrella que acapara titulares, pero es la pieza que más ha cambiado la economía práctica de los sistemas basados en LLM durante el invierno 2025-2026. Tras varios meses usándolo en producción, toca ordenar qué hace bien, qué no cubre y cuándo conviene elegirlo frente a su hermano mayor.
La propuesta: ligereza que ya no es juguete
Haiku 4.5 mantiene la promesa de la familia Haiku de ser el modelo pequeño y barato de Anthropic, pero con un salto cualitativo frente a Haiku 3.5. En tareas estructuradas, clasificación, extracción de entidades, generación de resúmenes y encadenamiento de llamadas a herramientas, el rendimiento se acerca notablemente al de Sonnet 4 del año anterior, con un coste que ronda un tercio y una latencia muy inferior. La combinación es lo que lo hace relevante.
El precio público de entrada y salida por millón de tokens lo coloca en un rango donde los cálculos de rentabilidad de sistemas con millones de peticiones mensuales cambian por completo. Un agente que con Sonnet 4.5 costaba cinco céntimos por ejecución pasa a costar uno con Haiku 4.5 si la tarea no requiere el razonamiento denso del modelo grande. Multiplica por decenas de miles de ejecuciones al mes y el margen operativo se transforma.
La ventana de contexto permite procesar documentos largos sin segmentar agresivamente, y el soporte para uso de herramientas está al mismo nivel que Sonnet 4.5. Esto es importante porque en muchos casos lo que limitaba a modelos pequeños anteriores no era la calidad del razonamiento sino la fiabilidad al invocar APIs externas, devolver JSON válido y manejar bucles agénticos sin perderse. Haiku 4.5 cruza ese umbral con claridad.
Dónde brilla
El terreno donde Haiku 4.5 supera la prueba de producción con menos fricción es el de los agentes de alto volumen y baja complejidad por paso. Clasificadores de tickets, extractores de datos estructurados desde correos, resumidores de informes, moderadores de contenidos, traductores contextuales y sistemas de ruteo donde cada petición hace una decisión acotada. En estos escenarios, la combinación de coste, latencia y calidad es difícil de batir con otros modelos comerciales de 2026.
Los flujos agénticos con muchos pasos cortos también encajan. Un agente que hace diez o veinte llamadas a herramientas por ejecución, donde cada paso es una decisión relativamente simple condicionada al estado actual, funciona muy bien con Haiku 4.5. El razonamiento denso no es necesario en cada paso; basta con que el modelo mantenga coherencia, invoque la herramienta correcta y procese el resultado. Esto lo hace candidato natural para pipelines donde antes se usaba Sonnet y donde cada llamada pesaba demasiado en la factura.
Un caso menos evidente pero igual de interesante es el preprocesamiento antes de modelos más grandes. Una arquitectura de dos niveles donde Haiku 4.5 hace filtrado, clasificación y preparación de contexto, y solo invoca a Sonnet 4.5 u Opus 4 cuando la tarea realmente lo justifica, puede reducir el coste total en un factor de cinco a diez sin perder calidad perceptible al usuario final. El patrón es conocido pero ahora es económicamente obvio.
Dónde no conviene forzarlo
Haiku 4.5 no es Sonnet 4.5, y pretender que lo sea lleva a malos resultados. Razonamiento denso multietapa, planificación compleja, matices lingüísticos sutiles, escritura creativa exigente y análisis que requieren sostener muchas piezas de contexto simultáneamente siguen siendo terreno donde el modelo grande marca diferencia. Meter Haiku en esos casos por ahorrar coste produce respuestas plausibles en superficie pero frágiles al examen, y normalmente acaba costando más en corrección humana que lo ahorrado en inferencia.
Tareas con ambigüedad alta, donde el modelo tiene que inferir intención desde pistas indirectas, también sufren. Haiku 4.5 es excelente cuando la instrucción es precisa y la salida esperada está bien definida; su rendimiento baja cuando hay que adivinar qué quiere realmente el usuario a partir de un mensaje incompleto. En estos casos, es mejor escalar a Sonnet o invertir en prompts más explícitos que forzar al modelo pequeño a hacer tareas que no son su fuerte.
La generación de código compleja es otra frontera. Haiku 4.5 maneja bien código de plantilla, scripts cortos y modificaciones puntuales guiadas. Para funciones largas con lógica intrincada, refactorizaciones que tocan varios archivos o depuración de errores sutiles, sigue siendo mejor Sonnet 4.5 o las alternativas especializadas. La diferencia se nota más en el número de iteraciones necesarias para llegar a código que funciona que en la calidad del primer intento.
Patrón combinado: Haiku y Sonnet juntos
El despliegue más rentable que hemos visto durante estos meses no es Haiku en solitario ni Sonnet en solitario, sino un ruteo explícito entre ambos. La aplicación decide, antes de invocar al modelo, qué complejidad tiene la tarea y envía a Haiku 4.5 los casos ligeros y a Sonnet 4.5 los casos que requieren razonamiento denso. Ese ruteo se puede hacer con reglas sencillas basadas en metadatos, con un clasificador previo que es a su vez una llamada a Haiku, o con estrategias adaptativas que aprenden del histórico.
Un ejemplo concreto: un sistema de atención al cliente que recibe diez mil conversaciones al día. El setenta por ciento son consultas repetitivas cubribles con Haiku 4.5 más base de conocimiento; un veinte por ciento son casos ambiguos que se benefician de Sonnet 4.5; un diez por ciento son casos críticos o muy complejos donde incluso conviene Opus 4 o escalado a humano. Este ruteo en tres niveles reduce el coste total respecto a usar siempre Sonnet en un factor de cuatro, manteniendo calidad equivalente porque cada caso va al modelo adecuado.
El coste del ruteo, si se hace con Haiku como clasificador inicial, es marginal frente al ahorro de no invocar Sonnet de forma indiscriminada. La complejidad añadida en el código es manejable con librerías estándar de orquestación de agentes, y el mantenimiento es sostenible si se documenta bien la lógica de clasificación. Es una inversión que se amortiza en semanas para cualquier sistema con volumen significativo.
from anthropic import Anthropic
client = Anthropic()
def route_task(prompt: str, complexity: str) -> str:
model = {
"simple": "claude-haiku-4-5",
"medium": "claude-sonnet-4-5",
"critical": "claude-opus-4",
}.get(complexity, "claude-haiku-4-5")
resp = client.messages.create(
model=model,
max_tokens=1024,
messages=[{"role": "user", "content": prompt}],
)
return resp.content[0].textCuándo compensa
La decisión de adoptar Haiku 4.5 como caballo de batalla de un sistema agéntico se simplifica si se responden tres preguntas honestamente. Primera, qué porcentaje de las peticiones son tareas estructuradas donde la instrucción es clara y la salida está bien acotada. Si es más del sesenta por ciento, Haiku 4.5 debe ser el modelo por defecto, con escalado selectivo a Sonnet. Si está por debajo, quizá no compense el esfuerzo de introducir ruteo.
Segunda pregunta, cuál es el volumen mensual real del sistema. Por debajo de unas decenas de miles de peticiones al mes, la diferencia de coste entre Haiku y Sonnet es ruido en la factura total, y no justifica la complejidad del ruteo. Por encima de cien mil peticiones, el ahorro empieza a ser significativo y pagar el coste de ingeniería del cambio tiene sentido. En el millón mensual, el ahorro anual financia un ingeniero a tiempo completo.
Tercera pregunta, qué tolerancia hay a una pequeña pérdida de calidad en los casos borderline. Haiku 4.5 no es peor que Sonnet en sus casos fuertes, pero en los casos intermedios a veces produce respuestas aceptables donde Sonnet produce respuestas óptimas. Si el negocio tolera esa diferencia, el ahorro está disponible. Si cada respuesta tiene que ser la mejor posible, el modelo grande sigue siendo la elección correcta y Haiku queda para tareas auxiliares internas.
Mi lectura
Claude Haiku 4.5 no es el modelo que genera titulares, pero es el que más ha cambiado la economía de los sistemas basados en LLM desde su publicación en octubre de 2025. En 2026, cualquier equipo que despliegue agentes o pipelines de procesamiento con volumen significativo debería tener Haiku 4.5 en su arquitectura de primera línea, no como opción de segunda para casos triviales, sino como caballo principal con escalado selectivo a Sonnet 4.5 o Opus 4 solo cuando la tarea lo justifique.
La lección general es conocida pero conviene repetirla: usar el modelo más grande disponible para todo es caro y frecuentemente innecesario. La disciplina de diseñar arquitecturas por capas, donde cada petición encuentra el modelo adecuado, es lo que separa los equipos que operan con márgenes sanos de los que viven ahogados por la factura mensual de inferencia. Haiku 4.5 hace esa disciplina más fácil y más rentable que nunca; aprovecharlo es cuestión de diseño, no de tecnología.
