Un modelo puede devolver una respuesta barata y aun así crear trabajo caro. Alguien tiene que comprobarla, repetir la petición cuando falla y reparar lo que pasó inadvertido.
Un error barato sigue siendo un error, y alguien acaba recibiendo la factura.
Los precios anunciados de Haiku 5.5 invitan a calcular cuánto costaría un resultado aceptable en una rutina concreta. La cuenta empieza en los tokens y continúa por cada corrección necesaria hasta que la respuesta pueda utilizarse.
Anthropic anunció Claude Haiku 5.5 el 7/10/2026. API, entrada/salida por millón de tokens: US$0,10/0,50 hasta 100.000 tokens de prompt; US$0,50/2,50 por encima. Disponible en Claude Platform, AWS, Google Cloud y Azure. Las lecturas de caché de Sonnet 5.5 cuestan la mitad. Fuente: Anthropic.
Definir cuándo está terminado
Pensemos en un sistema hipotético que distribuye informes de errores entre equipos. Una categoría resulta convincente en pantalla; la prueba es saber si dirige el informe al equipo correcto. Conviene preparar la evaluación con ejemplos de respuesta conocida, incluidos casos que encajan en varios departamentos y otros que necesitan la decisión de una persona.
Antes de cambiar el modelo, conviene definir la regla de aceptación. Una respuesta con JSON válido puede ser obligatoria; el formato apenas explica si los valores son correctos. Hay que contrastarlos con la evidencia original y decidir cuándo el sistema debe pedir ayuda. Una duda reconocida puede resultar más sencilla de resolver que una respuesta convincente almacenada silenciosamente en una base de datos.
Suma la primera llamada, los reintentos, las derivaciones y la revisión humana necesaria. Divide el gasto entre los resultados aceptados y presenta los casos sin resolver por separado. De lo contrario, el coste por tarea terminada oculta cuánto trabajo ha dejado pendiente el sistema.
Lo que acompaña a cada petición
Pensemos en un asistente hipotético que recibe toda la conversación en cada petición, incluidos planes descartados y errores anteriores. Cada tarea nueva hereda ese desorden. Una prueba útil compararía ese método con una selección cuidadosa de evidencias y un registro breve de decisiones, comprobando que la versión reducida conserva la información necesaria para responder correctamente.
Recortar a ciegas también puede generar trabajo extra. Una excepción, una fecha o una instrucción eliminada puede obligar a reparar la siguiente respuesta. Conviene medir el tamaño del contexto junto con la calidad y conservar ejemplos donde el detalle omitido cambia el resultado. El objetivo es proporcionar un material de trabajo manejable y suficientemente completo.
La caché necesita cuentas basadas en su reutilización real. Un bloque estable de instrucciones puede aprovecharse muchas veces; un documento que cambia constantemente quizá ofrezca menos ocasiones. Hay que registrar qué se almacena, qué se reutiliza y qué peticiones quedan fuera de ese beneficio. También conviene revisar las condiciones del proveedor elegido antes de convertir una tarifa anunciada en el coste efectivo del servicio.
Define el límite de reintentos antes de aumentar el volumen. En el ejemplo de los errores, una clasificación dudosa podría pasar a revisión al alcanzar ese límite. Conserva el motivo de la derivación: varios fallos en la misma categoría pueden revelar información ausente o una tarea que necesita redefinirse. Otra instrucción no siempre lo resolverá.
Mantén el gasto total junto al coste por tarea. Las llamadas más baratas facilitan añadir nuevos trabajos; una reducción por petición puede coexistir con una factura mayor. Quizá merezca la pena, siempre que sea una elección tomada con las cifras delante.
Una prueba piloto responde a la pregunta que deja abierta la tabla de precios. Compara el candidato con el proceso actual, revisa los resultados aceptados y examina los casos que fallaron.
El dato más útil del panel es cuánto cuesta el trabajo que realmente se puede aceptar.
¿Tienes otro punto de vista? Quiero escucharlo. hello@maisfps.com
