Claude Haiku 4.5: cómo operar un carril de baja latencia tras Haiku 3.5 sin confundir conservación mínima con continuidad garantizada

El problema no es elegir un modelo pequeño: es preservar un contrato operativo

La retirada de Claude Haiku 3.5 obliga a revisar más que la calidad aparente de las respuestas. Anthropic documenta que el identificador de Haiku 3.5 dejó de estar disponible el 19 de febrero de 2026 y recomienda Claude Haiku 4.5 como sustituto. Esa recomendación convierte a Haiku 4.5 en un candidato razonable para evaluar, pero no demuestra que sea intercambiable en una aplicación concreta.

Para un equipo que clasifica solicitudes, extrae campos, asiste a una persona en tiempo real o ejecuta subagentes de alcance limitado, el producto no consume solamente un modelo. Consume una combinación de identificador, proveedor de acceso, región o endpoint, SDK, parámetros de generación, prompt de sistema, herramientas, validador, política de reintentos y presupuesto de tiempo. Cambiar cualquiera de esas piezas puede alterar el resultado observado.

Por ello, la unidad de migración debe ser el flujo completo. Un cambio que mantiene la precisión media, pero incrementa el tiempo de cola o la proporción de documentos que requieren reparación de JSON, puede empeorar el servicio. Del mismo modo, una respuesta más rápida del modelo no garantiza una mejor latencia extremo a extremo si el canal elegido, la herramienta externa o un reintento consume el margen disponible.

Este análisis se centra en si Haiku 4.5 puede sostener un carril rápido controlable. No pretende establecer que sea superior a un modelo de mayor capacidad ni extrapolar resultados de benchmarks a una carga de producción. La evidencia decisiva para esa decisión procede de pruebas reproducibles del equipo sobre su tráfico, sus esquemas y sus dependencias.

Estado de ciclo de vida: una fecha mínima no es una promesa abierta

La documentación de deprecaciones de Anthropic lista `claude-haiku-4-5-20251001` como activo en la API directa y señala que su retirada no ocurrirá antes del 15 de octubre de 2026. La formulación importa: establece un límite inferior de conservación, no una fecha de retirada confirmada ni una garantía de disponibilidad posterior a ese día.

En consecuencia, a la fecha de referencia del 22 de septiembre de 2026, el identificador puede considerarse disponible según la documentación aportada, pero debe tratarse como una dependencia con horizonte de revisión cercano. Un sistema que traduzca «no antes de» por «seguirá disponible» estaría incorporando una suposición no respaldada por esa fuente.

Google Cloud también muestra una fecha mínima de retirada del 15 de octubre de 2026 para Claude Haiku 4.5 en su catálogo de partner models. La coincidencia de una fecha mínima entre canales no elimina la necesidad de consultar el estado específico de cada integración. El identificador expuesto, las regiones habilitadas, la capacidad y la política de soporte pertenecen al canal de acceso, no sólo al modelo.

La incertidumbre principal no es semántica: las fuentes aportadas no confirman una fecha final de retirada para Haiku 4.5. Tampoco aportan una reserva de capacidad para cada cuenta, región o modalidad de invocación. Por tanto, el plan debe contemplar tanto un aviso formal de ciclo de vida como una degradación operativa de un canal antes de que exista una retirada anunciada.

La definición de un carril rápido debe incluir cola, validación y abandono

Una métrica aislada de generación es insuficiente. Para interacciones que afectan a una pantalla, una automatización síncrona o una decisión en línea, conviene medir desde que el servicio recibe la petición hasta que la aplicación devuelve una respuesta utilizable. Ese intervalo incorpora serialización, red, espera en cola, primer byte o primer token, generación, llamadas de herramientas, validación, reparación y entrega.

El tablero mínimo debe separar latencia hasta el primer token de latencia total. La primera aproxima la capacidad de comenzar una respuesta en streaming; la segunda determina cuándo el usuario o proceso puede actuar. Ambas deben analizarse por percentiles, al menos p50, p95 y p99, y por tipo de carga. Una media baja puede ocultar una cola de casos lentos que agota los tiempos de espera.

También debe medirse la proporción de salidas aceptadas en el primer intento. Para extracción estructurada, la señal útil no es que el modelo produzca texto con apariencia de JSON, sino que el objeto parsea, satisface el esquema y supera las reglas de negocio. Para herramientas, la señal es que la llamada sea válida, autorizada, ejecutable y que el resultado se incorpore sin bucles o efectos duplicados.

Atribuir el fallo es igual de importante que contarlo. Un aumento de tiempo puede proceder del modelo, de la ruta de red, de un límite de tasa, del SDK, de una herramienta externa o del validador. Si los registros no conservan el canal, región, versión solicitada, duración de cada fase y motivo del reintento, la organización no podrá decidir qué revertir.

Pruebas de regresión: evaluar tareas, no una puntuación agregada

La evaluación debe usar un corpus congelado y representativo, complementado con tráfico sombreado cuando sea seguro. El corpus debe incluir entradas breves y largas, casos frecuentes y límites conocidos, idiomas relevantes, documentos con estructura irregular y condiciones que activen herramientas. Conviene versionarlo junto con el prompt, el esquema, el validador y el código de evaluación.

En clasificación, mida la concordancia con una referencia revisada y el coste de falsos positivos y falsos negativos por categoría. En extracción, mida campos correctos, omisiones, alucinaciones de valores y aceptación completa del esquema. En respuestas breves fundamentadas, defina qué fuentes o datos de entrada deben aparecer y cómo se penaliza una afirmación no sustentada por ese contexto.

