Claude Haiku 4.5 vs Claude Opus 5: cuándo una prima de coste puede justificar un mejor resultado

La decisión no es qué modelo es mejor, sino qué resultado compra cada flujo

Claude Haiku 4.5 y Claude Opus 5 cubren necesidades operativas distintas dentro de la oferta de Anthropic. Una comparación útil para producto, ingeniería y operaciones no puede limitarse a declarar que uno tiene más capacidad o que otro cuesta menos por token. La unidad de decisión debe ser la tarea aceptada: una salida que cumple requisitos funcionales y de calidad sin una corrección humana que cambie sustancialmente su contenido.

El precio por token sigue siendo relevante, porque condiciona el coste marginal, pero no resume el coste de producción. Una respuesta barata puede resultar más cara si obliga a repetir solicitudes, validar formatos, corregir omisiones o escalar casos al equipo experto. Del mismo modo, una respuesta de mayor coste inicial puede estar justificada cuando evita un fallo de cumplimiento, reduce de manera verificable los rechazos o resuelve una revisión que de otro modo requeriría intervención especializada.

No se han aportado ejecuciones, corpus, registros de tokens, mediciones de latencia ni evaluaciones humanas del ensayo descrito. Por tanto, este artículo no presenta una clasificación empírica de ganadores ni atribuye porcentajes de calidad a los dos modelos. Presenta un método para producir esa evidencia y una matriz de decisión condicional. Cualquier conclusión sobre superioridad en una tarea concreta deberá quedar supeditada a los resultados publicados bajo ese método.

La documentación oficial disponible indica diferencias materiales que afectan al diseño del ensayo. Entre ellas figuran una ventana de contexto mayor para Opus 5 que para Haiku 4.5, capacidades y configuraciones de razonamiento que han de registrarse, y condiciones de precio que pueden variar según el canal, la modalidad y los mecanismos de caché. Esas diferencias son parte de la decisión real, pero también pueden convertir una prueba aparentemente simétrica en una prueba injusta si no se declaran.

Qué debe mantenerse constante y qué debe registrarse

La comparación debe comenzar con un protocolo congelado antes de ejecutar solicitudes. El corpus ha de tener una versión identificable, sin elementos añadidos durante la evaluación. También deben permanecer constantes, cuando sean compatibles con ambos modelos, el mensaje de sistema, la instrucción de tarea, los documentos adjuntos, las herramientas disponibles, el esquema de salida, el límite de salida y la política de reintentos.

La igualdad literal de parámetros no siempre equivale a igualdad funcional. Si un modelo tiene opciones de razonamiento, esfuerzo o salida estructurada con semánticas distintas, el protocolo debe describir la configuración de cada brazo y explicar por qué representa un uso de producción razonable. No conviene desactivar una capacidad esencial de un modelo solo para conseguir simetría nominal; tampoco conviene activar capacidades en un solo brazo sin informar de su impacto en calidad, latencia y facturación.

Para cada ejecución deben guardarse los identificadores exactos de modelo, la fecha y hora, la región o residencia de datos aplicable, el proveedor o canal de API, los parámetros, el identificador del caso, la respuesta completa, el motivo de terminación, los tokens facturados y la latencia de extremo a extremo. El estado activo de un nombre comercial no basta: los snapshots o identificadores concretos son necesarios porque los modelos pueden actualizarse o retirarse.

La ventana de contexto merece una regla explícita. Si todos los casos caben dentro del límite de Haiku 4.5, ambos modelos pueden procesar el mismo expediente sin truncamiento. Si algunos casos exceden ese límite y caben en Opus 5, hay dos evaluaciones válidas pero distintas: una comparación en un subconjunto común y una evaluación operativa que reconozca que Haiku necesita fragmentación, recuperación documental u otro mecanismo auxiliar. Ocultar esa diferencia haría que el resultado fuese difícil de interpretar.

Prueba 1: clasificación con reglas y extracción estructurada

