¿Haiku 5.5 y esfuerzo bajo en Claude Code 2.1.295 realmente ahorran?

Las versiones de octubre de Claude Code trajeron cambios importantes para quienes corren tareas sin supervisión mediante claude -p. Entre la 2.1.292 y la 2.1.295, la herramienta fijó Haiku 5.5 como modelo por defecto para ese alias, permitió ajustar el nivel de esfuerzo en subagentes y añadió la opción de bloquear operaciones si falla un hook. Sin embargo, un análisis publicado en la plataforma japonesa Zenn muestra que recortar a ciegas puede salir bastante más caro de lo planeado.

El problema central es la tensión entre recortar gasto y mantener la calidad del resultado. Por un lado, muchos buscan bajar costos usando Haiku 5.5 y configurando effort en low para automatizaciones en segundo plano. Suena lógico sobre el papel, pero en tareas complejas como redacción o análisis profundo, un esfuerzo bajo puede hacer que el agente termine antes de tiempo o ignore instrucciones estrictas. La empresa del reporte advierte que hacer tres intentos fallidos con un modelo barato termina costando más que una sola ejecución bien hecha con un modelo superior.

A mí me parece que la tentación de poner todo en modo económico es una trampa común. Si tu script falla o entrega un resultado mediocre que requiere reintentos, el supuesto ahorro desaparece de inmediato. Donde sí tiene todo el sentido usar Haiku 5.5 con esfuerzo bajo es en tareas mecánicas de lectura y extracción, como armar reportes matinales de estado o consultar métricas de ventas.

Además, el reporte reveló sorpresas desagradables con el gasto real: consultas tan simples como calcular dos más dos llegaron a costar entre 0,27 y 0,47 dólares, debido a unos 41.000 tokens de caché acumulados. Para evitar sorpresas, recomiendan leer total_cost_usd en la salida JSON en lugar de asumir tarifas fijas, y limitar las corridas con --max-budget-usd 3.

En cuanto a seguridad, la versión 2.1.295 incorporó onFailure: "block", una función clave para hooks de comando y HTTP. Si el script del hook da error o agota el tiempo, la acción se frena en seco, evitando desastres como un push forzado accidental a ramas principales.

¿Prefieres forzar modelos ligeros con esfuerzo bajo en tus scripts desatendidos o mantienes modelos más capaces para asegurar la tarea al primer intento?

Fuentes: Zenn · Anthropic / GitHub