Los subagentes requieren un tratamiento especial. Su éxito no se limita a una respuesta final plausible: incluye el número de pasos, las invocaciones de herramientas, el cumplimiento de permisos, la detención al completar el objetivo y la ausencia de cambios duplicados. Ejecute primero en modo sin efectos o contra recursos de prueba. No permita que una comparación de modelos escriba en sistemas de producción.

Anthropic identifica Haiku 4.5 entre los modelos con conciencia de contexto en sus orientaciones de prompting. Esto puede ser relevante al adaptar plantillas y variables, pero no sustituye la regresión. La forma del prompt, las instrucciones de salida y el comportamiento de las herramientas siguen siendo propiedades que el equipo debe comprobar en el flujo implementado.

El canal cambia la operación: API directa, Amazon Bedrock y Vertex AI

No debe asumirse que el nombre comercial del modelo implica una interfaz idéntica. La API directa de Anthropic documenta el identificador fechado `claude-haiku-4-5-20251001`. En Amazon Bedrock, la documentación proporcionada describe identificadores de inferencia regionales, geográficos y globales, además de disponibilidad por regiones y endpoints. Esa distinción puede afectar a la selección de ruta y a la observabilidad que debe conservar la aplicación.

En Google Cloud, la ficha de Claude Haiku 4.5 usa el ID `claude-haiku-4-5`, enumera entrada de texto, imágenes y PDF, salida de texto, funciones, prompt caching, extended thinking y predicciones por lotes. También indica las regiones `us-east5`, `europe-west1` y un endpoint global. Estas capacidades documentadas no deben interpretarse como una obligación de activarlas ni como igualdad de configuración con la API directa.

El material de Google Cloud sobre endpoints multirregión explica una diferencia operativa relevante: los endpoints globales, multirregión y regionales suponen elecciones distintas en residencia de datos, cuota, resiliencia y perfil de latencia. Por tanto, una prueba desde un endpoint global no responde por sí sola qué ocurrirá si el servicio de producción exige una región concreta o restricciones de residencia.

La comparación entre canales debe incluir autenticación, límites efectivos, formatos de solicitud y streaming, trazabilidad, política de errores y soporte de retirada. La fuente de Amazon Bedrock confirma que existen variantes de identificador y rutas de inferencia; no basta para afirmar el rendimiento de una cuenta concreta. De igual modo, las capacidades enumeradas por Google Cloud no prueban que una modalidad esté habilitada en todas las organizaciones ni que su uso respete el presupuesto de latencia.

Despliegue controlado: doble ejecución, canary y reversión explícita

Un cambio de modelo debe empezar con inventario. Localice llamadas directas e indirectas, incluidos workers, integraciones de terceros, prompts embebidos, reglas de fallback y empleos por lotes. Para cada consumidor, registre el objetivo de servicio, la salida esperada, el canal, la región, el dueño técnico y el modelo alternativo. Sin este inventario, una retirada puede dejar rutas olvidadas que no aparecen en la prueba principal.

La doble ejecución sin efectos permite comparar resultados sin modificar el sistema de registro. Envíe una muestra representativa al flujo actual y a Haiku 4.5, aplique los mismos validadores y guarde diferencias anonimizadas cuando las obligaciones de datos lo permitan. Para subagentes, sustituya las herramientas de escritura por simuladores o ejecute contra entornos aislados.

Después, un canary debe exponer una fracción pequeña y reversible del tráfico real. Los umbrales de promoción y reversión deben acordarse antes del despliegue: por ejemplo, deterioro de percentiles, caída de aceptación de esquema, aumento de errores de herramientas o incremento de abandono. El valor numérico de cada umbral depende del flujo; no puede derivarse de la documentación de un proveedor.

El fallback no debe ser una etiqueta configurada pero nunca probada. Debe tener capacidad, permisos, plantilla compatible, límites conocidos y una ruta de activación con responsable. Pruebe tanto la conmutación manual como, si existe, la automatizada. Mida cuánto tarda en activarse y qué solicitudes quedan en curso durante el cambio.

Plan de salida: desacoplar la aplicación de un identificador concreto

La mejor preparación ante un cambio de ciclo de vida es una frontera de aplicación estable. El resto del producto debería pedir una operación —clasificar, extraer, responder o ejecutar una herramienta permitida— y no conocer el identificador específico del modelo. Un adaptador puede traducir esa operación a los formatos de cada canal, normalizar eventos de streaming y aplicar un validador común.

Ese desacoplamiento no exige fingir que todos los modelos son iguales. El contrato debe exponer diferencias que importen: modalidades admitidas, longitud y estructura de salida, política de herramientas, posibilidad de streaming, tiempos máximos y comportamiento ante indisponibilidad. Las capacidades no compatibles deben fallar de forma explícita o activar una degradación conocida; no conviene silenciarlas con una conversión que cambie la semántica.

Conserve evidencia de cada cambio: versión de prompts, corpus de prueba, resultados segmentados, configuración del canal, fechas de ejecución, incidencias y decisión de aceptación. Este expediente permite distinguir una regresión posterior del modelo de una modificación de prompt, SDK, red o validador. También reduce el tiempo de respuesta si el proveedor anuncia una retirada o si un endpoint deja de cumplir el presupuesto operativo.

La conclusión es condicional. Haiku 4.5 dispone de documentación que lo presenta como reemplazo de Haiku 3.5 y como opción disponible en los canales examinados. Sin embargo, sólo una evaluación de extremo a extremo puede demostrar que mantiene un carril rápido para una organización concreta. La fecha mínima de conservación debe usarse como plazo para terminar esa evaluación y ensayar una salida, no como motivo para posponerla.

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.