La primera carga de trabajo debe representar operaciones donde el volumen y la consistencia son importantes: enrutar tickets, etiquetar documentos, extraer campos de formularios o determinar si un caso cumple condiciones explícitas. El conjunto debe incluir ejemplos ordinarios, entradas incompletas, categorías limítrofes, contradicciones internas y casos que deban rechazarse por evidencia insuficiente.

La evaluación no debe reducirse a comprobar que la respuesta parece razonable. Debe medir exactitud por campo, coincidencia de la clasificación, validez sintáctica de la salida, conformidad con el esquema y rechazo correcto. En particular, un JSON válido que inventa un valor requerido no debe puntuar como éxito. Si el flujo de producción permite una reparación automática tras un error de esquema, esa reparación debe registrarse como reintento y entrar en el coste.

Las guías de prompting aportadas recomiendan concretar el formato de salida y emplear salidas estructuradas o herramientas con valores enumerados para tareas de clasificación. Esto favorece un diseño donde el modelo no tenga que adivinar la forma de la respuesta. Sin embargo, no elimina la necesidad de validar los valores frente a las fuentes de cada caso.

En esta tarea, Haiku 4.5 será una decisión racional si mantiene la tasa de aceptación acordada, su coste por caso aceptado es menor y sus fallos son detectables de forma determinista. Opus 5 estará justificado si reduce de forma suficiente los errores semánticos que no detecta el validador, los rechazos incorrectos o el trabajo humano de depuración. Esa conclusión solo puede obtenerse con datos de casos reales o representativos.

Prueba 2: síntesis fiel de documentación con evidencia interna

La segunda carga debe medir una habilidad distinta: transformar un conjunto documental en una síntesis que conserve los requisitos, condiciones, excepciones y desacuerdos relevantes. El objetivo no es premiar textos más largos ni una redacción más persuasiva, sino verificar que cada afirmación importante pueda vincularse a fragmentos del material proporcionado en el propio expediente.

El corpus debe mezclar documentos coherentes y documentos con vacíos o discrepancias. Debe incluir requisitos que aparecen en anexos, definiciones con alcance limitado, fechas o versiones incompatibles y peticiones que no se pueden responder con la evidencia disponible. Esto permite medir cobertura, omisiones críticas, atribuciones sin respaldo y el comportamiento ante incertidumbre.

Una rúbrica práctica separa cuatro dimensiones: cobertura de requisitos, fidelidad de las atribuciones, tratamiento de conflictos y utilidad de la estructura final. Los evaluadores deben disponer de una respuesta de referencia o de una lista de proposiciones comprobables, pero la revisión de calidad debe ser ciega respecto al modelo. Cuando la síntesis declare incertidumbre de forma correcta, no debe penalizarse por no resolver una ambigüedad que existe en las fuentes.

El mayor contexto anunciado para Opus 5 puede ser relevante cuando el expediente completo no cabe en el límite de Haiku 4.5. Aun así, no debe asumirse que una ventana de contexto mayor equivale automáticamente a una síntesis más fiel. La prueba tiene que separar los beneficios de procesar más documentación de los beneficios derivados del comportamiento del modelo. Para ello, conviene medir tanto un subconjunto común como los expedientes extensos que requieren una estrategia adicional con Haiku.

Prueba 3: revisión compleja con instrucciones conflictivas

La tercera prueba debe representar cambios técnicos, expedientes de cumplimiento, revisiones de políticas o propuestas operativas donde las instrucciones tienen restricciones múltiples y parcialmente enfrentadas. El modelo debe detectar conflictos, priorizar restricciones definidas por el protocolo y explicar qué información falta para emitir una recomendación segura.

Los casos han de contener restricciones de distinto tipo: requisitos funcionales, compatibilidad, seguridad, plazos, límites de modificación y condiciones de aprobación. Es importante incluir conflictos deliberados, pero no instrucciones maliciosas ni datos que no puedan evaluarse responsablemente. La respuesta esperada no tiene por qué ser una solución completa: en algunos casos, el resultado correcto será identificar un conflicto, abstenerse de recomendar una acción o escalar la decisión a una persona responsable.

