INTRODUCTION
Una factura del modelo más baja no termina el trabajo
Un modelo más barato puede volver viable una función útil. También puede hacer que una función poco útil genere más trabajo para todos. La decisión de producto consiste en saber si el menor costo de generación mejora un resultado que las personas realmente necesitan, incluyendo la revisión, las correcciones y el soporte.
Anthropic lanzó Claude Haiku 5.5 el 7 de octubre de 2026, orientándolo a tareas acotadas y de gran volumen, mientras mantiene modelos más potentes para trabajos difíciles. Eso invita a revisar las tareas del producto, en lugar de reemplazar automáticamente su modelo en todas partes.
Leé el precio y después cambiá la unidad
Verificado el 9 de octubre: Claude Platform publica tarifas de entrada/salida de Haiku 5.5 de USD 0,10/0,50 por millón de tokens para prompts de hasta 100.000 tokens, y USD 0,50/2,50 por encima. El precio de tokens no equivale al costo de una tarea terminada. Contabilizá aparte caché, herramientas y otros cargos aplicables.
Un equipo de producto necesita otra unidad: costo por resultado aceptado. Un resumen que un agente de soporte debe reescribir no equivale a uno que puede usar con confianza. Una etiqueta que envía un expediente al destino equivocado no es una ganga solo porque fue barata de generar.
Un método práctico consiste en dividir los costos del modelo, las herramientas, la revisión y las correcciones por la cantidad de resultados que cumplen un criterio de aceptación definido de antemano. Registrá por separado el tiempo transcurrido y los errores graves. Un promedio bajo no debería ocultar un fallo poco frecuente con consecuencias inaceptables.
La cola de revisión puede comerse el ahorro
Imaginemos una función interna de resúmenes. Es un ejemplo hipotético, no un resultado de un cliente de Blanche ni una prueba comparativa de modelos. Procesa 1.000 documentos. El equipo presupuesta USD 20 de generación y 100 minutos de revisión, valorados internamente a USD 30 por hora. El costo conjunto es de USD 70.
Supongamos que otra configuración baja la generación a USD 5, pero duplica la revisión a 200 minutos. El total pasa a USD 105. Este ejemplo no predice el rendimiento de ningún modelo. Solo muestra por qué una factura de API menor no demuestra que el proceso completo sea más barato. Estos totales ilustrativos excluyen alojamiento, impuestos, soporte e integración.
El diseño importa tanto como el modelo. Mostrá los pasajes originales junto al resumen. Facilitá la revisión de campos dudosos. Permití corregir un elemento sin reiniciar toda la tarea. Comprobá si estos cambios reducen el tiempo de revisión antes de aumentar el volumen generado.
Dale una tarea más pequeña al modelo pequeño
Una primera prueba razonable consiste en una etapa delimitada cuya respuesta pueda comprobarse: clasificar una solicitud, extraer un campo definido o preparar un resumen breve para revisar. Dejá claros los datos de entrada, la salida permitida y qué ocurre si algo falla.
Eso no exige una colección complicada de agentes. En un producto hipotético de atención al cliente, la primera versión podría distribuir solicitudes entre unas pocas colas existentes y derivar los casos ambiguos a una persona. No debería empezar a aprobar reembolsos silenciosamente solo porque el mismo modelo puede redactar una respuesta convincente.
Generar más no crea automáticamente más valor. Si el equipo solo puede revisar diez sugerencias, producir cien puede crear trabajo pendiente. Quizá convenga usar el ahorro para responder antes, añadir una segunda revisión en casos riesgosos o ofrecer una función que antes resultaba demasiado costosa.
A veces el modelo más potente es la opción más simple
Distribuir trabajo entre modelos añade mantenimiento, evaluaciones y otro lugar donde pueden esconderse errores. Para un producto de poco volumen o una tarea que exige razonamiento prolongado, un único modelo más potente puede ser la alternativa más económica en conjunto. La opción barata tiene que ganarse su lugar con resultados observados, no con su posición en una tabla de precios.
Por eso una demostración pulida no alcanza. Probá casos habituales, entradas ambiguas y fallos conocidos con los mismos criterios de aceptación. Contá las derivaciones y los reintentos. Revisá los errores concretos, no solo una tasa de éxito general. Conservá una forma de volver a la configuración anterior mientras probás un despliegue limitado.
Antes de cambiar la opción predeterminada
- Definí el resultado que necesita el cliente y qué significa que sea aceptable.
- Establecé una referencia de costos, espera, esfuerzo de revisión y gravedad de los errores.
- Compará las mismas tareas representativas, incluidos los casos difíciles.
- Incluí llamadas a herramientas, reintentos, correcciones y mantenimiento en la decisión.
- Ampliá el uso solo cuando mejore el proceso completo sin fallos inaceptables.
La baja del costo de inferencia abre espacio para diseñar mejores productos. La pregunta útil es cómo aprovecharlo. Para decidir qué construir después, empezá por el producto y sus usuarios, y elegí el modelo que haga funcionar toda la experiencia.