La evaluación debe valorar cumplimiento de restricciones, detección de incompatibilidades, precisión de las recomendaciones y necesidad de escalado humano. La utilidad no equivale a aceptar sin reservas una propuesta. Una recomendación que parece decisiva pero ignora una prohibición explícita es peor que una respuesta que delimita su incertidumbre y solicita la autorización necesaria.

Esta es la carga donde una prima de capacidad podría generar más valor, porque el coste de un error puede ser alto y la validación automática suele ser incompleta. Pero tampoco cabe deducir que Opus 5 deba utilizarse siempre. Si los casos se descomponen en verificaciones independientes, si las reglas están codificadas y si la revisión humana ya es obligatoria, un modelo más económico puede ser suficiente como primera capa. El ensayo debe medir la combinación de modelo, validadores y revisión, no el modelo aislado en un vacío.

Cómo calcular el coste por tarea correctamente completada

El indicador central es el coste efectivo por resultado aceptado. Su numerador suma el importe de las solicitudes necesarias para completar el conjunto de casos: tokens de entrada y salida, uso de caché cuando aplique, tokens asociados al razonamiento si son facturables, reintentos automáticos y llamadas auxiliares imprescindibles. Si el flujo incluye revisión humana, debe añadirse el coste definido para esa revisión, con una tarifa y una regla temporal declaradas.

El denominador no es el número total de solicitudes ni el número de respuestas que devuelven texto. Es el número de casos aceptados bajo la rúbrica. Cuando haya una edición humana menor permitida, el protocolo debe especificar qué significa menor. Por ejemplo, una corrección de puntuación podría seguir contando como aceptada con edición; añadir un requisito omitido o retirar una afirmación sin respaldo debe contar como modificación sustancial.

También es necesario publicar la mediana y un percentil alto de latencia de extremo a extremo, no solo el promedio. Los promedios pueden ocultar colas de espera que afectan a interfaces interactivas o acuerdos de nivel de servicio. La latencia debe medirse desde que el cliente envía la solicitud hasta que recibe y valida la salida, y debe informar si incluye reintentos y herramientas.

Las tarifas oficiales y los modificadores de precio requieren una captura fechada del canal usado. Una comparación de terceros puede servir como contexto metodológico, pero no sustituye el registro de facturación del ensayo: puede referirse a configuraciones de razonamiento o esfuerzo diferentes de las elegidas aquí. Las conclusiones económicas deben limitarse a la modalidad realmente medida.

Matriz de decisión y límites de la evidencia

La elección final debería ser por flujo, no por organización completa. Clasificaciones de gran volumen y bajo impacto, con esquemas estrictos y validadores sólidos, son candidatas a Haiku 4.5 si la prueba confirma una tasa de aceptación suficiente. Síntesis de expedientes que caben en el contexto común también pueden empezar por Haiku cuando las omisiones sean detectables mediante revisión proporcional. En ambos casos, el ahorro solo es real si no reaparece como reintentos o revisión humana.

Opus 5 merece evaluación prioritaria en expedientes que necesitan una ventana de contexto superior, revisiones con restricciones interdependientes o tareas en las que un fallo semántico sea costoso y difícil de detectar automáticamente. Aun en esas situaciones, la decisión debe depender de la diferencia observada en aceptación y coste total, no de la denominación del modelo o de un benchmark que use otro corpus.

Los resultados tendrán límites de transferencia. Un corpus interno, una plantilla concreta, una lengua, una región, un canal de acceso y una política de reintentos pueden alterar el resultado. Las ejecuciones deben repetirse después de cambios de snapshot, precios, límites o mecanismos de producto. La documentación de deprecaciones es especialmente relevante para no mantener conclusiones basadas en identificadores retirados.

La incertidumbre principal de esta comparativa es empírica: las fuentes aportadas describen capacidades, precios y condiciones de plataforma, pero no contienen el resultado de las tres pruebas propuestas. Hasta que se publique un conjunto de mediciones reproducibles, la recomendación correcta es implementar una prueba limitada, establecer umbrales de aceptación y desplegar por niveles de riesgo.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.